hg: macosx-port/macosx-port/jdk: Exporting the JNI interface via libjli to support BundleApp launching. Automatically picks client or server, or allows client code to specify via a JLI_ specific entrypoint.

[Mike Swingler]

On Sep 26, 2011, at 9:37 AM, Henri Gomez wrote:

> Yes, it is still a work in progress, however Eclipse and other bundled apps will have to be re-bundled (or for Eclipse, it's launcher will need to be re-plumbed) to include a .jre or .jdk bundle inside of them.
> 
> Eclipse won't be able to use an external JVM ?

As shipped today. As apps (like Eclipse) decide to adopt Java 7, each of them will have to explicitly make changes to opt-into using Java 7 anyway. This particular opt-in means loading the JVM from within their own app bundle, and using a modified or completely different loading stub.

>  OpenJDK-based bundles will probably never support any other JVMCapabilities beyond "CommandLine", because the Apple interfaces to each of the other capabilities are...odd, and the focus for apps (as well as the Oracle applet plug-in) is to bundle the .jre or .jdk that they require.
> 
> So Java based applications will embed their own copy of OpenJDK on OSX (Snow/Lion and higher ?) 

That's The Plan. Installing the .jdk bundles in /Library/Java/JavaVirtualMachines are for enabling the developer command-line tools and server-app deployments. If you make a .app bundle, you need to bundle. This is a requirement of the Mac App Store, and it also designs away the many of the issues we receive the most vitriolic hate mail (hate bugs?) about when we bump the JVM version behind the backs of unsuspecting developers.

Regards,
Mike Swingler
Java Engineering
Apple Inc.