Kubernetes-client: Module based library ( support for Java 9+ )

Created on 11 Feb 2020  路  7Comments  路  Source: fabric8io/kubernetes-client

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 + .

statustale
Source
picture ankeetj

Most helpful comment

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
picture dpratt on 6 May 2020
👍2

All 7 comments

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

rohanKanojia picture rohanKanojia on 11 Feb 2020

@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.

ankeetj picture ankeetj on 11 Feb 2020

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
dpratt picture dpratt on 6 May 2020
👍2

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!

stale[bot] picture stale[bot] on 6 Aug 2020

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

fransguelinckx picture fransguelinckx on 28 Aug 2020

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?

rohanKanojia picture rohanKanojia on 28 Aug 2020

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

fransguelinckx picture fransguelinckx on 6 Oct 2020
👍1
Was this page helpful?
0 / 5 - 0 ratings

Related issues

antonalechnovic picture antonalechnovic  路  5Comments
yaakua picture yaakua  路  3Comments
zregvart picture zregvart  路  4Comments
Kerruba picture Kerruba  路  4Comments
rittneje picture rittneje  路  3Comments