groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Groovy AOT compilation
Date Tue, 09 May 2017 20:05:36 GMT
On 09.05.2017 08:38, Cédric Champeau wrote:
> I'll let Jochen answer that, I don't recall the reasons why it was a
> breaking change. I think part of the answer is that Groovy classes
> implement GroovyObject, but I miss the details, I'm no dynamic expert ;)
>
> 2017-05-09 8:34 GMT+02:00 Graeme Rocher <graeme.rocher@gmail.com
> <mailto:graeme.rocher@gmail.com>>:
>
>     Would it make sense to have the metaClass field of GroovyObject
>     initialise lazily? In what circumstance would that be a breaking
>     change? Concurrency?

I do not remember the details anymore, since I made that experiment 
years ago. What I remember is that it broke tests and some kinds of 
setting meta class in an initializer block or was it adding meta methods 
there? Anyway. I remember trying it, it was not working and I did not 
spend much more time on trying to make it work. So a new try could bring 
fruit... especially in the context of CompileStatic. Frankly I don´t 
think a static compiled Groovy class does really have to implement 
GroovyObject at all.

As for the lazy init... it is legal to set the field to null and then 
call a method dynamically, since that will reinit the field.

Of course GroovyObjectSupport is something else, since that always does 
eager init.

concurrency is in theory an issue, but since getting a "new" meta class 
from the registry involves synchronization the worst thing that can 
happen is that the registry is asked more than actually needed or that 
an old value non-null is still visible in another thread. But I always 
said, that this is something we simply leave to the user.

bye Jochen

Mime
View raw message