Java 25 Support

[tugalsan]

Will there be incremental support, like Java 22; or will wait for LTS, like Java 25?

[thomasbehr]

We have not decided yet.

[yGuy]

For some releases Oracle decided to massively change the bytecode and thus supporting the new versions was a lot of effort. Then again for other releases the bytecode doesn't change at all and supporting the new version is mostly a one-line change.

Someone will need to take a look at the bytecode changes so that we can estimate the time it requires to update yGuard accordingly. It all depends...

[Fohlen]

Since Java 21 is the LTS release of Java for the foreseeable future (7 years), Java 22 support is not high on the priority list. However @tugalsan you can always kickstart this process. The first step is to research the Java bytecode instruction set. You can diff Java 21 and 21 from here. Once you have a list of new bytecode instructions compiled, we can decide which ones need adjustments. If there are no breaking changes, we can get this rolling quickly. Would you be willing to collect such a list for us? 😉

[tugalsan]

@Fohlen Did i understand correctly? As a first step, https://docs.oracle.com/javase/specs/jvms/seXXX/html/index.html site needs to be compared.

I created a HelloWorld project with Java22 and it worked https://github.com/tugalsan/com.tugalsan.tst.yguard . I am so confused.

Which version X should be compared against 22? What is the latest supported Java of YGuard?

[thomasbehr]

yGuard supports Java 21.

I think Fohlen meant to suggest comparing the Java 21 Virtual Machine Specification to the Java 22 Virtual Machine Specification.

Your HelloWorld project probably works, because your source code is essentially Java 8. I am not completely sure, but I think the Java compiler will actually not emit Java 22 byte code for such simple cases but emit Java 8 byte code. You probably need to add Java 22 language features for force the compiler to emit Java 22 byte code. (You can use javap to check the class file versions of the emitted byte code.)

[tugalsan]

Yea, pom has a problem, it was 21 eventually, my bad.

[kapilkumar9976]

Guys 23 will be best or 25 for lts

[yGuy]

yGuard supports Java 21.

Or more specifically: yGuard supports class files that are compatible with bytecode produced for the Java version 21 VM. This means that if you are using a newer version of the Java compiler that produces bytecode that is incompatible with Java version 21 VMs (and only then) yGuard will not necessarily be able to obfuscate it. If you can tell your tool chain to produce bytecode that works with Java version 21 VMs at runtime, all is fine, even if you are using Java version 42 features in your source code and calling APIs that are only part of JDK 5000. It's not about the class libraries and it's not about the source code features. It's all about the instructions at the class bytecode level. There have been very few breaking changes in the recent releases at that level, but Oracle hasn't been as careful and thoughtful in that respect in recent releases, either.

[yGuy]

At first glance the diff between 21 and 25 for the class file specification seems to be the version number, plus changes in type safety verification plus some changes in nomenclature and wording.
It seems there might be nothing else to do for tools that work with the class file than upping the version number. 🎉

This should be thoroughly checked and tested, but it might be easy this time!

[yGuy]

In order to support Java 25 classfiles, it looks like we need to do this:

• Accept class file major version 69 (Java 25).

-> Just bump the supported version check; no structural format changes.

• Handle the new ACC_IDENTITY flag (0x0020) for classes.

-> Replaces the old ACC_SUPER meaning in Java 25.

Preserve the bit as-is when reading/writing; don’t force it on or off.

• Recognize the new (preview) LoadableDescriptors attribute.

-> Class-level attribute introduced for value classes.

-> Copy through or update embedded class descriptors if renaming types.

• Continue renaming and preserving metadata attributes as before:

-> InnerClasses, EnclosingMethod, Signature, Record, LocalVariableTable, LocalVariableTypeTable, PermittedSubclasses, etc.

-> Attribute formats unchanged since Java 21.

• No changes to constant pool or bytecode instructions.

-> No new constant types or opcodes in Java 25.

• Preserve unknown attributes and flags to stay forward-compatible.

Overall: classfile format unchanged except for version bump, ACC_IDENTITY, and one new preview attribute. Looks like an almost trivial update implementation wise. But we need to do the testing, of course and someone should verify the above.

[Benetl2007]

hello Sebastian, hello Thomas,

were you speaking about MAJOR_VERSION from 0x41 (65 for Java 21) to 0x45 (69 for Java 25) in ClassConstants class?
hope to find a yGuard JDK 25 version in 2026

Regards,

[thomasbehr]

@Benetl2007 Yes, the first item in Sebastian's list means increasing the MAJOR_VERSION constant in interface ClassConstants from 0x41 to 0x45. To properly support Java 25 class files, all the other items in Sebastian's list need to be handled, too, though.