Abandon java 7 in favour of Java 8 as a baseline

[lazystone]

That will allow to fix #282 without additional dependencies.

[aharonha]

This Is a great idea, although some legacy dependent projects might break.
This calls for new versioning or forking.

[aharonha]

I believe that #286 would also be fixed.
Just working with java.time package would do the job.

[aadrian]

some legacy dependent projects might break.

@aharonha what projects do you mean?

[aharonha]

@aharonha what projects do you mean?

ones that we can't see ;-)

[aharonha]

Just working with java.time package would do the job.

e.g. this PR #311

[azagniotov]

@aharonha moving to Java 8 is definitely a breaking & non-backwards compatible change. I imagine the major version would need to be incremented, i.e.: 10.0.0

[lhazlewood]

Because of a backwards-incompatible breaking change, semver requires this to wait until at least 1.0.0. Assigning that milestone and we'll deal with it at that time.

[UkrainianCitizen]

I can help with the migration to the java.time.* or to Java 8 at all. @lhazlewood do you need such a help?

[DanFTRX]

According to this: https://developer.android.com/about/dashboards/ more than half of all android devices still ran on Java 7 last year. (Java 8 is on devices with API 24+).

A lot of people seem to forget that Android Java has a different release schedule than regular Java. While regular Java may be at version 11, Android Java is still barely jumping into Java 8 compatability.

Furthermore, 2018 Java 7 usage was still relatively high among most Java developers according to https://www.jetbrains.com/research/devecosystem-2018/java/

[mayonesa]

Supporting a Java 7 project w/ this library.

[ifzm]

+1

[UkrainianCitizen]

Supporting a Java 7 project w/ this library.

Migrate to 8, it is 2019 already, for God's sake. Regardless, just use an older version.
@lhazlewood when this will be implemented? I guess it would be an easier and smoother transition if it isn't done all at once. It would be feasible, for instance, firstly move to java.time because I guess it is the easiest part of this transition so to speak, break the transition into several parts as well as this issue. Only after that transition to streams etc. will follow. What do you think about that? I can do that.

[DanFTRX]

@UkrainianCitizen Dropping compatability for nearly half a userbase(Probably closer to 1/3 now but google apparently isn't updating it's numbers anymore) is not really a valid option for people.

[UkrainianCitizen]

@UkrainianCitizen Dropping compatibility for nearly half a userbase(Probably closer to 1/3 now but google apparently isn't updating it's numbers anymore) is not really a valid option for people.

This must be done eventually. Majority community uses Java 8 +. Using Java 7 in the popular third-party libraries restrains a lot and makes usage of such libraries less viable option.

[DanFTRX]

@UkrainianCitizen Eventually is not the same as right now though. Ideally Google releases updated marketshare numbers to confirm, but based on past trends I would estimate that Java 7 Android phones will be around in a significant enough percentage until 5-6 months after the next major Android version release

[DanFTRX]

Coincidentally enough they finally upgraded their marketshare numbers last night. Java 7 devices are currently sitting at 40% of all android devices.

https://developer.android.com/about/dashboards/

[strguntbr]

It is 2019! Oracle will be dropping support for Java 7 in July (https://www.oracle.com/technetwork/java/java-se-support-roadmap.html).
As I'm a backend developer, I don't know the exact situation related to Android, but I've been talking to the Android devs in my company (and I'm working in a company whos main activity is developing mobile apps). They told me that the are using Java 8 to develop Android apps. And they are supporting Android back to SDK 17 (that's Android 4.2.x and according to your link >98% of the Android devices)

[DanFTRX]

Android has a syntax desugaring compilation step that allows for select Java 8 APIs and language features to be compiled into Java 7 equivalent bytecode. It is not truly java 8, it pretty much just allows for lambdas and a few other syntax additions.

https://developer.android.com/studio/write/java8-support#supported_features

Java 8 isn't even truly supported in Android API 24 now that I look further.

Specifically the java.time package is not available on projects targeting below API 26 (60% of android devices) https://developer.android.com/reference/java/time/package-summary.html

Long story short is Android doesn't really have any real Java 8 support. It has whatever snippets of Java 8 Google deemed important enough to grab. And even then those snippets of support are only available when you drop support for large percentages of android devices.

[strguntbr]

So does anybody here know of an existing fork that's supporting java.time? I still object the decision not to move on and support java.time.
There has to be some way to support it. People are asking for it and nobody who has the choice wants to work with the pre java 8 date classes any more.
But I understand that it might be important for you if your main focus is on the Android community, but then it might be time for a fork (if it doesn't already exist) or maybe some additional module that adds java.time support to the existing library

[DanFTRX]

A moduled approach may be preferable. Because it could be implemented then with https://github.com/JakeWharton/ThreeTenABP for android, or java.time for non-android environments.

[jaapcoomans]

@lhazlewood browsing this and related issues and PR's I notice a common theme in all of them. JVM developers wanting to move forward to java.time and modules at the one side and android developers wanting to stay at 7 because that's the only option they have. It made me realize that these two platforms are drifting apart, leaving jjwt in between where neither choice will make both sides happy.

In order to break this impasse where both side holds eachother hostage, isn't it best to decide to split the library? I'm happy to contribute to that from the JVM perspective. It could either be a full split / fork resulting in two separate libraries (e.g. jjwt and ajwt), or it could be a modular approach with a shared core and two separate API's: one targeted at android, one targeted at the JVM / Java 11. If needed, this can partially be solved by making the shared core a multi-release jar. byte-buddy uses that technique to stay compatible with java 6 and at the same time be fully modular on java 9+, having the module descriptor. What do you think?

[strguntbr]

If necessary I could/would support implementing that approach. In the meantime I was playing around a little and added getters/setters that accept/return objects for the relevant datetimes to get a single library that works on android and if present can accept/return certain java.time classes

• One approach is purely based on reflection (https://github.com/strguntbr/jjwt/tree/jsr310-reflection). Thus this can be build without those classes on the classpath
• The other approach needs the classes to build, but if they are not present at runtime the classes that actually process the java.time objects are not instantiated and thus should also work without them (https://github.com/strguntbr/jjwt/tree/jsr310)

[UkrainianCitizen]

@jaapcoomans this is the best solution by far for this problem for now. @lhazlewood must give some feedback about that.

[jaapcoomans]

@strguntbr I've been playing around a little with using ServiceLoader instead of reflection for better decoupling between jjwt-api and jjwt-impl. Far from done yet, but a first attempt is here: https://github.com/jaapcoomans/jjwt/tree/service-loader. With that approach a provider configuration file in META-INF/services of the implementer will make the implementation available at runtime. This might be something to combine with your setup.
Using ServiceLoader also paves the way for JPMS.

[DanFTRX]

If we are lucky and it ever gets done, https://issuetracker.google.com/issues/114481425 will make a split unneccessary. Bazel has shown that desugaring standard libs like java.time is possible, so its up to the Android Team to incorporate a similar feature into D8.

[lhazlewood]

Just an update for those following along: The current plans around this issue is that we'll probably keep JDK 7 compatibility until just before we release 1.0 final. It'll be something like 0.14.0 (or similar) and the only difference between that release and the 1.0 final release will be that JDK 8 is used and JDK 7 is dropped from the compatibility/build matrix.

This is to ensure that JDK 7 or older Android users can have a fully RFC-compliant library for JWT that implements all RFC behavior. Immediately after that release, probably a week or two later, we'll release 1.0 that will be JDK 8 + only, and all new features/enhancements will be against 1.x or later only.

We have no desire to split the library across JVM languages or language features. Trust me, it is a MASSIVE amount of work to do this and, then support them in tandem.

[jaapcoomans]

Thanks for the clear update @lhazlewood. Is there a finite list of issues or items that still need tot be done to be fully RFC-compliant? I would be happy to see if I can file a PR for any of these to help speed up the process.

[lhazlewood]

#178 is all that remains, and the current plans are to get the JWT team together in person to knock it out as soon as possible. Due to work commitments though, that's still probably a couple of months away.

[DanFTRX]

@lhazlewood I'd just like to confirm that the 1.0 release will only be moving the baseline to Java 8 correct? Not any higher? As the Android ecosystem will likely not support Java 9+ for years to come.

At this point in time, most measurements put 80+% of android devices with Java 8 compatability. Additionally, according to some slides given at Google IO 2019, library backporting for major system libraries of Java 8 will be coming "soon" for older versions of android as well(Which would move compatability to essentially 100% with some edge cases). With any luck, their "soon" will be quicker than the 1.0 release here and no incompatabilities will occur.

[lhazlewood]

@DanFTRX correct, our 1.0 release will utilize JDK 8 APIs, but not JDK 9 or later.

Also, our release just prior to 1.0 will really contain everything for the 1.0 release as well, but without JDK 8 conveniences (like functional interfaces, etc). So even Android devs that need the 1.0 functionality will get it, but in the form of the last 0.x release.

The other caveat with the last 0.x release is that we will not work on it ourselves after that point. If the community wants to support it by submitting (relatively simple) PRs, we could probably do that, but we won't be proactively adding features to it ourselves.

[DanFTRX]

@lhazlewood My bigger concern is potential bugfixes/security patches that may occur.

[lhazlewood]

@DanFTRX it's a tough call - thankfully JJWT is quite stable, so other than 3rd-party dependency security issues - like Jackson recently - this may not be an issue at all. I suppose we can just 'wait and see', and if there is enough need for it, we can provide that.

[DanFTRX]

Good news is that an upcoming version of Android Studio will add java 8 library desugaring for select language APIs.(See link for details) Among these are the APIs that are most likely going to be switched to here in JJWT following the 1.0 release.

[lhazlewood]

That's pretty slick! Odds are very high that we'd probably only use language features supported by desugaring, so hopefully we won't see any issues. I can't say for sure, but I hope that would be the case.

[DanFTRX]

Just as an update, since April 2020, android now has the capability to backport most standard Java 8 core libraries to older devices, so Android shouldn't be a blocking point for Java 8 usage anymore.

[lhazlewood]

@DanFTRX thanks for the update, that's really helpful. I've made a ton of progress on JWE the last week, so hopefully it won't be too much longer before I can focus efforts on this issue and others slated for 1.0.