Björn Kautler created GROOVY-9368:
-------------------------------------
Summary: Breaking change regarding jointCompilationOptions
Key: GROOVY-9368
URL: https://issues.apache.org/jira/browse/GROOVY-9368
Project: Groovy
Issue Type: Bug
Affects Versions: 3.0.0-rc-3
Reporter: Björn Kautler
Actually this could just be a question, then sorry.
But I have the strong feeling that this change was unintended.
The Spock AST transformations complain if a specification has a constructor, as
this is not what a user should do.
In case of joint compilation though Groovy adds a no-arg constructor.
Before Groovy 1.7 this was marked as synthetic and could thus be excluded from
the check.
After 1.7 this was changed to additionally allow a public no-arg constructor if
joint compilation is used to heuristically find this situation.
To detect joint compilation it is checked whether
{{org.codehaus.groovy.control.CompilerConfiguration-getJointCompilationOptions}}
returns {{null}} or not.
In Groovy 2 this method only return non-{{null}} if joint compilation is used.
In Groovy 3 this changed.
The field still has a JavaDoc comment saying {{options for joint compilation
(null by default == no joint compilation)}}, but the method never had such a
guarantee in its JavaDoc and now the field is always set in the constructor,
but only filled if joint comiplation is used which breaks the recognition code
of course.
So is the correct way to now check for {{null}} or empty, or is this actually a
regression and the method should still return {{null}} for plain compilation?
Maybe it would also make sense to document either way at the method or to
provide a dedicated method that returns whether joint compilation is used.
(Actually even better would be a way to safely recognize constructors added by
the compiler.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
