Compile with Java 17

1

Hello everyone,

We are about migrating our application to latest LTS release. My own code is not compiling with Java 17 because Orekit uses some internal classes.

The error is :

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project orekit: Fatal error compiling: java.lang.IllegalAccessError: class org.orekit.compiler.plugin.DefaultDataContextPlugin$AnnotationTreeScanner (in unnamed module @0x5c92f780) cannot access class com.sun.tools.javac.tree.JCTree (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.tree to unnamed module @0x5c92f780 -> [Help 1]

I suspect that Java 17 compiler is more restrictive on this kind of uses, based on modules concept.

I might use temporarily a hack to avoid this error (java.lang.IllegalAccessError: cannot access class because module does not export to unnamed module - Stack Overflow).

It it planned to compile orekit with latest stable Java release ?

Best regards,

Anne-Laure

2

I would like so. It would also help releasing.
As an initial attempt, I tried to update all maven plugins and fixed many javadoc errors in Hipparchus (see the update-build-dependencies branch), but it failed at the continuous integration step (see Merge branch 'master' into update-build-dependencies · Hipparchus-Math/hipparchus@96aad94 · GitHub).

Perhaps @sdinot has a clue about this? If I remember correctly, he told me some weeks ago that this would require an update in our infrastructure, which is probably not a trivial task.

3

Thank you for the reply!

It looks like you have the same kind of errors, ie Java forbidding stuffs:

java.lang.reflect.InaccessibleObjectException-->Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @4cefa0be

In the stacktrace, it seems that it is the commons-lang dependency that causes the problem, doesn’t it ? I found this for example : How to fix "Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass? - Stack Overflow

Have you tried to use commons-lang3 instead ?
I am not sure at all that would fix the problem, it is just the first idea I could think of…

Best regards,

Anne-Laure

PS : I a m still searching how to workaround the problem with Orekit

4

We don’t have any dependencies in the Hipparchus library itself (only Java) and have only dependency to Junit (and of course its transitive dependencies) in the tests parts.
This branch was also intended to use recent versions of many build tools plugins (tools, not dependencies), so it should already be reasonably up to date.

5

You are right, the dependency comes from sonar. We can see it here :
https://mvnrepository.com/artifact/org.sonarsource.scanner.maven/sonar-maven-plugin/3.9.1.2184

We can find easily that others users are getting the same problem :

Indeed, it looks like the sonar server must be updated : you are currently using Sonar 7.5 (build 20543), you should be using v9.1.

6

Hi @Anne-Laure,

I think an upgrade of Sonar is planned by @sdinot, but I can’t tell you when exactly.

This can be a pain sometimes because Sonar can change the rules’ definition between 2 versions without maintaining compatibility. We’ll see how it goes.

Maxime

7

I am still fighting with this problem of illegal access.

I understand that DefaultDataContext is using internal JDK library to inspect code.

I have found that until JDK 16, it was possible to allow the compiler ignoring this type of illegal access :

But from Java 17, it is mandatory to replace the calls to internal jdk by external libraries :
https://openjdk.org/jeps/403#Description
I quote that

When standard replacements are available, switch to using those

I will go on to see how it can be replaced, hoping that we can :crossed_fingers: !

1 Like
8

That’s it! I found how to fix the problem :

Do you think it could be merged ? Delivered in a patch ?
For information, these changes are needed so we can migrate to Java 17 :blush:.

Best regards,

Anne-Laure