I took a look at the new Groovy 3 changes at http://groovy-lang.org/releasenotes/groovy-3.0.html and noticed there is still a question as to whether or not to implement lambdas, method references, and default methods as closures and traits. Is the Groovy team still taking feedback on these decisions?
If so, my vote would be to by default, emit JDK8+ "native" implementations wherever possible. I would even go as far to say to allow Groovy 3 to emit JDK8+ lambdas for any expression where a closure inline to a method taking a SAM, as a way to improve Groovy 2 code, but I can understand why it might be better to be consistent and have closure blocks always generate closures (as closures have delegate concept that extends Java lambdas). The reason for my vote is I work on a large Groovy project where performance is a significant consideration. My experience so far is that using closures with streams has poor performance such that any time I want to use streams I either write the class in Java or I make a utility class with the Streams code and call that utility class from Groovy. It is unfortunate that JDK 8's enhancements make Groovy feel a lot less necessary to me, especially since I learned how hard it is to avoid BigDecimal math even when using CompileStatic. We are working with a business rules system and sometimes a single rule can trigger 1k+ times within a single page refresh, so we have to pay attention to which Groovy features we use in certain rules. Avoiding closures, using for in preference to .each, etc., can result in order of magnitude speedup. That's why my vote is to have Groovy compile static generate code as close to Java as possible, whenever a choice is possible. Jason Winnebeck This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
