pi4j-v2
pi4j-v2 copied to clipboard
Pi4J
Java modules: add more info to website, document how/why, alternative approach with jlink/graalvm?
Java modules are hard to understand (and use), so we need to clearly show how/why they are used.
https://www.theoryofgeek.com/articles/fomo-java-module-edition
@FDelporte @savageautomate
After reading that article and having experienced some of this pain while once trying to get a JavaFX app to work and seeing that modules will never work with SpringBoot et. al. i think the best thing would be to ditch modules.
This also allows us to again make a simpler API. @savageautomate actually once even said that some API design choices were because of modules and now we have the issue that modules are more pain than gain...
If we remove the modules, then we don't really loose much. The whole plug-in infrastructure is still fine and we can still just keep the internal classes in an internal package and thus if someone uses it, and it gets changed in the future, then tough luck, the devs will have to fix their code.
What do you guys think?
P.S. I do appreciate, that @savageautomate probably did a lot of work to get modules to work, and of course it is always sad to see work become redundant... But i think i have to wholeheartedly agree with the following statement by the author of the blog entry:
I suspect the Java module system was created for one reason, and one reason alone - it is a way to technically enforce the breaking up of the JDK into individual components. The JDK team doesn’t care about stuff like Maven dependencies - that’s just end developer stuff.
On the other hand: GraalVM and other packaging solutions seem to require modules....
P.S. I do appreciate, that @savageautomate probably did a lot of work to get modules to work, and of course it is always sad to see work become redundant... But i think i have to wholeheartedly agree with the following statement by the author of the blog entry:
I'm reluctant to remove the modularization. I do like the concept of being able to hide/restrict access to implementation APIs in a single distributed JAR -- but I'm not living in the Java world anymore ... so ultimately I would defer to whatever the best practices are for Java Library development.
As far as I know removing it will force us to define the service/plugin relationships/interfaces in the service resource files like this one: https://github.com/Pi4J/pi4j-v2/blob/main/plugins/pi4j-plugin-raspberrypi/src/main/resources/META-INF/services/com.pi4j.extension.Plugin. I originally includes both the service META-INF files as well as the newer modular declarations in the module-info.java files like this: https://github.com/Pi4J/pi4j-v2/blob/main/plugins/pi4j-plugin-raspberrypi/src/main/java/module-info.java#L40. I suspect I was having trouble with the services getting picked up properly at runtime using only the definition in module-info.java. Of course this work was all back during Java 9 s... o something could have been broken back then. I would propose that if we keep modularization then we get rid of these service definitions in META-INF if possible just to avoid duplicate definitions.
On the other hand: GraalVM and other packaging solutions seem to require modules....
I do think GraalVM is very interesting and something I had planned on digging into further with Pi4J and RPi -- but alas -- no time.
I would propose that if we keep modularization then we get rid of these service definitions in META-INF if possible just to avoid duplicate definitions.
That would be a big mistake. If you have a modular jar, then a user can put it on the classpath OR on the module path and it should work in both settings. Also it is often the case that tests are run automatically on the classpath even if the main program uses the module path. In such a scenario you wouldn't be able to load your services properly. The definitions in META-INF and module-info are redundant but should always be present AND consistent.
And neither JPackage/jlink nor GraalVM native-image NEED the module system. I have shown with Dirk how to use JPackage without modules here: https://github.com/dlemmermann/JPackageScriptFX and when I build JavaFX applications with GraalVM/native-image I also never needed the module system. The GraalVM mostly just ignores it.