jjwt icon indicating copy to clipboard operation
jjwt copied to clipboard

Enable JDK9+ module-info

Open skjolber opened this issue 4 years ago • 18 comments

I'm trying to use modules in a support library, but there seems to be no module-info for jjwt. I suggest following either Jackson's or SLF4J's approach.

skjolber avatar Oct 18 '19 14:10 skjolber

First add a default module name, then later module info (a bigger job).

skjolber avatar Oct 21 '19 13:10 skjolber

This issue has been automatically marked as stale due to inactivity for 60 or more days. It will be closed in 7 days if no further activity occurs.

stale[bot] avatar Dec 20 '19 13:12 stale[bot]

Bump

skjolber avatar Dec 20 '19 18:12 skjolber

@skjolber now that 0.11.0 is out and builds/works on JDK 11, is this still needed?

lhazlewood avatar Feb 05 '20 23:02 lhazlewood

@lhazlewood can't seem to find any module descriptor or automatic module name entry in the manifest? Ref https://repo1.maven.org/maven2/io/jsonwebtoken/jjwt-impl/0.11.0/

skjolber avatar Feb 06 '20 11:02 skjolber

@skjolber correct, we didn't add them to the release - I was curious however if they are still necessary to use in JDK11 given that our builds run and work on JDK11.

lhazlewood avatar Feb 06 '20 19:02 lhazlewood

So disabling the module system is possible, and then all will run 'as before'. But that is hardly proper support. You might be interested in this: https://dzone.com/articles/automatic-module-name-calling-all-java-library-maintainers

I have best experience with using the moditech plugin, see this example.

skjolber avatar Feb 09 '20 17:02 skjolber

Hi @lhazlewood. Is there a due date for the 0.12.0 milestone?

andrewhrytsiv avatar Nov 08 '21 12:11 andrewhrytsiv

@andrewhrytsiv Hi! All I can say as an unpaid team of volunteers, we move as quickly as we're able, so we cannot commit to any dates or timelines.

I will say however that there has been a tremendous amount of active work in the last 3 months on the jwe branch and other PRs, so all I can say is that 1) we're working as hard as we can and 2) there are a lot of awesome things about to drop in the next release as soon as we can get it out. I hope that helps!

lhazlewood avatar Nov 08 '21 21:11 lhazlewood

@lhazlewood I appreciate your work. Thank you for the feedback.

andrewhrytsiv avatar Nov 09 '21 15:11 andrewhrytsiv

@skjolber @lhazlewood I could create such a file using the moditect plugin if you are interested. I did the same for snakeyaml: https://blog.bmarwell.de/2020/12/08/use-snakeyaml-in-a-modular-jlink-distribution.html

WDYT? We would even still be Java 7 compatible if you needed that.

bmarwell avatar Apr 16 '22 12:04 bmarwell

@bmarwell that would be great! Any help here would be much appreciated.

lhazlewood avatar Apr 18 '22 18:04 lhazlewood

@lhazlewood I do have a local sketch-up now, but various things will fail. Some Groovy tests are now restricted to the same level as Java is, e.g. DecodersTest will instantiate new Decoders() which will not be possible anymore. Another one is access to Base64.DEFAULT (which is package-private and fails with 'no such property exception').

Or the call to this package-private constructor in another test:

def decoder = new ExceptionPropagatingDecoder(new Decoder() { … }

There are 42 (of course!) of those in the api project alone.

Anyway, moditect is Java 8 and the jsonb-extension is also java8-only. That means that you wouldn’t be able to verify every feature using Java 7 anymore and release can only be done on Java 8 and above.

I will look further into it, but I am still far away from creating a branch with helpful commits.

bmarwell avatar Apr 20 '22 05:04 bmarwell

@bmarwell makes sense. I'm fine waiting for 1.0 to introduce these changes. I don't want to cause any more churn than is necessary. jwe is by far the highest priority, so anything else that requires more than trivial changes to the codebase or project configuration is best left for after that release.

lhazlewood avatar Apr 20 '22 19:04 lhazlewood

I'm not sure why you guys made this more complex than it has to be. You just need to add a few lines to pom.xml to turn your releases into multirelease JAR files and you're done. Here is the code I lifted from https://medium.com/@ankitagrahari.rkgit/multi-release-functionality-8fc423b6c94e:

<execution>
    <id>java11</id>
    <goals><goal>compile</goal></goals>
    <configuration>
        <release>11</release>
        <compileSourceRoots>${project.basedir}/src/main/java11</compileSourceRoots>
        <multiReleaseOutput>true</multiReleaseOutput>
    </configuration>
</execution>

No need to mess around with Moditect or any 3rd-party plugin. Don't get me wrong, Moditect is a great plugin, but there is an easier way to get this done in this case...

cowwoc avatar Mar 14 '24 16:03 cowwoc

No need to mess around with Moditect or any 3rd-party plugin. Don't get me wrong, Moditect is a great plugin, but there is an easier way to get this done in this case...

Yes, but back then it was probably necessary because jjwt did support very old Java versions (at least 7, maybe even 6) and needed to be compile on exactly java 8. Using MRJars would have meant introducing toolchains which is even more configuration compared to moditect which runs on 8. 😃

But yes,, the MR is now probably the better solution.

bmarwell avatar Mar 15 '24 20:03 bmarwell

@cowwoc JJWT still supports JDK 7, so if you'd like to open a PR that supports JDK 7 through 21, we'd appreciate it! 😉

lhazlewood avatar Mar 15 '24 22:03 lhazlewood

@lhazlewood Sorry. No time at the moment... I'll revisit this eventually but it could be months away.

cowwoc avatar Mar 16 '24 18:03 cowwoc