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

Drop support for Java 7 #4671

Closed
ejona86 opened this issue Jul 23, 2018 · 12 comments
Closed

Drop support for Java 7 #4671

ejona86 opened this issue Jul 23, 2018 · 12 comments

Comments

@ejona86
Copy link
Member

ejona86 commented Jul 23, 2018

#3961 (drop Java 6) is coming to a close. This issue is to track dropping support for Java 7. Or rather, using Java 8 language features. As discussed in #3961, Android has fine support for Java 8 language features. Java 7 isn't supported any longer and the Java community jumped on Java 8 pretty quickly. gRPC in particular would love to be able to use default methods on interfaces, and similar Java 8 features.

This issue is to track what needs to happen before we can drop Java 7. If that is "wait for X to happen," that's fine, but if we decide we can't drop Java 7 support yet we should have an idea of when it would be possible.

@ejona86 ejona86 added this to the Next milestone Jul 23, 2018
@ejona86
Copy link
Member Author

ejona86 commented Jul 24, 2018

I should note: yes, retrolambda can provide some sort of value here. But default methods require our users to run retrolambda.

@patflynn
Copy link

+1. Just to add that #4700 is an even better reason to upgrade. Diamond dep issues are a very common customer complaint and the sooner we can get our Google java lib transitive dep graph onto a common set of recent deps, the easier it'll be for most Cloud customers to use our libraries.

@ejona86
Copy link
Member Author

ejona86 commented Jul 31, 2018

There should be no diamond dependency issues specifically related to supporting an old JDK. Even with Guava, we run fine on newer versions of the libraries.

There are plenty of diamond dependency problems when using Java, because Maven fails as a package manager, but that should be considered unrelated to any JDK 7 discussion here. There is a set of package versions that work, even if Maven is not smart enough to select them for you.

@ejona86
Copy link
Member Author

ejona86 commented Sep 4, 2018

Netty is considering dropping Java 7 support in netty/netty#8259. It is possible for us to drop support for Java 7 in grpc-netty without dropping Java 7 support elsewhere.

@SharpMan
Copy link

SharpMan commented Sep 9, 2018

The support should not be dropped unless you are suggesting an important java8 feature in need.
I don't see how the miss-organization of your maven example is significant in this case.

@ejona86
Copy link
Member Author

ejona86 commented Sep 10, 2018

The support should not be dropped unless you are suggesting an important java8 feature in need.

I don't fully agree with that assertion. I would agree that it is easier to continue maintaining Java 7 support if we don't need Java 8 features, but that doesn't mean the cost is free and we should support it "just because," even if nobody is using it.

I alluded to things above with "gRPC in particular would love to be able to use default methods on interfaces, and similar Java 8 features." We are also feeling the pain as the Java ecosystem leaves Java 7 behind.

I don't see how the miss-organization of your maven example is significant in this case.

What are you referring to here?

@SharpMan, are you in need of Java 7 support?

@nicolasnoble
Copy link
Member

By the way, we're still supporting NodeJS 4 for grpc-node, and the main reason is that dropping support for an older runtime would require a major version bump. I don't know to which extend this rule would apply here...

@ejona86
Copy link
Member Author

ejona86 commented Sep 10, 2018

@nicolasnoble, that's not a universal opinion and we are not concerned with it here. Major vs minor version doesn't really change anything functionally in Java, so it is mainly a discussion for purists.

@ejona86
Copy link
Member Author

ejona86 commented Oct 9, 2020

Guava is looking to drop Java 7 support. It currently doesn't seem there's a substantial group of gRPC users needing Java 7 support, so we're happy to follow suit. I'll mention explicitly this would not change our supported Android versions.

OpenTelemetry is requiring Java 8, where classically I've seen the tracing folks to be pretty conservative. It seems there was a straggler that would need Java 7 support, but they were going to maintain a private fork. We currently don't depend on them and we could depend on them without issue, but it is demonstration that maybe Java 7's time is passed. It does greatly improve their ability to design APIs.

Because this is a big change, I think we'll change the bytecode version but embargo actually using any of the Java 8 features for one-to-two releases. This will provide an emergency rollback strategy to resolve any unexpected issues (e.g., maybe someone's Android toolchain has trouble). That won't be enough time for all Java 7 users to notice, as they may not update grpc except once every several years. If push comes to shove after that point, where we need some level of Java 7 support, we'd probably entertain keeping an old release branch alive with basic bug fixes instead of reviving Java 7 for feature releases.

It's not clear to me if grpc-context will also drop java 7 support. If just grpc-context remains Java 7, that wouldn't be that bad. Although we'd still need to figure out how to determine when dropping Java 7 is okay. Maybe we drop Java 7 but keep an extended embargo for grpc-context to let users come to us to form a plan. There's multiple things to figure out for the module.

ejona86 added a commit to ejona86/grpc-java that referenced this issue Apr 16, 2021
This change can have large impact from two aspects:
1. It calls out a _large_ impact on the _few_ Java 7 users.
2. It may have _small_ impact on the _many_ Android users.

grpc#4671 tracks gRPC's removal of
Java 7 support. We are quite eager to drop Java 7 support as that would
allow using new language features like default methods. Guava is also
dropping Java 7 support and starting in 30.1 it will warn when used on
Java 7. The purpose of the warning is to help discover users that are
negatively impacted by dropping Java 7 before it becomes a bigger
problem.

The Guava logging check was implemented in such a way that there is an
optional class that uses Java 8 bytecode. While the class is optional at
runtime, the Android build system notices when dexing and fails if
Java 8 language featutres are not enabled. We believe this will not be a
problem for most Android users, but they may need to add to their build:

```
android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}
```

See also https://github.com/google/guava/releases/tag/v30.1
ejona86 added a commit that referenced this issue Apr 19, 2021
This change can have large impact from two aspects:
1. It calls out a _large_ impact on the _few_ Java 7 users.
2. It may have _small_ impact on the _many_ Android users.

#4671 tracks gRPC's removal of
Java 7 support. We are quite eager to drop Java 7 support as that would
allow using new language features like default methods. Guava is also
dropping Java 7 support and starting in 30.1 it will warn when used on
Java 7. The purpose of the warning is to help discover users that are
negatively impacted by dropping Java 7 before it becomes a bigger
problem.

The Guava logging check was implemented in such a way that there is an
optional class that uses Java 8 bytecode. While the class is optional at
runtime, the Android build system notices when dexing and fails if
Java 8 language featutres are not enabled. We believe this will not be a
problem for most Android users, but they may need to add to their build:

```
android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}
```

See also https://github.com/google/guava/releases/tag/v30.1
@ejona86
Copy link
Member Author

ejona86 commented Sep 27, 2021

Guava 31.0 dropped Java 7 support, so we'll probably want to follow suit soon. We need to decide if we bump our major version; bumping major version when dependencies change is explicitly not a major version per semver, but some people expect it none-the-less. If we do bump the major version then there won't be any embargo on Java 8 features for a period, as the major version makes it quite awkward to begin supporting Java 7 again after we drop it.

@ejona86
Copy link
Member Author

ejona86 commented Dec 23, 2021

I've created gRFC P5 JDK Version Support Policy: grpc/proposal#283 . The group discussion is at https://groups.google.com/g/grpc-io/c/S1biTro_sbE .

@ejona86
Copy link
Member Author

ejona86 commented Jan 18, 2022

Fixed in #8828

@ejona86 ejona86 closed this as completed Jan 18, 2022
@ejona86 ejona86 removed this from the Next milestone Jan 18, 2022
@ejona86 ejona86 added this to the 1.44 milestone Jan 18, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants