Mike Swingler (Apple JVM developer) said: http://lists.apple.com/archives/java-dev/2011/Jul/msg00041.html http://lists.apple.com/archives/java-dev/2011/Jul/ms

Mike Swingler (Apple JVM developer) said: http://lists.apple.com/archives/java-dev/2011/Jul/msg00041.html http://lists.apple.com/archives/java-dev/2011/Jul/msg00041.h... After a decade of shipping Java on the Mac and tricking old apps that hardcode paths to the 1.3.1 JVM, or putting in class loader hacks to fake out Xerces XML classes that were moved in 1.5.0, we are ready to try something different. In http://lists.apple.com/archives/java-dev/2011/Jul/msg00044.html http://lists.apple.com/archives/java-dev/2011/Jul/msg00044.h... What you loose in a per-app embedded model is shared memory mapping of the native libraries and .jar files, but this is the same problem as a half dozen apps embedding (often different) versions of the Sparkle.framework to do app self-updates. The cost of the JVM heap is still the same, and class-sharing was never ported to 64-bit by Sun, so that optimization hasn't been around for a long time on Macs. In http://lists.apple.com/archives/java-dev/2011/Jul/msg00038.html http://lists.apple.com/archives/java-dev/2011/Jul/msg00038.h... Long-term, we recommend that app developers who use the JavaApplicationStub should transition to embedding the Java runtime within their own app. We are working with Oracle on the OpenJDK project to provide an open source version of JDK7 that can be embedded, and several developers have already started deploying their apps with an embedded JDK7 (but it requires many manual steps right now). We are tracking the progress of creating an embeddable JRE in http://java.net/jira/browse/MACOSX_PORT-105 http://java.net/jira/browse/MACOSX_PORT-105 Conclusion: Apple's JVM team think this model is better for solving end users problem with JVM compatibility.