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]> 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 > > > >
