Bump the minimum required JDK to 11

[gastaldi]

JDK 11 introduces several improvements to the language (including java.net.http.HttpClient, which could be useful in case there are plans to change the HTTP implementation - see #2764), among other nice-to-have features.

[manusa]

In earlier discussions some of the team members had discrepancies with the migration (at least, myself and I think @iocanel were against it). So it would be good to see if any of the members of the community would have any problem with this and the reasons why.

+1 In my case, given the fact that JDK 17 (LTS) should be GA in a few days, it makes sense to drop support for JDK 8 and encourage users to start migrating to at least JDK 11.

Relates to:

• Move to use okhttp4 due to a bug on IPV6 based cluster #2632 (Internal Http client replacement)
• Add support for Apache HttpClient #1973

[jorsol]

I also vote for Java 11+, it would be nice to have a version using java.net.http.HttpClient (aka zero-dep) but my guess is that some features might need to be "reimplemented".

There might be users stuck in JDK8, but my guess is that applications that call K8s APIs are fairly recent, so there might not be a "real" reason beyond bureaucratic companies.

IMHO, prolonging the agony of enduring old Java versions is a waste of resources, yet I understand that companies are really slow with changes, but having libraries that are only supported in newer Java releases might be an incentive to upgrade. Also, JDK vendors don't help in this regard since Java 8 will be supported for a longer time than even Java 11!!!

[lion7]

I'd love if moving to JDK 11 also means that OkHttp will be replaced with zero-dep java.net.http.HttpClient.
Currently I'm trying to create a native image of my project using GraalVM, but it fails because OkHttp added support for GraalVM in their 5.x release and onwards. Since this (awesome!) client is still stuck at OkHttp 3.x, it just won't work.

[gastaldi]

I'd love if moving to JDK 11 also means that OkHttp will be replaced with zero-dep java.net.http.HttpClient. Currently I'm trying to create a native image of my project using GraalVM, but it fails because OkHttp added support for GraalVM in their 5.x release and onwards.

@lion7 have you used Quarkus? You can use Kubernetes-client and package into a native application without any problems: https://quarkus.io/guides/kubernetes-client

[lion7]

Cool! Thanks for the tip, this is exactly what I was looking for 😄

[shawkins]

There will hopefully be movement on #3549 which isolates the okhttp client - a summary of where things are at: #3547 (comment) - that includes a draft of the alternate jdk client.

The thinking now is to get the ball rolling on this feature in 5.11. That means it's likely we won't officially support the jdk client and may need to keep some of the methods that have been removed that relate to okhttp. That will unfortunately mean that the okhttp dependency will be needed with 5.11 - even if you supply an alternative client.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[manusa]

A JDK11 HttpClient based implementation module was added in #3857 (#3855).

Only the modules related to this implementation are baselined to Java 11 (although 16+ is recommended since there is a bug in the JDK).

The rest is still JDK 8 compatible.