Despite all the efforts to reformulate JavaSE into the so-called consumer JRE (quicker download time to where will start running something, improved browser plug-in, better modularized runtime library code, etc.), the Java JVM still remains an unsuitable runtime for web applications.
The JVM still has too much overhead and memory foot print - it adds 27MB to my Safari browser's memory foot print when I load the first page with a Java applet: http://java.com/en/download/help/testvm.xml Now Safari, and most existing browsers that support Java, will typically run Java applets on the same JVM instance. So the overhead of the JVM gets shared amongst all the applets. (I tested this by opening the above link in multiple tabbed pages and the memory spiked but went back down to the level it was at after loading the first applet instance.) Yet one of the architecture benefits of Google Chrome will be that it will run a tabbed page in its own process instance - for isolation and thus stability. This implies that the presence of a Java applet on a page would cause a new JVM instance to be spawned. Hmm - 20 to 30 MB overhead for every page an applet appears on? We can likely expect that Firefox, Opera, and even IE will copy-cat the process isolation feature from Google Chrome because it makes a lot of sense, bestowing true benefit to users. So assuming a trend toward process isolation of web pages, building RIA apps in GWT instead of JavaFX looks to be a more scalable approach. The Google Chrome JavaScript V8 runtime is going to be much more efficient when running multiple GWT apps in each its own tab session. For all kinds of reasons, really, Google had no choice than to go down the path of improving JavaScript vs expect they'd ever be able to build out the future of the web on top of the Java JVM. To expect that the JVM is a suitable runtime for web RIA is, alas, an idealistic fatalism. And when it comes to web RIA I don't see how the vaunted Java Hotspot VM can even be regarded as a crown jewel. It is fine for server apps and traditional desktop apps (NetBeans), but compared to V8, TraceMonkey, Silverlight CLR, and Flash Player runtimes, it doesn't compete. The JVM is too big and complex relative to those other runtimes - it doesn't have a suitable architecture for running web RIA. When starting down the path of the Consumer JRE and JavaFX, Sun should have also designed a new JVM that is suitable for the web. And they should have earmarked a subset of JavaSE that is specifically for sandboxed web apps. That would then constitute what would first load. A full JavaSE might then incrementally install at some point if the user were to run, say, Java web start app. These considerations were all very basic and rather apparent. I don't understand why Sun missed the ball by such a wide margin. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
