Newton’s Lore

If you’re developing software that might get run on an Intel Xserve with Dual Xeons it might be useful to get one to test with. This Apple page about Intel build numbers show’s it’s using build 8N1215 of Mac OS X, which is (unsurprisingly) newer than all other builds.

Just to make things easier for those using Java, it uses build 1.5.0_06-113 and JVM build 1.5.0_06-68 (which is a JVM I don’t think ships on any other MacIntel boxes, and I’ve managed to crash :).

Apple has a Developer article on Bug Reporting Best Practices

which includes tips for writing meaningful descriptions, and individual tips for more detailed reporting of bugs in Xcode, Java, Safari, Mail, iChat, Audio, USB/Firewire Ports/Drives, AirPort, iPod, iDVD. The information was also presented at a WWDC session this year (I was at another session at the time).
Interesting tips include using

sample (Application Name) 15

to ’sample’ hung applications.

There are also instructions for turning on more bug reporting in iChat and Mail.App.

So, if you’ve got a Java application bundle that’s built on a PowerPC Mac, the JavaApplicationStub file that’s copied into the bundle is PowerPC only. This file is copied in from

/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub

On an Intel Mac, this file is a Universal binary (ie PowerPC and Intel code).

So if you build your Java app bundle on PowerPC it won’t run on an Intel Mac.

One possible solution to this problem is to copy the Universal JavaApplicationStub from an Intel Mac into your bundle, or do the build on an Intel Mac.

If your Java app uses a native C JNI library that you’ve compiled yourself, and you’re getting the error message

FATAL ERROR in native method: JNI received a class argument that is not a class

then you should try recompiling the JNI library on an Intel Mac and including it with your Bundle. If your jni library worked on PowerPC but doesn’t on Intel then you probably just need to recompile it as a Universal binary on Intel (or perhaps, with a newer development environment), no code changes necessary.
These things worked for me after a bit of experimentation, I hope they work for you and save you some time.

If you’re in the eastern states of Australia and have installed your OS patches (Win,Mac OS X 10.3.9, 10.4.x,10.4.x Server) for this year’s changes to daylight saving (thanks to the Commonwealth Games, daylight Savings stops next weekend rather than last weekend) and still can’t work out why your Java apps aren’t handling the time change correctly, you need to upgrade your version of Java. (This will also affect changes to the US’s daylight savings next year.) It definitely affects Windows, not sure if Mac OS X Java suffers the same fate.

Java has its own set of timezone information embedded in it. Yay.

Of course, being in WA I otherwise don’t care.