Support for java 16 / asm 9.1

[frode-carlsen]

Any chance there'll be a new release soon that supports java 16? Because asm is bundled inside the aspectjweaver jar, tools that rely on aspectjweaver for instrumentation fails, and there's no easy way to replace.

(we're in the process of migrating numerous applications and micro-services forward from 11->16 in preparation for the LTS release coming soon, and this is our final hurdle.

[aclement]

I believe there are snapshots available for Java16 (@kriegaex can give you the snippet of maven for where). The release based on this is due quite soon (not months).

[kriegaex]

• http://aspectj.2085585.n4.nabble.com/AspectJ-AJDT-AspectJ-Maven-development-versions-for-Java-16-available-td4652803.html
• https://github.com/eclipse/org.aspectj/pull/41#issuecomment-826066012

[frode-carlsen]

😃 Great! Think I'll hold off until the release then

[kriegaex]

Why is that? Feedback before the release would be much more helpful than afterwards, and then you either have to wait for a bugfix release that might take a while, depending on how busy we are with our daytime jobs, or live with a bug. Please help us help you. If this is about your internal releases being unable to include snapshots, I can prepare a fixed version number, something containing beta, release candidate or whatever.

[frode-carlsen]

a fixed beta would be useful, we can try that out

[kriegaex]

a fixed beta would be useful, we can try that out

I just remembered your request. Sorry to reply late, but just in case you are not subscribed to the AspectJ users mailing list: We have a milestone release out on Maven Central:

https://www.eclipse.org/lists/aspectj-users/msg15508.html

@frode-carlsen, I hope this serves your purpose. Please be so kind as to close the issue, I do not have the necessary rights here (yet).

[frode-carlsen]

Great, thanks!

I've tried it out. Not quite there yet- we're using htis with the Allure Framework (https://docs.qameta.io/allure/#_junit_5) and upgrading from Java15/Aspectjweaver1.9.6 to Java16/Aspectjweaver1.9.7.M2 it fails to run properly.

Not sure if ths is due to a problem with backwards compatibility or a problem in the allure imlementation, but I've opened an issue there https://github.com/allure-framework/allure-java/issues/589

[kriegaex]

Actually, AspectJ 1.9.6 does not support Java 15, only 14. Only 1.9.7 supports both 15 and 16. Actually, your Allure issue suffers from lack of reproducibility. If you can create an MCVE, I will take a look. Maybe there is a dependency management glitch, maybe you hit a real error. But the AspectJ part looks good, because your ASM error is gone, i.e. the ASM 9.1 contained in AspectJ actually recognises Java 16 class file major 16.

I never used Allure before, so I do not know which dependencies it might have itself.

Edit: What happens if you use AspectJ 1.9.7.M2, but stick with Java 15 for the moment? Changing two things at once makes it difficult to reason about possible root causes.

[frode-carlsen]

Ok, here are my results

• 1.9.6 + Java 15 + Allure 2.14.0 ->OK
• 1.9.7.M2 + Java 15 + Allure 2.14.0 -> OK
• 1.9.7.M2 + Java 16 + Allure 2.14.0 -> fails to discover tests.

[kriegaex]

Are you seeing any exceptions anywhere? BTW, I almost forgot, there is an aspect weaving issue when running on JDK 16, see the commit comment at https://github.com/eclipse/org.aspectj/commit/79e44360cd95b14fa255daaac069f9b76c488451. We activated JVM command line parameter --add-opens java.base/java.lang=ALL-UNNAMED when running on Java 16. This happens automatically in our build, so I forgot about it already. AspectJ needs access to a now protected internal Java API. Andy did not have time to investigate if there is a workaround which does not require it, but for now you should use it. Maybe it causes an exception which is somehow swallowed by JUnit or Allure.

Give it a spin, would you please? Then report back. It is just a guess, but maybe it helps.

P.S.: I am still waiting for that MCVE. It would be very helpful. Just something minimal, reproducing the problem. A single test is enough, just a Maven project with JUnit 5, Allure and Java 15 vs. 16, succeeding and failing in the same way.

[frode-carlsen]

The above JVM command line parameter doesn't make any difference.

It seems to happen when a module compiled for java 16 imports records compiled under java 15 and it tries to add an aspect around a method invocation (see MyTest).

I've managed to create a smaller MVCE. but it's a bit tricky to run. To reproduce, the "dto" module in the following must be compiled with jdk 15, and the mvce module compiled and run with java 16. The MyTest will then fail to run with a"TestEngine with ID 'junit-jupiter' failed to discover tests" message

If changing everything to java 16 (see java.version in dto module) it will work. If changing java.version in root to 15, and aspectjweaver to 1.9.6 it will should work.

A workaround is then to avoid mixing java 15 dependencies into java 16 projects

aspectjweaver-issue45.zip

[kriegaex]

I did not try your MCVE, because from your description I can tell you that probably you do not have an AspectJ problem at all, it is simply how JDK preview features work. You cannot run code compiled on a JDK using preview features on a JDK version other than the one used for compilation. Records were in preview on JDK 15, then final on 16. Here is some proof, simply using javac, no ajc involved at all, no JUnit or Allure:

$ cat MyRecord.java
public record MyRecord(int id, String name) {}

$ cat App.java
public class App {
  public static void main(String[] args) {
    new MyRecord(11, "John Doe");
  }
}

$ . ~/set-jdk.sh 15
New JDK directory: jdk-15.0.2
Saving old variable values to __PATH and __JAVA_HOME

$ javac --enable-preview --source 15 MyRecord.java App.java
Note: MyRecord.java uses preview language features.
Note: Recompile with -Xlint:preview for details.

$ java --enable-preview App

$ . ~/set-jdk.sh 16
New JDK directory: jdk-16
Saving old variable values to __PATH and __JAVA_HOME

$ java --enable-preview App
Error: LinkageError occurred while loading main class App
        java.lang.UnsupportedClassVersionError: App (class file version 59.65535) was compiled with preview features that are unsupported. This version of the Java Runtime only recognizes preview features for class file version 60.65535

$ java App
Error: LinkageError occurred while loading main class App
        java.lang.UnsupportedClassVersionError: App (class file version 59.65535) was compiled with preview features that are unsupported. This version of the Java Runtime only recognizes preview features for class file version 60.65535

$ javac MyRecord.java App.java

$ java App

So if you please recompile your code using Java <16 preview features on JDK 16, it should work.

In the AspectJ test suite, we also had to implement new logic for tests using preview features to only be run if the JDK exactly matches. Before, we would simply run all tests requiring new JDK features on any JVM >= the minimum version required. Then came --enable-preview, and we had to take special precautions for those types of tests. Some JDK features are in preview for more than one JDK major version, and you cannot even run the same JDK(n) preview feature on JDK(n+1) if it is in the next preview iteration there. So this is something a Java developer needs to remember, when experimenting with preview features, with or without AspectJ.

That you see no stack trace in your LTW situation (i.e. byte code is being created during runtime, not in a static compilation situation), could be a problem with the project setup or a catch block not logging the exception, of maybe there is none. I never tested that before. Actually, I am wondering why the JVM even starts without errors, loading your Java 15 preview class. Maybe it is loaded later, when spawning the test JVM.

[kriegaex]

OK, I tried your MCVE. After having built dto on JDK 15, switch to JDK 16 and simply run Maven with -e in order to display stack traces:

$ mvn -e -pl mvce clean install

...
[ERROR] TestEngine with ID 'junit-jupiter' failed to discover tests
[ERROR] org.junit.platform.commons.JUnitException: TestEngine with ID 'junit-jupiter' failed to discover tests
[ERROR]     at org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discoverEngineRoot(EngineDiscoveryOrchestrator.java:111)
...
[ERROR] Caused by: org.junit.platform.commons.JUnitException: ClassSelector [className = 'aspectjweaver.issue45.MyTest'] resolution failed
[ERROR]     at org.junit.platform.launcher.listeners.discovery.AbortOnFailureLauncherDiscoveryListener.selectorProcessed(AbortOnFailureLauncherDiscoveryListener.java:39)
...
[ERROR] Caused by: java.lang.UnsupportedClassVersionError: aspectjweaver/issue45/MyRecord (class file version 59.65535) was compiled with preview features that are unsupported. This version of the Java Runtime only recognizes preview features for class file version 60.65535
[ERROR]     at java.base/java.lang.ClassLoader.defineClass1(Native Method)
...

There you have it. Just like in my javac example before. Quod erat demonstrandum. 😉

---

P.S.: When trying to build module dto on JDK 16, trying to use JDK 15 target + preview features, Maven actually tells you that this is a "no-no":

$ mvn -pl dto clean install

...
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] invalid source release 15 with --enable-preview
  (preview language features are only supported for release 16)
...

[frode-carlsen]

Great, thanks for all help. Learnt something new

The Java 15 with preview came from a library, so did not trigger the compilation error, but the JRE perhaps could have done at runtime?

[kriegaex]

the JRE perhaps could have done at runtime?

It does, see my previous comment. Just Maven did not display the full stack trace by default.

[frode-carlsen]

👍 Should've known. It was staring us in the face the whole time. The build hadn't enabled the -e switch

[kriegaex]

Don't worry, I am happy to help. An MCVE is always useful, BTW. I stopped counting how many dozen times I said that to people on StackOverflow already. So thanks for providing one. That made it super easy to confirm the root cause. 🙂

[frode-carlsen]

🙂 Thanks again for your help and time. Now everything works like a charm with the latest beta.