-
Notifications
You must be signed in to change notification settings - Fork 79
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
_JAVA_OPTIONS can cause builds to fail #171
Comments
The gradle stack trace that lead me to that file was
|
The history of that code, showing where the issue was introduced and where it was fixed: https://android.googlesource.com/platform/tools/base/+log/mirror-goog-studio-main/build-system/gradle-core/src/main/java/com/android/build/gradle/tasks/GeneratePrefabPackages.kt |
Yup that's the preferred way IMHO. We should not be using |
@cortinico Do you think we could change the defaults? How many of the various memory options are actually required by default anyway? |
Yup, the default should be empty, as those flags are already specified in the |
Frustratingly, even an empty but present _JAVA_OPTIONS environment variable causes the "Picked up _JAVA_OPTIONS:" line to be printed. |
What about removing the gradle_options and java_options parameters entirely? If they can default to empty, the orb user can also just set their own environment variables on the job when needed |
Yup that should be doable |
Do you know if there's any reason behind the |
Disabling the gradle daemon makes sense when building on CI. So that can probably be removed as well |
IIUC, if it's enabled in CI, that means it will continue running in the background and consuming resources while later steps (e.g. simulators & tests) are executed. Looked around a bit, and after the change in recommendation (see gradle/gradle#2824), travis-ci briefly enabled the Gradle daemon (see travis-ci/travis-build#1603) and then re-disabled it shortly after due to due Android memory errors (see travis-ci/travis-build#1611) and that seems to have remained the case. |
# [8.0.0](v7.4.0...v8.0.0) (2024-05-23) ### Bug Fixes * remove _JAVA_OPTIONS parameter & environment (closes [#171](#171)) ([d737af9](d737af9)) * Merge pull request #172 from devnev/no-java-options-env ([a7d373e](a7d373e)), closes [#172](#172) ### BREAKING CHANGES * The java_options parameter has been removed. Specify your JVM options in the gradle.properties file or in the gradle_options with -Dorg.gradle.jvmargs= instead.
🎉 This issue has been resolved in version 8.0.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Orb version
react-native-community/react-native@7.1.1
What happened
I initially assumed the
Picked up _JAVA_OPTIONS...
line here was informational, as the JVM simply outputs it on startup when the _JAVA_OPTIONS is present. But there's no other error output, so I had to dig a bit further using the stack trace, and found https://android.googlesource.com/platform/tools/base/+/ed16bbacedbae05db984c1429955429764b21af2, a very recent change to gradle to consider _JAVA_OPTIONS informational rather than an error. Removing the _JAVA_OPTIONS fixed the build.Expected behavior
I'm not sure if this is worth fixing given the upstream gradle fix, but I also wonder if the _JAVA_OPTIONS use couldn't be replaced with having the same options in
-Dorg.gradle.jvmargs
, which seems to be more standard. At the very least this issue might help others resolve the issue.The text was updated successfully, but these errors were encountered: