groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: [jira] [Commented] (GROOVY-7492) Groovy should allow CompileStatic classes to not implement GroovyObject
Date Sun, 05 Jul 2015 10:45:56 GMT
Jochen, yes a minimized runtime is probably the way to go medium to long
term. The question for me is whether the feature is of any use (requiring
the full jar) in the meantime? I sent an email to the dev (for now) mailing
list to gather further feedback.

On Sun, Jul 5, 2015 at 8:16 PM, Jochen Theodorou (JIRA) <>

>     [
> ]
> Jochen Theodorou commented on GROOVY-7492:
> ------------------------------------------
> The idea was to provide a minimized runtime for compilestatic. The problem
> is that some of the methods are calling other methods dynamically inside.
> booleanUnbox for example realizes GroovyTruth to some extend and may end up
> calling asBoolean(). It is the same for several methods in DGM.
> Not requiring the Groovy runtime means to remove many additional elements
> Groovy has over Java. That impacts casting, GDK methods and many other
> things. Which is why I suggest to instead think about an alternative static
> compiler runtime. Basically a helper library. And then we would have to go
> through each an every case to think about alternatives.
> > Groovy should allow CompileStatic classes to not implement GroovyObject
> > -----------------------------------------------------------------------
> >
> >                 Key: GROOVY-7492
> >                 URL:
> >             Project: Groovy
> >          Issue Type: New Feature
> >            Reporter: Paul King
> >            Assignee: Paul King
> >              Labels: experimental
> >             Fix For: 2.5.0-beta-1
> >
> >
> > Groovy's powerful AST transformation capabilities are extremely useful
> even in mostly Java projects but the fact that generated classes implement
> GroovyObject means that Groovy must be on the classpath when using any of
> the generated artifacts. This proposed new feature allows an opt-out
> {{@POJO}} marker interface which still applies Groovy's AST transforms but
> then leaves them in a much more Java-like state. The mechanism currently is
> only enabled when using @CompileStatic since it produces Java-like code.
> This opens up some of Groovy's powerful transforms to the wider Java
> community. Groovy can effectively be used as a Lombok-style pre-processor
> for some Java classes. Note that this is still an experimental feature - it
> isn't guaranteed at this stage to always produce code which is free from
> any Groovy jar dependency. As an example, @Immutable for instance might
> require the Groovy jar. We might also consider producing some trivial size
> jar if we can't remove all usages of Groovy code.
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

View raw message