[External] : Re: JEP-412 & OpenGL

[Maurizio Cimadamore]

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