Java 21 support

[kriegaex]

Right after Eclipse 2023-09 was released, as usual the beta branch for the next Java version (21) was merged into the main branch. Java 21 support is now available on Eclipse Marketplace, but according to the mailing list announcement, only final features are supported, no preview or incubator features yet. Those are planned to be finished by Eclipse 2023-12:

We are pleased to announce the Java 21 support for Eclipse 2023-09 (4.29).

The release notably includes the support of the following standard Java 21 features:

• [21] JEP 440: Record Patterns
• [21] JEP 441: Pattern Matching for switch

(...) The known issues and the preview features are retargeted to 4.30 timeframe or to the next Java version as appropriate.

With AspectJ being dependent on JDT Core, the first Java 21 release of AspectJ (1.9.21) will only contain what is described above. An update release 1.9.21.x is scheduled to be released, after upstream support for the remaining JDK 21 features has been released.

[kriegaex]

After building the first version of AspectJ with a JDT Core with Java 21 support, the I found out that there are Java 17 class files in several Eclipse JDT Core dependencies, which make their way into aspectjtools.jar, i.e. the AspectJ compiler Ajc will need a Java 17 runtime environment (previously Java 11). 🙁

I analysed the situation in detail after unpacking the four main AspectJ JARs into subdirectories and checking on classfile major versions via javap. First, let us create lists containing pairs of classfiles and their major versions:

$ find aspectjrt -type f -name '*.class' | xargs javap -v | grep -E '^(  major version:|Classfile)' > aspectjrt.txt
$ find aspectjmatcher -type f -name '*.class' | xargs javap -v | grep -E '^(  major version:|Classfile)' > aspectjmatcher.txt
$ find aspectjweaver -type f -name '*.class' | xargs javap -v | grep -E '^(  major version:|Classfile)' > aspectjweaver.txt
$ find aspectjtools -type f -name '*.class' | xargs javap -v | grep -E '^(  major version:|Classfile)' > aspectjtools.txt

Next, let us display some stats:

$ grep -E '^  major version:' aspectjrt.txt | sort | uniq -c
    131   major version: 52

$ grep -E '^  major version:' aspectjmatcher.txt | sort | uniq -c
    434   major version: 52

$ grep -E '^  major version:' aspectjweaver.txt | sort | uniq -c
     37   major version: 49
    935   major version: 52

$ grep -E '^  major version:' aspectjtools.txt | sort | uniq -c
     37   major version: 49
   2050   major version: 52
   2481   major version: 55
    691   major version: 61

Major	Java version
49	5
52	8
55	11
61	17

I.e., the situation for the upcoming AspectJ 1.9.21 with Java 21 support is as follows:

• Runtime, matcher and weaver still work under Java 8.
• Tools (compiler) needs a Java 17+ runtime environment.

[jeromevdl]

Hi, is there any ETA for this to be released? We're heavily depending on aspectj and cannot provide a java21-compatible version of our library without this. Thanks for your work!

[kriegaex]

The problem is that Java 21 support in the Eclipse Java Compiler we depend on is still neither officially released nor complete in the current development version. That is the only reason why I did not release AspectJ 1.9.21 shortly after JDK 21 became available.

But there have been 1.9.21 snapshots for quite a while now. Please use that for now and report back problems. If it works for you, I can then maybe release a milestone, if the only problem is that you do not want to depend on a snapshot.

[jeromevdl]

Thanks for the prompt answer. We cannot rely on a SNAPSHOT, as it's not available in maven central. I can obviously test with a local build of the java-21 branch. Will tell you.

[kriegaex]

It is available on Maven Central's snapshot repository. No need to build locally.

[kriegaex]

See #242 (comment) for how to add it to your Maven build.

[kriegaex]

Well, are you actually using any Java 21 language features or just compiling to target 21?

Edit: This is a reply to the now deleted comment:

My end-to-end tests are passing with the 1.9.21-SNAPSHOT. I'm not sure to understand what is missing on your side but it's working fine for us.

[jeromevdl]

I've deleted because there was actually an error in my E2E tests, wanted to make sure. It was for another reason.

We actually don't use any Java 21 feature, just targeting 21 for the compilation.

[kriegaex]

We actually don't use any Java 21 feature, just targeting 21 for the compilation.

Then IMO you do not need AspectJ 1.9.21 at all. There is zero value in creating Java 21 byte code, if you do not use any Java 21 language features. Your previous Java 8, 11, 17 or 20 byte code will still run fine under JDK 21, unless you use e.g. old Java 8 APIs no longer in existence in more recent JDKs like e.g. javadoc taglet stuff from JDK 8.

I even consider it harmful to force compilation to a more recent target unnecessarily. Older byte code can always run on more recent JDKs, but not the other way around. You new library version would require JDK 21 as a minimum runtime environment. You will just unnecessarily piss off your customers.

[jeromevdl]

Yes, we know it still runs when compiling with an older version. We're providing a library for AWS Lambda and people will have to weave their code with it, and now than Java 21 is available as a runtime for Lambda, people can use Java 21, and thus need the version 1.9.21...
Plus our build process (end-to-end tests) is based on a matrix composed of all JDK supported by Lambda (LTS: 8, 11, 17, 21)

[kriegaex]

FWIW, I released a milestone 1.9.21.M1 without any release notes. It is available on Maven Central, so you do not have to use a snapshot.

[kriegaex]

Yes, we know it still runs when compiling with an older version. We're providing a library for AWS Lambda and people will have to weave their code with it, and now than Java 21 is available as a runtime for Lambda, people can use Java 21, and thus need the version 1.9.21... Plus our build process (end-to-end tests) is based on a matrix composed of all JDK supported by Lambda (LTS: 8, 11, 17, 21)

@jeromevdl, one more time: Using JDK 21 or running code on it does not necessarily mean to compile to target 21 for no good reason. This is harmful! Your library should be compiled to the lowest possible byte code version. That way, it runs on both new and old JDKs. But if compiled to target 21, there is no chance to run in on any JDK below 21. If the users of your library - is the name a secret, BTW? - run their code on JDK 21, that is just fine. What does your library do, and how is it woven into the target code? LTW? CTW? Post-CTW?

[kriegaex]

As you can see here, Eclipse 2023-12 SimRel (simultaneous release) is scheduled for 2023-12-06. That will also be the official release date for Java 21 support in Eclipse IDE and Eclipse Java Compiler (ECJ). As explained before, ACJ forks and therefore depends on ECJ. I.e., AspectJ 1.9.21 is expected to be released shortly after Eclipse 2023-12. Currently, Eclipse SimRel is in RC2. A few days ago, I merged in some upstream fixes without any new problems, so the situation seems to stabilise. I want to write a few regression tests for Java 21 preview features which were not available in ECJ the first time I merged, but I did not get around to that yet.

Simply use the M1 and be happy. Just because the ".Mx" suffix will go away, it does not mean that everything is perfect, and its existence does not mean that the release is unstable.

Like I also said before: 99% of users clamoring for a JDK 21 release are not using any JDK 21 features at all. So why the hurry?

[kriegaex]

Please refrain from unnecessary full quotes, I just edited your comment to remove one. No harm done, just be more considerate when quoting in the future. 🙂

I belong to that 1% 😅. We are using JDK 21 features such as virtual thread

That is the perfect counter-example. Virtual threads are API, not a language feature. An AspectJ compiler or weaver update should not be necessary for your code to use virtual threads. In principle, you should be able to use a very old version, compile to target 8, 11, 17 or whatever, and still be able to use JDK 21 to develop your application and use virtual threads.

[kriegaex]

Update: I just tried and used a Maven playground project, opened it in my IDE, switched the to build JDK 21, pasted some virtual thread code into the main method, used an old 1.9.8 AspectJ Compiler via AspectJ Maven Plugin, set the source/target levels to 11, and it compiled fine. The code also executes fine, both from the command line and in my IDE. The only suboptimal thing is that the IDE imports language level 11 and squiggly-underlines the new API, suggesting to upgrade to 21. I simply ignored that, and everything compiles and runs the way I expected it to. Like I said, it is just API.

[kriegaex]

So what about pattern matching?

Pattern matching for switch is a language feature. It should work, because it was previewed several times and previous AspectJ versions always supported the preview feature. The final can only be used with a new AspectJ version, but you have the M1 already. If you are that bleeding-edge, then you either have to use the milestone or wait until the official ECJ for Java 21 is out and followed by a corresponding AspectJ release. Complain to the JDT Core team, not to me. AspectJ depends on them.

IMO, virtual threads are the much more impactful change in JDK 21. This is going to be the future of Java. With virtual threads, IMO reactive frameworks become superfluous and never would have been developed, if virtual threads would have been there earlier. But sorry, I am digressing. Anyway, pattern matching is just syntactic sugar. Either wait for the final release, if you have a problem with M1, or simply do not use that feature yet.

Also, is there any proper way to integrate the aspectj with lombok

That is a whole new topic. Please search for my answers about that on Stack Overflow.

[kriegaex]

I very much doubt that for your customer it is important that you use pattern matching for switch and force him to also use JDK 21 if he depends on your library, just because you do. There is no urgent need to use JDK 21 language features, if you just want to reap the benefits of virtual threads, like I said. Try not to make your luxury problem the customer's problem. That way, you get around the question of why you are delivering something with a milestone dependency to him.

[kriegaex]

I have refreshed JDT Core again, adjusted AspectJ to it and released 1.9.21.RC1 to Maven Central. On GitHub, you can find the corresponding AspectJ installer. The most notable change is that JEP 430 (String Templates Preview) is now supported by the compiler. I did not test it, but I saw it in the commit logs. Feel free to test yourself.

I am not expecting any substantial changes in the compiler anymore until the final release, but of course cannot speak on bahalf of the JDT Core developers.

[kriegaex]

AspectJ 1.9.21 is available on Maven Central. Please study the release notes. Currently, I am trying to make AJDT work with the new AspectJ release. Once that is don, I will also announce the release on the AspectJ "announce" and "users" mailing lists, as usual.