Drop support for Java 7 #4671
Comments
|
I should note: yes, retrolambda can provide some sort of value here. But default methods require our users to run retrolambda. |
|
+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. |
|
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. |
|
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. |
|
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.
What are you referring to here? @SharpMan, are you in need of Java 7 support? |
|
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... |
|
@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. |
|
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. |
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
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
|
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. |
|
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 . |
|
Fixed in #8828 |
#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.
The text was updated successfully, but these errors were encountered: