Is this discarded?

What's the reason for downgrading java version? Generally we want to upgrade not downgrade?

What's the reason for downgrading java version? Generally we want to upgrade not downgrade?

People are forced to use a new version. From my perspective is not a problem, but it is usual to use Java 8 for libraries and Java 11 for Gradle plugins (because some big plugins were forced to move to Java 11 tho).

@hfhbd I have created this PR to reduce the target Java version to 11 in sql-psi.

I suspect we may still require 17 in the end as that's what AGP uses now.

Is that still a thing? I think they reverted the need to have Java 17 in AGP as I am upgrading my convention plugins to the latest AGP version and they are using Java 11.

Started in AGP 8: https://developer.android.com/build/releases/past-releases/agp-8-0-0-release-notes

Paparazzi just forced us to 17 internally because it bumped layoutlib from AGP to the version from AGP 8.x.

I will have to recheck, but I am using AGP 8.7.3 and the plugin is built with Java 11. Something must be different as I can merge any AGP PR but SqlDelight 2.0.2 PR fails because of Java 17.

I am pretty confident it is using Java 11 as any look for JavaVersion does not show up anything about JavaVersion_17

Anyway, Gradle 8.10 emits a warning if you don't use a JVM < 17 gradle/gradle#29507, because Gradle 9.0 will require a JVM 17.

I'm still happy to target as low as possible while running on as new as possible ourselves. 11 is a pretty reasonable low mark for tooling things.

I can run assemble on SqlDelight by publishing the sql-psi to MavenLocal. However, I need to keep the Intellij plugin module using Java 17.

Trying to run all the tests but some of them are failing. I migrated some deprecated APIs that were using inline to other new ones that are not inline and I can be missing something. I am running the tests from a Windows machine too, which can affect.

When sql-psi is published using Java 11, I will create the PR.