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

Re: Leopard Questions

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.

The main area for rework I see for myself is because a Java int will no
longer be wide enough to hold a pointer. I'll have to modify a couple
native functions in a couple of jnilibs, but other than those, I think I'll
be OK. I expect this transition to be easier than the i386 one, mainly
because I've already resolved the endian-ness issues. Of course, the
magnitude of any conversion task depends on how wedded one's code is to
jint's as wide enough for pointers.

Thanks -- I'd forgotten about that issue. We use CocoaComponent to embed a WebKit view in a JFrame, and thus need to address it. I just checked the CocoaComponent JavaDoc, and it notes that method "int createNSView()" is deprecated as of OS X 10.4 in favour of "long createNSViewLong()". So this one has been publicly resolved. I can't think of any other public APIs that expose a native pointer to Java code.

Other questions, such as about the C QT API, are probably best answered by
waiting for the Leopard preview DVD to arrive.

In our particular case, we have a release coming out just before when I expect the Leopard seeds to come out. If we can't slip Leopard support into that scheduled release we will have to either wait for the next scheduled release (months later), or put out an unscheduled "emergency" release for Leopard compatibility. We would much prefer to get this stuff into our scheduled release. OTOH, if Apple could publicly comment on how well existing 32-bit JNI libs will work under 64-bit Leopard, that might alleviate any concern we have about things breaking unexpectedly under 64-bit Leopard, requiring an unscheduled release.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden


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

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.