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.
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
