https://gradle.com/ logo
Join Slack
Powered by
In a clean Windows 10 Sandbox (and on macOS at one...
# community-support
o
In a clean Windows 10 Sandbox (and on macOS at one contributor) and on a Contributor on Windows 11, gradle says Shortening Java classpath [C...] and then
Copy code
Starting process 'command 'C:\Users\WDAGUtilityAccount\.gradle\jdks\amazon_com_inc_-24-amd64-windows.2\bin\java.exe''. Working directory: C:\Users\WDAGUtilityAccount\AppData\Local\Temp\jabref\jabgui Command: C:\Users\WDAGUtilityAccount\.gradle\jdks\amazon_com_inc_-24-amd64-windows.2\bin\java.exe --enable-native-access=ai.djl.tokenizers,ai.djl.pytorch_engine,com.sun.jna,javafx.graphics,javafx.media,javafx.web,org.apache.lucene.core --add-opens java.base/java.nio=<http://org.apache.pdfbox.io|org.apache.pdfbox.io> --add-opens java.base/jdk.internal.ref=<http://org.apache.pdfbox.io|org.apache.pdfbox.io> --add-modules jdk.incubator.vector -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseZGC -XX:+ZUncommit -XX:+UseStringDeduplication -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp C:\Users\WDAGUtilityAccount\.gradle\.tmp\gradle-javaexec-classpath17673669193172587711.jar --module org.jabref/org.jabref.Launcher
Successfully started process 'command 'C:\Users\WDAGUtilityAccount\.gradle\jdks\amazon_com_inc_-24-amd64-windows.2\bin\java.exe''
Then I get
Copy code
Error occurred during initialization of boot layer
java.lang.module.FindException: Module org.jabref not found
Build 00ba7384-9696-4fa9-9223-172669a8483f is closed
On my Windows 10 machine (no Sandbox), gradle does not call 
Shortening Java classpath
. Can I turn off this feature? Or maybe use it for module-path?
v
The pathing-jar shortening is used, if the path exceeds the command line lengths restrictions.
On Windows this is 32766 characters.
So you probably have in the sandbox and at that contributor longer paths because of longer username or similar and on your local machine you have a shorter username and thus shorter paths, resulting in short-enough commandline.
You can "disable" the shortening by setting the internal 
org.gradle.internal.cmdline.max.length
system property to a large enough value, as this overrides the hard-coded OS-dependendent max length, but then the execution of course might fail due to too long command line
You could try to shorten the commandline yourself, for example by writing the classpath and modulepath arguments to an "@-file" and configuring that as argument instead of the classpath and modulepath arguments if you use a Java version that can recognize them or something similar.
Either way, you should of course report that as bug if there is none yet. Obviously the splitting into classpath and modulepath happens after that shortening was done and thus is ineffective which then makes your run fail as the module is missing. This is of course a bug in Gradle. 😞
Argh, no, the splitting into classpath argument and modulepath argument indeed happens first. But then the length is checked and if it exceeds the maximum, then the pathing jar is built with all jars so the modulepath gets lost. 😞 Still a Gradle bug though.
o
I am doing code and fix here to fix it
👌 1
(Smalltalk: I patched OpenJDK and JavaFX; nothing can stop me - hahaha)
👌 1
(Smalltalk 2: Each year's GSoC has a phase where we need to patch the Java eco system)
😄 1
Now fighting with spaces in paths
v
Yep, the old song 😄
o
Handicap: 
:distributions-full:binDistributionZip
does not recompile following class 
subprojects/core/src/main/java/org/gradle/process/internal/JavaExecHandleBuilder.java
v
Why not?
o
Interesting question. I am wondering. I told it to write "HUBBA" into the file, but that did not appear. Trying ./gradlew --info --no-build-cache --rerun-tasks clean distributions fullbinDistributionZip now 🙂
even that does not help but compile errors are detected. this is so strange
🧐 1
OK, 
git clean -xdf
and then 
./gradlew --info --no-build-cache --rerun-tasks clean :distributions-full:binDistributionZip
did not help Fresh Windows Sandbox But now my family calls -- maybe I can continue this night... Intermediate state is https://github.com/gradle/gradle/pull/34227
Copy code
Unable to download toolchain matching the requirements ({languageVersion=17, vendor=any vendor, implementation=vendor-specific, nativeImageCapable=false}) from 'null', due to: No defined toolchain download url for WINDOWS on x86_64 architecture.
work around: 
mise exec java@17 -- ...
Ah, it was about not deleting 
~./gradlew/wrapper/dists
maybe - because compilation updates the bin file as of today 🙂
OK, I think, I need to give up - PR works for normal case, but not when ANTLR generation is involved - https://github.com/gradle/gradle/pull/34227
OK, did not give up - had a last idea - worked
👌 1
🎉 1
3 Views
Open in Slack
PreviousNext
Powered by