Drop Java 7 compatibility #229
Assignees
Labels
Comments
cpovirk
added
P3
type=other
|
RE: Maven Toolchains: google/error-prone#3895 (comment) |
copybara-service bot
pushed a commit
that referenced
this issue
May 30, 2023
- Set `-source 8 -target 8`. We already have a depencdency on `guava-android`, which began requiring Java 8 a while back, so we might as well unlock the ability to use Java 8 language features ourselves. (I also found I had to set `-source 8` in `maven-javadoc-plugin` to prevent it from trying to pass a `--module-path`, which leads to problems with our usages of `@NullableDecl`, which isn't in a module. That's probably unrelated: We probably just haven't run Javadoc since some `maven-javadoc-plugin` upgrade.) Work toward #240, and fixes #229 - Don't refer to Java 9+ `ByteBuffer` methods, and set up Error Prone enforcement of future such mistakes. Compare google/guava#6334. Fixes #113 RELNOTES=Officially dropped support for Java 7, and restored accidentally dropped support for Java 8. PiperOrigin-RevId: 535378262
Closed
copybara-service bot
pushed a commit
that referenced
this issue
Jun 26, 2023
Since both flavors of Guava require Java 8+ nowadays (as [will jimfs](#229)), I don't think there's an advantage of using `guava-android`. I suppose that I could look into how much of `java.file.nio` can work [under new versions of Android](https://developer.android.com/reference/java/nio/file/Path) or [with desugaring](https://developer.android.com/studio/write/java11-nio-support-table). (Notably, do custom file systems work at all?) But my guess is that, in general, any Android code that can use `java.file.nio` can use `guava-jre`—though perhaps it shouldn't do _either_ of those things :) RELNOTES=n/a PiperOrigin-RevId: 543516882
copybara-service bot
pushed a commit
that referenced
this issue
Jun 26, 2023
Since both flavors of Guava require Java 8+ nowadays (as [will jimfs](#229)), I don't think there's an advantage of using `guava-android`. I suppose that I could look into how much of `java.file.nio` can work [under new versions of Android](https://developer.android.com/reference/java/nio/file/Path) or [with desugaring](https://developer.android.com/studio/write/java11-nio-support-table). (Notably, do custom file systems work at all?) But my guess is that, in general, any Android code that can use `java.file.nio` can use `guava-jre`—though perhaps it shouldn't do _either_ of those things :) RELNOTES=n/a PiperOrigin-RevId: 543520082
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We claim compatibility with it, and we might well provide it as recently as our latest release, but we haven't been testing for compatibility since f730377 (since we didn't do whatever the Maven equivalent of https://jakewharton.com/build-on-latest-java-test-through-lowest-java/ is—I thought I had a Maven link handy, but I didn't find it instantly, so I gave up):
jimfs/.github/workflows/ci.yml
Line 17 in 8428991
I believe that we lost compatibility as of the ICU4J upgrade that we merged a while back (but haven't put in a release yet):
So mainly I think we'll just want to update our docs whenever we make another release.
The text was updated successfully, but these errors were encountered: