Hi All,
I'm maybe too cautious here, but I was thinking about Michael's "some core
principles on how we want to use it" again.
So I reviewed what we have done so far (sub-tasks of OFBIZ-9350). Fortunately I
think we are mostly doing good :)
I though still believe that we should pay more attention about Groovy type safety. When you use an IDE, and even more when it's IntelliJ, you can
certainly worry less about variable types.
But even with Eclipse it's less obvious, not speaking about plain text (for instance while debugging in an environment where you don't have an IDE at
end, etc.)
Please don't take the following personally, I'm just looking for examples to
argument my words.
For instance I find this well done
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/groovyScripts/rate/RateServices.groovy?view=markup
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/groovyScripts/budget/BudgetServices.groovy?view=markup
This a bit less, but still not worrying
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/groovyScripts/agreement/AgreementServices.groovy?view=markup (why no
String in few places, do we want to continue this way?)
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/groovyScripts/admin/AcctgAdminServices.groovy?view=markup (is
EntityCondition use obvious enough?)
The question: should we do more efforts for variables types when porting Minilang to Groovy or is OK as we did so far? You can ignore my question and
I'll then no longer ask and consider a bit of types missing is not an issue.
But when you think about it, services are our API, so maybe (re)-read [3] below.
Also, even if it's out of subject and for a long term (how long?) future, I'm still worried about Groovy future (starting with Java 9 and after)... I
hope we will not find ourselves having to migrate services from Groovy after having done the Minilang migration or even while doing it...
My 2 cts
Jacques
Le 28/05/2017 à 15:16, Jacques Le Roux a écrit :
Well said Taher,
I also believe, using a profiler when needed is the best way when you worry about performance in a specific context. Blindly improving performance
might get you into premature optimization[1] which we should avoid in OOTB code.
I agree with Michael about "some core principles on how we want to use it." One point we need to discuss is if we want to use the optional typing
feature of Groovy[2] or strictly restrict to type safety (always? in which circumstances?[3])
Jacques
[1] https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
[2]
http://javabeginnerstutorial.com/groovy/groovy-the-concept-of-optional-typing/
[3] http://groovy-lang.org/style-guide.html#_optional_typing_advice
Le 28/05/2017 à 14:06, Taher Alkhateeb a écrit :
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
