improve Bytes.kt compatibilty for running from java 8 but compiling from java 11 #112
Conversation
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @SanjayVas and @stevenwarejones)
a discussion (no related file):
Where do we need Java 8 compatibility? While we currently use language version 8 (mainly because it doesn't matter much when using Kotlin), but I believe we've expected at least JDK 11 at runtime which IIUC doesn't have this issue.
If we do need Java 8 compatibility, then we should see about what we need for Bazel flags to use the appropriate --release option for javac as described in the article. We should also document explicitly that we intend to be compatible with Java 8 in this case. I know that there are some changes to how Bazel builds Java code in Bazel 5 if that has any impact. See #110
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, all discussions resolved (waiting on @SanjayVas)
a discussion (no related file):
Previously, SanjayVas (Sanjay Vasandani) wrote…
Where do we need Java 8 compatibility? While we currently use language version 8 (mainly because it doesn't matter much when using Kotlin), but I believe we've expected at least JDK 11 at runtime which IIUC doesn't have this issue.
If we do need Java 8 compatibility, then we should see about what we need for Bazel flags to use the appropriate
--releaseoption for javac as described in the article. We should also document explicitly that we intend to be compatible with Java 8 in this case. I know that there are some changes to how Bazel builds Java code in Bazel 5 if that has any impact. See #110
Looks like --release isn't well-supported due to also blocking access to internal APIs like sun.misc.Unsafe, which is depended upon by protobuf.
See https://www.morling.dev/blog/bytebuffer-and-the-dreaded-nosuchmethoderror/
This change is