Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Leopard Questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Leopard Questions




On Nov 2, 2006, at 4:13 PM, Doug Zwick wrote:

On 25-Aug-06, at 2:56 PM, Scott Kovatch wrote:

On Aug 25, 2006, at 3:53 PM, Doug Zwick wrote:

Greg Guerin wrote:

c) There is currently no such distinction visible for ppc vs i386, so I
would expect none for 64 vs 32 bit. That said, the "os.arch" system
property is readable by untrusted JNLP apps, and it often signals
architecture width. The reason I expect this is because of how the 'arch'
command works, and how architectures are signified in the sysctl values and
elsewhere. I think the ppc-64 value is "ppc64", but I don't know what the
x86-64 value is.

The JNLP Resource tag allows differentiation of resource downloads based on architecture as well as system (using the arch="ppc" and arch="i386 x86" attribute, along with os="Mac\ OS\ X"). We currently use this to only download the appropriate flat binary JNI lib for the current client, and avoid the overhead of downloading a Universal Binary (our end-users are very bandwidth conscious, so the megabyte or so that we save is very important). I hope we can continue to use this technique. This issue is of lesser import, as changing the JNLP files is a much smaller deal than changing our JNI libs.

I have been thinking about this, and the short answer is, yes, you should still be able to do that. I will file a bug to remind myself to double-check Web Start so that 64-bit x86 is correctly identified as such. I'm not sure it is right now.

Will WebStart by default use a 32-bit or 64-bit JVM on 64-bit capable hardware? If one needs a 64-bit JVM, how would one specify this in the JNLP? More to the point, since our app uses native libs that will not load into a 64-bit process, how would one specify the need to use a 32-bit JVM in the JNLP? The JNLP spec states that to specify a specific JRE one specifies the appropriate auto-download URL to the HREF attribute in the J2SE tag. Given that OS X does not support auto-download, this seems unworkable.

It took me some time to get all the right answers, but I think I've got enough to answer your questions, Doug. I have asked Matt Drance to write up a tech note about this, so some things might change slightly (like the exact string for 64-bit x86), but this is what I'm planning for Web Start. The tech note will be the final word, however.


-- Web Start will always use the 32-bit JVM by default, regardless of the hardware in use. That's consistent with the rest of our Java tools.

-- There will not be a 64-bit PPC JVM.

-- Java Web Start does not, and will not, do a prefix match on the architecture string. It is always an exact match on the whole string.

-- If your application wants to take advantage of the 64-bit JVM, you can do this in the JNLP file.

<resources os="Mac\ OS\ X" arch="x86_64">
  <java version="1.6*">
  <jar href="lib/app.jar" main="true"/>
  <nativelib href="lib/mac64/corelibs.jar"/>
</resources>
<resources os="Mac\ OS\ X" arch="x86">
  <java version="1.6*">
  <jar href="lib/app.jar" main="true"/>
  <nativelib href="lib/macintel/corelibs.jar"/>
</resources>

etc...

If your native library is 3-way fat, you can leave the arch parameter out altogether.

<resources os="Mac\ OS\ X">
  <java version="1.6*">
  <jar href="lib/app.jar" main="true"/>
  <nativelib href="lib/fatmac/corelibs.jar"/>
</resources>

The JNLP file technically cannot choose which VM will be used -- it's up to the JNLP client to do that. But, Web Start is expected to choose the first resources block in the JNLP file that matches. If an application prefers the 64-bit JVM the JNLP should have a resources block with that architecture first in the list.

-- It is possible to specify an exact JVM and architecture with the href attribute, but that will also lock you to a product version, which is likely not what you want. As mentioned earlier, the 32-bit JVM is always the first choice if no other preference is indicated, so you'll be fine.

I can't think of a situation where the 64-bit JVM is chosen if it isn't specified in the "arch" attribute, but the best defense would be to check the value of "os.arch" when your application starts up and then alert the user of the situation.

There is no plan to have a user interface that would allow a user to force the 64-bit JVM, but that's not set in stone. If the architecture used by the JVM is important to you, however, you can set up your JNLP file so that it won't matter.


Hope this helps. If you have more questions, go ahead and ask.

Scott

------------------
Scott Kovatch
Apple Computer
Java Runtime Classes
Cleveland Hts, OH
email@hidden

I am Scott Kovatch, and I approved this message.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Leopard Questions (From: Doug Zwick <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.