Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abandon java 7 in favour of Java 8 as a baseline #308

Open
lazystone opened this issue Mar 7, 2018 · 36 comments
Open

Abandon java 7 in favour of Java 8 as a baseline #308

lazystone opened this issue Mar 7, 2018 · 36 comments
Labels
jdk8 Changes related to migrating to JDK8 API features
Milestone

Comments

@lazystone
Copy link

That will allow to fix #282 without additional dependencies.

@aharonha
Copy link

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

@aharonha
Copy link

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

@aadrian
Copy link
Contributor

aadrian commented Mar 21, 2018

some legacy dependent projects might break.

@aharonha what projects do you mean?

@aharonha
Copy link

@aharonha what projects do you mean?

ones that we can't see ;-)

@aharonha
Copy link

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

e.g. this PR #311

@azagniotov
Copy link

@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
Copy link
Contributor

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
Copy link

UkrainianCitizen commented Nov 23, 2018

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

@DanFTRX
Copy link

DanFTRX commented Mar 4, 2019

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
Copy link

mayonesa commented Mar 12, 2019

Supporting a Java 7 project w/ this library.

@ifzm
Copy link

ifzm commented Mar 29, 2019

+1

@UkrainianCitizen
Copy link

UkrainianCitizen commented May 6, 2019

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
Copy link

DanFTRX commented May 6, 2019

@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
Copy link

UkrainianCitizen commented May 7, 2019

@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
Copy link

DanFTRX commented May 7, 2019

@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
Copy link

DanFTRX commented May 8, 2019

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
Copy link

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
Copy link

DanFTRX commented May 21, 2019

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
Copy link

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
Copy link

DanFTRX commented May 21, 2019

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
Copy link
Contributor

@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
Copy link

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

@UkrainianCitizen
Copy link

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

@jaapcoomans
Copy link
Contributor

@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
Copy link

DanFTRX commented Jul 1, 2019

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
Copy link
Contributor

lhazlewood commented Jul 16, 2019

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
Copy link
Contributor

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
Copy link
Contributor

#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
Copy link

DanFTRX commented Oct 21, 2019

@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
Copy link
Contributor

@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
Copy link

DanFTRX commented Oct 21, 2019

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

@lhazlewood
Copy link
Contributor

@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
Copy link

DanFTRX commented Oct 24, 2019

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
Copy link
Contributor

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
Copy link

DanFTRX commented Mar 1, 2021

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
Copy link
Contributor

@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.

@lhazlewood lhazlewood added the jdk8 Changes related to migrating to JDK8 API features label Sep 5, 2023
@jglick jglick mentioned this issue Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
jdk8 Changes related to migrating to JDK8 API features
Projects
None yet
Development

No branches or pull requests