Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log important JVM errors to Gradle output #71

Open
mchwedczuk-box-com opened this issue Jun 3, 2022 · 1 comment
Open

Log important JVM errors to Gradle output #71

mchwedczuk-box-com opened this issue Jun 3, 2022 · 1 comment

Comments

@mchwedczuk-box-com
Copy link

mchwedczuk-box-com commented Jun 3, 2022

Recently I have been migrating my project to JDK 17.
I used the common workaround for GJF 15.x, that is extra --add-exports directives:

org.gradle.jvmargs=--add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED \
  --add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED \
  --add-exports jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED \
  --add-exports jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED \
  --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED

The problem was that I also had org.gradle.jvmargs entry in my ~/.gradle/gradle.properties so my fix was not working (user settings takes precedence over project settings in Gradle).

The behaviour of the plugin was as follows, all files where marked as INVALID. No error message was provided, neither in Gradle --debug output or in Gradle deamon logs.

Interestingly after removing org.gradle.jvmargs from ~/.gradle/gradle.properties the plugin cached the INVALID statuses in fileStates.txt file and the problem persisted until I executed ./gradlew clean.

Looking at the source code of the plugin I noticed that in few places you are catching Throwable or Error. This is a bad practice. If you want to catch JVM errors like ClassDefNotFound (like I get with the missing exports) it would be good to at least log those errors to Gradle output.

One example of such place:

Please make the plugin more debuggable by not swallowing important JVM errors but instead by logging them as WARNings to Gradle output.

@jimshowalter
Copy link

Agree with the author's points--the precedence order is surprising, and the error handling obscures root cause.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants