So I tried to upgrade my sandbox from using JME 3.2 SDK to a newer version and ran into a multitude of issues, which i will document here for informational purposes:
Attempt to install JME 3.3 SDK errors out with dialog box indicating NoClassDefFoundError for java.util.jar.Pack200. (known issue, but no documented workaround)
attempt to install JME 3.4 SDK - appears to install fine, but attempts to launch quietly shutdown. checking system Console reveals:
Nov 17 11:17:29 buddha java[5310]: getattrlist failed for /Library/GPUBundles/AMDRadeonX4000GLDriver.bundle/Contents/MacOS/ATIRadeonX4000SCLib.dylib: #2: No such file or directory
Nov 17 11:17:29 buddha java[5310]: getattrlist failed for /System/Library/Extensions/AMDRadeonX4000GLDriver.bundle/Contents/MacOS/ATIRadeonX4000SCLib.dylib: #2: No such file or directory
Nov 17 11:17:29 buddha java[5310]: getattrlist failed for /System/Library/Frameworks/OpenGL.framework/Resources//GLRendererFloat.bundle/GLRendererFloat: #2: No such file or directory
attempt to install JME 3.5 - appears to install fine, but launching errors out same result as SDK 3.4
attempt to install JME 3.6.1 - appears to install fine, but launching errors out same result as SDK 3.4
attempt to install JME 3.7- appears to install fine, but launching errors out even quieter:
Nov 17 11:24:40 buddha com.apple.xpc.launchd[1] (application.?.139384116.139386553[6840]): Service exited with abnormal code: 2
so for now, i’m stuck on SDK 3.2. i will try the dot-Zip installations having used them for vanilla netbeans in the past to see if they perform better.
On Mac the SDK does not provide JDK for you, and you must get one for yourself. I recently installed the SDK 3.7 successfully on Mac Air (the thin laptop, specs unknown but old AF) using JDK 21.
So my question is, what JDK you are on? And have you tested JDK 21?
Googling this issue seems that this is quite a widespread error on MacOS. I hope newer JDKs solve this. If it is down to LWJGL 2… well, we are not going to have a good time…
the mac pro has 6,7,8, 11, 17, and 21 all installed. for some context, i’ve been doing JavaEE dev for longer than the EE spec has existed. these issues are deeper than “is it plugged in”, as can be seen in the logged errors (or lack thereof because 3.7 fails without a whisper in Console).
even trying to bootstrap the dot-Zip install from terminal with JDK 21 on the path and directly forced by adding jdkhome=$JDK_HOME ./jmonkeyengine results in:
java.lang.IllegalStateException: Missing hosting module org.netbeans.libs.javacimpl for fragment org.netbeans.modules.nbjavac.impl
at org.netbeans.ModuleManager.refineClassLoader(ModuleManager.java:909)
at org.netbeans.StandardModule.classLoaderUp(StandardModule.java:527)
at org.netbeans.ModuleManager.enable(ModuleManager.java:1330)
at org.netbeans.ModuleManager.enable(ModuleManager.java:1254)
at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:316)
at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:252)
at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:298)
at org.netbeans.core.startup.Main.getModuleSystem(Main.java:173)
at org.netbeans.core.startup.Main.getModuleSystem(Main.java:142)
at org.netbeans.core.startup.Main.start(Main.java:299)
at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)
at java.base/java.lang.Thread.run(Thread.java:834)
for extra context, i have NB 21 and 23 installed and they both work fine with zero issues
that is a great find. not a solution, but it definitely exposes the issue with 3.4, 3.5, and 3.6.1 (trying to locate the gpu driver using an outdated mech). i’m guessing that lies in the native code parts of the SDK (lwjgl? bullet? opengl bindings?). doesn’t clear up the 3.7 issue, but it definitely still helps. i guess i can look at the 3.6 codebase, see about changing that one section to use the modern mech for loading the shared library and re-compiling.
and it DID answer the question. i tried running the dot-Zip version explicitly using the 21 JDK installed. and it reported the message indicated in the posting.
build the installer from scratch, but had to hand fix a couple bits (bad command flags to ln that work on linux but fail on macosx)
runs fine just like the “off the shelf” installer from the website
running the new installed instance fails exactly like the off the shelf installed version.
same version (3.6-sdk4) runs fine using the SDK source and gradlew run command. so i’m guessing the bundled app version has something spurious in it’s assembly/install.
following a SO posting about someone years ago having an issue upgrading NB from 12 to 13, i did some sleuthing around in the directory
~/Library/Application Support/jmonkeyplatform
in there i found a couple directories in reference to my other installs
3.0/
v3.2.2-stable-sdk1/
dev/
liblwjgl.jnilib
so i tarballed these directories and moved the .jnilib to a .bak file, and then gave the 3.6.1 JME SDK app a double click…
and Voila! worked.
so it appears that there is something spurious in how JME SDK handles separate installs and i’m guessing there are some “bad assumptions” in how it caches or overwrites (or doesn’t) previous installed artifacts.
as an aside, this is definitely NOT an netbeans issue, because i’ve had (and currently do have) numerous netbeans parallel installs on this machine over the years and never had them conflict with each other.
This in turn is a known issue. The SDK uses the same settings directory for all versions. All SDK release notes contains this warning or instructions to delete the old SDK settings. Although we don’t have the directory instructed for MacOS as I have no clue about that.
It might work without getting rid of the settings, and then you’ll have your settings from previous version which is super great. The bigger the jump, the more likely it is not to work. For recent versions it has worked fine. This is mainly due to the NB modules being quite stable now for long time (no removals etc).
I’m glad you got it working! There will be another SDK 3.7 release soonish also
