[External] : Re: JEP-412 & OpenGL

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Oct 12 12:49:57 UTC 2021


Looks great! Please let us know should you find any performance 
discrepancies between this version and the other ones you were working on.

Maurizio

On 11/10/2021 22:48, Martin Pernollet wrote:
> Hi,
>
> Here are a teapot and a surface drawn with Panama+Jzy3D :)
>
> It is still very crappy and there is a lot of work to do for a clean integration, but I can't resist sending this first baby step!
>
> Best,
>
> Martin
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> Le lundi 11 octobre 2021 à 5:06 PM, Martin Pernollet <martin.pernollet at protonmail.com> a écrit :
>
>> Thank you Maurizio. I confirm that using IntelliJ allows editing a program without having to rebuild outside the IDE.
>>
>> I kept my questions and your answers there : https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/issues/3__;!!ACWV5N9M2RV99hQ!YC2kNOlMARZTrQkMOk3puAwTXLWo46CBCDz9R6-819sTyw2oKjzdsVpneNdYH7jPW3nhQ0U$
>>
>> Sent with ProtonMail Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>
>> Le lundi 11 octobre 2021 à 16:47, Maurizio Cimadamore maurizio.cimadamore at oracle.com a écrit :
>>
>>> On 11/10/2021 12:43, Maurizio Cimadamore wrote:
>>>
>>>> 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.
>>> Performed some more tests:
>>>
>>>      // pkg/A.java
>>>      package pkg;
>>>
>>>      class A {
>>>          public static void foo() { }
>>>      }
>>>
>>>      // pkg/B.java
>>>      package pkg;
>>>
>>>      public class B extends A { }
>>>
>>>      // Test.java
>>>      import static pkg.B.foo;
>>>
>>>      class Test {
>>>           public static void main(String[] args) {
>>>               foo();
>>>           }
>>>      }
>>>
>>>
>>> I compiled this with both javac and the Eclipse compiler. With javac,
>>>
>>> Test::main has the following bytecode:
>>>
>>>                0: invokestatic  #2                  // Method pkg/B.foo:()V
>>>
>>>
>>> With Eclipse, I see the following:
>>>
>>>                0: invokestatic  #12                 // Method pkg/A.foo:()V
>>>
>>>
>>> Of course, the code compiled with javac runs, whereas the one compiler
>>>
>>> with Eclipse fails with this:
>>>
>>>      Exception in thread "main" java.lang.IllegalAccessError: failed to
>>>      access class pkg.A from class Test (pkg.A and Test are in unnamed module
>>>      of loader 'app')
>>>           at Test.main(Test.java:5)
>>>
>>>
>>> Which seems like a bug in the Eclipse compiler, and an unfortunate one
>>>
>>> too, since jextract relies on this pattern quite a lot.
>>>
>>> Maurizio


More information about the panama-dev mailing list