> On Mar 15, 2023, at 3:37 AM, Martin Pernollet
> <[email protected]> wrote:
>
> Hi Sergey,
>
> We access OpenGL through native bindings generated by JExtract, from project
> Panama. These bindings are packaged as a library visible here
> (https://gitlab.com/jzy3d/panama-gl).
>
> The -XstartOnFirstThread option is needed by OpenGL on macOS as OpenGL
> invocation MUST be performed from macOS main thread.
>
This is possible with your Panama related in a somewhat limited way. I have an
application that does it at SwingGL-1.0.dmg[1]. This an x86 built app. This
application bundles the native executables for an offscreen Mesa[2] build and
freeglut[3]. freeglut appears to have a dependency on XQuartz[4]. The
application doesn’t provide this dependency. XQuartz would need to be
pre-installed. This renders the Teapot image offscreen and then copies it to a
Swing JPanel. It does not require the -XstartOnFirstThread switch.
It is limited in how it provides access to the native libraries.
java.library.path isn’t sufficient. I think this is because there is still
Apple OpenGL related floating around that gets found first. Although I don’t
think the Apple provided is adequate to provide what is actually needed to
support OpenGL So you have to use the DYLD_LIBRARY_PATH environment variable.
This is problematic for a java application since you can’t use relative paths.
The solution this application uses is to start a different ‘java’ process.
private static final String[] procArgs = new String[] {
System.getProperty("java.home")+"/bin/java",
"-cp",System.getProperty("java.class.path"),
"--enable-preview",
"--enable-native-access=ALL-UNNAMED",
"-Djava.library.path="+System.getProperty("java.library.path"),
"us.hall.gl.GLProcess"
};
And give it the DYLD_LIBRARY_PATH environment variable.
environment.put("DYLD_LIBRARY_PATH",System.getProperty("java.library.path"));
Which can just be java.library.path which jpackage automatically sets to the
application internal ‘app’ directory. Making sure that all the executables end
up being put in that directory.
Another limitation is that besides the need for a absolute path
DYLD_LIBRARY_PATH, you can’t use the system path native ‘java’ command. This is
due to Apple security protections.[5][6].
So DYLD_LIBRARY_PATH or any other DYLD environment variable can’t be used with
the installed native ‘java’ command in /Library/Java/JavaVirtualMachines.
The application needs to provide its own java command using its own jlink
parameters that don’t strip native commands. Something like…
--jlink-options '--strip-debug --no-man-pages --no-header-files’
An additional limitation here is that including the java command precludes that
application from getting into the Mac App Store as a resolution to
JDK-8286122[7].
I’ve thought this resolution was unfortunate and there might possibly be some
other approach that would allow developer applications to include native apps
in the App Store. Maybe the SIP issue provides a little more incentive to
revisit this issue at some point?
For some reason you get an extra window when this runs. I think this comes out
of freeglut/XQuartz initialization and will try to figure out how to get rid of
it. I plan to look a little more at what is possible with this approach for
macOS applications to use OpenGL ongoing. But I think this does show it isn’t
necessarily completely impossible to have such support. Maybe just a little
limited.
[1] http://mikehall.pairserver..com/SwingGL-1.0.dmg
[2] https://www.mesa3d.org/
[3] https://freeglut.sourceforge.net/
[4] https://www.xquartz.org/
[5]
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html
[6] https://developer.apple.com/forums/thread/703757
[7] https://bugs.openjdk.org/browse/JDK-8286122
