Which Java versions should we support

[BraisGabin]

Java 17 is here. And It is a LTS. From now we said that we support the LTS and the last java version. But if we continue doing that we will need to support 4 different versions in 6 months. That seems a bit too much work to me.

Should we think about dropping the support for Java 8? The Android Gradle Plugin already dropped it so a lot of our users are forced to use Java 11 already and I don't know if there were other people out there using Java 8 apart from Android developers...

So my proposal would be to drop the Java 8 support as soon as Java 18 is released (March 2022).

I would like to hear reasons against this. Are there users out there that really care about Java 8 support?

[JavierSegoviaCordoba]

Personally, I am using Java 11 because Android supports it, but that change is recent, so probably a lot of Android projects will be stuck on JVM 8 for months.

[schalkms]

+1
I think detekt should still support Java 8 or rather drop another version.

[BraisGabin]

For sure there will be projects. But why they can't update? Why do we want to still support those? Is there any real reason to it? Right now the support of Java8 is being a pain because we have flaky ci.

Detekt as a project has a lot of things in its plate. And I'm OK with that if those things have sense. But is there new users adopting detekt that can't compile using Java 11?

We are a static analysis tool. To me it is OK to "force" our users to use a not very old version for the compilation.

If there is out there some framework or library that only works with Java 8 and it have more than a few users I'm ok supporting 4 different Java versions. But without any good reason i don't see why should we keep it.

About dropping any other version support I don't see it. Nearly all teh android projects that doesn't use Java 8 used java 11. So we can't drop that. And don't support the last LTS doesn't seem fair for the people that try to keep their dependencies up to date as much as possible.

[schalkms]

Certainly, ways exist to gather this information.
For instance, one could create a survey, which asks the detekt user base regarding the configured JVM version. Obviously, you receive only a small coverage of the configured Java versions depending on the total number of answers.
Another way could be the use of telemetry.

But is there new users adopting detekt that can't compile using Java 11?

Think about big enterprise projects with many developers working simultaneously on the code base. It's not always that easy and cheap to upgrade to the latest Java versions due to a number of factors.

[3flex]

Right now the support of Java8 is being a pain because we have flaky ci.

As a counter for this, it seems it's Java 8 on Windows that's consistently failing due to OOM issues. The changes in #4128 should help, as with the Worker API detekt will run out of the main Gradle process, and the JVM args requesting increased memory allocations can probably be removed. This should reduce memory pressure on the CI runner.

If we can try to fix the root cause then it won't be a burden to support Java 8 in CI.

Another option is excluding dokka tasks from most OS/JDK combos, similar to verify-generated-config-file and compile-test-snippets which are currently only run on Ubuntu/JDK 11. There's no reason to build docs on every OS/JDK combo, and dokka tasks are notoriously memory hungry: Kotlin/dokka#1405

[chao2zhang]

Another factor is the AGP's roadmap https://developer.android.com/studio/releases/gradle-plugin-roadmap

AGP 8.0 (~H1 2022)
Old APIs are removed

It feels to me that there could be backward-incompatible changes in that version - This seems to match the Java 18 timeline as well.

[cortinico]

+1 on this. I'd say we should be fine dropping the Java 8 support, as soon as Android/AGP does the same. as soon as there 2 major versions of AGP out that don't support Java 8 anymore.

EDIT: to clarify myself as AGP 7.0 already dropped support for Java 8.

[cortinico]

Also relevant to this discussion: #4133
We're basically "soft" blocked and can't use the newer AGP APIs till we get rid of Java 8

[BraisGabin]

Other issue related with us supporting java8: #3396 (comment)

And maybe #4120 is relevant for this discussion too.

[JavierSegoviaCordoba]

I had no issues upgrading AGP, but I am not sure if it can be a problem in some cases, if not, I don't see any problem to drop 8.

Another thing is... if a project can't upgrade to AGP 7 probably not upgrading detekt would not be a big problem for them because they have to have bigger problems.

[Jintin]

For me I think leave Java 8 behind is ok if we make it clear on either README or documentation (or both?).
If some project still using Java 8 they can stick to the old version of detekt.

[chao2zhang]

At the very minimum, if we drop Java 8 support and users still prefer Java 8 - We can still publish java8 variant release if needed.

[vladimirfx]

If Detekt hard drop JDK 8 it simply freezes Kotlin upgrade in many projects using JDK 8.

[vladimirfx]

I think Detekt JVM support should align with Kotlin. Android is not only Kotlin target and Detekt is most sophisticated code checker for Kotlin.
For many backend projects Kotlin is only way to develop modern and correct code with relatively current technologies. That projects simply can not upgrade JDK version - it is by far difficult in comparance to Android.
So for Android it can be JDK 11 (and max, actually) as minimum because of usage of new AGP API. But for everything else it could align with Kotlin - JDK 8-17 (for Kotlin 1.6).

[chao2zhang]

From my company, service/backend engineers are able to upgrade JDK 11 with the language level still set at 1.8. Although this is still not an easy process, at least we only need tooling change and do not need code migration.

[vladimirfx]

The short answer is Project Jigsaw (Java 9) and Java internal API encapsulation. This makes most classical JEE applications and many Spring-based apps nonupgradable at adequate time and budget. So problem is not in Java 11, but in Java 9+.
I know teams that use Java 1.6-1.7 and dream to migrate to Java 8! Some of these teams are using Koltin to write new business code. Moreover one of the sale-point of Kotlin is modern and safe development practices on old JDKs. Kotlin 1.5 from 2020 supports Java 6 from 2006. Why? Android... no there are legacy backend projects. Event last decision for Kotlin 1.6 to support Java 8 as a minimum is highly adjective.

So please consider saving Java 8 compatibility and Kotlin parity in this area in the future.

Thank you for such a useful tool! Detekt is a very important Kotlin ecosystem component without any real alternative.

At our team, we use a very successful combination of Detekt (type resolution mode) + Sbotbugs for the JVM backend and Android projects.

(background: I'm an IT consultant, mostly in backend enterprise-class systems)

[chao2zhang]

Thank you for providing the context. My company has a standardized Gradle build systems across all Java projects so we never use Java 9 module systems at all. But I assume that is not the case for Spring-based apps (Apologies I can't learn enough even by reading the documentation) that upgrading Spring major versions is not a trivial task.

With all being said, I think Detekt need to support Java 8 in some form, as long as Kotlin supports Java minimum version 1.8.

[vladimirfx]

From my company, service/backend engineers are able to upgrade JDK 11 with the language level still set at 1.8. Although this is still not an easy process, at least we only need tooling change and do not need code migration.

I think is not so easy. When your engineers switch JDK it immediately starts complaining about the usage of some restricted APIs. With a very high probability, your app servers use NIO API that behaves differently in Java 11. If you use TLS/SSL - you must retest clients OR tune runtime options. And so on...
IMO the process of migration to Java 11 should start from the developer machine and ends in UAT with full regress.

And yes, Java is brilliant in backward compatibility but evet it should make progress that is not possible without breaking changes.

In that perspective, Android migration is by far more simple if most of your code-base is in Kotlin. Actually, migration is done for you by Google and you 'just' need to upgrade the plugin and AS. In contrast, many backend systems will 'never' upgrade - it is just discontinued at some (far) point in time.

[vladimirfx]

Thank you for providing the context. My company has a standardized Gradle build systems across all Java projects so we never use Java 9 module systems at all. But I assume that is not the case for Spring-based apps (Apologies I can't learn enough even by reading the documentation) that upgrading Spring major versions is not a trivial task.

With all being said, I think Detekt need to support Java 8 in some form, as long as Kotlin supports Java minimum version 1.8.

The problem is not from build time - there you can use event Java 17 (Gradle 7.3+) but in runtime. You can run build from higher Java versions targeting lower versions but that conf not so stable as it should be, unfortunelly.
What I writen above it mostly about symetric build/runtime evrironments...

[BraisGabin]

Could we revisit this topic? Right now on CI we are againt 8, 11 and 17. But JDK 19 is out there already and 20 is going to be released this month.

Also, AGP 8.0 is on beta and it will be the second major AGP release without support for JDK8 (#4130 (reply in thread))

So probably it is time to reopen this topic.