Apparently, a first version of OpenJDK for Mac ARM is available at Azul. How difficult would it be to compile JOGL for this environment? Are there some directions that would help to try generate the required .dylib files? Any hope that they will be available for the final 2.4.0?
Thanks for your suggestions.
Thanks for the instructions. They were useful and after a few changes, I was able to get a running JOGL / Java 3D application running on a Mac ARM
As instructed, I downloaded Azul OpenJDK for Java 11 and 8 (my target), installed Ant and CMake. There's no version of CMake for macOS arm64 yet but using Intel version with Rosetta 2 correctly worked.
There was no problem to compile Gluegen but the generated .dylib file was for x86_64, not arm64. Therefore, I replaced "x86_64" by "arm64" in gluegen/make/gluegen-cpptasks-base.xml file in the two following lines:
and that was enough to get libgluegen_rt.dylib for arm64 architecture (info checked with "lipo" command).
I even succeed to create a "universal" .dylib file which combines both architectures with the command:
It was a little more complicated to generate JOGL .dylib files. First, I searched in .xml files some lines similar to the ones for Gluegen architecture, and after a few failures, I realized that there was no .xml files to change for JOGL because the build process reused the compilation configuration set for Gluegen!
There was also a link to SWT that I didn't succeed to set, so I just removed the following folders where it's referenced:
NEWT couldn't still be generated but as I don't need it, I just used the .dylib files that were successfully generated.
Finally, I extracted the libjogl_desktop.dylib, libnativewindow_awt.dylib and libnativewindow_macosx.dylib files needed by Java 3D, and signed the 4 .dylib files once I realized it was required to make run an arm64 application under macOS 11.
The result can be tested with the JAR executable SweetHome3D-6.4.2a-jogl-2.4.0-rc-20200307.jar which is able to run under macOS Intel or ARM, Windows and Linux.
If you want to test the universal .dylib files I generated in your own program, just extract the following files found in the java3d-1.6/macosx folder of the previous JAR executable.
There was a compilation issue because it didn't find some SWT classes. But as I didn't need SWT support, I didn't look further since the 3 DLLs I needed were already generated. I wouldn't worry too much about that.
This is very useful for us, thank you for making it available! But our application uses the class com/jogamp/opengl/util/gl2/GLUT which doesn't seem to exist in the new jars. Does anyone know if it is it tied to the SWT/Native-Window stuff that couldn't be built, or if there might be another way to make sure it is provided? Or has it been deprecated in 2.4? I'd like to learn what I can about my chances before attempting the MacOS-ARM build myself.
I see, thanks! I found I can use the jars and libs provided with SweetHome if I put another jar that has GLUT in my classpath but that seems like an ugly way to handle this. (Sweet Home 3D is a dandy product, by the way. We're remodeling right now so I'm glad I ran into it!)
Is there a correct way to use an existing prebuilt jogamp-fat.jar (e.g. https://jogamp.org/deployment/jogamp-next/fat/jogamp-fat.jar ) with these new jnilib files or would it need to be rebuilt from scratch with references to the new architecture? (Just dropping the new libs into the same directory as the fat jar doesn't let it find them, of course, but I'm wondering if there are additional tweaks to the JRE invocation or edits to the fat jar that might do it.)
Next step, I tried to prepare a .app bundle for macOS to let users make tests without installing Java.
This required the jpackage command found in Azul Open JDK 15 that replaces the missing javapackager of Oracle Java. To get a "universal" .app bundle able to run under x86_64 and arm_64 architectures, I also merged the Contents/MacOS executable and Java runtime .dylib files contained in the .app bundle generated by jpackage with the lipo command (see my previous message).
Finally, I signed the application with entitlements described here and successfully submitted it for notarization to Apple.
The resulting application can be found in SweetHome3D-6.4.2b-macosx.dmg (81.6 MB).
A few users reported that Sweet Home 3D could hang too with JOGL v2.4.0-rc-20210111, but I didn't find where this deadlock could come from yet. It's probably bound to the modifications for macOS made last year (see this commit and this one). I was wondering if synchronizing on another existing lock (like the one returned by Component#getTreeLock) would help, but I didn't try yet (and my suggestion might be just stupid or nonsense).