https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
c
likely the lib instrumentation variable, it’s enabling instrumentation of classes and the instrumentation lib doesn’t support the Java version they were compiled with (63 -> Java 19).
Java 19 is pretty new, generally find that most things work with Java 17 (last LTS release), beyond that is hit and miss.
e
Sorry, but I have no idea what you are talking about...
What do the two line I added to 
build.gradle
have to do with Java 19?
c
Some part of the code is being compiled with Java 19. Part of the test framework is instrumenting that - parsing the compiled bytecode and doodling it with some instrumentation - but that part doesn’t support Java 19. 
PROCESS_LIB_INSTRUMENTATION
enables the instrumentation.
e
What code?
c
It doesn’t say in that error message. Perhaps running with 
--stacktrace
will tell you the class it can’t handle.
Presumably your code base isn’t Java 19 then?
e
PROCESS_LIB_INSTRUMENTATION
is my own defined environment variable... My code base is Java 8, and why would changing 
build.gradle
matter?
c
that change to build.gradle enables something in the test framework that instruments class files. It’s tripped across a class file that is Java 19. Are you perhaps running Gradle with Java 19 (./gradlew --version).
grab the whole stacktrace, that will help with specifics.
e
So, commenting out the changed lines
Copy code
//    environment 'PROCESS_LIB_INSTRUMENTATION','true'
//    environment 'PROCESS_LIB_BUNDLE_LOG_LEVEL','info'
Causes the same error
c
huh, that’s different than originally reported. Anyhow - grab the whole stacktrace and let’s go from there.
e
What it looks like, is simply changing 
build.gradle
causes the error. Reverting the file, everything works fine
c
interesting. Can you get a full stacktrace?
e
My sense is that Gradle is the most fragile build tool I have ever used...
c
Hasn’t been my experience.
e
It has certainly been my experience...
c
Ok, so you are running Java 19, but it’s Gradle 7.4 that doesn’t support Java 19.
e
Again... when there is no change to the 
build.gradle
file, no error... When I modify the file, the error happens. This is insane regardless of everything else.
c
expected. Gradle has cached the compilation of build.gradle. Changing it doesn’t find a cache entry and requires recompilation, which fails due to Java 19 being installed since last compiled.
e
Ahh, a caching issue...
For me, it is not expected...
Is there a way to tell gradle which JVM to use?
c
Via 
gradle.properties
in your home directory.
~/.gradle/gradle.properties
e
Trying, but things do not work as documented...
Copy code
./gradlew clean test -Dorg.gradle.java.home=//Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home
Works, but the properties files do not...
c
org.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home
in ~/.gradle/gradle.properties
e
So, as I have mentioned before, Gradle changes so quickly, most of the Gradle tips and trick on the internet are out-of-date... I don't want to change 
~/.gradle/gradle.properties
yet because I am using Java 19 on another project using Gradle 8...
c
fair enough. This command: 
./gradlew clean test -Porg.gradle.java.home=//Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home
e
The next thing I want to do is upgradle (I made the word up) to Gradle 7.6 for our whole Big Ball Of Mud, because it does support Java 19... My boss is pretty much on board...
c
nice. May want to start by going to Java 17 first, then try 19; as it’s relatively new, newly supported in Gradle, on short term support, and perhaps various plugins etc may have issues.
Java 17 will get some good performance boosts over previous versions.
e
After upgradling to 7.6, then I will update all our Java to 11... Java 19 is used on a POC project.
After Java 11, Java 17...
c
cool.
e
It's embarrassing that we still use Java 8, and in some cases, Java 6
c
indeed. often work with enterprises that are in the same situation.
e
I found out recently that I have https://en.wikipedia.org/wiki/Sensory_processing_sensitivity which may explain why I find Gradle so frustrating...
c
interesting. Will read up on that some more, perhaps I have some of that…
e
Well, 20% of the population have it... not just people, but other animals too...
v
The next thing I want to do is upgradle (I made the word up)
Actually you didn't, at least the Gradle guys use it too when they update the Gradle build to a new Gradle version. :-)
Btw. you might also consider using JVM toolchains to decouple the Java version used to run Gradle from the Java version used to build and run your code. That way you can use any supported Java version to run Gradle, while you can use a different version for building and running your code.
e
Thanks, but I already use the toolchains, my problem was that Gradle 7.5.1 does not support Java 19, but I found a way around that.
v
It does not support running Gradle itself with Java 19. Using it for a toolchain should hopefully work. That's one of the reasons for the toolchains' invention afaik.
e
For my new POC project, I am using Gradle 8, which is fine with Java 19 For the BBOM, I plan to upgrade to Gradle 7.6
👌 1
11 Views
Open in Slack
PreviousNext
Powered by