Module based library ( support for Java 9+ )

[ankeetj]

I'm using Java 11 and trying to create a lightweight JRE . Is there a new version for kubernetes-client which uses modules ? It will make uptake very easy in java 9 + .

[rohanKanojia]

@ankeetj : Our client has been compatible with JDK 11 since v4.1.2

[ankeetj]

@ankeetj : Our client has been compatible with JDK 11 since v4.1.2

I'm using 4.6.4 version of kubernetes-client and there is no module-info.class there.

[dpratt]

A quick workaround for this would be to add an Automatic-Module-Name directive to the MANIFEST.MF file in your published jars. It doesn't require any other Java 9 specifics, nor does your code have to behave like a module. However, it does provide a stable module name for anybody that does want to use your client in a modular application. Without it, a modular application importing your library on the modulepath gets a name generated from the filename of the jar, which is obviously not a good thing. To do this, you need to do two things

• Pick unique module names for each of your artifacts. It's worthwhile spending a little time (but not much) on this, as if you ever do move to a truly modular jar, you're going to want to keep the same name.
• Add bits to the build to add an Automatic-Module-Name entry to each jarfile produced by your build - you can see more info on that here

[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!

[fransguelinckx]

Are there any short or long term plans on adding support for java modules?

[rohanKanojia]

Actually, we tried moving to java modules but it seemed quite painful as it required some of the dependencies (like sundrio for builder generation) to move to modules too. Are you blocked due to this issue?

[fransguelinckx]

We have a workaround where we re-package the kubernetes-client packages in 1 jar, so certainly no blocker.

[manusa]

Now that #4464 / #4460 has been tackled, we should be able to complete this issue.

#2110 should now be closed or recreated from scratch (@rohanKanojia).