Build piccolo2d with the Java platform module system and/or add automatic module name

[vanderzee-anl-gov]

I am a developer on a project that uses piccolo2d. We want to transition our project to being fully modular in the sense of making use of the Java platform module system.

In order for our project to be modular, our dependencies must be somewhat modular as well, not having split packages and so on. I have not fully analyzed this project, but in testing our build so far, there do not appear to be any split packages.

I think it would be fairly simple to add an automatic module name to your distribution, which would allow you to continue to compile against versions of Java prior to Java 9, while establishing a dependable module name for consumers of the project that want to become fully modular.

[tcfurrer]

If you locally hacked each of the jars to contain the needed the manifest entry, and the OpenJDK JVM (without applying unusual override switches) was able to load all of the jars simultaneously at runtime without fatal errors, then there must indeed be no package overlaps (at least in the jars that you used). The requirement to not have package overlaps across simultaneously-loaded modules is strictly enforced (at least by the OpenJDK JVMs).

In cases like this, any active Java library project should have already added the module name in a release by now. I believe you are correct that it should be easy to add (if not, I'd be curious to hear about the reasons here). Only libraries which need difficult refactoring (to eliminate the package overlaps) might reasonably choose to fall behind the times (and only for unfortunate practical reasons).

In fact, in easy cases like this one, it should also be straightforward to add a module-info. The only catch there is maintaining support for Java 8 and earlier. In my opinion, Java 8 is now so old that living Java library projects ideally would build separate releases for older java versions VS newer ones, just to avoid becoming increasingly irrelevant over time.

Modular libraries enable more than just use of the library within projects which themselves desire modularity alone. Library modularity is also strictly required in order to take advantage of jlink, jpackage, ahead-of-time compilation, and more. It's disappointing to see (and experience) modern java projects which are still being held back from using these features (at least not without awkward hacks to jar files, local rebuilds/forks, etc).