<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><br><blockquote type="cite"><div>On Mar 15, 2023, at 3:37 AM, Martin Pernollet <martin.pernollet@protonmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div>Hi Sergey,<br><br>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).<br><br>The -XstartOnFirstThread option is needed by OpenGL on macOS as OpenGL invocation MUST be performed from macOS main thread. <br><br></div></div></blockquote><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>private static final String[] procArgs = new String[] {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>System.getProperty("java.home")+"/bin/java",</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"-cp",System.getProperty("java.class.path"),</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"--enable-preview",</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"--enable-native-access=ALL-UNNAMED",</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"-Djava.library.path="+System.getProperty("java.library.path"),</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"us.hall.gl.GLProcess"</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>};</div><div><br></div><div>And give it the DYLD_LIBRARY_PATH environment variable.</div><div>environment.put("DYLD_LIBRARY_PATH",System.getProperty("java.library.path"));</div><div><br></div><div>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.</div><div><br></div><div>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]. </div><div><br></div><div>So DYLD_LIBRARY_PATH or any other DYLD environment variable can’t be used with the installed native ‘java’ command in /Library/Java/JavaVirtualMachines. </div><div><br></div><div>The application needs to provide its own java command using its own jlink parameters that don’t strip native commands. Something like…</div><div>--jlink-options '--strip-debug --no-man-pages --no-header-files’</div><div><br></div><div>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]. </div><div><br></div><div>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?</div></div><div><br></div><div>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.</div><div><br></div><div>[1] <a href="http://mikehall.pairserver..com/SwingGL-1.0.dmg">http://mikehall.pairserver..com/SwingGL-1.0.dmg</a><br></div><div>[2] <a href="https://www.mesa3d.org/">https://www.mesa3d.org/</a></div><div>[3] <a href="https://freeglut.sourceforge.net/">https://freeglut.sourceforge.net/</a></div><div>[4] <a href="https://www.xquartz.org/">https://www.xquartz.org/</a></div><div>[5] <a href="https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html">https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html</a></div><div>[6] <a href="https://developer.apple.com/forums/thread/703757">https://developer.apple.com/forums/thread/703757</a></div><div>[7] <a href="https://bugs.openjdk.org/browse/JDK-8286122">https://bugs.openjdk.org/browse/JDK-8286122</a></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br></body></html>