+1 certainly sounds like a good plan On Tue, 7 Mar 2017 at 01:17 Alex Heneveld <[email protected]> wrote:
> > +1 > > Minor comments: > > > 2. For a "MethodEffector", the effector invocation goes through > > `GroovyJavaMethods.invokeMethodOnMetaClass`. This calls into groovy > > code to find the method that matches the given arguments. > > Reflections.findMethodMaybe and invokeMethodWithArgs might be drop-in > replacements > > > one can often supply a Groovy closure instance (e.g. as a config key > value) and > > have it automatically converted to Predicate/Function/etc > > Java 8-isms should let us overhaul this. As a first step in 0.11 for > good measure we should log.warn if a Closure is being supplied. > > --A > > > > On 06/03/2017 19:01, Aled Sage wrote: > > Hi all, > > > > I propose we deprecate and then remove the remaining groovy code from > > Brooklyn: deprecate for 0.11.0, and delete a couple of releases later. > > > > I think we should treat Groovy like any other JVM-based language that > > users might want to use: it's the user's responsibility; we present a > > pure Java API that those languages can call. > > > > I'd estimate the first stage (deprecation in 0.11.0) as being just a > > few hours work. > > > > _*Advantages of Deleting this Code*_ > > > > * Simplify our code base > > (with all the usual advantages of understandability, simpler > > refactoring, etc). > > * Make support easier > > (luckily no-one has asked any Groovy questions in years! Do we > > really want to fix any bugs that Groovy users hit?!) > > * Make it easier for (Java) developers: > > o More understandable e.g. the black magic of how "MethodEffector" > > works. > > o Easier IDE setup (e.g. don't need to worry about .groovy files, > > or risk breaking them if you ignore them) > > * Simplify our build process > > * Reduce our binary distribution by over 7MB > > > > > > _*Background*_ > > The most early versions of Brooklyn (before it joined Apache) were > > written in Groovy. We grew to regret that technology choice, and > > switched to pure Java instead. We also now strongly recommend users to > > focus on YAML-based blueprints whereever possible, which makes things > > like Groovy support even more redundant. > > > > > > _*Current Usage*_ > > Groovy is (unfortunately) still used under-the-covers in a few places: > > > > 1. Groovy's `ObservableList` is used under-the-covers by > > `LocalEntityManager.entities`. > > 2. For a "MethodEffector", the effector invocation goes through > > `GroovyJavaMethods.invokeMethodOnMetaClass`. This calls into groovy > > code to find the method that matches the given arguments. > > 3. `GroovyJavaMethods` is used for some groovy'isms (Groovy Truth > > primarily). > > > > Groovy's closures have special support in various places - e.g. some > > methods are overloaded to accept a Closure instead of a > > Runnable/Callable/Function/Predicate. Also, the `TypeCoercions` means > > that one can often supply a Groovy closure instance (e.g. as a config > > key value) and have it automatically converted to Predicate/Function/etc. > > > > I think our build does special groovy stuff (e.g. there are groovy > > test classes, which explicitly test the Closure support). > > > > > > _*Next Steps*_ > > Assuming we agree... > > > > For 0.11.0: > > > > * Deprecate all methods that take a Groovy parameter type (e.g. > > Closure, groovy.time.TimeDuration, etc). > > * Deprecate `GroovyJavaMethods` and the other classes in the > > `brooklyn-utils-groovy` module. > > * Include in the release notes that this is deprecated, and Groovy > > will be removed from Brooklyn in a future release. > > > > Subsequently: > > > > * Remove internal uses of Groovy, at our leisure. > > > > In some future release: > > > > * Delete all the deprecated methods and utilities, the groovy > > dependency, the .groovy test classes, and any other mentions of it > > from our poms/build. > > > > I'd estimate the first stage (for 0.11.0) as being just a few hours work. > > > > Aled > > > > > >
