Build fails under Java 17

[Fingel]

When attempting to run the project under Java 17, the build fails with the following error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:processDebugMainManifest'.
> Unable to make field private final java.lang.String java.io.File.path accessible: module java.base does not "opens java.io" to unnamed module @32d74d85

Running the build on Java 11 does not result in this error.

System Information:

openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12)
OpenJDK 64-Bit Server VM (build 17.0.1+12, mixed mode)
Linux 5.16.8-arch1-1

Steps to reproduce:

1. You'll need to have Java 17 installed, but you probably don't want to get rid of your (working) version already installed. If you are on Linux, most distros provide some way of switching the current default JRE. In debian/ubuntu based distros, you can install Java 17 using apt and use update-alternatives --java. On Arch Linux you can use archlinux-java to set the default JRE after installing from the official repos.
2. Clean and rebuild the project. In the root of the project, I ran npx react-native start --reset-cache. In the android directory, I ran ./gradlew clean
3. Start the project with ./tools/run-android --stacktrace --info

Googling the specific error returns this SO question as the first result:
https://stackoverflow.com/questions/67782975/how-to-fix-the-module-java-base-does-not-opens-java-io-to-unnamed-module

While it's not clear to me the exact reason for the specific error, the general consensus appears to be a mismatch between Gradle and JRE versions.

Gradle provides a compatibility matrix here: https://docs.gradle.org/current/userguide/compatibility.html
And indeed the first version of Gradle to support Java 17 is 7.3. It appears zulip-mobile is using 6.9:

zulip-mobile/android/gradle/wrapper/gradle-wrapper.properties

Line 9 in 29b08c5

distributionUrl=https\://services.gradle.org/distributions/gradle-6.9-all.zip

Could the solution be upgrading Gradle?

Attempting to upgrade Gradle to the minimum version that supports Java 17 results in this error:

FAILURE: Build failed with an exception.

* Where:
Build file '/home/austin/Documents/zulip/code/zulip-mobile/node_modules/expo/android/build.gradle' line: 3

* What went wrong:
A problem occurred evaluating project ':expo'.
> Plugin with id 'maven' not found.

Which leads us to the following issue:

expo/expo#12774

So it appears that only the latest versions of react-native and expo support Java17/Grade 7. So the right call might be to upgrade react-native itself.

The documentation mentions using the upgrade tool: https://reactnative.dev/docs/upgrading#1-run-the-upgrade-command which in turn uses this project: https://github.com/react-native-community/rn-diff-purge#diff-table-full-table-here to provide diffs for each react-native version upgrade. However, attempting to run the upgrade tool gives us a 404:

info No version passed. Fetching latest...
(node:292856) Warning: Accessing non-existent property 'padLevels' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
info Fetching diff between v0.64.3 and v0.67.2...
error Fetch request failed with status 404: 404: Not Found.
error Failed to fetch diff for react-native@0.67.2. Maybe it's not released yet?
info For available releases to diff see: https://github.com/react-native-community/rn-diff-purge#diff-table-full-table-here

This is interesting because that project is supposed to provide a diff matrix for each react-native version to every version after it. We are currently on version "0.64.3":

zulip-mobile/yarn.lock

Line 9641 in 29b08c5

version "0.64.3"

However, that version appears to be missing from the upgrade matrix: https://react-native-community.github.io/rn-diff-purge/

causing the upgrade tool to fail.

I have opened an issue with rn-diff-purge react-native-community/rn-diff-purge#55 so that hopefully this can be resolved.

[gnprice]

Thanks for the writeup!

For upgrading React Native to v0.65, I've just filed #5230. It sounds like either that, or a subsequent upgrade (v0.66 and v0.67 are now out too), will resolve this. So we can leave this here and let it be resolved by an upgrade.

[Mihir3]

Hi, so when I was trying to build the app on Android Emulator (Pixel 4 Google Play) via Android Studio on macOS Monterey (v 12.0.1), I ran into the same series of issues as mentioned by @Fingel above. And since the ideal solution is the upgrade of react-native version which is yet in progress, I tried to build the app with Java 15 instead of 17 considering the Gradle 6.9 configuration of the app.
And ran into the following issue :

Looking up online, found this comment on an old Github thread discussing the above issue :
alwx/react-native-photo-view#189 (comment)
which led to a suggestion to install Jetifier to provide support in :
facebook/react-native#25483 (comment)
After installing Jetifier in the project as mentioned in the above comment, the app compiled successfully.
So, I thought it might be useful to share this for new contributors trying to build the app locally on their machines until the upgraded version of Zulip app with latest react-native configuration gets released.
Hope it helps.

[gnprice]

@Mihir3 No changes like that should be necessary -- we already have a postinstall script that covers exactly that step.

In general, if you find you have to edit package.json or any other file in order to build the app, that's always something we want to resolve in the main repository (either by changing some code, or clarifying something in our setup instructions) so that other contributors don't have to do that.

I'd be interested to hear more -- would you please file a new issue, with a copy-paste of the exact commands you tried and error output you saw? (It's clearly a different issue from the one this issue thread is for -- you were using Java 15, not Java 17 -- so a new issue is best.)

Or start a thread in #mobile in the Zulip community server (https://zulip.com/development-community/) with the same information, and we'd be glad to help there.

[Mihir3]

@gnprice Thanks for the comment. And as suggested, I've opened a new issue #5288 describing the similar compilation issue.