groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject experimental new feature @POJO
Date Sun, 05 Jul 2015 10:41:43 GMT

Hi folks,

If anyone has some free cycles, I wouldn't mind some help looking at an experimental feature
(no sooner than Groovy 2.5) I discussed with a few of the core committers some time back -
but none of us really had the time to look at it properly. The basic idea is to provide a
marker interface, @POJO, which when used in conjunction with @CompileStatic would produce
(ideally) Java-consumable artifacts. We deemed that we'd only try this with @CompileStatic
code since it is closer to normal Java code and doesn't require the elaborate metaclass mechanics
to work properly.

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

Next steps are to decide whether to take this forward and how. 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.

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?
(b) Some things like list/map literals currently make use of Groovy code, should we try to
avoid that?
(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.

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.

Cheers, Paul.

This email has been checked for viruses by Avast antivirus software.

View raw message