Build against a newer well supported Java version

[javanegmond]

Describe the bug
The kubernetes java client is built against Java 8. This leads to a plethora of issues when using newer JDKs in projects.

Client Version
Any

Kubernetes Version
Doesn't matter

Java Version
Java 8

To Reproduce
Any Build

Expected behavior
kubernetes-client is built against a new, well supported, version of Java

KubeConfig
Not applicable

Server (please complete the following information):
Not Applicable

Additional context
As just one example, Bytebuddy (used for Mockito in testing, among others) can no longer enhance bytecode for the kubernetes client in combination with OpenJDK 21 without adding a flag for experimental support.

In #2452 some sort of workaround is laid out to be able to use the kubernetes client with Spring 6. More importantly, it is mentioned that:

because we need to maintain Java 8 compatability
And I strongly wonder why there is this need. I couldn't find it personally. Wouldn't it be more apt to move on to a new, well supported, version of Java and let projects that are stuck on Java 8 deal with it by forking this repo instead?

[brendandburns]

We're committed to supporting Java8 for the time being at least. One alternative might be to create a legacy build which supports Java8, while moving the general library forward to a newer version of the JDK.

We would be happy to entertain proposals or PRs to achieve that.

However, given the number of projects out there that still target Java8, moving forward exclusively would harm a large number of existing users and asking them to fork is not a user-centric approach.

[javanegmond]

However, given the number of projects out there that still target Java8, moving forward exclusively would harm a large number of existing users and asking them to fork is not a user-centric approach.

Not moving forward is not a community centric approach instead. A choice should be made: support a small set of users sticking to old, unsupported versions of the language, or the bigger community? If anything, we should encourage users still on Java 8 to move on.

I'll see if I can find some time to see what needs to be done to move this project towards the current era. As for legacy support (a legacy build or an untouched branch maybe); that will not be on me as you'll understand.

[javanegmond]

FWIW, running unit tests this projects master branch as is using JDK 21 runs into an absolute smashing list of errors like this one:

[ERROR]   ResyncRunnableTest.testSupplierReturnsNull » Mockito 
Mockito cannot mock this class: class io.kubernetes.client.informer.cache.DeltaFIFO.

If you're not sure why you're getting this error, please open an issue on GitHub.


Java               : 21
JVM vendor name    : Oracle Corporation
JVM vendor version : 21+35-LTS-2513
JVM name           : Java HotSpot(TM) 64-Bit Server VM
JVM version        : 21+35-LTS-2513
JVM info           : mixed mode, sharing
OS name            : Linux
OS version         : 5.4.0-166-generic


You are seeing this disclaimer because Mockito is configured to create inlined mocks.
You can learn about inline mocks and their limitations under item #39 of the Mockito class javadoc.

Underlying exception : org.mockito.exceptions.base.MockitoException: Could not modify all classes [class java.lang.Object, class io.kubernetes.client.informer.cache.DeltaFIFO]

Similar error will occur in any dependant project that mocks any of the class provided by this project in their tests. This effectively blocks users of this project from moving forward with the latest technology, or find all sorts of workarounds that are undesirable.

I think this alone is enough argument to abandon Java 8. However, even more than dropping support for Java 8, I think it's important to always support building using the newest version of the JDK and currently this project does not build with JDK 21.

[Bas83]

This would be nice. We are about to move to JDK 21 (as soon as Spring Boot 3.2.0 is released) but if there are problems with the Kubernetes client we'd not be able to move forward with that. Am I understanding correctly it wouldn't even be possible to use the library with JDK 21? Or is it only a matter of not being able to run your tests?

[javanegmond]

Am I understanding correctly it wouldn't even be possible to use the library with JDK 21? Or is it only a matter of not being able to run your tests?

If you abstain from any bytecode modifications (for example: mockito tests) on any classes built with JDK 8 (in some cases even 11 or 17), I think you should not run into runtime issues with JDK 21. No guarantees from my end on your runtime though.

[brendandburns]

I believe that if we also upgrade to mockito 6 unit tests should start working again.

[javanegmond]

I believe that if we also upgrade to mockito 6 unit tests should start working again.

Mockito 6 has not been released?
https://github.com/mockito/mockito/releases

I have built using mockito 5.6 in the attached PR; and that would still fail as long as some of the build targets older Java versions.

[brendandburns]

oops, sorry, I meant Mockito 5, got it confused w/ Spring 6 :( and yes, I think that Mockito 5 requires Java11 at least.

[brendandburns]

@Bas83 if you run into any problems using this library with Java21 other than running the unit tests, please let us know.

[codefromthecrypt]

@brendandburns I've been through this recently with zipkin and main thing is compile floor of 8 is fine until LTS moves past 21. If you want, I can update the maven-enforcer-plugin config to constrain to LTS sdks (as well the github job), so 11, 17 and 21. This helps prevent using non-LTS features and also gives an easy answer when questions like this come up again. Unless you really need to, I would only run CI on the edges. For example, permit building with 11, 17, 21, but only burn CI resources on 11, 21. Lemme know if you want a hand.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten