Library does not work in eclipse and sonar

[martinroucek]

Hi,

our company use Java-Thread-Affinity in our project. Unfortunately after upgrade from OpenJDK 8 to OpenJDK 11 Java-Thread-Affinity started cause problems with sonar analysis (https://www.sonarqube.org). The sonar analyzer uses Eclipse java compiler (ECJ) to create abstract syntax tree. I've setted up the minimalistic project for demonstration:

Project: https://github.com/martinroucek/sonar-ecj-problem
Code: https://github.com/martinroucek/sonar-ecj-problem/blob/master/src/main/java/example/Main.java

I understand that sonar analysis maybe is not critical issue for you. But because the problem is in ECJ the library causes compile errors in Eclipse IDE which is still quite popular. When you import demo project into Eclipse it fails with errors:

The project was not built since its build path is incomplete. Cannot find the class file for java.lang.String. Fix the build path then try building this project
The type java.lang.String cannot be resolved. It is indirectly referenced from required .class files

Do you have any idea what causes this issue?

[dpisklov]

None of us (developers) uses Eclipse I'm afraid, and at the moment we don't have any capacity to play with it. That said, we are happy to accept PRs

[m-anthony]

@martinroucek : what version of Eclipse are you using ? I remember that my company has this kind of weird message when we migrate to Java 9 with an older Eclipse than the one I use currently.

If I try to use JTA in a Java 11 project on Eclipse 2019-06 powered by a Java 11 JVM, I have this error message :

The package java.lang is accessible from more than one module: <unnamed>, java.base

I assume we have the same issue, but you are using an older eclipse which does not handle this properly, so the whole java.base module is not loaded properly and String is not accessible for the compiler

I did further investigations on the root cause since our company has the same issue, and although I have not find a clean solution (other than recompiling without the "faulty" classes), let me share what we found.

• To make NonForkingAffinityLock work, 2 classes are added in the java.lang package (ThreadTrackingGroup and ThreadLifecycleListener)
• In a JDK 11+ project, if JTA.jar is on the class path, it will be part of the unnamed module and exports this package which is already exported by java.base
• This configuration is illegal, however there is an unresolved bug in javac that allows it to work : https://bugs.openjdk.java.net/browse/JDK-8215739
• ECJ does not have this bug when compiling to java 11+ bytecode, so compilation is not possible. When the javac bug will be resolved, no one will be able to use JTA with the latest java version.

On a JVM 8, NonForkingAffinityLock will work only if the jar is part of the boot classpath (cf Affinity static methods code). Invoking NonForkingAffinityLock static methods directly without including the jar in the boot classpath will lead to this error on class loading :

java.lang.SecurityException: Prohibited package name: java.lang

I assume that if you need this feature, you need to use the -Xbootclasspath/a option

On a Java 9+ runtime (even if the application was compiled on java 8), NonForkingAffinityLock will not be used by Affinity, since the code relies on property "sun.boot.class.path" which was removed in Java 9

So the easiest way to make JTA work on a JDK11+ compile/runtime is to remove those java.lang classes and NonForkingAffinityLock from the JAR since it is very plausible that it will never be used in your case

[The-Alchemist]

Might also be relevant to some users: https://stackoverflow.com/a/62073700/423943

affinity is a transitive dependency of many OpenHFT projects, but it can probably be excluded if you're not using the thread affinity features.

[RobAustin]

Thanks for the detailed description above. Please note, pull requests are always welcome, If it’s possible to fix this by changing the code, If anyone wants to take on this issue, we are always pleased to receive and merge in your pull requests.