Support for Java 18+?

Looks like MAJOR_VERSION is 0x3D (61) which is Java 17.

yGuard/src/main/java/com/yworks/yguard/obf/classfile/ClassConstants.java

Line 30 in 1f7f317

public static final int MAJOR_VERSION = 0x3D;

https://stackoverflow.com/questions/9170832/list-of-java-class-file-format-major-version-numbers

Error: java.io.IOException: Incompatible version number for class file format: 62.0

At the time of this writing, yGuard supports class file formats of Java 17 and lower. See also the compatibility documentation.

Considering that the next LTS is Java 21, and GA is not expected before end of year, there isn't really any point in pushing this forward. We should reevaluate once Java 21 is in preview.

Hello, now Java 21 is released and yguard is the only stopper currently for me to upgrade to the new JDK 21.
Do you plan to add this support soon?

Well, while we do plan to add support for Java 21, we do not have a schedule for that yet. So, it may yet be a while before Java 21 is supported.

When is support for Java 21 expected to be available? Are there perhaps any concrete plans in the meantime?

What's the pressure, here? Did you all convert your code to use the new Java 21 language features? Which ones are they?
You are aware that you can easily execute your code on a newer runtime, too, aren't you?

Is this about compiling with and for Java 21 *exclusively?

If you can compile for or on Java 18, the current version of yGuard should work fine on the 21 runtime. If not, this would indicate a bug, rather than an missing feature.

Thank you for your answer.

We are currently switching our build pipelines on a test branch to the new JDK 21. Both source and target levels are set to 21. We want to check if there are any problems to be expected somewhere (bytebuddy and asm issues or other breaking changes related to reflection etc.). Currently the build works fine, but is broken at the end because of this yGuard exception:

java.io.IOException: Incompatible version number for class file format: 65.0
	at com.yworks.yguard.obf.classfile.ClassFile.read(ClassFile.java:355)
...

Edit:
When we try to compile with target release '17', we get this from compiler:

    [javac] warning: source release 21 requires target release 21

@t-huebner if you're doing that you can help us here by compiling a list of potentially breaking changes or additions to the JVM bytecode. This can kickstart development (if there are no significant changes it may be a simple as upgrading the version constant)

What about setting source and target to 17? Are you using any of the new language features? If not, I don't see why you would want to use source 21. You can still use JRE 21, of course. Otherwise, obviously yGuard is one of the many failing tests in your test and the result is: It's too early for 21. :-)

Thank you very much! We would like to use java 21 language features soon, and this is only possible with source level 21, which requires target level 21, which requires a new yGuard release, which doesn't break the build ;-)

And this is the reason for my question how your planning regarding Java 21 is. It's not super urgent, but it's helpful for our internal planning and tool selection.

Best regards
Tobias

Thanks - really just out of curiosity: which one of the new features are you most interested in?

Virtual threads. Any updates on the schedule? Any help needed?

Virtual Threads.... I don't believe there is anything in the bytecode or the language that has changed for the platform to support them. So supporting (only) them would be trivial. It might work for you to just patch yGuard to accept the higher class file version number. (again, what a stupid decision to increase the file version of .class files even if nothing has changed in the standard....)
But on the other hand increasing the version number should indicate full support for all the features that actually did change on the class file level.

It would be great to start with a compilation of a list of these changes. From this, we could derive separate issues and tasks.

I took the liberty of diffing JVM 17 vs JVM 18 spec from the official specification.

It appears the following new language instructions have been added:

ArrayCreationExpressionWithoutInitializer
ArrayCreationExpressionWithInitializer

While I am not aware that we handle array creation in any specific way, we should check if ASM abstracts this away, upgrade ASM, and add a test case. Then we are good to go for JDK 18 support. @thomasbehr is this something you want to look at or should I take a stab?

@Fohlen I just pushed some improvements for Java 21 compatibility which I had coded some time ago. I think those improvements cover all the non-preview byte code related changes from Java 17 to Java 21. I haven't had the time to prepare a proper release, though.

Seems to me like the array creation stuff is just changed notation in the language specification to make it more clearer to a reader that there are different way to declare and initialize arrays. I.e. those are not actual changes in the language or the byte code.

Hello Thomas,

thank you very much for the early Christmas present! The test build is now running flawlessly with yGuard 4.1.0.

Best regards
Tobias

Just want to say thank you as well :D This made our day (we were finishing off our Java 21 upgrade but had to keep sourceCompatibility set to 17 because of this problem. Now we can fully upgrade!).

It really is a Christmas gift 👍 .

Merry Christmas!