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 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. 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. https://www.avast.com/antivirus
