Dev Chat on Open JVM Integration PostponedThursday December 9th, 1999Our planned developer chat, a Q&A on OJI with Ed Burns, has been postponed due to problems with network connections on the east coast. If you're interested in knowing more about OJI and its progress, be sure to stop by Mozilla.org's OJI pages. We will be posting a new chat schedule soon, and this chat will be rescheduled then. Also, our XPCOM chat with Suresh Duddi and Scott Collins from last week has been rescheduled for next Friday, December 17th, at 3:00pm PST. Too bad I'm going to miss it. If anyone's listening, please put the log of it on MozillaZine. Thanks. Someone be sure to ask him what the status of Open JVM Intergration for Linux is, and what JVM are available (going to be available) for Linux Mozilla. Thanks again. I'm not going to be able to attend, either, but please ask whether current JREs for Linux (such as Blackdown, IBM) can be used with Mozilla and if it will be possible to use non-Java VMs through the OJI and, if so, how language detection will be done. 1) at work i live behind a strict firewall with no IRC access. you might want to look into supporting the javasoft developer's connection chat applet which works over HTTP. 2) will mozilla's javascript implementation be rhino (javascript in java)? and ditto for ns v5? if not, how tightly will the two be integrated? 3) will mozilla augment the java security system in any way? e.g. the management of certs, the management of permissions, etc? 4) how will mozilla's cache be integrated with java? will the user get some control over the caching of .class and .jar files? will the provider of .class and .jar files have a way to request specific cache behavior? >2) will mozilla's javascript implementation be rhino (javascript in java)? and ditto for ns v5? if not, how tightly will the two be integrated? I can tell you right now that's not the case. Jazilla (which is moving to sourceforge.com, because of server failures) uses Rhino for Javascript, but Rhino is Javascript in Java; that means it's probably a tad slow for use in a rendering engine that actually displays the entire app. It's a darn good package; it's probably just not quite fast enough (it's great for pure Java stuff, but combined with C++ stuff it might seem odd). actually i remember seeing in netscape's demo of rhino that the java javascript engine was actually -faster-, although i forget the exact reasons for it... That's because it has two modes. In the interpreted mode, it's *WAY* slower than the C/C++ version of the engine. In compiled mode, where everything is actually Java when it runs, it's somewhat faster than the C/C++ counterpart. I don't have any numbers on how long compiling takes etc.. Using compiled mode in a browsing environment is probably not an option. |