Hi Paul,
thank you for the feedback (I searched the Groovy Jira, but was using
"field assignment" as the search term, so missed this issue).
Weird bug, just taking away all the final qualifiers actually works, no
@Lazy required - I didn't even test that far, since that is such a
general problem, that I would have thought people would already have
complained about this in troves...
Cheers,
mg
On 10.03.2018 22:10, Paul King wrote:
There is a known bug in trait initialization for final fields:
https://issues.apache.org/jira/browse/GROOVY-8281
It's on my list to fix before 2.5.0 final. Happy for any assistance.
Cheers, Paul.
On Sun, Mar 11, 2018 at 6:37 AM, MG <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I recently refactored the reflection code of my framework to
support using traits to share fields. The shared fields are
initialized during field declaration (i.e. not in a ctor) for user
convenience (they represent columns in a table). In this
particular case, fields needed to be passed as parameters to to
other field's ctors. In this case the problem is, that the fields
passed to other fields ctors seem to alwys be null. The same code
constructs have been working for years when using them directly
inside a class.
Questions:
1. What is the expected behavior in this case ? Should this work
in traits ?
2. If this is not a bug in Groovy: What is the best workaround ?
I only had very little time to work on this last week, so I
used a @Memoized helper method whose return value is used in
both the field initializations - works, but a pretty terrible
solution and user experience.
I just did a quick spike at home using @Lazy on one field:
This seems to work, but not, if combined with final - so the
field could be reassigned (which I don't want) unless the
framework user introduces a shared @Lazy "hidden" private
helper field (similar to my @Memoized method).
3. In general: What is the exact order that fields get
initialized in Groovy - and is this behavior expected to
change in the future ?
Cheers,
mg
