[Netty 5] Use Java8 as minimum Java version

[normanmaurer]

Netty 5 will move to Java 11 as minimum.

This is driven by the fact that we assume that the development of Netty 5 will take some time and for people that can not switch to Java11 there will still be support for netty 4.1.

[smaldini]

Bold but interesting choice ! Java 11 is far from mainstream but it is all relative to 5.0 timeline as well so I am not too worried. We can still evaluate by then if we really needed any Java 9-11 API to achieve what we want. It seems that Finalizer/Cleaner/RefCounted might be one.

I believe the non Java 8 API tho will be pretty limited but if that happens, I wonder if we should have a 4.2 both introducing new features/changes, along with deprecations and requiring Java 8 only.

[normanmaurer]

@smaldini sounds fair enough... That said I can at least think of two things that are interesting for us which are both not in Java8.

• Compact string to maybe replace AsciiString :
  [Netty 5] Is AsciiString still useful ? #8548
• Cleaner to replace finalize() as these are for example not supported on substrate VM :
  [Netty 5] Finalizer vs Cleaner vs ReferenceCounted  #8542

[smaldini]

Yeah so we need to look at AsciiString vs String but that seems like a small price to pay to keep compat if it was the only thing. That's up for debate tho.
About finalize() I would hope we could get away without using them. Implicit behavior depending on non deterministic GC behavior seems dangerous enough that maybe the best way would be to require explicit releasing. It seems to be doable with 4 use cases: HashedWheelTimer, OpenSslContext, OpenSslEngineand PoolArena. One use case is more tricky because leaky : Recycler. We already educate users to pay attention to ReferenceCounted#release calls and management of event loop / pool resources so it shouldn't be too far a gap to maybe transition to explicit behavior here too.

[ejona86]

Java 11 may be a bit too aggressive for gRPC to use it soon, as we may need to support "the last two LTS releases." That would mean it'd be 3 years from now before gRPC could use Netty 5. Our support timelines are still a bit up-in-the-air, though.

@smaldini, #8052 will likely resolve the Recycler issue. But I don't think we could remove all usages, for example, leak detector. Although maybe we can make such things optional and then use Cleaner or ObjectCleanerThread. Or may also be possible to fake an API like Cleaner using a custom class with finalizer(). Or just periodically poll a ReferenceQueue when registering new objects to be watched. I do agree this is a reasonable risk to using Java 8.

Concerning Compact strings/AsciiString, I think it would be fair to say, "if you want Netty to be more efficient, use Java 11." As in, we can still design for preference of Java 11+ without dropping Java 8, and it's not even difficult to do so in this case.

[SharpMan]

I would have understood choosing JDK10 for Http/2 features, but you guys went straight from the goal of Java 8 to 11 ?
Did the community had any word on this ?
Although , Java11 does support tls1.3, I think the project will go through the longest ever unstable version.

[normanmaurer]

@SharpMan none of the things here is written in stone and just suggestions. We would love to hear suggestions from the community

[winterbe]

@SharpMan HTTP Client has changed from JDK 10 to 11. In Java 10 it was only available from jdk.incubator package. You shouldn’t build a library on top of that API.

[johnou]

@SharpMan I think you'll find Netty 4.x is Java 6. Java 11 is also the next LTS.

[SharpMan]

l find Netty 4.x is Java 6. Java 11 is also the next LTS.

So everyone has to deal with commercial licenses 👏

@SharpMan none of the things here is written in stone and just suggestions. We would love to hear suggestions from the community

JDK 9 Issues
JDK 10 Issues

Netty has to complete solving issues related to previous JDK versions in order to aim for the new java version. All the features mentioned on the Netty 5 report will take 2-3 years to be tested and released. So if we add the estimated time to fix JDK11 issues, it would take forever.
It is for the best of Netty to remain running on JDK8 minimal version, otherwise this project will just become a mess.

[Mr00Anderson]

Advancing Java Version
Pros:

• Modules (Smaller distros)
• Future Java (Value Types/Generic Specialization)

Cons:

• Java direct buffer allocation is slower on reading then the Unsafe direct buffer allocation. Though I have not seen if the read performance has increased on ByteBuffer.allocateDirect() in future versions of Java.

[normanmaurer]

So far we did not find any requirement for Java 11 but can life with Java 8 as minimum requirement. Let me close this one and update the title to reflect that we use Java8 as a minimum

[fabienrenaud]

@normanmaurer #8838 is slated for Netty 5 and requires Java 11

[johnou]

@fabienrenaud doesn't require Java 11, it can be optional.

[kasobol-msft]

@normanmaurer It looks like Netty 5's baseline is now JDK 11 #10650 . This issue and referenced PR mention that 4.x line is going to be supported for a time being. Could you please shed some light on the plans for the 4.x? For how long is it going to be supported?

[normanmaurer]

@kasobol-msft there is not real defined date yet but I am sure it will be quite some time