This isn't a significantly big deal, but if it can be fixed easily, it should be. Java doesn't work under Rosetta, but instead of gracefully accepting the fact that a JVM can't be started, we crash when we're running translated. I don't have a good stack because, um, we're running under Rosetta.
Printed to the console:
### MRJPlugin: getPluginBundle() here. ###
### MRJPlugin: CFBundleGetBundleWithIdentifier() succeeded. ###
### MRJPlugin: CFURLGetFSRec() succeeded. ###
Java for ppc cannot run in this configuration.
Please consult documentation.
This is one option:
But it's probably better to implement a fix that will give up without crashing if a JVM can't be started.
*** Bug 324524 has been marked as a duplicate of this bug. ***
Here's what's happening. On the first call to JEP's [AppletView maybeCreateJavaVM:...], the call to JNI_CreateJavaVM is failing and JEP is properly returning an error (ENOMEM). On the next call into maybeCreateJavaVM:, JNI_GetCreatedJavaVMs returns success and indicates that one JVM is available, and gives back a JavaVM object for it. The object is detached, so maybeCreateJVM: attempts to attach it by calling AttachCurrentThread, and that's where the crash occurs.
I can't think of a good reason for JNI_GetCreatedJavaVMs to return bogus JVMs, so I'll follow up separately on that with Apple.
In the mean time, I'm adding a static variable to maybeCreateJavaVM: that tracks whether or not a JVM was ever created successfully, and avoiding calling JNI_GetCreatedJavaVMs if none has been. Running under Rosetta now, the broken-plugin icon is properly displayed upon encountering Java.
I'll post the patch here and check in a new fat JEP bundle with this modification for Camino 1.0.
Reminder: those of you patching JEP locally for x86/universal builds will also be interested in bug 315163. This bug affects Rosetta so the ppc build is the critical portion, that bug affects the straight x86 build.
Created attachment 210813 [details] [diff] [review]
Only try existing JVMs if any had been created
New JEP bits (0.9.5+c+2) checked in on CAMINO_1_0_BRANCH.
Thanks for the Radar number...I'll track that.
This was fixed on the trunk, 1_8, and 1_8_0 branches by checking in a universal JEP 0.9.5+c with these patches in bug 327785. Bug 327785 contains details about what exactly was checked in. This bug will remain open until the patches or something else that accounts for the bugs makes it upstream to the JEP.
*** Bug 333009 has been marked as a duplicate of this bug. ***
JEP 0.9.5+d now contains a similar fix. This version is now on the 1.8 branch and trunk. 0.9.5+c, with x86 patches including this one, is now on the 1.8.0 branch and shipped with 188.8.131.52.
*** Bug 331494 has been marked as a duplicate of this bug. ***