Drop support for Java 6 #3961
Comments
|
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. |
|
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
|
|
oops sorry I thought this was the census repo. Ignore me!
|
|
@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. |
|
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>
.
|
|
Adding to the Java7 wishlist: |
|
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- |
|
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>
.
|
|
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>
.
|
|
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 |
|
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>
.
|
|
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. |
|
protocolbuffers/protobuf#4224 protobuf dropped Java 6 support |
|
Android is not a limiting factor. We should be able to use Java 7 (and even 8) language features and still support Android API level 14. To manage runtime API availability there are Android profiles for animalsniffer. Not everything is supported for Java 8, but most of the useful things are. For example, that would allow us to have default interface methods. Java 8 would require our users to add some configuration to their builds, but they're probably already doing that. Note that the animal sniffer piece is really important to me; I don't want constant accidental regressions to android. One notable detail: try-with-resources is not available in the "Java 7" setup in Android, but is with the "Java 8". To enable Java 8 (language features), our users would need: android {
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}More details: http://tools.android.com/recent/androidstudio032released (Java 7). https://developer.android.com/studio/write/java8-support (Java 8) We may want to encourage our users to use the Java 8 support so we can use try-with-resources. We'd still build with Java 7 bytecode. It'd help multiple parts of our code, mainly to manage suppressed exceptions. (Since older Android doesn't have suppressed exceptions, we couldn't require support for it. But "if supported, use it" is a fine approach.) |
|
For posterity, the email announcement: https://groups.google.com/d/msg/grpc-io/ajGrPStRS1I/KPlXLYmsAQAJ |
Core and OkHttp are left with Java 6 for the moment. Once we resolve their issues they could be bumped as well. Updates grpc#3961
Core and OkHttp are left with Java 6 for the moment. Once we resolve their issues they could be bumped as well. Updates #3961
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
The text was updated successfully, but these errors were encountered: