Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liberty Gradle Plugin 3.7 seems to require use of JDK19 #857

Closed
UlrichLohrmann opened this issue Oct 25, 2023 · 9 comments · Fixed by #858
Closed

Liberty Gradle Plugin 3.7 seems to require use of JDK19 #857

UlrichLohrmann opened this issue Oct 25, 2023 · 9 comments · Fixed by #858

Comments

@UlrichLohrmann
Copy link

Hi,
I have developed an additional Gradle Pluging to simplify use of Open Liberty Gradle Plugin in our Environment. I use Adotium JDK 17 LTS Version for my build. In the Gradle build file I import the Open Liberty Gradle Plugin with the following statements.

buildscript { dependencies { classpath 'io.openliberty.tools:liberty-gradle-plugin:3.7' } } . dependencies { . implementation 'io.openliberty.tools:liberty-gradle-plugin:3.7' . }

If I use Version 3.7 as shown above I get the following message as soon as Gradle is started:

Unsupported class file major version 63

This means that I have to use at least JDK19 for my build.

If I use version 3.6.2 of the Liberty Gradle Plugin, everything works fine with JDK17. So it seems to me that either the Open Liberty Plugin or one of its transitive dependencies requires JDK19. The release notes of version 3.7 don't have any comment concerning JDK19.

Could you please give a hint whether JDK19 is required for Open Liberty Gradle plugin Version 3.7?

Best regards
Ulrich

@sreich
Copy link

sreich commented Oct 25, 2023

I'm interested in this too, before I try to upgrade

Do you not use Java toolchains as Gradle highly recommends?

This has other benefits and decouples the execution of Gradle from your actual build. Also enables you to test and run them side by side.

But ultimately, Gradle itself would need to be executed with whatever minimum there is(like this issue), but that doesn't imply or should not affect your builds for your code themselves unless you did it incorrectly (like not using toolchains

@cherylking
Copy link
Member

Version 3.7 definitely should not require Java 19. We ran our builds/tests on Java 8, 11 and 17. The Java compiler source/target in our build.gradle still says 1_8...as in Java 8.

What version of Gradle are you using?

@cherylking
Copy link
Member

@sreich Thank you for your input. There is an issue open to explore using toolchains. We have not had the bandwith to prioritize that over other issues yet. Contributions are welcome.

@cherylking
Copy link
Member

@UlrichLohrmann I just tested a Gradle project locally and it worked fine with the following:

Liberty Gradle Plugin: 3.7
Java: 17.0.5
Gradle: 7.6

@UlrichLohrmann
Copy link
Author

I use Gradle 7.5. The build process uses a Java Toolchain

java { toolchain { languageVersion = JavaLanguageVersion.of(17) vendor = JvmVendorSpec.ADOPTIUM } }

I will try to make a small sample to reproduce.

@cherylking
Copy link
Member

@UlrichLohrmann Is it possible for you to try with Gradle 7.6 and see if it makes a difference? I have seen some posts externally where people complain of the Unsupported class file major version 63 with Gradle and upgrading to 7.6 resolved it.

@cherylking
Copy link
Member

After much research, it seems to be a known issue between Gradle versions. Upgrading to 7.6.1 is the recommendation. Looking at our changes from 3.6.2 to 3.7, it is not clear to me why this has just now become a problem. I will update our README and release notes to indicate a minimum of 7.6.1 is required.

@cherylking
Copy link
Member

Here's the Gradle issue that tracked this problem.

@UlrichLohrmann
Copy link
Author

Thank your for your inventigations. I can confirm that problem does not longer occur with Gradle 7.6 nor with Gradle 7.6.1. Thank you for help with this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants