Re: Leopard, Snow Leopard & 32bit, 64bit Preferences

Got it -- thanks for the explanation.  If I can paraphrase the outcome: there's no way preferred way to say in an Info.plist, "run in the 32bit architecture if you have 32bit Java, run in 64bit if you don't".  However, we can get close by assuming that 10.5 only has 64bit and 10.6+ has 32bit & 64bit.

Thanks!

Sam

On Tue, Nov 3, 2009 at 2:39 PM, Mike Swingler <email@hidden> wrote:

On Nov 3, 2009, at 10:56 AM, Sam Berlin wrote:

Yup, there's a CFBundleIdentifier.  I'll give the LSMinimumSystemVersionByArchitecture a shot, but I was trying to stay away deciding the logic based on OS version (from advice on this list).  My hope was that LSArchitecturePriority by itself would work, and the launcher would refuse to use the 32bit architecture on platforms where there was no 32bit Java (so that, if pigs started flying and a 32bit Java came out for 10.5, it would automagically work -- or if Apple removed 32bit support from 10.6, the app would continue to launch).  Is LSArchitecturePriority supposed to be doing what it's doing, or should it be recognizing the Java architecture support?

The issue is that LaunchServices does not know it's launching a Java application, and it has no knowledge of Java, it's versions, their architectures, or the phases of the moon. It simply picks an architecture in the Mach-o executable, and starts it.

Once that occurs, the JavaApplicationLauncher.framework and JavaVM.framework scans the available JVMs, their architectures, the user's preferences, and chooses the "best" JVM to launch in the current architecture*.

Also, now that Mac OS X 10.6 has shipped, it's not a particularly creative leap of imagination to guess that Apple will _not_ be expanding it's configuration, support, and testing matrix of Java versions on Mac OS X 10.5. Removing 32-bit support from 10.6 doesn't make any sense, because that would leave 32-bit only machines without a functioning Java.

Cheers,

Mike Swingler

Java Runtime Engineer

Apple Inc.

* Launching situations involving PPC/Rosetta, broken i386 stubs, impossible version requests, and JVMArchs/JVMArches may result in re-executing using the system-provided JavaApplicationStub with any number of skanky hacks attempting to avoid infinitely re-exec()'ing or fork() bombing your computer.

On Tue, Nov 3, 2009 at 1:50 PM, Mike Swingler <email@hidden> wrote:

On Nov 3, 2009, at 10:25 AM, Sam Berlin wrote:

> Folks,
>
> There was a discussion a while back on this list about 32bit & 64bit Java Preferences.  In summary, Snow Leopard supports 32 & 64bit Java, and Leopard supports 64bit Java only.  In our case, we want Snow Leopard to run 32bit (because we use native libraries that are only available in 32bit), but want Leopard to still run properly with 64bit Java (and we'll detect the architecture and not load the native libraries).  So we need our JavaApplicationStub to have both 32bit & 64bit slices (since we don't want to build & ship two different apps) and whichever is preferred will be used.
>
> Mike Swingler suggested that we use LSArchitecturePriority in the Info.plist (as opposed to the deprecated JVMArchs key in the Java element in Info.plist).  However, this does not seem to work right.
>
> The immediate issue we found was that altering the elements in LSArchitecturePriority in an existing Info.plist did nothing.  It was as if it the order of the items in it (or the existence of it at all) just didn't matter.  OTOH, right-clicking on the app and choosing whether to run in 32bit or 64bit mode did change the mode.
>
> Then we found that it seems like LSArchitecturePriority is being applied to new applications when they are installed.  (For example, after running the pkg installer, it accepted the priority in order of LSArchitecturePriority.)  However, the catch was that it was accepting the priority on Leopard too, even though there was no 32bit Java available.  When installing an app into Leopard with an LSArchitecturePriority that had i386 before x86_64, Java failed to start (giving an error message).
>
> It seems like the only reliable way to prefer 32bit & fall back to 64bit if 32 isn't available is to use the deprecated JVMArchs element.  Am I going about this the wrong way?

Does your app have a CFBundleIdentifier? Without one, LaunchServices can't reliably track it's settings for your app. I've also found that if LaunchServices is being flaky about picking up changes to the Info.plist, sometimes I can get it "unstuck" by moving that app to another directory, and moving it back.

To specify an OS to architecture minimum boundary, try adding a LSMinimumSystemVersionByArchitecture dictionary to your Info.plist. You can specify a minimum of i386=10.6.0, x86_64=10.5.0, and prioritize i386 above x86_64 with LSArchitecturePriority. Please see <http://developer.apple.com/Mac/library/releasenotes/Carbon/RN-LaunchServices/index.html> for more information about these two Info.plist keys.