Under Eclipse, editing slightly a program make it fail after a modification

[jzy3d]

(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/ 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.

[jzy3d]

Maurizio answered

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:: - but it seems like the bytecode generated by Eclipse ends up with opengl.glut_h_N:: 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.

[jzy3d]

Maurizio added

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.

[jzy3d]

I confirm that using IntelliJ avoid this problem.

[laeubi]

@jzy3d If you think this is a bug in the compiler (AFAIK Java 17 support is still new and there might be improvements needed) it would be best to report these here: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JDT (Component core, prefix [ejc])

[jzy3d]

Thank you @laeubi . I haven't had the time to do it, this ticket as already been forwarded here!