Hi. This is Josh from the JavaFX team at Sun (posting from my gmail account). I'd like to correct a few things you got wrong here:
> 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.) This is true. One JVM is shared by all applets. > 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? This is incorrect . There will still be a single JVM instance shared by all applets, regardless of the tab or page it is one (with a few specific exceptions). This is a core feature of the new applet plugin in JavaSE 6 update 10. > 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. Which will be great, especially if they encourage adoption of of JavaSE 6 update 10, as Chrome requires. > 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. Since one VM will be used (with appropriate protection between applets), the cost of the VM will be amortized across the tabs, thus making Java based frameworks (like JavaFX) more efficient. > 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 are you are saying 'the JVM' what you really mean is the JRE, Java Runtime Environment. It is the JVM (the Java virtual machine) plus all of the runtime libraries that make up the Java platform. The JVM is actually the smaller portion. Yes, the JRE is bigger than What MS, Adobe, and the browsers provide. But it also does a lot more. There are plusses and minuses. We are addressing the minuses, as I'll show below. In the plus category you can do far more in a JVM based app than you can in a Flash or Silverlight app, thanks to the rich API provided by the JRE and the huge ecosystem of Java libraries out there. > 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. We haven't missed the ball. These are all good ideas, which is why we are *already doing them* !. :) Let me tell you a bit more about JavaSE 6 update 10, and some of the future improvements in Java 7. Part of update 10 is a kernel installer. It will install just the bare minimum subset of Java required to run your typical Swing app. This is about 4MB, compared to the 10+ for the full install. This bare minimum will run a slower but smaller JVM and download just the parts of the runtime needed for your app. Then, in the background, it will continue to install the rest of Java, just as you suggest. Eventually you will have the exact same bits on disk as if you had done the traditional installer. (assuming it wasn't pre-installed when you bought your computer, which is becoming more common). So you can see, your idea is something we've been thinking about for a while and implemented for JavaSE 6 update 10. Good idea! There is a limit to how much optimization we can do with creative downloading, however. The JRE is a big and complex runtime with a lot of internal cross dependencies (there's far more to the JRE than just the public APIs). In Java 7 we are adding modules support and are beginning the process of modularizing the JRE. We are cutting the cross dependencies, making the JRE modular and subset-able. This is very exciting stuff that will ensure the JRE has a long and prosperous future. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
