[External] : Re: JEP-412 & OpenGL
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Mon Oct 11 11:43:32 UTC 2021
On 11/10/2021 12:19, Martin Pernollet wrote:
> Thanks!
>
> The console is indeed informing me about an NPE without much details :
> Uncaught exception: java.lang.NullPointerException
>
> This was due to my code. That would be great to also have the
> stacktrace for this.
The single line you get with the exception name corresponds to my
experience with these kind of issues. Would be great as @jvernee
mentions to have a proper stack trace printed out, yes.
>
> I now get an empty window but I'll investigate.
>
>
> As a side note (maybe not Panama related), working with an IDE is not
> easy for me because when running from Eclipse STS 4, I often got
> /Exception in thread "main" java.lang.IllegalAccessError: failed to
> access class opengl.glut_h_3 from class
> org.jzy3d.chart.factories.PanamaGLFrame (opengl.glut_h_3 and
> org.jzy3d.chart.factories.PanamaGLFrame are in unnamed module of
> loader 'app')/
>
> The exception is appearing each time I change a line of code. When
> leaving Eclipse for building from CLI, I can start the app from CLI,
> and then get IDE working again (!). I always have VM
> args -XstartOnFirstThread --enable-native-access=ALL-UNNAMED
> --add-modules jdk.incubator.foreign
> -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
> <https://urldefense.com/v3/__http://OpenGL.framework/Versions/Current/Libraries/__;!!ACWV5N9M2RV99hQ!ZzJTEzmwC4Msl9959MQ3ugrU8tvXMuJRXORnwPuOn8UCK1IuP0u8Cb9lz8oUle0woV3CsWU$> activated.
>
> Also worth sharing - but not a Panama problem : the "Organize import"
> from Eclipse always replace
>
> *import* *static* opengl.glut_h.*;
>
> by
>
> *import* *static* opengl.glut_h_2.GLUT_DEPTH;
>
> ...
>
> *import* *static* opengl.glut_h_3.glutMainLoop;
>
> ...
>
> Which are not accessible, so every time I want to update and clean
> imports, they actually got mangled the bad way for Eclipse to work. I
> am still not a king with recent Java version so I might have badly
> configured my IDE.
Both issues you report seem to have to do with Eclipse having issues
with the shape of the generated code that comes out of jextract. We try
to hide most of the API away (e.g. glut_h_3 is not really accessible,
and only has package-private access) - but it seems like Eclipse emits
references to these classes, instead of emitting references to the
public accessible subclass. I'm pretty sure that the bytecode coming out
of Eclipse is different than the one from javac, and this is the issue.
All the calls in your code should have the form
opengl.glut_h::<methodName> - but it seems like the bytecode generated
by Eclipse ends up with opengl.glut_h_N::<methodName> instead.
I have no such problems when running code with IntelliJ - but IntelliJ
is using javac as a backend compiler, so that might explain the discrepancy.
Maurizio
>
> Best
>
> Sent with ProtonMail
> <https://urldefense.com/v3/__https://protonmail.com/__;!!ACWV5N9M2RV99hQ!ZzJTEzmwC4Msl9959MQ3ugrU8tvXMuJRXORnwPuOn8UCK1IuP0u8Cb9lz8oUle0wAKkuj7U$>
> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> Le lundi 11 octobre 2021 à 12:00 PM, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> a écrit :
>>
>> Hi,
>> great progress! I believe the crash you are seeing is caused by a
>> Java exception in one of your upcalls. The VM should print something
>> on System.out before crashing (e.g. the name of the exception at
>> least). Do you see anything printed out?
>>
>> While this look like a plain VM crash, this indicates an issue in
>> some of the Java code you're calling back to; or, well, Glut seems to
>> be calling back to. The last non-Panama element on the stack is this:
>>
>> |C [GLUT+0x59dd] -[GLUTView drawRect:]+0x5d|
>>
>> So I believe this is where the upcall occurs; we start executing Java
>> code (from native), the Java code throws, and, when we exit from the
>> upcall, the Panama upcall handler detects that there's been a Java
>> exception in the upcall, and terminates the VM.
>>
>> The stack trace that comes out of this is not the same as the one you
>> get when running in 100% Java mode, sadly - but I believe this is
>> what is happening. We should improve the diagnosability situation
>> here - I had similar failures in tests when trying to change the
>> API/implementation, and those can be quite nasty to debug.
>>
>> Maurizio
>>
>>
>> On 11/10/2021 10:40, Martin Pernollet wrote:
>>> Hi everyone,
>>>
>>> I have been a bit further on testing Panama with Jzy3D. I wrote a painter implementation for Panama allowing to invoke OpenGL (almost) exactly like I do for JOGL (binding with GlueGen) or for EmulGL (CPU rendering).
>>>
>>> I am facing a JVM crash that I copied here for readability :https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/issues/2__;!!ACWV5N9M2RV99hQ!abx9gY2FrNyuDCIyS8_fQoldx_0_H-rDrXwIxeytxkhDcav4c1-vvsvfjKayRKJPXmCSGTA$ <https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/issues/2__;!!ACWV5N9M2RV99hQ!abx9gY2FrNyuDCIyS8_fQoldx_0_H-rDrXwIxeytxkhDcav4c1-vvsvfjKayRKJPXmCSGTA$>
>>>
>>> Would someone suggest something to do to go ahead?
>>>
>>> You won't be able to run on your side immediately since I can't redeploy Jzy3d Maven snapshot version right now.
>>>
>>>
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>
>>> Le mardi 21 septembre 2021 à 11:02 PM, Maurizio Cimadamore<maurizio.cimadamore at oracle.com> <mailto:maurizio.cimadamore at oracle.com> a écrit :
>>>
>>>> On 21/09/2021 19:11, Martin Pernollet wrote:
>>>>
>>>>> Thank you a lot, it is working now, what a beautiful teapot :) Git repo updated with your suggestions.
>>>>>
>>>>> It seems that the window is a native one, so I presume that rendering in a classical AWT Canvas will require to render offscreen, get the image, then draw it in a Canvas. Right?
>>>> GLUT uses its own way for opening windows - so yes, that'd be a native one.
>>>>
>>>> Maurizio
>>>>
>>>>> Martin
>>>>>
>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>
>>>>> Le mardi 21 septembre 2021 à 19:50, Jorn Verneejorn.vernee at oracle.com <mailto:jorn.vernee at oracle.com> a écrit :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Your source code looks correct to me.
>>>>>>
>>>>>> I've tried out the project here as well, and the only two changes I had
>>>>>>
>>>>>> to make to make it work were changing the compiler plugin to version
>>>>>>
>>>>>> 3.8.1 (it seems like the latest version was not picking up the
>>>>>>
>>>>>> `--add-modules` flag). I then have this in the pom.xml:
>>>>>>
>>>>>> <plugin>
>>>>>>
>>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>>>
>>>>>> <version>3.8.1</version>
>>>>>>
>>>>>> <configuration>
>>>>>>
>>>>>> <source>17</source>
>>>>>>
>>>>>> <target>17</target>
>>>>>>
>>>>>> <encoding>UTF-8</encoding>
>>>>>>
>>>>>> <compilerArgs>
>>>>>>
>>>>>> <arg>--add-modules=jdk.incubator.foreign</arg>
>>>>>>
>>>>>> </compilerArgs>
>>>>>>
>>>>>> </configuration>
>>>>>>
>>>>>> </plugin>
>>>>>>
>>>>>>
>>>>>> (Everything else still the same),
>>>>>>
>>>>>> And after running `mvn clean package` I can run the program with:
>>>>>>
>>>>>> > java '-Djava.library.path=<path with dll>'
>>>>>>
>>>>>> --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign
>>>>>> -jar .\\\\target\\\\panama-gl-2.0.1-SNAPSHOT.jar
>>>>>>
>>>>>>
>>>>>> (Just had to fix a minor issue in Teapot since I'm using freeglut, but
>>>>>>
>>>>>> that shouldn't matter for you). This displays the teapot for me.
>>>>>>
>>>>>> So the only thing I can suggest at this point is to update the version
>>>>>>
>>>>>> of your maven-compile-plugin
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> Jorn
>>>>>>
>>>>>> On 21/09/2021 19:38, Martin Pernollet wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thanks for the jar option clarification.
>>>>>>>
>>>>>>> Teapot [0] indeed imports opengl.glut_h.* but opengl.glut_h extends opengl.glut_h_3 (and cascading to h2 and then h1). All the GL primitives called by Teapot are methods defined in glut_h_*, e.g. as glShadeModel(). Does this look normal then?
>>>>>>>
>>>>>>> [0]https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/Teapot.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NPDlt7v$ <https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/Teapot.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NPDlt7v$> can be nicely browsed on Github that provides an IDE like ability to navigate in code.
>>>>>>>
>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>
>>>>>>> Le mardi 21 septembre 2021 à 18:42, Jorn Verneejorn.vernee at oracle.com <mailto:jorn.vernee at oracle.com> a écrit :
>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> Note that anything passed after the `-jar <jar>` argument is a program
>>>>>>>>
>>>>>>>> argument, passing all the flags before `-jar` passes them as VM
>>>>>>>>
>>>>>>>> arguments, which is correct.
>>>>>>>>
>>>>>>>> The second error message you are getting is a bit puzzling. It seems
>>>>>>>>
>>>>>>>> that somehow your Teapot class is directly trying to access an internal
>>>>>>>>
>>>>>>>> binding class.
>>>>>>>>
>>>>>>>> Note that the generated bindings should be accessed through
>>>>>>>>
>>>>>>>> opengl.glut_h, which is public [1], instead of opengl.glut_h_3, which is
>>>>>>>>
>>>>>>>> package-private [2].
>>>>>>>>
>>>>>>>> HTH,
>>>>>>>>
>>>>>>>> Jorn
>>>>>>>>
>>>>>>>> [1] :
>>>>>>>>
>>>>>>>> https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NGhSAfu$ <https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NGhSAfu$>
>>>>>>>>
>>>>>>>> [2] :
>>>>>>>>
>>>>>>>> https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8G52B9OM$ <https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8G52B9OM$>
>>>>>>>>
>>>>>>>> On 21/09/2021 16:41, Martin Pernollet wrote:
>>>>>>>>
>>>>>>>>> Yes, I also added it at runtime as follow
>>>>>>>>>
>>>>>>>>> java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
>>>>>>>>>
>>>>>>>>> But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow
>>>>>>>>>
>>>>>>>>> java -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar
>>>>>>>>>
>>>>>>>>> WARNING: Using incubator modules: jdk.incubator.foreign
>>>>>>>>>
>>>>>>>>> Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
>>>>>>>>>
>>>>>>>>> at Teapot.main(Teapot.java:80)
>>>>>>>>>
>>>>>>>>> Still have to learn a few things about modules :)
>>>>>>>>>
>>>>>>>>> Sent with ProtonMail Secure Email.
>>>>>>>>>
>>>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>>>
>>>>>>>>> Le mardi 21 septembre 2021 à 14:41, Maurizio Cimadamoremaurizio.cimadamore at oracle.com <mailto:maurizio.cimadamore at oracle.com> a écrit :
>>>>>>>>>
>>>>>>>>>> Hi Martin,
>>>>>>>>>>
>>>>>>>>>> I think the compilation setup looks correct. The question is how do you
>>>>>>>>>>
>>>>>>>>>> run the application? The --add-modules option has to be added both at
>>>>>>>>>>
>>>>>>>>>> compile-time (which you are doing) and at run-time.
>>>>>>>>>>
>>>>>>>>>> Maurizio
>>>>>>>>>>
>>>>>>>>>> On 21/09/2021 13:15, Martin Pernollet wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
>>>>>>>>>>>
>>>>>>>>>>> Error: Unable to initialize main class Teapot
>>>>>>>>>>>
>>>>>>>>>>> Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
>>>>>>>>>>>
>>>>>>>>>>> Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
>>>>>>>>>>>
>>>>>>>>>>> (1) mvn install -D--add-modules=jdk.incubator.foreign
>>>>>>>>>>>
>>>>>>>>>>> (2) mvn install --add-modules jdk.incubator.foreign
>>>>>>>>>>>
>>>>>>>>>>> (3) mvn install without arguments by relying on maven compiler plugin setup as follow
>>>>>>>>>>>
>>>>>>>>>>> <plugin>
>>>>>>>>>>>
>>>>>>>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>>>>>>>>
>>>>>>>>>>> <version>2.3.2</version>
>>>>>>>>>>>
>>>>>>>>>>> <configuration>
>>>>>>>>>>>
>>>>>>>>>>> <source>17</source>
>>>>>>>>>>>
>>>>>>>>>>> <target>17</target>
>>>>>>>>>>>
>>>>>>>>>>> <encoding>UTF-8</encoding>
>>>>>>>>>>>
>>>>>>>>>>> <compilerArgs>
>>>>>>>>>>>
>>>>>>>>>>> <arg>--add-modules</arg>
>>>>>>>>>>>
>>>>>>>>>>> <arg>jdk.incubator.foreign</arg>
>>>>>>>>>>>
>>>>>>>>>>> <arg>--add-exports</arg>
>>>>>>>>>>>
>>>>>>>>>>> <arg>jdk.incubator.foreign</arg>
>>>>>>>>>>>
>>>>>>>>>>> </compilerArgs>
>>>>>>>>>>>
>>>>>>>>>>> </configuration>
>>>>>>>>>>>
>>>>>>>>>>> </plugin>
>>>>>>>>>>>
>>>>>>>>>>> I'll gladly bundled the Q&A in the above readme for other developers.
>>>>>>>>>>>
>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>>
>>>>>>>>>>> Martin
>>>>>>>>>>>
>>>>>>>>>>> [1]https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$ <https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$>
>>>>>>>>>>>
>>>>>>>>>>> [2]https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$ <https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$>
>>>>>>>>>>>
>>>>>>>>>>> Sent with ProtonMail Secure Email.
>>>>>>>>>>>
>>>>>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>>>>>
>>>>>>>>>>> Le lundi 20 septembre 2021 à 14:24, Martin Pernolletmartin.pernollet at protonmail.com <mailto:martin.pernollet at protonmail.com> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> Thank you all for your answers.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll give a try in the coming weeks and will tell you how this works.
>>>>>>>>>>>>
>>>>>>>>>>>> Martin
>>>>>>>>>>>>
>>>>>>>>>>>> Sent with ProtonMail Secure Email.
>>>>>>>>>>>>
>>>>>>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>>>>>>
>>>>>>>>>>>> Le samedi 18 septembre 2021 à 12:56, John Rosejohn.r.rose at oracle.com <mailto:john.r.rose at oracle.com> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Actually the JOGL work is one of the old inspirations for Panama.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ‘90s for a pre-Java VM.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The primitives I am thinking of these days are:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Panama native lookup accesses nearly all native entry point.
>>>>>>>>>>>>>
>>>>>>>>>>>>> These are optimizable by the JIT and/or AOT to be equivalent with today’s ad hoc JVM native transition wrappers.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it’s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> JOGL can stay as it is until it is ready to retool into the more powerful framework.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sep 17, 2021, at 9:26 AM, Maurizio CimadamoreMaurizio.Cimadamore at oracle.com <mailto:Maurizio.Cimadamore at oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Martin,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hope this answers your question
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maurizio
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 17/09/2021 12:54, Martin Pernollet wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1]https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$ <https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [2]https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$ <https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [3]https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$ <https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [4]https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$ <https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$>
>
More information about the panama-dev
mailing list