[
https://issues.apache.org/jira/browse/GROOVY-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131662#comment-18131662
]
ASF GitHub Bot commented on GROOVY-11154:
-----------------------------------------
paulk-asert commented on PR #3016:
URL: https://github.com/apache/groovy/pull/3016#issuecomment-6393362310
Thanks Daniel.
1. Yes, that's intentional. When the base has no (Binding) constructor,
ModuleNode's contextual constructor is super() followed by setBinding(context),
so it goes the same way as the no-arg one. I've expanded the comment to say so.
A consequence: a base with only argument constructors gives a script that
GroovyShell can't run itself, which is expected, since such bases are
instantiated by the hosting engine.
2. Agreed. The Verifier weaves initializers in later, and the @Field test
covers that.
3. Agreed, I'd leave generating the script constructors from the resolved
base as follow-up work for 7.
4. I checked this one with a precompiled base passed as scriptBaseClass.
When nothing is inherited, the Verifier adds a default constructor, so the
script still fails with the same "Implicit super constructor PrivBase() is
undefined for generated constructor" error as before, not a class with no
constructors.
The CI failure is the groovy-lsp publishDiagnostics race, which is now fixed
on master. A rebase will clear it.
> Script subclasses cannot have constructors with arguments
> ---------------------------------------------------------
>
> Key: GROOVY-11154
> URL: https://issues.apache.org/jira/browse/GROOVY-11154
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 4.0.7
> Reporter: Jonny Carter
> Priority: Major
>
> Prior to the fix for GROOVY-9857, subclasses of {{Script}} could have
> constructor arguments and still be used (with a little help from
> {{InheritConstructors}} and {{DefaultGroovyMethods#newInstance}}).
> For example, the following script executes find in Groovy 3.x, but fails
> after Groovy 4.0.7:
> {code}
> import groovy.transform.InheritConstructors
> import org.codehaus.groovy.ast.AnnotationNode
> import org.codehaus.groovy.ast.ClassNode
> import org.codehaus.groovy.classgen.GeneratorContext
> import org.codehaus.groovy.control.CompilationFailedException
> import org.codehaus.groovy.control.CompilePhase
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.SourceUnit
> import org.codehaus.groovy.control.customizers.CompilationCustomizer
> import org.codehaus.groovy.runtime.DefaultGroovyMethods
> abstract class NamedScript extends Script {
> NamedScript(String name) {
> }
> }
> def compilerConfig = new CompilerConfiguration()
> compilerConfig.setScriptBaseClass(NamedScript.class.getName())
> compilerConfig.addCompilationCustomizers(new
> CompilationCustomizer(CompilePhase.CONVERSION) {
> @Override
> void call(SourceUnit source, GeneratorContext context, ClassNode
> classNode) throws CompilationFailedException {
> classNode.addAnnotation(new AnnotationNode(new
> ClassNode(InheritConstructors.class)))
> }
> })
> def classLoader = new GroovyClassLoader(new GroovyClassLoader(),
> compilerConfig)
> def parsedClass = classLoader.parseClass('println "Foo"')
> DefaultGroovyMethods.newInstance(parsedClass, "dummy").run()
> {code}
> The error returned is:
> {noformat}
> Implicit super constructor NamedScript() is undefined for generated
> constructor. Must define an explicit constructor.
> {noformat}
> Ratpack relies on this behavior for its custom text template renderer.
> See how script objects are instantiated in the
> [ScriptEngine#create|https://github.com/ratpack/ratpack/blob/503060ab2351a49f6e96416d588607ff7ef63028/ratpack-groovy/src/main/java/ratpack/groovy/script/internal/ScriptEngine.java#L51]
> method.
> I talked this out in the Groovy community Slack with [~blackdrag] (see
> [thread|https://groovy-community.slack.com/archives/C2NEFCM55/p1691783910137829]),
> who suggested that we should skip the check for constructors for Script
> subclasses as a bugfix in Groovy 4, with a potentially breaking change in
> Groovy 5 to make constructor generation for Script subclasses happen in the
> same place as any other class.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
