Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.0.0-rc-3
-
None
-
None
Description
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.)
Attachments
Issue Links
- links to
