Bump Java Version to 8

[Josh Cummings]

Java 7 was EOL by Oracle in 2015.

Spring no longer supports Java 7 as of version 5 (2017).

(Not sure precisely which component to select, please correct it if my guess was wrong)

[Vladimir Dzhuvinov]

Hi Josh,

I would also love a switch to Java 8, if it wasn't for Android. We have a commitment to support Android as well, and Java 8 hasn't made it there yet.

[Josh Cummings]

Curses.

Well, hopefully, that comes soon. Looks like Android supports a number of things in Java 8, but not java.time (which is the one giving me heartburn).

Thanks for the update.

[Tomaž Cerar]

java.time support was added to Andriod Oreo, api level 26. https://developer.android.com/reference/java/time/package-summary So maybe going forward it would make sense to move to JDK 8 also for android, or have on android friendly branch for JDK7 compatibility, that would be current code + major security related fixes. For example, okhttp project did the same just recently.

Going forward it would also be interesting to start utilizing features that Java 11+ brings to table, given that JDK8 mainline public updates (from oracle) have stopped and is as such somewhat EOL.

[Igor Volkov]

Saying JDK 8 is somewhat EOL while comparing to JDK 11 is somewhat misleading . Due to licensing changes pretty much everyone migrated from Oracle JDK to a flavor of OpenJDK. According to Wikipedia AdoptOpenJDK 8 is supported until September 2023, while AdoptOpenJDK 11 is supported until September 2022, although Amazon Corretto is to be supported until August 2024.

Is there a roadmap for migration to Java 8?

[Vladimir Dzhuvinov]

Duplicate of #394.

[Carlos Tasada]

@Vladimir Dzhuvinov I would like to resurrect this ticket Given than Android already seems to be supporting JDK11 or even 17 (Android 14) and knowing that the whole Spring ecosystem is now working already working with Java 17 I think would be good to re-evaluate the upgrade to a newer Java version.

I would be happy to provide a PR if it helps

[Vladimir Dzhuvinov]

@ Carlos: I’m curious to read what changes you envision for Java 8? I want us to have a plan what this update is going to touch, so we can 1) ensure consistency (otherwise we won’t know what we’d be reviewing for) and 2) can then clearly explain the changes to developers. So, there must be clear objectives. Also, whether there are going to be any breaking changes (hopefully not ).

[Carlos Tasada]

@Vladimir Dzhuvinov that’s totally fair. From my POV the upgrade to Java 8 or even newer would help with:

• Use a JDK with support. Java 7 is really old and support is dropping

  • Oracle support for Java 7 is already finished. Support for Java 8 and 11 is only available as extended support
  • Azul Zulu only provides extended support for Java 7. Java 8 will be supported for 6 more years, while, oddly enough, Java 11 will be only for 2 more years
  • Eclipse Temurin, doesn’t support Java 7. Security support for Java 8 and 11 will be provided for 2 and 3 more years

• Reduce complexity: Nimbus provides support for Java 7+, but has modules for Java 9+ and uses Bouncy Castle Java 1.8 libraries

• Reduce risks: Even when this library is quite self-contained, some of the used dependencies may drop support at any time, forcing unexpected migrations or increased maintenance complexities

• Looking at different ecosystem reports we can see:

  • NewRelic (2024): Java 7 (0.2%) Java 8 (28%), Java 11 (33%), Java 17 (35%), Java 21 (1.4%)
  • JetBrains (2023): Java 7 (2%) Java 8 (50%), Java 11 (38%), Java 17 (45%)

With the migration of the Spring Ecosystem to Java 17, I only expect a larger push towards Java 17 or newer.

I don’t know all the use cases that Nimbus is covering, but I think a clear push to drop Java 7 support and fully use Java 8 would be a good first step. Looking at the dependencies we may already be there.

Using a newer Java version will provide access to newer APIs, some of them even more performant, like the Base64 implementation. I don’t expect a security risk with that change, since any JDK up to 17 has years of usage.

From an API perspective (integration by 3rd party frameworks) I don’t expect any breaking change. A different think is the introduction of breaking changes because the Bytecode uses a newer version and really old services may not support it, but looking at the previous ecosystem reports, both Java 8 and 11 look like safe bets.

I would be happy to help migrating the code to a newer Java version.

‌