JEP-412 & OpenGL

[John Rose]

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] http://jzy3d.org/
>> 
>> [2] https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl
>> [3] https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl
>> [4] https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java