GROOVY-7492: Groovy should allow CompileStatic classes to not impleme…

[paulk-asert]

…nt GroovyObject

[paulk-asert]

DO NOT commit as is. This is still experimental. I need to see if we can remove ScriptBytecodeAdapter usage within constructors as a minimum.

[PascalSchumacher]

Paul: What do think, is this worth keeping open, or better of closed (to reduce the number of open pull requests)?

[mojo2012]

Just curious, but how can this be open for over 3 years? Did all tests pass back then? If yes why not merge it? The idea of not having to extend GroovyObject sound interesting.

[paulk-asert]

The removal of the GroovyObject interface was relatively easy. But the goal would be that code with @pojo and @CompileStatic wouldn't need the Groovy jar as a dependency. That isn't yet the case. I guess we could look at making this an incubating feature for Groovy 4.

[paulk-asert]

OK.
Also, I am not sure if @POGO is better than @POJO.

Well, the goal is to be not like a normal Groovy object but as close to a plain old Java object as possible even though the source is Groovy. So, in the best possible case, you could use Groovy to be like a Lombok processor and produce Java classes which don't need the Groovy runtime jars to work successfully. As mentioned earlier, that isn't the case for all but the very simplest of cases today but we can expand over time - Records (or record-like classes) could be an early focus.

[sirinath]

Any progress in removing Groovy Jar dependency?

[paulk-asert]

Yes, for simple cases combining @CompileStatic with @pojo (incubating feature in Groovy 4), no jar is needed, e.g.:
https://speakerdeck.com/paulk/groovy-roadmap?slide=34
(This is the "Using Groovy as an alternative to Lombok" scenario which has been an idea for a long time)

But currently only simple cases are supported and there is not a lot of doco around what is possible - it is more a feature for those in the know to start playing with at the moment - hence the incubating status. To give you an idea, if you, for instance, used a GString, you would need the jar since it has the GString class. Other places still fallback to the dynamic runtime in certain scenarios, so you'd need it there too. Feedback welcome of course. We hope to make more scenarios not need the jar over time and add some documentation over time once it becomes more stable.