Hi Michael, Thank you for sharing your research findings. All good stuff
A note on optimization: I always prefer to defer optimization because usually in production systems the bottlenecks are only in certain key areas in your application. Also, if you pickup a fast language but write poor logic you'll still end up with performance issues. IMHO efficient clean code always wins. It's easier to understand, It's easier to optimize and easier to profile. Also doing any kind of optimization without measurement might not be useful. So all tips and tricks on optimization might not be effective until we identify the bottle necks and measure their improvements after optimization. So perhaps profiling is very important in here. I think premature optimization usually leads to less clear code, and more corner cases. So perhaps we need to be a bit careful not to put too much of that upfront. Cheers, Taher Alkhateeb On Sun, May 28, 2017 at 1:34 PM, Michael Brohl <michael.br...@ecomify.de> wrote: > Thanks all for your opinions! > > It seems that most of us are in favor of using Groovy instead of Java for > services, events and tests. > > Discussing this internally here at ecomify, it worried us a bit because of > possible performance issues and the better support for Java in Eclipse > (IntelliJ Idea is much better in this field but we cannot expect that > everyone has a copy of it available). > > I did some more reasearch and found a very good article from David E. > Jones about his experience and workarounds he made for Moqui [1]. > > Other interesting resources are [2], [3], [4]. > > My learning from this research is, that we have to be careful how to use > Groovy in OFBiz and need to define some core principles on how we want to > use it. > > One main pattern seems to use the @CompileStatic annotation to avoid > performance issues. This comes with the downside of not being able to use > Groovy features that depend on dynamic typing. > > It would be good if the Groovy experts can add some opinions and I propose > to make a "Groovy best practices" article for our Wiki out of them. > > Thanks and regards, > > Michael Brohl > ecomify GmbH > www.ecomify.de > > > [1] https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones > > [2] https://stackoverflow.com/a/5239450/4579639 > > [3] https://dzone.com/articles/java-7-vs-groovy-21 > > [4] https://stackoverflow.com/a/42040250/4579639 > > > Best regards, > > Michael Brohl > ecomify GmbH > www.ecomify.de > > > > Am 19.05.17 um 16:20 schrieb Jacopo Cappellato: > > My preference is to migrate to the Groovy DSL, and enhance it if required. >> The Groovy DSL is the natural evolution of the core concepts and strengths >> of Minilang and is preferable, in my opinion, to plain Java for the >> implementation of business logic. >> >> Jacopo >> >> >> On Fri, May 19, 2017 at 12:38 PM, Michael Brohl <michael.br...@ecomify.de >> > >> wrote: >> >> Hi All, >>> >>> according to the discussion in [1] and the Jira issue [2] we decided to >>> deprecate mini lang and migrate it to Java and/or Groovy code. >>> >>> To help contributors finding the right approach for the migration, we >>> should define which mini lang code should be migrated to Java code, >>> groovy >>> or some DSL (which has to be further developed). >>> >>> I'd propose to generally migrate services, events and tests to Java code >>> to begin with. >>> >>> >>> There was also a proposal by Paul Foxworthy [3] to have an automatic >>> conversion between mini lang and groovy DSL. Maybe we can extend this to >>> generate Java code also? >>> >>> Any ideas and approach to do this? >>> >>> >>> Happy to hear your opinions, >>> >>> best regards, >>> >>> Michael Brohl >>> ecomify GmbH >>> www.ecomify.de >>> >>> >>> [1] https://lists.apache.org/thread.html/253b41060a295b8ab68bc78 >>> 763cc129fc74b712cf776f8716022097f@%3Cdev.ofbiz.apache.org%3E >>> >>> [2] https://issues.apache.org/jira/browse/OFBIZ-9350 >>> >>> [3] https://lists.apache.org/thread.html/6ce592d253c102e50f25f5f >>> 2095dab1e9b7c54e48260b9e6d1cda9e1@%3Cdev.ofbiz.apache.org%3E >>> >>> >>> >>> >>> > >
