Yes, I've been coming to that conclusion as well, that it is a bug. At minimum it's something the static compiler can/should do, I think. It appears that the issue is that it's not creating (and using) a synthetic method to set the field, like it does to get the field.
I've created a new issue https://issues.apache.org/jira/browse/GROOVY-7705 "CompileStatic closure accessing "thisObject" private field: setProperty instead of synthetic method". The closest existing issue I found is https://issues.apache.org/jira/browse/GROOVY-6825, but it seems to be for inner classes rather than closures, so I'm not sure if this is exactly the same issue. Jason -----Original Message----- From: Jochen Theodorou [mailto:[email protected]] Sent: Tuesday, December 08, 2015 2:57 AM To: [email protected] Subject: Aw: CompileStatic closure accessing "this object" private variable via setGroovyObjectProperty Gesendet: Montag, 07. Dezember 2015 um 18:12 Uhr Von: "Winnebeck, Jason" <[email protected]> An: "[email protected]" <[email protected]> Betreff: CompileStatic closure accessing "this object" private variable via setGroovyObjectProperty I have code with performance issues using closures accessing private fields: @CompileStatic class X { private Y a,b,c void blah() { doClosureThing { //This gets run in a loop, 1000s of times a = … b = … c = … }}} When profiling, I see the majority of time is spent in ScriptBytecodeAdapter.setGroovyObjectProperty. [...] Is this expected behavior for static compiler? Since the compiler checks the assignments to a/b/c, it should also create a direct access to the variables imho. So my answer would be no bye Jochen ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
