Drop support for Java 6

[ejona86]

This would allow using (at least some) Java 7 language features and more of the Java 7 API. Android support for Java 7 has advanced. We need to figure out exactly what restrictions we'll need, but on the surface things seem far enough along to push forward with the drop of Java 6 support.

We'd still support the subset of Java 7 that is used by Android; we're not willing to reduce our API level support for this.

@ericgribkoff

[ejona86]

For anyone seeing this and panicking, "it's okay." We plan to be careful with this and check that any solutions will work well for our users. This is an eventual goal.

[codefromthecrypt]

java 7 has few notable language features, and I think most of these can be rewritten with retrolambda. java 6 allows old apps to be automatically instrumented with an agent, something that @CodingFabian mentioned to me some time back. AFAIK you there are some lowest common denominator bytecode level rules (newer apis don't matter as long as they are not required to be called) In brave, for example, we still routinely get requests for tracing spring 2.5 applications (over 10 years old), presumably the reason people ask is indeed because they can't change them. Reason I mention this is to just help spread awareness of the android unrelated concern, not to suggest that concern must be addressed here

[codefromthecrypt]

oops sorry I thought this was the census repo. Ignore me!

[ejona86]

@adriancole, Census at least was partially following suit from gRPC, so it's still useful to know that even if gRPC drops support it may be good for Census to be more conservative.

We do actually agree that there were few Java 7 language features that are transformative. So we've not pushed too hard. But we do want Java 8 language features, and Java 7 is a stepping stone for that.

Android has come along and is even supporting Java 8 features. Java 7 is not receiving public updates and Java 8/9 public updates will stop this year. Combined with the "one + three back" policy means we may find ourselves not easily able to support Java 6. Adding in Oracle's move to a 6 month release schedule forms a bit of a perfect storm. We could possibly post-process with retrolambda or similar, but EOL increases testing burden as well.

I'm sure we'll not be the only ones trying to figure things out, so some common approaches will probably surface. But the burden is increasing for unknown benefit. Even if we decide to continue supporting Java 6, we should have an idea of how much benefit it's providing and how to determine when to stop.

The solution here may be to just rely on maintenance to old release branches, so people stuck on an older JDK stop receiving features without being completely hung to dry. But even that will have complications, like dealing with bug fixes in Netty.

Stuff to figure out.

[codefromthecrypt]

Good summary. I think there is more gravity here than census as census doesnt have an api that exposes any 3rd party types (well maybe guava). So for me there are two very different things.. the bytecode level of the api and then the implied runtime (which has all the dodgy implications and affects how code is internally written). Only major crossover issue in grpc-context as if that lifts to a higher level, so does a lot else even if context could probably be written at bytecode 1.5 ;)

…

On 12 Jan 2018 11:57 pm, "Eric Anderson" ***@***.***> wrote: @adriancole <https://github.com/adriancole>, Census at least was partially following suit from gRPC, so it's still useful to know that even if gRPC drops support it may be good for Census to be more conservative. We do actually agree that there were few Java 7 language features that are transformative. So we've not pushed too hard. But we do want Java 8 language features, and Java 7 is a stepping stone for that. Android has come along and is even supporting Java 8 features. Java 7 is not receiving public updates and Java 8/9 public updates will stop this year <http://www.oracle.com/technetwork/java/eol-135779.html>. Combined with the "one + three back" policy <http://openjdk.java.net/jeps/182> means we may find ourselves not easily able to support Java 6. Adding in Oracle's move to a 6 month release schedule forms a bit of a perfect storm. We could possibly post-process with retrolambda or similar, but EOL increases testing burden as well. I'm sure we'll not be the only ones trying to figure things out, so some common approaches will probably surface. But the burden is increasing for unknown benefit. Even if we decide to continue supporting Java 6, we should have an idea of how much benefit it's providing and how to determine when to stop. The solution here may be to just rely on maintenance to old release branches, so people stuck on an older JDK stop receiving features without being completely hung to dry. But even that will have complications, like dealing with bug fixes in Netty. Stuff to figure out. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3961 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD619MEeMrbv1dxFzxWK7kUZZPBulTcks5tJ4DpgaJpZM4RbfSt> .

[carl-mastrangelo]

Adding to the Java7 wishlist: ThreadLocalRandom and ForkJoinPool, as well as setRemoveOnCancelPolicy

[ejona86]

I just realized that Guava 20 is the last version that uses Java 6 bytecode. We really need to be able to get to/past Guava 21, because that's when Guava stopped breaking non-@Beta APIs. Guava 21 itself is not feasible, since it requires Java 8. But Guava 22-Android supports Java 7.

[codefromthecrypt]

What about a compilation test on grpc-context which uses old guava? (Or animal sniffer to do the same) On 26 Jan 2018 4:59 am, "Eric Anderson" <notifications@github.com> wrote: I just realized that Guava 20 is the last version that uses Java 6 bytecode. We really need to be able to get to/past Guava 21, because that's when Guava stopped breaking non-@beta APIs. Guava 21 itself is not feasible, since it requires Java 8. But Guava 22-Android supports Java 7. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3961 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD618QoE3fNWA15K6YPHz0Wa0OE9tk-ks5tOOsogaJpZM4RbfSt> .

[codefromthecrypt]

Actually iirc grpc-context doesnt use guava. Anyway any deps that guava/jre6 compat are important you could use same approach which still allows less restricted code to rely on newer guava or newer jre signatures. One of the advantages of a multi-module build is granularity like this

…

On 26 Jan 2018 6:58 am, "Adrian Cole" ***@***.***> wrote: What about a compilation test on grpc-context which uses old guava? (Or animal sniffer to do the same) On 26 Jan 2018 4:59 am, "Eric Anderson" ***@***.***> wrote: I just realized that Guava 20 is the last version that uses Java 6 bytecode. We really need to be able to get to/past Guava 21, because that's when Guava stopped breaking ***@***.*** APIs. Guava 21 itself is not feasible, since it requires Java 8. But Guava 22-Android supports Java 7. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3961 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD618QoE3fNWA15K6YPHz0Wa0OE9tk-ks5tOOsogaJpZM4RbfSt> .

[ejona86]

Yes, however we've got the OSGi+Java 9 module stuff that requires re-uniting grpc-context and grpc-core. We'll have the new API, but this does make migration all the more awkward. What a mess...

Maybe we split out grpc-api (io.grpc) from grpc-core (io.grpc.internal et al), and keep grpc-context+grpc-api Java 6-safe. But we do depend on Guava in io.grpc. Most of it is easy to avoid, except for BaseEncoding for base64. Maybe we move that part of Metadata to internal. Or maybe we accept the Guava dependency that simply won't be used at runtime (and so it could be safely downgraded). What a mess...

[codefromthecrypt]

luckily base64 isn't that big of a library, but anyway I think mechanics of base64 are far less troubling than the maintenance debt you hint at. @raphw what's your take on this.. how strictly do you think a library like gprc should be wrt JRE level? Are there OSGi+Java 9 problems unresolvable when pinning forward to 9 and back to 6? or maybe alternate approaches available? In brave, we use 1.6->9 with OSGi (no Java 9 module stuff yet), but easier as it isn't an I/O library so needs less ... libraries. Feel free to link any pointers to help steer this

…

On Fri, Jan 26, 2018 at 8:39 AM, Eric Anderson ***@***.***> wrote: Yes, however we've got the OSGi+Java 9 module stuff that requires re-uniting grpc-context and grpc-core. We'll have the new API, but this does make migration all the more awkward. What a mess... Maybe we split out grpc-api (io.grpc) from grpc-core (io.grpc.internal et al), and keep grpc-context+grpc-api Java 6-safe. But we do depend on Guava in io.grpc. Most of it is easy to avoid, except for BaseEncoding for base64. Maybe we move that part of Metadata to internal. Or maybe we accept the Guava dependency that simply won't be used at runtime (and so it could be safely downgraded). What a mess... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3961 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD610HgtWXFvDslUvl_pguAEFTx0Lggks5tOR7GgaJpZM4RbfSt> .

[raphw]

At the moment, the largest user groups are Java 6 and Java 8 users. Java 6 users are often in the enterprise building legacy apps and I assume that not many of those adopted gRPC. From that perspective, a direct update to Java 8 seems to make more sense than Java 7. But since it is mentioned that Android still relies on Java 7, this might be the right decission nevertheless. I thought that Android had adopted Java 8 for most features? Quick Google search basically confirmed that.

[xuwei-k]

protocolbuffers/protobuf#4224 protobuf dropped Java 6 support