JEP-412 & OpenGL

Tue Sep 21 17:38:13 UTC 2021

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://github.com/jzy3d/panama-gl/blob/main/src/main/java/Teapot.java 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 Vernee <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://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java
>
> [2] :
>
> https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java
>
> 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 Cimadamore 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$
> > > >
> > > > [2] 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 Pernollet 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 Rose 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 Cimadamore 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$
> > > > > > > >
> > > > > > > > [2] 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$
> > > > > > > >
> > > > > > > > [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$