Closed gundoghusse closed 11 months ago
MarioKusek
commented
11 months ago I don't know if this is relevant to this problem but I had similar one.
In Problems View I had error regarding some library that could not be found. Gradle refresh did not help. But when you go to Project -> Properties -> Gradle there are set some program arguments like in picture here:
When I delete program arguments and refresh gradle project error disappears.
I hope this helps.
oleosterhagen
commented
11 months ago @gundoghusse I can reproduce your error when running Gradle 7.3 with Java 21. This is not supported, see Compatibility Matrix.
I think there are three possible solutions:
eclipse.ini and start Eclipse with Java 17 (instead of Java 21)gradle.properties in your project root: org.gradle.java.home=<path to Java 17> (see Gradle Properties)
gundoghusse
commented
11 months ago I don't know if this is relevant to this problem but I had similar one.
In Problems View I had error regarding some library that could not be found. Gradle refresh did not help. But when you go to Project -> Properties -> Gradle there are set some program arguments like in picture here:
When I delete program arguments and refresh gradle project error disappears.
I hope this helps.
Hi, unfortunately I didn't have any arguments so that did not help
gundoghusse
commented
11 months ago @gundoghusse I can reproduce your error when running Gradle 7.3 with Java 21. This is not supported, see Compatibility Matrix.
I think there are three possible solutions:
- Switch the project to Gradle 8.5, e.g. Project > Properties: Override workspace settings > Specific Gradle version
- Edit your
eclipse.iniand start Eclipse with Java 17 (instead of Java 21)- Add this property to the
gradle.propertiesin your project root:org.gradle.java.home=<path to Java 17>(see Gradle Properties)
Thanks for the reply, but I'm not sure that it helps.
Regarding step 1 above: We're unable to upgrade existing user/customer branches to gradle 8.5, and our developers need to be able to work on both the main branch (j21, gradle 8.5) and old branches (j21, gradle 7.3) in parallel . Does this mean that our users will have to have two separate eclipse installs as we are unable to upgrade the gradle version for old branches? We've never had to resort to that for any previous versions. Maybe I'm doing something wrong, but I run into a wall no matter what I do as soon as I want to build both branches with the same eclipse.
For step 2, I already have java 17 in eclipse.ini, which works for the j21-branches since they specify the JVM in the project settings.
For step 3, I suppose that's the same problem as for step 1, we cannot do a blanket upgrade of all branches.
gundoghusse
commented
11 months ago After more trial and horror, this seems to be related to "toolchain" issues (not finding the installed JDKs), but with really confusing error messages, I'm closing this issue
We are in the middle of upgrading a large-ish Java project from java 17 to 21 (and gradle 7.3 to 8.5). We have no problems building both old branches and new branches of the project from the commandline using gradle. But we have very difficult problems with buildship from Eclipse 2023-12. Building the j21 branch seems to work for most of our users even though there are some issues there with getting it working the first time, which tends to require some special hacks from time to time. Building a j17 branch works sometimes, but usually not at all. I could get it to build such branches for a while, but at some point, it stopped working and I can't even get it back at this point, which makes me suspect issues with how the gradle caches are used. Right now, I get the error attached below (slightly anonymized paths). This example is from Windows, but I can repeat the same issue on Linux as well. As shown, buildship builds the old branch using gradle 7.3 (which is correct) and not shown is that the build path points to java 17. But it still runs into a problem with java-21-compiled class files (version 65). I am unclear if this is some eclipse-internal file, a plugin dependency, or if it tries something in my project although the latter seems unlikely.
We have a requirement to support java 17-based branches for quite some time still, so we need Eclipse to support both types at the same time. I have not seen this type of issue with previous upgrades of java versions and gradle versions while doing the same type of upgrade, so I don't think I've messed up the build file.
Is this supposed to work?
Error message:
Could not open cp_init generic class cache for initialization script 'C:\Users\XXX\workspace.metadata.plugins\org.eclipse.buildship.core\init.d\eclipsePlugin.gradle' (C:\Users\XXX.gradle\caches\7.3\scripts\XXXX). Could not compile initialization script 'C:\Users\XXX\workspace.metadata.plugins\org.eclipse.buildship.core\init.d\eclipsePlugin.gradle'. startup failed: General error during conversion: Unsupported class file major version 65 java.lang.IllegalArgumentException: Unsupported class file major version 65 at groovyjarjarasm.asm.ClassReader.(ClassReader.java:199)