JSR 376 / Java Platform Module system and Service Loader experience

 I have some pet projects I work on and I decided to convert one from a plain Java project over to using the Java Service loader and the Java Platform Module System.  The project uses a few well known libraries but isn't using Spring or other giant frameworks. I figured this should be pretty straight forward to do.

I started by converting over to the Java Service loader and after a bit of refactoring I got that working pretty well.  I expect anyone trying to convert an application or service over to it will find plenty of things that should be refactored to make it work well. It was a good experience though even though it was a good amount of work initially.

And then I started the conversion to the Java Platform Module system.  This was pretty difficult to get started and required more work and refactoring.  Some issues may simply be tooling issues in Eclipse or something along those lines.  For my first attempt, I eventually bailed on it and started from scratch again. 

At this point, I did make lots of good progress. I had things pretty much sorted out except for one thing. I had a problem with the Infinispan cache and the module system.  I didn't expect that and I tried all kinds of things to get past the issue.  I eventually ended using the JSR 107 Cache-api to abstract as much as possible from Infinispan specifics.  At this point, I expected it to work but I finally ended up at a particular error. The error indicated that there was an Infinispan package name that existed in two different jar files (with different classes) and that isn't supported by the module system.  I thought maybe it was a regression or small oversight - I mean, the module system has been around for some time now.  

I did a search of Infinispan issues for JSR 376, Jigsaw and platform module system but found no issues.  I finally put in an issue and the next day the tech lead closed the issue as a duplicate.  The original issue was reported by that tech lead back in 2019 as a high priority ticket.  If I had searched for "module", I probably would have found it.  Anyways, being that this was known since 2019 and the original ticket mentioned more packages that were split between jars - I am guessing this won't end up fixed anytime soon.

I removed Infinispan and am just using the JSR-107 support as a way to hide my use of a simple map for in-memory use for now.  I wanted to persist my data (which was a key benefit of Infinispan) so I briefly looked at creating my own file based persistence layer using some plain IO stream support along with protobuffers but even that had some issues.  

I'm planning to switch to ASN.1 - that is more standardized and has better "enterprise support" than most of the other serialization frameworks. Try finding active open source projects for "serialization" from google results related to that.  There are a few but there are many more that seem pretty dead. ASN.1 isn't going away anytime soon and there is an active Java project supporting it (along with many other language projects).

Thanks for reading!

Scott

[2023/06/11 Update] I'm coming to the conclusion that using the Java Platform Module system is both too high of a risk and too painful to do for any large software system. It is a risk because you can't guarantee it is going to work in a fully modular system because so many libraries and transitive dependencies are not modularized and/or have split packages. Based on how long the feature has been around, I don't see the situation improving without some major push that forces it. Trying to use Maven plugins such as "moditect-maven-plugin" and the "jlink" tool is way more effort than a short or mid-term payback would make worthwhile. Working with this tooling and trying to resolve the issues one at a time is a huge headache - certain errors are not found in a deterministic fashion. This means that you add a "fix" into the config and rerun your build and you don't get the error but you end up with a different one.  This doesn't mean you fixed the original error, it just means that it didn't pick the same problem point to report on.

I'm also rethinking the ASN.1 conversion. I was able to get the asn1bean project compiled (i.e. the ASN1 Compiler part) with Java 18 with some effort. I'm still determining if the generated code will really work the way I need/expect it to.  I've got some other things I want to work on now so maybe I'll come back to it later.