Skip to content
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 Android flavor with -source 8 -target 8 (but still avoid Java 7+ APIs) #5269

Closed
cpovirk opened this issue Oct 9, 2020 · 3 comments
Closed

Comments

@cpovirk
Copy link
Member

@cpovirk cpovirk commented Oct 9, 2020

Currently, our "Android" flavor of Guava supports 2 use cases:

  • Android users (API level 15 (Ice Cream Sandwich) and up)
  • Java 7 users

We are definitely not going to start using Java 8 APIs. Thus, we are not going to increase our minimum Android version to 24, nor are we going to require our users to enable library desugaring. In short: We'll continue to support older versions of Android with no changes on users' part.

However, we are investigating whether to stop supporting non-Android users who use Java 7. This would let us simplify some implementations (mainly by using lambdas), but more importantly, it would let us make some API improvements -- like default methods on interfaces and type annotations (such as for nullness).

This is part of a larger effort by many Google projects to consider dropping support for Java 7. Please let us know if you anticipate problems from this change -- mainly, if you are using Guava in your library or app and you support Java 7. Thanks.

(Please also spread the word. I will additionally announce this on our mailing list. Later, we may also try to introduce some warnings when Guava is run under Java 7.)

@ganeshbhargav
Copy link

@ganeshbhargav ganeshbhargav commented Oct 19, 2020

Migrating from Java 7 to Java 8 is recommended because of New language features, security improvements, Optimum performance, Writing code more efficiently, Oracle recommendation to uninstall pre-8 versions to avoid security risks, Older releases no longer publicly supported, Third party Java libraries no longer being developed and supported.

To check the new features in JDK 8 by library - check https://www.oracle.com/java/technologies/javase/8-whats-new.html

To check incompatibilities between JDK 7 and JDK 8 - https://www.oracle.com/java/technologies/javase/8-compatibility-guide.html#A999387

To check incompatibilities between Java SE 7 and SE 8 - https://www.oracle.com/java/technologies/javase/8-compatibility-guide.html#A999198

To check Features removed in JDK 8 - https://www.oracle.com/java/technologies/javase/8-compatibility-guide.html#A999476

To check Features removed in Java SE 8 - https://www.oracle.com/java/technologies/javase/8-compatibility-guide.html#CHDGHIIH

I do not anticipate any change in Applications using Guava as long as the API's remain the same and return the same result as they used to when they were in Java 7.
The compiled app with guava libraries must be able to run on Java 8 platform.

Hope this helps resolve the issue.

kluever added a commit that referenced this issue Dec 11, 2020
More precisely, log a warning if lambda expressions or type annotations in our classes would produce an exception. If someone wants to use Retrolambda or a similar tool to rewrite our classes, that's fine with us if it works. And our support for Android is unchanged: The Android toolchain rewrites lambdas and removes type annotations.

This is a step toward removing Java 7 support entirely: #5269

RELNOTES=Introduced a warning log message when running under Java 7. This warning is not _guaranteed_ to be logged when running under Java 7, so please don't rely on it as your only warning about future problems. If the warning _itself_ causes you trouble, you can eliminate it by silencing the logger for `com.google.common.base.MoreObjects$ToStringHelper` (which is used _only_ for this warning). This warning prepares for [removing support for Java 7 in 2021](#5269). Please report any problems.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=346795766
kluever added a commit that referenced this issue Dec 11, 2020
More precisely, log a warning if lambda expressions or type annotations in our classes would produce an exception. If someone wants to use Retrolambda or a similar tool to rewrite our classes, that's fine with us if it works. And our support for Android is unchanged: The Android toolchain rewrites lambdas and removes type annotations.

This is a step toward removing Java 7 support entirely: #5269

RELNOTES=Introduced a warning log message when running under Java 7. This warning is not _guaranteed_ to be logged when running under Java 7, so please don't rely on it as your only warning about future problems. If the warning _itself_ causes you trouble, you can eliminate it by silencing the logger for `com.google.common.base.MoreObjects$ToStringHelper` (which is used _only_ for this warning). This warning prepares for [removing support for Java 7 in 2021](#5269). Please report any problems.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=346795766
@ijuma
Copy link

@ijuma ijuma commented Feb 12, 2021

Out or curiosity, what's the downside of requiring library desugaring?

@cpovirk
Copy link
Member Author

@cpovirk cpovirk commented Feb 12, 2021

For most users, it's probably a reasonable thing to enable. However, there are downsides in some cases. As I understand them, the downsides are:

copybara-service bot pushed a commit that referenced this issue Mar 9, 2021
RELNOTES=Increased the aggressiveness of [Guava 30.1](https://github.com/google/guava/releases/tag/v30.1)'s warning log message for running `guava-android` under a Java 7 VM. (Android VMs are unaffected.) If the warning _itself_ causes you trouble, you can eliminate it by silencing the logger for `com.google.common.base.Preconditions` (which is used _only_ for this warning). This warning prepares for [removing support for Java 7 in 2021](#5269). Please report any problems. We have tried to make the warning as safe as possible, but anytime a common library logs, especially as aggressively as we do in this new release, there is the potential for [`NullPointerException`](https://stackoverflow.com/a/41017717/28465) or even [deadlock](https://stackoverflow.com/a/48009613/28465). (To be clear, Guava will not log under Java 8 or Android, but it will under Java 7.)
PiperOrigin-RevId: 361604103
copybara-service bot pushed a commit that referenced this issue Mar 9, 2021
RELNOTES=Increased the aggressiveness of [Guava 30.1](https://github.com/google/guava/releases/tag/v30.1)'s warning log message for running `guava-android` under a Java 7 VM. (Android VMs are unaffected.) If the warning _itself_ causes you trouble, you can eliminate it by silencing the logger for `com.google.common.base.Preconditions` (which is used _only_ for this warning). This warning prepares for [removing support for Java 7 in 2021](#5269). Please report any problems. We have tried to make the warning as safe as possible, but anytime a common library logs, especially as aggressively as we do in this new release, there is the potential for [`NullPointerException`](https://stackoverflow.com/a/41017717/28465) or even [deadlock](https://stackoverflow.com/a/48009613/28465). (To be clear, Guava will not log under Java 8 or Android, but it will under Java 7.)
PiperOrigin-RevId: 361700569
copybara-service bot pushed a commit that referenced this issue Mar 23, 2021
Relevant to #5269 in that it's an exception -- a case in which we *are* willing to use a Java 7 API because we know this particular API is safe to use under Android.

RELNOTES=n/a
PiperOrigin-RevId: 364549818
copybara-service bot pushed a commit that referenced this issue Mar 23, 2021
Relevant to #5269 in that it's an exception -- a case in which we *are* willing to use a Java 7 API because we know this particular API is safe to use under Android.

RELNOTES=n/a
PiperOrigin-RevId: 364567470
copybara-service bot pushed a commit that referenced this issue Mar 23, 2021
…sage.

This is largely a rollback of the original Java8Usage change, but I've modified it in a few ways:

- I set `-source 8 -target 8` in the backport.
- I kept the code to make includes/excludes fully work with maven-compiler-plugin, since that could save us some confusion down the line.
- I incorporated a rollback of the changes to Preconditions from CL 361700569, in which I moved the warning from MoreObjects to Preconditions.
- I added errors to our internal release scripts so that we don't accidentally make a release that drops Java 7 support before we're ready.

Fixes #5269

PiperOrigin-RevId: 364405695
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants