Compile GSP pages statically across an application

[codeconsole]

Makes GSP static compilation something an existing application can turn on. Measured on an application with 73 <g:set> across its views and a page reading Grails internals reflectively: 415 compilation errors to 0, with two of its own pages edited.

Turning it on

grails:
    views:
        gsp:
            compileStatic: true

The same thing can now be asked for from the build, beside the artefact opt-ins:

grails {
    compileStatic {
        gsp = true
    }
}

The build option states the same grails.views.gsp.compileStatic setting as a system property, so it reaches both places a page is compiled: the forked page compiler, and the JVM running the application, which compiles a page again when it changes. A page compiled one way by the build and another way while being developed would be worse than not offering the option. A page still decides for itself with <%@ page compileStatic="false" %>.

gsp is not part of compileStatic { all = true }. The artefact opt-ins fail on code that is doubtful anyway; this one fails on a page reading a model variable it has not declared, which describes most pages in an application that has never declared one.

What a page has to declare

A page that declares a model states what it is rendered with, so a name outside it is a mistake and is reported:

<%@ page model="Book book" %>
<h1>${book.title}</h1>      <%-- ${publisher} here is an error: it is not in the model --%>

A page that declares nothing has stated nothing, and reads what it is rendered with the way a page that is not compiled statically reads it.

This is the decision the rest follows from. Compiling statically is worth ~1.5x whether or not a page declares anything (below), so requiring every model to be declared first would cost most applications the benefit to gain checking they had not asked for. Declaring buys checking, compiling statically buys speed, and they can be adopted separately. To hold every page to what it declares:

grails {
    compileStatic {
        gsp = true
        strictGsp = true
    }
}

Names the framework binds

These no longer need declaring, and most carry their real types, so they are checked:

Name	Type
params	TypeConvertingMap, so params.id and params.int('max') both resolve
flash	FlashScope
request, response, session	HttpServletRequest, HttpServletResponse, HttpSession
application, servletContext	ServletContext — the same object under both names
webRequest	GrailsWebRequest
controllerName, actionName, namespace	String

Written into the page rather than onto the class it extends: a page is compiled with the application's classpath and that class is not, so FlashScope and GrailsWebRequest, which live in a module depending on the one holding that class, can be named there and not there. It also leaves a page free to declare one of these names in its own model and get its own type.

servletContext is newly bound; only application was, which is the same object.

Being typed, they are checked: ${request.contextPathTypo} is an error, and the converters from #15715 resolve, since session.string('x') only compiles where the session carries its type.

grailsApplication and applicationContext are the only two deliberately not typed. What pages read from them is not declared anywhere: grailsApplication.controllerClasses is matched at runtime against (\w+)(Classes) and answered from the artefact handlers, an open set no interface can enumerate. Typing them only changes which type the failure names, so they are read dynamically, which lets them work.

Names a page introduces

The var and status attributes of the tags a page calls are names the page has declared as plainly as it can, and no longer need declaring again:

<%@ page compileStatic="true" %>
<g:set var="total" value="${books.size()}"/>
<g:each in="${books}" var="book" status="i">${i}. ${book.title}</g:each>
Total: ${total}

What such a name holds is decided by the tag at render time, so it is read dynamically. To apply an operator to it the page has to say what it is, with either tag:

<g:def type="int" var="total" value="${books.size()}"/>   <%-- a local --%>
<g:set type="int" var="total" value="${books.size()}"/>   <%-- a local, and written to the scope --%>
${total + 1}

g:set gained the type: the declaration is written first and the tag is then called with the declared variable as its value, so the scope write still happens and scope still decides where it goes. Untyped g:set is unchanged. A type is accepted only alongside value — with a body or bean the value is produced when the tag runs, so there is nothing to declare from, and that is rejected rather than ignored.

g:def emitted int.cast(...) for a primitive, which throws whatever it is handed, so a page using one compiled and then failed to render. Both tags cast through the wrapper now.

Each tag is used where it fits. The welcome page's counts and collections are read only by the page that declares them, so it uses g:def, which is a local and nothing more. g:set type= is for a value that does need to be in a scope, which previously could not be typed at all.

Holding an artefact type back from all

compileStatic { all = true; services = false } enabled services anyway: the shortcut was folded in as all || services, and every flag carried a convention of false, so a type set to false could not be told apart from one never set. An artefact type now falls back to all rather than being OR-ed with it.

What it is worth

One page body, compiled three ways, 200 rows, 800 renders, median of 7:

dynamic	1.00x
static, nothing declared	1.55x – 1.70x
static, model declared	1.38x – 1.62x

The gain comes from compiling the page statically at all. Declaring a model buys type checking, not speed — the two static rows are indistinguishable here, and their ordering flips between runs. Round-to-round spread is roughly 2x, so these are directional: in-process renders, no HTTP, no JMH, one machine.

Limitations

• An operator applied to a value of no known type is reported, and has to be. ${rows[0]} where nothing said what rows holds is an error rather than being read dynamically: a subscript is written into the class as getAt, and the writer that does it fails with a GroovyBugError rather than an error when handed a receiver whose type was never established. The report says what the page can do — declare it, or give it a type with <g:def type="...">. It covers a closure parameter too, which nothing declares and nothing resolves.
• Templates. A _foo.gsp rendered via <g:render template="foo" model="[...]"/> takes its model from the caller, so it has to declare every attribute it may be passed, and nothing checks that the caller and the template agree.

Relationship to #16134

#16134 resolves tag calls at compile time and overlaps here in one place: its change to GroovyPageTypeCheckingExtension seeds the allowed namespaces from the compiled tag library index, which makes grails.views.gsp.compileStaticConfig.taglibs and the taglibs page directive unnecessary for any tag library on the compile classpath. The section documenting them here should gain a note saying so once that lands; they remain meaningful only for namespaces filled in while the application runs.

Nothing else here changes: that PR touches tag dispatch only, and resolveProperty is untouched by it.

Two files are touched by both and will need merging whichever lands second — GrailsCompileStaticOptions, where that PR adds strictTags and dynamicTagNamespaces to the same block this adds gsp and strictGsp to, and GroovyPagePlugin.

[codecov]

Codecov Report

❌ Patch coverage is 80.93023% with 41 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.6392%. Comparing base (a6f4846) to head (a8e9fb6).
⚠️ Report is 12 commits behind head on 8.0.x.

Files with missing lines	Patch %	Lines
...sp/compiler/GroovyPageTypeCheckingExtension.groovy	72.7273%	9 Missing and 12 partials ⚠️
...oovy/org/grails/gsp/compiler/GroovyPageParser.java	88.4210%	5 Missing and 6 partials ⚠️
.../plugin/views/gsp/GroovyPageForkCompileTask.groovy	33.3333%	4 Missing ⚠️
...rails/gradle/plugin/core/GrailsGradlePlugin.groovy	0.0000%	2 Missing ⚠️
...ls/gradle/plugin/views/gsp/GroovyPagePlugin.groovy	80.0000%	2 Missing ⚠️
.../web/taglib/WebRequestTemplateVariableBinding.java	50.0000%	1 Missing ⚠️

Additional details and impacted files

@@                Coverage Diff                 @@
##                8.0.x     #16139        +/-   ##
==================================================
+ Coverage     52.3242%   52.6392%   +0.3151%     
- Complexity      18537      18579        +42     
==================================================
  Files            2039       2038         -1     
  Lines           97498      97207       -291     
  Branches        17138      17036       -102     
==================================================
+ Hits            51015      51169       +154     
+ Misses          38998      38545       -453     
- Partials         7485       7493         +8     

Files with missing lines	Coverage Δ
...l/src/main/groovy/grails/util/BuildSettings.groovy	19.0476% <ø> (ø)
...n/core/GrailsCompileStaticArtefactsProvider.groovy	100.0000% <100.0000%> (ø)
...adle/plugin/core/GrailsCompileStaticOptions.groovy	100.0000% <100.0000%> (ø)
.../plugin/core/GrailsGspCompileStaticProvider.groovy	100.0000% <100.0000%> (ø)
...oovy/org/grails/gsp/CompileStaticGroovyPage.groovy	66.6667% <ø> (ø)
...ovy/org/grails/gsp/compiler/tags/GroovyDefTag.java	66.6667% <100.0000%> (+4.1667%)	⬆️
.../web/taglib/WebRequestTemplateVariableBinding.java	56.2500% <50.0000%> (-0.2016%)	⬇️
...rails/gradle/plugin/core/GrailsGradlePlugin.groovy	0.0000% <0.0000%> (ø)
...ls/gradle/plugin/views/gsp/GroovyPagePlugin.groovy	59.2105% <80.0000%> (+3.1499%)	⬆️
.../plugin/views/gsp/GroovyPageForkCompileTask.groovy	26.6667% <33.3333%> (+0.7407%)	⬆️
... and 2 more

... and 10 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jdaugherty]

Can't we fix the set tag to handle types? We can always set it to Object and it should still work, no? Why the def?

[jdaugherty]

@codeconsole I think we need to work on the syntax here before proceeding. The set tag could take a type so the compiler knows the type or the def tag could be improved to autocast.

[codeconsole]

g:set takes a type now (a794e2a): the declaration is written first and the tag is still called, so the scope write happens, scope/bean are unaffected, and untyped g:set is unchanged. type is only valid alongside value — with a body or bean there's no expression to declare from.

g:def needed the autocast too: it emitted int.cast(...) for a primitive, which throws whatever it's handed, so a page compiled and then failed to render. Casts through the wrapper now (43dcdc4).

The welcome page stays on g:def — those twelve values are read only by the page that declares them, so the scope write is unused. Say the word if you'd rather it demonstrate g:set type= instead.

[bito-code-review]

The requested file index.gsp is not present in the provided pull request diff. As a result, I cannot analyze the set tag or its implementation details in that file. Please ensure the file is part of the PR or provide the relevant code snippet if you would like me to review it.

[matrei]

Why is [autor] a typo. It should be reported anyway if spelled correctly as it was not declared as part of the model, right? So using a typo in this example is redundant?

[codeconsole]

Any name outside the model is reported whether it's spelled correctly or not. Changed the example to [publisher], which is simply not in the model.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: a8e9fb6
▶️ Tests: 69200 executed
⚪️ Checks: 80/80 completed

---

Learn more about TestLens at testlens.app.