Consider switching minimum JDK support to 1.8 and release 4.2.0 #8259
Comments
|
And just to be clear 4.2.0 would be completely identical in terms of API etc with 4.1.0. The only difference would be the minimum java version requirement for now |
|
+1. The minimum jdk version for cassandra is java 8, with cassandra version 3.0 and higher. |
|
Most open-source projects now require Java 8 so I think that's a good idea. With regards to 4.2.x versus 5.0.0, it seems like you're suggesting the former since the Netty APIs will remain the same even if some will see this as a breaking change. A number of people in the Kafka community were opposed to bumping the Java version requirement without a major version bump in Kafka itself. We bumped Kafka's major version and then some were confused that there weren't major API changes in Kafka. So some people will be confused either way. :) |
|
@ijuma yeah the former... That said I want to start working on netty 5 soon as well, which will contain API breakage of course. |
|
I like the idea of having an artifact that can be used as a compatible drop-in for 4.1.x with improved performance in exchange for a higher JDK. With Lettuce requiring Java 8 anyways and the broad Java 8 requirements as of Project Reactor and Spring Framework, this should be a nice alignment. |
|
This sounds fine to me. gRPC is still supporting Java 7, but we can make it where just grpc-netty requires Java 8. I had been starting discussions on dropping Java 7 as well in grpc/grpc-java#4671 . We (grpc) may want to do a "soft" Java 8 release before Netty where we just change the bytecode, so we can see any fall-out before it is hard to backpedal. Yes, we could stay on 4.1, but it'd be useful to know ahead-of-time if we can't jump to 4.2. |
|
+1, please :) and I guess you'll support parallel 4.1.x/4.2.x API-compatible releases for some time with no distinction of major features, that would be ideal for projects that still need to transition from 7 to 8. |
|
Yes that would be my plan |
|
+1 from us! |
|
Green from us. |
|
+1 from us😄 |
|
Cool, +1 from us. |
|
Also @rkapsi |
|
@normanmaurer two 👍 from us |
|
+1. Migrated to Java 8 loooong time ago. Just curious if we should call this new version 4.2 or 5.0. By choosing 5.0, 1) we can emit a strong signal that it's not a drop-in replacement and 2) we can finally hide the ancient 5.0.0.AlphaX releases from search.maven.org, but I'm just fine with 4.2 as well. |
|
+1. expect since jdk 11 |
|
+1.Good。And JDK11 coming soon。 |
|
+1, please :) , and JDK 11 support as well. |
|
+1 for 8 |
|
@normanmaurer is there any planned dates for this? |
|
Not yet
… Am 05.10.2018 um 16:16 schrieb Dmitriy Dumanskiy ***@***.***>:
@normanmaurer is there any planned dates for this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
+1 from us too. |
|
+1 from us! |
|
+1 from us too! |
|
+1 from us too |
|
+1 |
|
@normanmaurer thoughts on this given latest changes to |
|
+1 |
|
Anything holding this up? I am looking at some contention issues right now in Let's do it! |
|
@normanmaurer any updates on dropping JDK versions less than 1.8? Would like to see Netty get rid of |
|
+1 We're running Java 11 in production now, with some legacy Hadoop stuff stuck on Java 8. I'm fairly sure our security team would knock down a suggestion to run anything on Java 7! |
|
@normanmaurer so 3 years passed since that proposal and still no movements... Is there anything that blocks you maybe? Java 17 will be released soon and netty is not even on Java 8, not good. |
Motivation: The workaround introduced by netty#203 (completed by netty#5644) on bug [JDK-6427854](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6427854) turns out to be no longer applicable since Java 1.7. Only first few builds of JDK 7 were affected by the bug, which got fixed in **build 8**. Since JDK 7 was feature complete in [build 123](https://blogs.oracle.com/java/post/jdk-7-feature-complete), there's no need to therefore apply the workaround since Java 1.7. Modifications: This commit makes sure the workaround (consisting in setting the system property `sun.nio.ch.bugLevel` to an empty string unless defined) doesn't get applied when the detected Java version is greater than or equal to 1.7. Result: The workaround gets only applied for Java versions strictly prior to 1.7. Conditioning the workaround to the Java version will incidentally help get rid of it when bumping up the minimum JDK support as proposed in various issues s.a. netty#8259 and netty#8540.
Motivation: The workaround introduced by #203 (completed by #5644) on bug [JDK-6427854](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6427854) turns out to be no longer applicable since Java 1.7. Only first few builds of JDK 7 were affected by the bug, which got fixed in **build 8**. Since JDK 7 was feature complete in [build 123](https://blogs.oracle.com/java/post/jdk-7-feature-complete), there's no need to therefore apply the workaround since Java 1.7. Modifications: This commit makes sure the workaround (consisting in setting the system property `sun.nio.ch.bugLevel` to an empty string unless defined) doesn't get applied when the detected Java version is greater than or equal to 1.7. Result: The workaround gets only applied for Java versions strictly prior to 1.7. Conditioning the workaround to the Java version will incidentally help get rid of it when bumping up the minimum JDK support as proposed in various issues s.a. #8259 and #8540.
Motivation: The workaround introduced by netty#203 (completed by netty#5644) on bug [JDK-6427854](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6427854) turns out to be no longer applicable since Java 1.7. Only first few builds of JDK 7 were affected by the bug, which got fixed in **build 8**. Since JDK 7 was feature complete in [build 123](https://blogs.oracle.com/java/post/jdk-7-feature-complete), there's no need to therefore apply the workaround since Java 1.7. Modifications: This commit makes sure the workaround (consisting in setting the system property `sun.nio.ch.bugLevel` to an empty string unless defined) doesn't get applied when the detected Java version is greater than or equal to 1.7. Result: The workaround gets only applied for Java versions strictly prior to 1.7. Conditioning the workaround to the Java version will incidentally help get rid of it when bumping up the minimum JDK support as proposed in various issues s.a. netty#8259 and netty#8540.
Motivation: The workaround introduced by netty#203 (completed by netty#5644) on bug [JDK-6427854](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6427854) turns out to be no longer applicable since Java 1.7. Only first few builds of JDK 7 were affected by the bug, which got fixed in **build 8**. Since JDK 7 was feature complete in [build 123](https://blogs.oracle.com/java/post/jdk-7-feature-complete), there's no need to therefore apply the workaround since Java 1.7. Modifications: This commit makes sure the workaround (consisting in setting the system property `sun.nio.ch.bugLevel` to an empty string unless defined) doesn't get applied when the detected Java version is greater than or equal to 1.7. Result: The workaround gets only applied for Java versions strictly prior to 1.7. Conditioning the workaround to the Java version will incidentally help get rid of it when bumping up the minimum JDK support as proposed in various issues s.a. netty#8259 and netty#8540.
Motivation: The workaround introduced by netty#203 (completed by netty#5644) on bug [JDK-6427854](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6427854) turns out to be no longer applicable since Java 1.7. Only first few builds of JDK 7 were affected by the bug, which got fixed in **build 8**. Since JDK 7 was feature complete in [build 123](https://blogs.oracle.com/java/post/jdk-7-feature-complete), there's no need to therefore apply the workaround since Java 1.7. Modifications: This commit makes sure the workaround (consisting in setting the system property `sun.nio.ch.bugLevel` to an empty string unless defined) doesn't get applied when the detected Java version is greater than or equal to 1.7. Result: The workaround gets only applied for Java versions strictly prior to 1.7. Conditioning the workaround to the Java version will incidentally help get rid of it when bumping up the minimum JDK support as proposed in various issues s.a. netty#8259 and netty#8540.
and others
Opening this for discussion...
What are others thoughts of releasing netty 4.2.0.Final where we move to Java8 as minimum requirement ? This would allow us to get rid of some nasty reflection hacks and replace these with method handles etc.
We could still support 4.1.x for a while in parallels.
Once we start next major (a.k.a netty 5) we should consider even moving to java11 I think but thats for discussion after this one...
The text was updated successfully, but these errors were encountered: