Am 05.07.2015 12:41, schrieb Paul King:
[...]
The goal would be to open up some of the functionality within Groovy to
currently Java-only projects which might not want to introduce the full
Groovy language but like some of the features, e.g. properties, AST
transforms, etc. They might think of Groovy as a giant lombok-style
processor.
See https://issues.apache.org/jira/browse/GROOVY-7492 for more details.
The removal of the GroovyObject interface and associated methods from
the generated classes is relatively straight-forward - see the
experimental PR referenced in the issue. But currently the bytecode
still has numerous references to Groovy classes. There are numerous
casts, Groovy idioms like println which call DGM.println, various
unboxing steps and various other calls some of which are required
functionality, e.g. some transform generated code currently calls back
into Groovy library code directly.
I think most of the problems with depending on the dynamic runtime can
be solved by using a different runtime... in the best case the dynamic
runtime can use that one as well. But I do see a problem with extension
methods. There is nothing telling us if they use the meta class system
inside. Maybe annotate the methods? And what do we do with methods that
use dynamic behaviour but are referenced in such a class? compilation
error? just select an alternative if there? Inheritance cold become very
tricky too
Next steps are to decide whether to take this forward and how.
I think for android we should look into this.
We
already have static and dynamic behavior within Groovy. We don't want
this to become some third behavior over and above not having the
GroovyObject methods in play. So we really do want this to be what makes
sense for @CompileStatic in the context of the GroovyObject methods not
being part of the generated classes.
Groovy already knows classes with and without GroovyObject. I don't see
a big deal in that part. Though the gain of not having those is also
small. If nothing would depend on dynamic behaviour, then the meta
classes would never be created, keeping a few interfaces would be all
that is needed.
Some obvious questions:
(a) Should we still require that the Groovy jar needs to be on the
classpath or produce some light-weight alternative with a very few
number of classes or strive to generate code that is self-contained?
self-contained means to not depend on anything from DGM for example. I
think that will take away too much. I see a bigger future in an
light-weight alternative.
(b) Some things like list/map literals currently make use of Groovy
code, should we try to avoid that?
you mean ScriptBytecodeAdapter and such. That could be changed and
normal Groovy could use that then as well. But of course it is a change
in the bytecode interface.
(c) Some transforms might always need calls back into the Groovy jar. Do
we want the burden of documenting this at this stage? We already have
further work to do wrt traits and transforms.
I guess we would have to document this then, yes.
In due course, we will seek further feedback from the user mailing
list/broader community but I think the idea needs some more fleshing out
before wider feedback will be useful.
I think most important is to know why we want to do use to know how we
want to do this. I see for example android (maybe IoT) as goal for that.
And of course we then have to ask about the gain as well.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
