JDK 10+ support

I’m using java 9 modules in my project and when I try to use it, I get this compilation error:

> Task :auth:compileJava FAILED
error: the unnamed module reads package io.jsonwebtoken.io from both jjwt.api and jjwt.jackson
error: module reactor.core reads package io.jsonwebtoken.io from both jjwt.api and jjwt.jackson
error: module spring.boot.starter reads package io.jsonwebtoken.io from both jjwt.api and jjwt.jackson
error: module jjwt.jackson reads package io.jsonwebtoken.io from both jjwt.api and jjwt.jackson
error: module com.fasterxml.jackson.databind reads package io.jsonwebtoken.io from both jjwt.api and jjwt.jackson
error: module jjwt.impl reads package io.jsonwebtoken.io from both jjwt.api and jjwt.jackson
...

My gradle file looks like this:

implementation 'io.jsonwebtoken:jjwt-api:0.10.5'
runtime 'io.jsonwebtoken:jjwt-impl:0.10.5','io.jsonwebtoken:jjwt-orgjson:0.10.5'

I couldn’t make it work or find any workaround to this issue.

[jaapcoomans]

Bumped into this issue as well. Happy to file a PR with a solution for using JJWT on the module-path. But looking at #400 I want to check the best solution path here first. It’s a little bit of a catch 22 because breaking backwards compatibility causes issues for existing users, whereas not solving the issue blocks users wanting to move forward with JPMS.

There are a few options that both solve the split-package issue and keep backwards-compatibility into account:

1. Deprecate and replace the current jackson and orgjson extensions by new ones. That is, not only the classes, but the whole deliverable. As long as jjwt and its extensions are not fully modular (and thus interpreted as an automatic module), only deprecating the offending classes will not help, as their package will still be exported and cause split-package issues.
2. Pull the extensions (back) into the main artifact. That of course has an impact on distribution and transitive dependencies.

Non-options:

1. Go fully modular (and therefore make it possible not to export the offending package). The jjwt extensions have non-modular dependencies. These first need to become proper JPMS modules.
2. Only rename the packages. This will, as mentioned, break backwards compatibility. A little search on github alone taught me that these classes are indeed directly referenced by some projects.

Bottom line I guess that solution number 1 is the most viable option here.

[mcgin]

The same issue applies to the two classes in jjwt-orgjson