Can't find ResourceBundle with JPMS

[tasogare3710]

ResourceBundle fails to load if the ResourceBundle is specified using the resourceBundle element of the CommandLine.Command annotation.

info.picocli/CommandLine$Model$Messages#createBundle is calling ResourceBundle#getBundle(String), so it seems to be looking for ResourceBundle from info.picocli module. Is there a way to specify the module in which the ResourceBundle or to use the ResourceBundleProvider?

[remkop]

Thank you for raising this!

Looking at the javadoc for Resource Bundles in Named Modules, and ResourceBundleProvider, no, this is currently not yet supported in picocli as of version 4.6.1.

I am not opposed to adding support for this. One thing to note is that in order to continue to only require Java 5 or higher at runtime, adding support for resource bundles in modules will require the use of reflection. It is likely that only the CommandLine.Model.Messages class needs to be modified, but I have not looked at the details of what the implementation would look like.

A potential issue is that picocli currently only requires Java 8 or higher to build the project.
So how do we test this functionality?

When running in continuous integration environments, picocli is built and all tests are executed on Java versions 8-16.
One idea is to have some tests that are only executed when running on Java 9 or higher.
Also, we could create a small pre-built picocli-based application that is a JPMS module, include the binary JAR of that application to the resources of the picocli project, and reference this application from the test (again, only when running on Java 9 or higher).

Do you think you will be able to provide a pull request for this?

[tasogare3710]

Do you think you will be able to provide a pull request for this?

I'm so sorry, but I not know picocli inside out to send a pull request.

A potential issue is that picocli currently only requires Java 8 or higher to build the project.
So how do we test this functionality?

I'm not sure if this will work with picocli, but how about using a multi release jar files and including picocli for java8 and picocli for java9 and higher in single jar file?

[tasogare3710]

This is the smallest gradle project that can reproduce this issue.

unzip, cd and run:

gradlew run

1. java with JPMS is required.
2. This will fail to run.
3. Uncomment line 17 of app\build.gradle and comment out lines 18 and 19 to successfully run.

[remkop]

Thank you for providing the sample project.

I'm so sorry, but I not know picocli inside out to send a pull request.

Understood, no problem.
I am extremely pressed for time and I don't see myself working on this issue in the near future.

Let's leave this ticket open for someone who is willing to work on it.

[tasogare3710]

Of course. no problem too.

Thank you.

[aalmiray]

Interested in seeing this issue moving forward. How can we keep backward compatibility while supporting Java 9+ and modules?

[tasogare3710]

JPMS is not backward compatibility. upgrade path called --illegal-access option was removed in java17, but you can still use multi-release-jar.
And next LTS will be released this September.

https://openjdk.org/jeps/238
https://openjdk.org/jeps/403

[aalmiray]

Might be much to ask to use MR-JARs as most of picocli is implemented as an annotation with embedded types. For this to work the class responsible for loading resources would have to move to a top level class, then a Java9+ compatible implementation may be placed in /META-INF/versions/9.

[tasogare3710]

Mhh, divide into smaller milestones step by step.

[remkop]

I’m assuming that the programmatic API CommandLine.setResourceBundle works correctly with modular applications, is that right?

(only the annotations give errors?)

[aalmiray]

Yes. Using the programmatic API works with modules.