Downgrade codegen and remaining subprojects to JDK 17

[hpmellema]

Description of changes

Downgrades codegen to JDK 17.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[rhernandez35]

We can and should keep the code generator itself on 21. We only need to target producing 17 bytecode for the client shapes.

[hpmellema]

We can and should keep the code generator itself on 21. We only need to target producing 17 bytecode for the client shapes.

Not sure I follow. If we intend to support customers on JDK17 then it seems like the the code generator plugin should be built on that version. If the code generator plugin targets JDK21 then customers will need to have a JDK21 toolchain configured just to execute the build tooling which seems like it could be a confusing/suboptimal customer experience. Is there some reason I am missing to keep the generator on 21?

[rhernandez35]

We can and should keep the code generator itself on 21. We only need to target producing 17 bytecode for the client shapes.

Not sure I follow. If we intend to support customers on JDK17 then it seems like the the code generator plugin should be built on that version. If the code generator plugin targets JDK21 then customers will need to have a JDK21 toolchain configured just to execute the build tooling which seems like it could be a confusing/suboptimal customer experience. Is there some reason I am missing to keep the generator on 21?

We control the JVM used to run the CLI, right? I thought it was bundled into smithy-cli's runtime image. Or does the smithy gradle plugin use the gradle daemon's JVM when run in gradle? If we're in total control of the JVM used to run the smithy tooling, then we can do whatever we want in the plugins.

[hpmellema]

We control the JVM used to run the CLI, right? I thought it was bundled into smithy-cli's runtime image. Or does the smithy gradle plugin use the gradle daemon's JVM when run in gradle? If we're in total control of the JVM used to run the smithy tooling, then we can do whatever we want in the plugins.

When we are running the build with Gradle the Smithy build tasks will use the Gradle daemon's JVM for executing the build plugins. This is because the Smithy Gradle plugins use the CLI as a JAR dependency rather than using the bundled CLI binary.