Repository navigation
Make this library a Java module #79
Description
I wanted to use this library in modularized Java application, but, not surprisingly, am getting an error:
Package 'jssc' is declared in module 'jssc', but module 'org.example.myapp' does not read it
I found issue #60 describing a workaround to this. However, wouldn't it be a better solution if jssc was a Java module itself, i.e. declared its own module-info.java?
Activity
tresf commentedon Mar 16, 2021
Sure!
pietrygamat commentedon Mar 17, 2021
Adding this would require the project to be compiled with jdk 9+, and to make sure the backwards comatibility with jre6 is preserved, some significant changes should be made in pom.xml. I can offer my help, but first I need some clarification:
Should it be assumed that the library still can be built with jdk7+ for those working on it locally, or can things be simplified, and from now on building the library requires jdk9+ (or even explicitly 11)?
tresf commentedon Mar 17, 2021
@pietrygamat great question. Ideally, JDK8 should ultimately be EOL and dropped. In practice though, (according to a recent JetBrains survey), JDK8 is still the most prominent version by a long shot.
For this reason, I believe the binaries to be compatibility with JDK8 is the most important moving forward. Compiling to JDK6 was done as a courtesy to @scream3r. When we talked about this on the phone he had quite the interest in maintaining backwards compatible with legacy computers for time to come and the library should be simple, small and it should "just work". To that point, as modules become the norm, we need to ensure they "just work" too.
The only thing I'd caution against is the way we represent the JSSC version: We should consider bumping to 3.0.0 if we're to change the minimum Java version, so that developers can safely checkout and fork any v2.9.x tag for backports.
From a high level, it's my instinct that the build system should continue to work with JDK8 if 9+ isn't available. This is based on the fact that JDK8 is still the most prominent version found and is even available as a port to some obscure systems. JDK11: not so much. Furthemore, although JDK9+ is where modules were introduced, Oracle's short lifespan of these Java versions makes them increasingly hard to find, so I'm in strong favor of migrating any JDK9+ tasks/tutorials/CIs to JDK11 (well, probably our only option anyway).
Hope that's not too much of a mouthful.
tresf commentedon Mar 17, 2021
It's my opinion that the simpler the code, the better. I don't think the code is complex now (the build system is, a bit).
Include module-info.java
Include module-info.java
Include module-info.java
Include module-info.java
Include module-info.java
Warn when building on JDK that limits the compatibility of resulting jar
Warn when building on JDK that limits the compatibility of resulting jar
Warn when building on JDK that limits the compatibility of resulting jar
Warn when building on JDK that limits the compatibility of resulting jar
Include module-info.java
Warn when building on JDK that limits the compatibility of resulting jar
tresf commentedon Aug 5, 2021
@pietrygamat can you help summarize what's needed to close this out? I'm not very familiar with the module system, but we're nearing a new release and as far as I understand the build system is ready with these changes.
pietrygamat commentedon Aug 5, 2021
Build the release with JDK11 and publish it, I guess. Users depending on artifacts from dependency management systems will be able to get the jar with module support (thanks to #81 )
tresf commentedon Aug 5, 2021
@pietrygamat perfect, thanks. @GMKennedy and I will build with JDK11 and then we'll close when #104 is merged then. :). Note, I've placed some comments in slack about fixing some compiler warnings before release. They aren't directly related to this, but since they're a result of a newer compiler your thoughts are welcome. 🍻
tresf commentedon Aug 5, 2021
Ok, I think this is directly related.... to suppress the compiler warnings the only combination I've found to work is:
I believe this is new with the addition of #92 which.
@pietrygamat I'm going to add this to #105 branch, merge into
mastertoday but if you feel that suppressing these is frowned upon feel free to take them back out.