Support for Java 22 about proguard HOT 14 OPEN

I would also like to use Java 22 with proguard, so I created a PR similar to the one for Java 21 mentioned above: Guardsquare/proguard-core#127

Thanks!

from proguard.

The changes made by @henm have been merged already. Can we also expect a release in the near future :-? That would be great.

from proguard.

The support to Java 22 urges!

Caused by: java.lang.UnsupportedOperationException: Unsupported version number [66.0] (maximum 65.65535, Java null)

Please as soon as possible! We need 🚀

Thank you 🙌

from proguard.

It looks like none of the features or changes in Java 22 require any special handling by ProGuard beyond the version number (e.g. no new attributes, bytecode instructions).

Could you make a PR with the required changes, similar to the changes made for Java 21? Guardsquare/proguard-core#92

from proguard.

I do not understand. You say it is very easy and you ask me to make a Pull Request? I am not familiar with the code and GitHub policies, so for me it is a lot of work finding out what you mean and how to do that. I can wait, but I would hope there is an update when JDK 22 releases on March 19. I am not requesting special favors only that Proguard is compatible with the current JDK and maybe even with the EA when there is a release candidate.

from proguard.

Came here as well to look for a release date on the Java 22 support in maven! I am currently migrating the application from Java 8 to 22 and found out it uses proguard and now I am stuck on the final step before being able to release :(

from proguard.

@lordarnoud to bypass this issue and not delay the releases, what I made was compile with Java 21 and then flawless run with Java 22.

It is not how we like to work, but until the new Proguard comes out, the only way to run with Java 22 is by compiling to Java 21.

Of course, it is very bad for us programmers because we are unable to use in the source code any new feature of Java 22 yet... 😭

But at least in production, we can benefit from Java 22! 🚀

from proguard.

I just stumbled across the same problem. I made a tool that can change classfile version in one go in directories/zip archives/single files.
It only changes version of the class, no actual backporting is done.
The command line syntax is ... majorVersionFrom majorVersionTo file1 file2 file3 "file4"
(majorVersion is the JDK version, not classfile version)
Example use is as follows (Change version in shadow jar, from 22 to 21):

val changeVersion = tasks.register<JavaExec>("changeVersion") {
    javaLauncher.set(javaToolchains.launcherFor {
        languageVersion.set(JavaLanguageVersion.of(17))
    })
    classpath(project.file("versionchanger.jar"))
    mainClass.set("dev.xdark.versionchanger.CLI")

    args(
        listOf("22", "21") + listOf(project1, project2, project3)
                .map { it.tasks.shadowJar.get().archiveFile.get().asFile.absolutePath }
    )
}

Hope someone finds this useful.

from proguard.

@xxDark What makes you think that an incompatible class file gets compatible by just changing a number in it? This may just lead to difficult to trace crashes.

from proguard.

@xxDark What makes you think that an incompatible class file gets compatible by just changing a number in it? This may just lead to difficult to trace crashes.

Nothing makes me think that. That is why I put the text in bold.
JDK 22 classfile format did not change (correct me if I'm wrong), and I needed to use Proguard with it. It did not work, so I made that fast tool to change all classfile versions for me.
I'm well aware that classfiles don't get compatible by just changing their major version.

from proguard.

Is there a release date in sight for this? :) Or any updates on it?

from proguard.