Universal builds for 64-bit only?

[Mike Swingler]

On Dec 3, 2011, at 6:40 AM, James Melvin wrote:

> Hi,
> 
> In more closely examining the hotspot build on Mac OS X, we appear to be
> building the following JVMs, followed by universal binary packaging...
> 
> Client at ${JAVA_HOME}/jre/lib/client/libjvm.dylib
> - 32-bit Client JVM
> 
> Server at ${JAVA_HOME}/jre/lib/client/libjvm.dylib (one binary, 2 archs)
> - 32-bit Server JVM
> - 64-bit Server JVM
> 
> Being new to the platform, I have some general, perhaps naive
> questions...
> 
> 1) What is the value of a universal binary with only 1 arch?

What do you mean?

> 2) We plan to only support 64-bit JDKs...
>    a. Is there value in continuing to build 32-bit JVMs?
>    b. Should we drop universal builds, if we only build 64-bit JVMs?
>    c. Can the JDK use universal binaries and Hotspot not use them?

There is only value to continuing 32-bit builds for client code that needs features only available in 32-bit (legacy Quicktime, Carbon, etc). There are some 32-bit only machines (which are stuck on SnowLeopard) that won't be able to run 64-bit executables.

Dropping support for 32-bit also implies that the -client option will just redirect to -server, right?

> 3) Various infrastructure depends on a relocatable JDK.  Can we expect
>   to support both a formally installed system JDK and a freestanding
>   JAVA_HOME?

No. You cannot assume there will ever be a "system" JDK. We are moving to a model where every app that requires Java will have to bundle it in it's own app bundle. Even a JDK installed for command-line use can be in many different locations on disk, so you can never rely on a fixed path for the JDK (which is why we have the /usr/libexec/java_home command for scripts and command-line deployments).

> 4) What is the plan for deployment?  Supported .dmg or just .zip?

AFAIK, it's currently a .dmg for the developer-focused command-line development package (.jdk bundle in /Library/Java/JavaVirtualMachines).

> 5) What is the strategy for auto-update?  Supported independently or
>   through Apple OS updates?

Apple will not update Java provided by Oracle (Java SE 7 or greater).

Last I was involved in the discussions, the plan was for apps that embed Java to update it on their own schedule. The applet plug-in, as a concrete example of this, will have it's own auto-update mechanism, and will only update the .jre that is private to it's own bundle.

Regards,
Mike Swingler
Apple Inc.