Goddot grale build error dsl

using jdk 17 and 21(alone and together) with godot 4.2 getting error Could not open dsl generic class cache for script ,C:…\android\build\config.gradle’
(C:…gradle\caches\7.4.2\scripts\813bi42cv3jm42g4zilxge7pu)

BUG! exception in phase ‘semantic analysis’ in source unit ‘BuildScript’ Unsupported class file major version 65

does anyone have any idea I am trying to trouble shoot but no luck so far.

It might be that you need to use Java 8 not 17 as seen this error with people not having java 8 installed.
Try the java 8 JDK and see if the issue is resolved.

1 Like

thank you, I tried it but still a mystery. also tried disabling my fire wall and opening godot in admin with the idea it might be a permission issue. thank you again.

ok so I think I have a lead if I run the gradlew.bat file it throws up error but if I run the bat file itself as administrator then I succeeds but I don’t know how to run it every time as admin I’m not real a windows guy I switched from Linux because windows is very compatible with so much stuff.
is there a setting in widows or in godot that I’m not thinking of that can do what I need.
the only thing I can find is to run it as admin by making a short cut for bat but then godot will not run shortcut but og bat file.

Unfortunately i dont think you can run the batch file directly as administrator.
From what i know of windows (And i had issue with this with Godot) is that running as administator and being an administrator on the machine is different as being an admin is technically a group.
I wonder if right clicking the godot program itself and running as administrator will give any different results?
Give it a try and let us know what happens.

1 Like

unfortunately, not I can start goddot in administrator but not the project as far as I can find I am messing with anti vires now I have norton it might be causing issues. starting to run out of ideas though.

I’m starting to think about running godot from a vm running ubuntu. if that works ok then any permission problems would be an easy checking drwxrwxrwt and aa-profile and I don’t think aa would even run right in a vm anyway at leas it dos not in wsl2

I’ve spoken to Kaan and some others and we are all lost for a solution on this as i dont know why this is occuring.
I hope that your solution has yielded positive results.

Regardless i will keep digging to see if i can find a solution to this issue

1 Like

I’m well out of my comfort zone putting a reply into this, but sometimes I like to just investigate random stuff and see what I can discover. With everybody stumped anyway, I figure it can’t hurt.

Have a look at this:

I noticed a couple of things that are consistent between these issues:

This suggests that the setup is using a version of Java that is more recent than what the project was compiled for. Given that the support guy in the other post indicates that major revision 63 is jdk19, I’m guessing 65 is jdk21, which is consistent with what you indicated you have installed.

Then I saw a link to this, which indicates that versions of Gradle and Java generally need to match:
https://docs.gradle.org/current/userguide/compatibility.html
and if I’m correct in assuming this means you’re using Gradle 7.4.2:

then it looks like your setup is trying to use jdk21 with this project, even though you have jdk17 installed as well for presumably this reason. That points to one other thing he mentions: “What is JAVA_HOME envirionment variable set to?” According to another similar issue, a mismatch here can cause this sort of unexpected compatibility problem, as some people have mentioned here:

Hopefully that helps. And if not, it was definitely an interesting distraction, lol XD

2 Likes

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.

Privacy & Terms