-
Notifications
You must be signed in to change notification settings - Fork 10.8k
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
Build with --release 8, or require builds to use JDK 8 #3990
Comments
Later, assuming that the implementation of GoogleCloudPlatform/cloud-opensource-java#1605 goes in, we should consider switching to the Linkage Checker Enforcer Rule. |
Ah, but the Linkage Checker will check only against the JDK that you're using to build. So we're back to needing to require builds to use JDK 8. And all the Linkage Checker would be doing then is looking at dependencies (of which we have effectively none). |
|
As I just noted on the protobuf thread, it sounds like the best option is to require builds to be done with JDK 8. (It might also be OK to build with a newer JDK but with an older bootclasspath, but I'm not sure how well supported that is, since bootclasspath is on the way out. I gather that we're internally doing something along those lines with Bazel, but I don't know how easy it is to do the equivalent externally or with Maven.) We could consider requiring JDK 8 only for release builds. That would make life easier for an average developer who wants to contribute to Guava (and might not have JDK 8 lying around). On the other hand, it might make it more confusing to reproduce actual problems. Maybe we'd want to support some kind of Hmm, and we have Travis building with various versions.... I wonder how long it will be until openjdk8 is no longer available there. |
(Certainly we at least want it to be possible to build and test with another JDK, since we want to verify that Guava works with new Java versions.) |
Hmm, internally we're not going to be able to keep building with JDK 8 after our switchover. (And as established above, we can't just use Such a check, of course, would catch only the methods that we specifically program it to look for. If we get things right internally, that should also make it possible to build with JDK 11 externally. And building with JDK 11 is good for at least one more reason: Just as we currently use We'll see if it's still straightforward to refer to |
Hmm, and this is not the same thing, but when testing my fix for
It works fine if I set JAVA_HOME, but it's unfortunate that that's necessary. I will see if 3.2.0 works better. |
(3.2.0 has the same problem.) |
…rns in Java 9+. Doing so produces a jar that doesn't work under Java 8. This CL addresses the currently existing problematic calls (by calling the methods on the supertype Buffer instead), but we should also add safeguards. The normal solution to this general problem is to use --release, but doing so here is complicated. For more information, see #3990 RELNOTES=n/a ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=327654073
Ah, since we run our build and tests under JDK 11 with Travis, I guess we have evidence that that works, at least currently :) |
…rns in Java 9+. Doing so produces a jar that doesn't work under Java 8. This CL addresses the currently existing problematic calls (by calling the methods on the supertype Buffer instead), but we should also add safeguards. The normal solution to this general problem is to use --release, but doing so here is complicated. For more information, see #3990 RELNOTES=n/a ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=327654073
406a4ea did enough that I'm no longer alarmed about this. Still, we'll want to do more before too long. |
Some work on |
We already have cases of the conditional use I described above. Specifically, we use APIs from higher than Java 6 in guava-android -- again, only conditionally, but guava/android/guava/src/com/google/common/util/concurrent/FuturesGetChecked.java Line 117 in c8d0536
|
|
We can also consider using That said, that is an option only for the JRE, not for Android. That said, we less urgently need |
This is the first use of a Java 9 API in Guava, but we use the API only when it's available, so we maintain compatibility with Java 8. Use of Java 9 APIs is relevant to #6549 and #3990 (and also mojohaus/animal-sniffer#67). I didn't make the same change for `guava-android`, which [will add `java.util.zip.CRC32C` in API Level 34](https://developer.android.com/reference/java/util/zip/CRC32C). I don't know if Android is providing similar performance improvements, so it might not even matter. But even if I wanted to do it, I can't with my current approach, which relies on `MethodHandle`—unless I want to make even the usage of `MethodHandle` conditional on a reflective check :) RELNOTES=`hash`: Enhanced `crc32c()` to use Java's hardware-accelerated implementation where available. PiperOrigin-RevId: 539983316
There are many downsides to the "be very very sure" approach, but one that's only recently occurred to me is this: Other people may build their own copies of Guava for internal use (to fulfill security requirements, to apply patches, to insert debugging printlns...). It would be nice if they didn't encounter any unpleasant surprises when they switch from a prebuilt Guava to a version that they build locally—and potentially build with a different version of javac. (not that we are currently relying on our builds to be built with JDK 8, but the JDK developers have the right to make another |
Coming here from google/auto#1596 Fwiw, that "animal sniffer doesn't detect everything" issue has been known for almost a decade (and the underlying issue for much more: there's a reason why javac warns when using |
The bizarre thing about the |
Sorry, I was a bit distracted by my Animal Sniffer grouchiness yesterday, and I didn't really speak much to your point, nor think things through a whole lot in general. If I had any point yesterday, it would be: The combination of Animal Sniffer and an additional build with Java 8 has worked pretty well for us, except for the For our projects that don't even use Animal Sniffer yet, I definitely would want to pursue the toolchain-based approach (rather than Animal Sniffer) if we were to decide to pursue anything at all. Our current approach in Guava (and Truth and maybe others) is Doing It Wrong (though we're likely to be OK in practice, given that we've thrown yet more testing thrown into the mix). Your comment also reminds me that, while I found that we could add |
We're also hearing that Android desugaring is more reliable when libraries are compiled against |
(Ideally we'd have a test that runs D8/R8 over |
I'm not sure that any of these end up being _necessary_ to what I'm doing in #7331 (comment) / #3990 (comment). But the upgrade to `maven-surefire-plugin` changes that plugin's toolchain behavior, so I particularly want to use the new version there in advance of starting to use toolchains. RELNOTES=n/a PiperOrigin-RevId: 655556207
I'm not sure that any of these end up being _necessary_ to what I'm doing in #7331 (comment) / #3990 (comment). But the upgrade to `maven-surefire-plugin` changes that plugin's toolchain behavior, so I particularly want to use the new version there in advance of starting to use toolchains. This includes a workaround for a bug in the JDK 8 javac. (I don't know why the bug is appearing only after these upgrades.) ``` Error: /home/runner/work/guava/guava/guava/src/com/google/common/hash/BloomFilter.java:[78,29] error: cannot find symbol symbol: class Serializable location: class BloomFilter<T> where T is a type-variable: T declared in class BloomFilter ``` RELNOTES=n/a PiperOrigin-RevId: 655556207
In particular: - Use JDK 22 for compilation to [avoid a JDK 11 bug](#7331). - Another way to avoid that bug would be to use JDK 8, which [would also provide a `--release`-like compatibility guarantee](#3990). However, that could complicate [using newer APIs conditionally](#6549). And of course we'd expect JDK 8 to be buggier than JDK 22. (In fact, we still have a workaround or two for JDK 8 bugs (with a brand new one coming in cl/655556207), and we could now remove those—assuming that none of our users use JDK 8 to build Guava outside of our Maven build.) JDK 22 also supports new versions of Error Prone, while JDK 8 does not. - This change also allows us to simplify our Error Prone configuration, which until now needed different profiles in order to support both JDK 8 and JDK 9+. We could now upgrade Error Prone, but I haven't done so yet. - Continue to use JDK 11 for Javadoc, as [we're doing now](https://github.com/google/guava/blob/5041fbe61965a73ea269c7c24ea746d89bd1b1ba/.github/workflows/ci.yml#L89-L99) because of [problems with at least JDK 21](#7109). - What matters might actually be the version used [by _JDiff_](#6549 (comment)), which comes from the version in the linked `ci.yml` file. But since we're using JDK 11 currently for docs in general, I'm sticking with that for now. Still, we should consider [upgrading the version used for Javadoc generation](#6790 (comment)). But this CL is already complicated enough.... - When we hard-code JDK 11, we need to remove the `<source>${java.specification.version}</source>` line: That would otherwise set (for example) `-source 17` when running Maven under JDK 17, and JDK 11 wouldn't recognize it. As I recall, the `java.specification.version` usage was from the days in which we tried to inherit Javadoc from the JDK. Inheritance had [stopped working](#6790), and we ripped it out in cl/614693592. (See also [these notes](#5457 (comment)).) Fixes #7331 RELNOTES=n/a PiperOrigin-RevId: 655592201
In particular: - Use JDK 22 for compilation to [avoid a JDK 11 bug](#7331). - Another way to avoid that bug would be to use JDK 8, which [would also provide a `--release`-like compatibility guarantee](#3990). However, that could complicate [using newer APIs conditionally](#6549). And of course we'd expect JDK 8 to be buggier than JDK 22. (In fact, we still have a workaround or two for JDK 8 bugs (with a brand new one coming in cl/655556207), and we could now remove those—assuming that none of our users use JDK 8 to build Guava outside of our Maven build.) JDK 22 also supports new versions of Error Prone, while JDK 8 does not. - This change also allows us to simplify our Error Prone configuration, which until now needed different profiles in order to support both JDK 8 and JDK 9+. We could now upgrade Error Prone, but I haven't done so yet. - Continue to use JDK 11 for Javadoc, as [we're doing now](https://github.com/google/guava/blob/5041fbe61965a73ea269c7c24ea746d89bd1b1ba/.github/workflows/ci.yml#L89-L99) because of [problems with at least JDK 21](#7109). - What matters might actually be the version used [by _JDiff_](#6549 (comment)), which comes from the version in the linked `ci.yml` file. But since we're using JDK 11 currently for docs in general, I'm sticking with that for now. Still, we should consider [upgrading the version used for Javadoc generation](#6790 (comment)). But this CL is already complicated enough.... - When we hard-code JDK 11, we need to remove the `<source>${java.specification.version}</source>` line: That would otherwise set (for example) `-source 17` when running Maven under JDK 17, and JDK 11 wouldn't recognize it. As I recall, the `java.specification.version` usage was from the days in which we tried to inherit Javadoc from the JDK. Inheritance had [stopped working](#6790), and we ripped it out in cl/614693592. I assume that we'll now get the default from the JDK whose Javadoc binary we're using, which (again) will now be 11. That seems fine. We could consider setting it to 8 to match our normal build (which I thought I had remembered was the `maven-javadoc-plugin` default, but I don't think I'm seeing that, at least not under our current versions), but I don't see much downside to 11—or even to newer versions that we might someday use for Maven Javadoc generation, given that we keep the code compiling under new versions already. Some other thing I'm wondering: - I wonder if we should activate(?) some of the plugins, including the new toolchain plugins, in the `<plugins>` (not just `<pluginManagement>`) section of the parent `pom.xml`. Might that save us from having to do so in each separate `pom.xml`? (We might actually mostly get away with activating(?) them only in the main `guava` build: That _downloads and registers_ the toolchains, and then at least the other projects' _per-plugin_ toolchain configuration probably finds them? But for the more general configuration to work, I think we at least need to activate(?) `maven-toolchains-plugin` in each? I haven't experimented a ton with this.) (See also [these notes](#5457 (comment)).) So Fixes #7331 RELNOTES=n/a PiperOrigin-RevId: 655592201
In particular: - Use JDK 22 for compilation to [avoid a JDK 11 bug](#7331). - Another way to avoid that bug would be to use JDK 8, which [would also provide a `--release`-like compatibility guarantee](#3990). However, that could complicate [using newer APIs conditionally](#6549). And of course we'd expect JDK 8 to be buggier than JDK 22. (In fact, we still have a workaround or two for JDK 8 bugs (with a brand new one coming in cl/655556207), and we could now remove those—assuming that none of our users use JDK 8 to build Guava outside of our Maven build.) JDK 22 also supports new versions of Error Prone, while JDK 8 does not. - This change also allows us to simplify our Error Prone configuration, which until now needed different profiles in order to support both JDK 8 and JDK 9+. We could now upgrade Error Prone, but I haven't done so yet. - Continue to use JDK 11 for Javadoc, as [we're doing now](https://github.com/google/guava/blob/5041fbe61965a73ea269c7c24ea746d89bd1b1ba/.github/workflows/ci.yml#L89-L99) because of [problems with at least JDK 21](#7109). - What matters might actually be the version used [by _JDiff_](#6549 (comment)), which comes from the version in the linked `ci.yml` file. But since we're using JDK 11 currently for docs in general, I'm sticking with that for now. Still, we should consider [upgrading the version used for Javadoc generation](#6790 (comment)). But this CL is already complicated enough.... - When we hard-code JDK 11, we need to remove the `<source>${java.specification.version}</source>` line: That would otherwise set (for example) `-source 17` when running Maven under JDK 17, and JDK 11 wouldn't recognize it. As I recall, the `java.specification.version` usage was from the days in which we tried to inherit Javadoc from the JDK. Inheritance had [stopped working](#6790), and we ripped it out in cl/614693592. I assume that we'll now get the default from the JDK whose Javadoc binary we're using, which (again) will now be 11. That seems fine. We could consider setting it to 8 to match our normal build (which I thought I had remembered was the `maven-javadoc-plugin` default, but I don't think I'm seeing that, at least not under our current versions), but I don't see much downside to 11—or even to newer versions that we might someday use for Maven Javadoc generation, given that we keep the code compiling under new versions already. Some other thing I'm wondering: - I wonder if we should activate(?) some of the plugins, including the new toolchain plugins, in the `<plugins>` (not just `<pluginManagement>`) section of the parent `pom.xml`. Might that save us from having to do so in each separate `pom.xml`? (We might actually mostly get away with activating(?) them only in the main `guava` build: That _downloads and registers_ the toolchains, and then at least the other projects' _per-plugin_ toolchain configuration probably finds them? But for the more general configuration to work, I think we at least need to activate(?) `maven-toolchains-plugin` in each? I haven't experimented a ton with this.) (See also [these notes](#5457 (comment)).) So Fixes #7331 RELNOTES=n/a PiperOrigin-RevId: 655592201
In particular: - Use JDK 22 for compilation to [avoid a JDK 11 bug](#7331). - Another way to avoid that bug would be to use JDK 8, which [would also provide a `--release`-like compatibility guarantee](#3990). However, that could complicate [using newer APIs conditionally](#6549). And of course we'd expect JDK 8 to be buggier than JDK 22. (In fact, we still have a workaround or two for JDK 8 bugs (with a brand new one coming in cl/655556207), and we could now remove those—assuming that none of our users use JDK 8 to build Guava outside of our Maven build.) JDK 22 also supports new versions of Error Prone, while JDK 8 does not. - This change also allows us to simplify our Error Prone configuration, which until now needed different profiles in order to support both JDK 8 and JDK 9+. We could now upgrade Error Prone, but I haven't done so yet. - Continue to use JDK 11 for Javadoc, as [we're doing now](https://github.com/google/guava/blob/5041fbe61965a73ea269c7c24ea746d89bd1b1ba/.github/workflows/ci.yml#L89-L99) because of [problems with at least JDK 21](#7109). - What matters might actually be the version used [by _JDiff_](#6549 (comment)), which comes from the version in the linked `ci.yml` file. But since we're using JDK 11 currently for docs in general, I'm sticking with that for now. Still, we should consider [upgrading the version used for Javadoc generation](#6790 (comment)). But this CL is already complicated enough.... - When we hard-code JDK 11, we need to change the `<source>${java.specification.version}</source>` line: That would otherwise set (for example) `-source 17` when running Maven under JDK 17, and JDK 11 wouldn't recognize it. As I recall, the `java.specification.version` usage was from the days in which we tried to inherit Javadoc from the JDK. Inheritance had [stopped working](#6790), and we ripped it out in cl/614693592. I first tried going with the default from the JDK whose Javadoc binary we're using, which (again) will now be 11. But that led to a problem in `org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor`, which apparently tries to look up the module name for the `-source 11` run but uses the Maven run's JDK instead of the Javadoc toolchain or Maven toolchain. So now I've set it to 8 to match what we use for `maven-compiler-plugin`. (I _thought_ I had remembered that `maven-javadoc-plugin` defaulted to matching `maven-compiler-plugin`, even though that's weird. Maybe the two actually just read from the same Maven property or something, or maybe the behavior changed.) Some other thing I'm wondering: - I wonder if we should activate(?) some of the plugins, including the new toolchain plugins, in the `<plugins>` (not just `<pluginManagement>`) section of the parent `pom.xml`. Might that save us from having to do so in each separate `pom.xml`? (We might actually mostly get away with activating(?) them only in the main `guava` build: That _downloads and registers_ the toolchains, and then at least the other projects' _per-plugin_ toolchain configuration probably finds them? But for the more general configuration to work, I think we at least need to activate(?) `maven-toolchains-plugin` in each? I haven't experimented a ton with this.) - I forgot the other thing while I was typing :( (See also [these notes](#5457 (comment)).) So Fixes #7331 RELNOTES=n/a PiperOrigin-RevId: 655592201
I'm not sure that any of these end up being _necessary_ to what I'm doing in #7331 (comment) / #3990 (comment). But the upgrade to `maven-surefire-plugin` changes that plugin's toolchain behavior, so I particularly want to use the new version there in advance of starting to use toolchains. This includes a workaround for a bug in the JDK 8 javac. (I don't know why the bug is appearing only after these upgrades.) ``` Error: /home/runner/work/guava/guava/guava/src/com/google/common/hash/BloomFilter.java:[78,29] error: cannot find symbol symbol: class Serializable location: class BloomFilter<T> where T is a type-variable: T declared in class BloomFilter ``` RELNOTES=n/a PiperOrigin-RevId: 655556207
I'm not sure that any of these end up being _necessary_ to what I'm doing in #7331 (comment) / #3990 (comment). But the upgrade to `maven-surefire-plugin` changes that plugin's toolchain behavior, so I particularly want to use the new version there in advance of starting to use toolchains. This includes a workaround for a bug in the JDK 8 javac. (I don't know why the bug is appearing only after these upgrades.) ``` Error: /home/runner/work/guava/guava/guava/src/com/google/common/hash/BloomFilter.java:[78,29] error: cannot find symbol symbol: class Serializable location: class BloomFilter<T> where T is a type-variable: T declared in class BloomFilter ``` RELNOTES=n/a PiperOrigin-RevId: 655637260
In particular: - Use JDK 22 for compilation (also, for any other [affected plugins](https://maven.apache.org/guides/mini/guide-using-toolchains.html#prerequisites)) to [avoid a JDK 11 bug](#7331). - Another way to avoid that bug would be to use JDK 8, which [would also provide a `--release`-like compatibility guarantee](#3990). However, that could complicate [using newer APIs conditionally](#6549). And of course we'd expect JDK 8 to be buggier than JDK 22. (In fact, we still have a workaround or two for JDK 8 bugs (with a brand new one coming in cl/655556207), and we could now remove those—assuming that none of our users use JDK 8 to build Guava outside of our Maven build.) JDK 22 also supports new versions of Error Prone, while JDK 8 does not. - This change also allows us to simplify our Error Prone configuration, which until now needed different profiles in order to support both JDK 8 and JDK 9+. We could now upgrade Error Prone, but I haven't done so yet. There are probably other simplifications that we could perform, as well, such as `maven-javadoc-plugin.additionalJOptions`. - Originally, I'd set up this CL to explicitly set only the toolchain of `maven-compiler-plugin` to 22. I had it using 11 for any other plugins (just Animal Sniffer, maybe?), I think from when I was trying to get toolchains to take effect at all. I've since changed this CL to set the _default_ toolchain to 22 while still including overrides for `maven-javadoc-plugin` and `maven-surefire-plugin`. - Continue to use JDK 11 for Javadoc, as [we're doing now](https://github.com/google/guava/blob/5041fbe61965a73ea269c7c24ea746d89bd1b1ba/.github/workflows/ci.yml#L89-L99) because of [problems with at least JDK 21](#7109). - What matters might actually be the version used [by _JDiff_](#6549 (comment)), which comes from the version in the linked `ci.yml` file. But since we're using JDK 11 currently for docs in general, I'm sticking with that for now. Still, we should consider [upgrading the version used for Javadoc generation](#6790 (comment)). But this CL is already complicated enough.... - When we hard-code JDK 11, we need to change the `<source>${java.specification.version}</source>` line: That would otherwise set (for example) `-source 17` when running Maven under JDK 17, and JDK 11 wouldn't recognize it. As I recall, the `java.specification.version` usage was from the days in which we tried to inherit Javadoc from the JDK. Inheritance had [stopped working](#6790), and we ripped it out in cl/614693592. I first tried going with the default from the JDK whose Javadoc binary we're using, which (again) will now be 11. But that led to a problem in `org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor`, which apparently tries to look up the module name for the `-source 11` run but uses the Maven run's JDK instead of the Javadoc toolchain or Maven toolchain. So now I've set it to 8 to match what we use for `maven-compiler-plugin`. (I _thought_ I had remembered that `maven-javadoc-plugin` defaulted to matching `maven-compiler-plugin`, even though that's weird. Maybe the two actually just read from the same Maven property or something, or maybe the behavior changed.) Some other thing I'm wondering: - I wonder if we should activate(?) some of the plugins, including the new toolchain plugins, in the `<plugins>` (not just `<pluginManagement>`) section of the parent `pom.xml`. Might that save us from having to do so in each separate `pom.xml`? (We might actually mostly get away with activating(?) them only in the main `guava` build: That _downloads and registers_ the toolchains, and then at least the other projects' _per-plugin_ toolchain configuration probably finds them? But for the more general configuration to work, I think we at least need to activate(?) `maven-toolchains-plugin` in each? I haven't experimented a ton with this.) - I forgot the other thing while I was typing :( (See also [these notes](#5457 (comment)).) Fixes #7331 RELNOTES=n/a PiperOrigin-RevId: 655592201
In particular: - Use JDK 22 for compilation (also, for any other [affected plugins](https://maven.apache.org/guides/mini/guide-using-toolchains.html#prerequisites)) to [avoid a JDK 11 bug](#7331). - Another way to avoid that bug would be to use JDK 8, which [would also provide a `--release`-like compatibility guarantee](#3990). However, that could complicate [using newer APIs conditionally](#6549). And of course we'd expect JDK 8 to be buggier than JDK 22. (In fact, we still have a workaround or two for JDK 8 bugs (with a brand new one coming in cl/655556207), and we could now remove those—assuming that none of our users use JDK 8 to build Guava outside of our Maven build.) JDK 22 also supports new versions of Error Prone, while JDK 8 does not. - This change also allows us to simplify our Error Prone configuration, which until now needed different profiles in order to support both JDK 8 and JDK 9+. We could now upgrade Error Prone, but I haven't done so yet. There are probably other simplifications that we could perform, as well, such as `maven-javadoc-plugin.additionalJOptions`. - Originally, I'd set up this CL to explicitly set only the toolchain of `maven-compiler-plugin` to 22. I had it using 11 for any other plugins (just Animal Sniffer, maybe?), I think from when I was trying to get toolchains to take effect at all. I've since changed this CL to set the _default_ toolchain to 22 while still including overrides for `maven-javadoc-plugin` and `maven-surefire-plugin`. - Continue to use JDK 11 for Javadoc, as [we're doing now](https://github.com/google/guava/blob/5041fbe61965a73ea269c7c24ea746d89bd1b1ba/.github/workflows/ci.yml#L89-L99) because of [problems with at least JDK 21](#7109). - What matters might actually be the version used [by _JDiff_](#6549 (comment)), which comes from the version in the linked `ci.yml` file. But since we're using JDK 11 currently for docs in general, I'm sticking with that for now. Still, we should consider [upgrading the version used for Javadoc generation](#6790 (comment)). But this CL is already complicated enough.... - When we hard-code JDK 11, we need to change the `<source>${java.specification.version}</source>` line: That would otherwise set (for example) `-source 17` when running Maven under JDK 17, and JDK 11 wouldn't recognize it. As I recall, the `java.specification.version` usage was from the days in which we tried to inherit Javadoc from the JDK. Inheritance had [stopped working](#6790), and we ripped it out in cl/614693592. I first tried going with the default from the JDK whose Javadoc binary we're using, which (again) will now be 11. But that led to a problem in `org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor`, which apparently tries to look up the module name for the `-source 11` run but uses the Maven run's JDK instead of the Javadoc toolchain or Maven toolchain. So now I've set it to 8 to match what we use for `maven-compiler-plugin`. (I _thought_ I had remembered that `maven-javadoc-plugin` defaulted to matching `maven-compiler-plugin`, even though that's weird. Maybe the two actually just read from the same Maven property or something, or maybe the behavior changed.) Some other thing I'm wondering: - I wonder if we should activate(?) some of the plugins, including the new toolchain plugins, in the `<plugins>` (not just `<pluginManagement>`) section of the parent `pom.xml`. Might that save us from having to do so in each separate `pom.xml`? (We might actually mostly get away with activating(?) them only in the main `guava` build: That _downloads and registers_ the toolchains, and then at least the other projects' _per-plugin_ toolchain configuration probably finds them? But for the more general configuration to work, I think we at least need to activate(?) `maven-toolchains-plugin` in each? I haven't experimented a ton with this.) - I forgot the other thing while I was typing :( (See also [these notes](#5457 (comment)).) Fixes #7331 RELNOTES=n/a PiperOrigin-RevId: 655647768
#7333 has provided yet another line of defense here: It arranges for us to always build with the same JDK version (currently 22) but to then run tests with JDK 8 and others. It is still possible for an incompatibility to sneak through if we're lacking in test coverage, but again, this is all yet another line of defense (in addition to, e.g., Animal Sniffer, which was already quite good at catching API problems, the main problems [edit: though not necessarily the only ones]), so we should have gone from "in quite good shape" to "in very good shape." [edit: I confirmed that, if I insert calls to JDK 9+ |
Another thing that we've considered in the past but that I don't see discussed here is the approach that we use inside Google: We could use the javac The tricky part might be getting the path to that JDK. It would be nice if there were some way to get the path to a given JDK toolchain as a system property, but I haven't found one so far. We presumably could use I doubt that it's worth it unless something changes. But something very well could change, perhaps with |
I wonder how much work we could avoid, if any, by migrating to Bazel, which I believe has support for Java toolchains. 🤔 |
Yeah, I wonder that from time to time. I know that, earlier on, there were relatively frequent changes in Bazel, which we weren't great about keeping up with in our few projects that do use Bazel. I imagine that that's stabilized a bit by now, and it's not like Maven has been maintenance-free, either :) I do think we're in a fairly decent place with Maven at the moment, though I would still like to do things like:
I don't have a great feel for whether those would be easier on net with Bazel than with Maven, but obviously we'd rather not figure them all out with Maven and then re-figure them all out with Bazel.... |
I've been asking myself similar questions about Error Prone :) It would make things like MR-JARs and |
I discovered in protocolbuffers/protobuf#7827 (comment) that Animal Sniffer does not fail the build for dangerous covariant return types. This means that, if we build a Guava release with JDK 11 (which we probably will, if we haven't already!), it will contain references that don't work under JDK 8. We do in fact have such references.
Luckily, I do not see any additional such problems in the Android branch. (Presumably our internal Android tests have detected any possible problems so far.)
We should set this up before our next release or else be VERY VERY sure to use JDK 8 to build it.
The text was updated successfully, but these errors were encountered: