Building Universal Java App Bundles on Mac OS X

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


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.

2 thoughts on “Building Universal Java App Bundles on Mac OS X”

  1. After installing Xcode 2.4.1 on ppc and Java 1.5, the JavaApplicationStub appears to be universal:

    $ size -arch all /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub
    __TEXT __DATA __OBJC others dec hex
    4096 4096 0 9572 17764 4564 /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub (for architecture i386)
    36864 4096 0 7188 48148 bc14 /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub (for architecture ppc)

  2. A follow up to this post. I was running into a similar issue on an Intel based Mac. Any JNI calls made into the native code would crash the application. Specifically, any time I was trying to call GetStringUTFChars to convert a jstring to a const char buffer. The problem ended up being an outdated jni.h file. The jni.h file which I was including in my code came from an old JavaVM framework dated before the Intel JavaVM framework was released. Updating the jni.h to the latest one resolved my problem.

Leave a Reply

Your email address will not be published. Required fields are marked *