codeconsole opened a new pull request, #16118:
URL: https://github.com/apache/grails-core/pull/16118
Compiling GSP pages is forked, and a forked process runs whatever JVM it is
given. Nothing gave it one, so it inherited the JVM running Gradle — meaning a
project that declared a Java toolchain had its pages built by a different Java
from everything else it built.
Nothing failed while building. The mismatch surfaced the first time a page
was rendered:
```
UnsupportedClassVersionError: gsp_appindex_gsp has been compiled by a more
recent version
of the Java Runtime (class file version 70.0), this version of the Java
Runtime only
recognizes class file versions up to 69.0
```
`compileGroovyPages` now takes its launcher from the project's toolchain, so
pages are compiled by the same Java as the rest of the project:
```groovy
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
```
What a page is compiled *for* follows what it is compiled *by*, unless the
build sets `targetCompatibility` itself, which still wins.
The launcher is a `@Nested` input rather than an internal detail because the
task is cacheable. The Java that did the compiling is part of what the result
is, and without declaring it a cache entry produced by one Java was handed to a
build asking for another — which survived a `clean`, so the usual workaround of
pointing `JAVA_HOME` at the intended Java did not help either.
### Limitations
A project that declares no toolchain is still built by the JVM running
Gradle. That is what compiling pages fell back to before and remains the right
answer when nothing else was asked for, but it means a build relying on
`JAVA_HOME` alone is unchanged by this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
