JPMS support

[shs96c]

It would be nice to be able to use jcommander in an app built by jlink. This could be done if it defined a module-info.class for use with JPMS (apparently the automatically declared modules used in the manifest aren't good enough for jlink)

Even without the driver of jlink, integration with JPMS will be useful as more people switch to using modules as a part of their build and when Java 11 ships.

[io7m]

It seems that a module name was published in 1.75 and then withdrawn again in 1.78. What's going on?

[ice1000]

I am also looking for this. Hopefully it could be done

[ice1000]

The module file is moved outside of the source directory: https://github.com/cbeust/jcommander/blob/master/module-info.java

Idk why.

[ice1000]

Hi @cbeust what happened to module-info.java?

[JohnLCaron]

Hi, is it possible to get the module_info back in?

Or (for me at least) even just "Automatic-Module-Name: com.beust.jcommander" added to MANIFEST.MF ?

[ice1000]

Hi, is it possible to get the module_info back in?

Or (for me at least) even just "Automatic-Module-Name: com.beust.jcommander" added to MANIFEST.MF ?

FYI https://picocli.info/ supports JPMS 😉

[JohnLCaron]

thanks, @ice1000

[cowwoc]

@mkarg I love all the changes you've made lately. Now that the library depends on JDK 17, can you please move module-info.java back into the src directory?

[mkarg]

Gili, long time no see! :-)

We can make a deal: If you provide a PR that provides the needed changes including a unit test that proofs the correctness of the module-info file, then I will merge it to the master branch. :-)

[cowwoc]

@mkarg I'm not sure what kind of test you had in mind for proving the correctness of the module-info file. Historically, all I do is check that the code continues to compile and all existing tests continue to pass after adding the file. What other kind of breakage do you foresee?

[mkarg]

Having a module-info implies an information hiding contract, and the test should proof that the contract is not broken:

• It really allows to access everything that MUST get accessed.
• It really prevents access to everything that MUST NOT get accessed.

[cowwoc]

I don't understand why Java Modules get so much hate, but ultimately it's up to you to decide how you want to run your projects...

That's fine. I'll move on.

[mkarg]

This is a misunderstanding. I do not hate Java Modules. I just have no clue how it works so to see whether the module does what it shall do I need that test.

[cowwoc]

@mkarg Let's take a step back... what is the state of this project? Do the existing tests hit all the methods that you wish to expose to your users (your public API)? Do your code (or your dependencies) make use of reflection?

You can think of module-info.java as a white-list of Java packages. You list packages that you wish to expose. Everything else remains internal. The same goes for reflection. You need to explicitly grant users access (on a package level) to use reflection on your classes.

[cowwoc]

I forgot to mention... there are some design benefits to Java Modules that you might want to take advantage of.

In the past, if you wanted one class to communicate with another in a different package, you'd either have to grant your users access to potentially non-public APIs, or play some dirty tricks (using reflection?) to get things done. Perhaps you've seen people declare non-public classes as public "for testing purposes" (in order for unit tests to be able to interact with them).

With Java Modules, when you declare public classes you get to specify who (if anyone) has access to them. So for example, you could have public classes that are only accessible from inside the API (not the end-users). You can have public classes that are only accessible to your unit tests. There is a lot of flexibility there.

[mkarg]

That's all fine and undisputed. Still we need a unit test proving that nobody breaks that module's intention once it is in place, so please write the test and I will merge the module ASAP. :-)

[mkarg]

@mkarg Let's take a step back... what is the state of this project? Do the existing tests hit all the methods that you wish to expose to your users (your public API)? Do your code (or your dependencies) make use of reflection?

You can think of module-info.java as a white-list of Java packages. You list packages that you wish to expose. Everything else remains internal. The same goes for reflection. You need to explicitly grant users access (on a package level) to use reflection on your classes.

Don't know why you tell me. I know all that.

Check the code and you will find the answers. BTW, it is not "my" project, I am just maintaining it.