Could not open settings generic class cache for settings file settings.gradle


Says it can not open it. Picture of a file being there provided.
file called “settings” with a type of .gradle is there. Can not provide a picture since being a new user.

Java version is 8.

The problem is not, that the file is not accessible.
The problem is “Unsupported class file major version 63”.
63 means Java 19.
So you try to use something that was compiled for Java 19+ with something Java -18, and that fails.

Thank you for your reply! java -version in cmd shows 19. Same with properties. Tried with both jdk versions, the problem did not go away. What am I doing wrong, kind sir?

What does ./gradlew --version say?
What is JAVA_HOME envirionment variable set to?

Where should I put the command? My cmd and Visual Studio don’t read this command. Both with and without the slash and dot. JAVA_HOME is set to: C:\Program Files\Java\jdk-19. Thank you!

In your root project directory, where you have the gradlew.bat.
If you call from Bash or similar, for example from “Git Bash”, it is ./gradlew.
If you call from PowerShell, it is .\gradlew.
If you call from Cmd, it is just gradlew.

Btw. your screenshot shows you use Gradle 7.5.
This is not supported to run on Java 19: Compatibility Matrix

Hello I have the same problem but with Java 21 and gradle 8.5


Could you please help me resolve this issue ?

No, you are not.
You are using Gradle 7.6 and that does not support running with Java 21:
image

What gradle -v outputs is totally irrelevant, as that is just some locally installed Gradle distribution that is usually never used, or better said you should never use it and usually not even have it installed.
Each project should have the 4 Gradle wrapper files included that define with which version of Gradle the build is compatible with, tested with, and should be run against, and cares for exactly that version to be used.

For the build you are running that is Gradle 7.6.

Hello, thank you very much for your answer. What I don’t undestand is that I downloaded gradle 8.5 and followed the instructions from the Gradle website. I tried to delete every file concerning gradle 7.x but everytime I run the cordova build command it still uses gradle 7.6. I added the environment variables and path to the gradle8.5\bin file in my system advanced settings so I don’t understand why it doesn’t use this version of gradle. Would you please help me ?

As I already said in my last post.
What Gradle version you have installed or have in any environment variables or paths is absolutely irrelevant.
You do not even need to have any version of Gradle installed.
Every sane Gradle-based project has the 4 wrapper files included and those files control which version of Gradle is used to run the build, as the build is designed for exactly that Gradle version and is known to properly work with exactly that Gradle version.
If you would run a build that is written for 7.6 using 8.5, you could maybe be lucky and it works, or it could fail fatally, or even worse it could silently be successful while not having worked like expected.

Hello, so what can I do to solve this problem? Should I downgrade the java version or upgrade the gradle version?

Yes, exactly, . . . . .

@jadoprog were you able to get this work?

I have similar issue. I’m on java 21, and downloaded gradle 8.7, and that’s the only version I installed.
But when I run build, I got error

* What went wrong:
Could not open cp_settings generic class cache for settings file '/home/ec2-user/sql-parser-service/settings.gradle' (/root/.gradle/caches/8.1.1/scripts/e0nxm4dfbqqivwyg9olb9hxj9).
> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65

I deleted that .gradle folder, and it created the exact same folder again.

Oh, figured, I have to run gradle wrapper --gradle-version 8.7

Just to advise I am also recieving this error with gradle version 8.8 and JDK 22, which are both listed as compatible with eachother on the compatability matrix. I had to downgrade to JDK 21 and set the java_home environment variable to the JDK21 installation location to get my gradlew build working.

Can you share a build --scan URL?
If it really fails to run with Gradle 8.8 on Java 22, that’s probably a bug you should report.
But most often you are just not running what you think you are. :slight_smile:

Hi there, I actually think this is an issue with springboot rather than gradle, I am following the guide here: https://spring.io/guides/gs/spring-boot which has led me to install the latest version of gradle and the JDK, but I assume the springboot configuration itself seems to have a dependency on the specific JDK 21 version and is generating an error unless I downgrade from JDK 22.

As part of the guide it asks you to clone this repo: git clone https://github.com/spring-guides/gs-spring-boot.git which seems to have the dependency on JDK21.

I later realised it is the springboot configuration because if I generate a package here: https://start.spring.io/ I can specify JDK 22 and now the build would complain unless I have my java_home path set to version 22 instead.

Sorry for the confusion I am new to all of these packages, but just following their guides does not explain the JDK requirements.

Here is my gradlew build --scan url which I ran earlier but unfortunately did not make any sense to me: Build Scan® | Develocity (it just seemed to report the same error which I saw originally on the CLI which led me to this forum in the first place).

It was the comment two up from my original comment which led me here: ```

BuildScript’ Unsupported class file major version 65

I am following the guide here: https://spring.io/guides/gs/spring-boot which has led me to install the latest version of gradle

Any guide that makes you install any version of Gradle is actually bad.
But I don’t think that guide meant you to install Gradle.
You should never need any version of Gradle installed.
The only time where you need an installed Gradle version is, if you either have a build that is missing the 4 Gradle wrapper files - which I consider a build bug - or if you want to kick-start a new build without any IDE with Gradle integration, Spring initializer service, or other Gradle build around with which you could do it.
For all other cases, i.e. running a build, you should always use the Gradle wrapper.

And if you have Gradle 8.8 installed, but use something else in the wrapper, and correctly use the wrapper to run the build, then you exactly have what I said. You are not running what you think you are running. :slight_smile:

Here is my gradlew build --scan url which I ran earlier but unfortunately did not make any sense to me: Build Scan® | Develocity (it just seemed to report the same error which I saw originally on the CLI which led me to this forum in the first place).

The important thing it shows is exactly what I assumed. That is run using Gradle 8.3 and that is not compatible with Java 22.