Support JSR310 (Java 8+ Instant / Duration)

[dongzhuang]

Currently, JJWT compiles for Java 1.7 (much of this has to do with Android support).

JJWT 1.0 will contain breaking changes, at that point we could update the Date and longs to Instant and Duration.

Until then use:

• Date.from(instant)
• Duration.ofSeconds(10).toMillis()

[AlexandreCassagne]

@bdemers Could you comment on whether there are any blockers here? If not I may have time to propose a merge request here.

[bdemers]

Thanks @AlexandreCassagne, go for it!

The work on the jwe branch is wrapping up.
My suggestion would be to use that branch as a starting point. (though if you based it on master it shouldn't be that difficult to merge after)

[AlexandreCassagne]

Cheers!

[AlexandreCassagne]

@bdemers I noticed that your project's target is still Java 1.7.

Will this change soon? Because the JSR310 changes require Java 8+. If backward compatibility is a long-term concern, one approach could be building a two-pronged interface - the legacy interface (exposing only Java 7 features) and a new interface with a more modern API.

This would probably be achieved using 2 maven subprojects - 1 targeting 1.7, the other for example a modern Java version.

I have no experience contributing to this project - I'm content upgrading to Java 8+ for my use cases ;-) but I can also create a pull request with 2 modules. Let me know your preference, or any other approach.

[bmarwell]

There are a few PRs waiting for Java 8 "loitering around". 😅
Big, big +1

[lhazlewood]

We do want to move to JDK 8 as soon as possible, but we'll be doing it as soon as we're 100% specification complete. The jwe branch contains all remaining improvements to ensure support for fully encrypted JWTs.

The delay was also due to additional JWT specifications being finalized more recently, specifically Edwards elliptic curve cryptographic algorithms as well as new JWK types for Edwards curve keys. Also, JJWT is used a lot in Android apps, and JDK 7 apis are more prevalent in that ecosystem.

Once these additional things at finished (we're nearly at 100% code coverage for all new code), we'll cut a JDK 7-based release and then probably move to JDK 8 compatibility. At least this way, people on JDK 7 / Android still get 100% of all of the JWT specifications ' functionality, even if they may not get additional conveniences until moving to 8+.

Another complication is native Edwards APIs are not available until JDK 11 (X25519 and X448 curves and keys) and JDK 15 (Ed25529 and Ed448 curves and keys), and so supporting them with native APIs is important too, possibly via Java 9+ multi-release jars.

So all of this needs to be taken into account when moving to a multi-version API strategy for JJWT. Not exactly trivial, but not terrible either. It's probably one of the first things we'll address after all the JWE + Edwards stuff is released, which I hope is very soon. It's so close to being fully code/test complete.

Hopefully that helps give everyone some insight into the challenges related to this ticket 😅

[bmarwell]

Any update on this? I'd be willing to contribute! 😇

[lhazlewood]

Just doing some housekeeping: closing this issue as it is a duplicate of #235. It will be resolved with that issue.