Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ofbiz.apache.org
Subject: Re: [DISCUSSION] migrate mini lang to Java and/or groovy
To: dev@ofbiz.apache.org
References: <f5e76ee0-067c-e032-2c6c-145f2cefbb41@ecomify.de>
	<CALzBqrYpLjHis7E7_FvsC_e_MOFWa4rmV6rq56qC6E4rU=vAKA@mail.gmail.com>
	<8dc0ef20-5260-c31c-00ef-b508619e388f@ecomify.de>
	<CAFqjAi1QtWFAzmpbVHPZYmUkBL6J3ZcHh4593Dzt0ARt30=zxQ@mail.gmail.com>
	<e8ea3e89-3517-12c1-8619-2fbac8641b58@les7arts.com>
From: Jacques Le Roux <jacques.le.roux@les7arts.com>
Organization: Les Arts Informatiques
Message-ID: <f8f512dc-35a8-9b8f-6abe-23c6e0c30a81@les7arts.com>
Date: Thu, 30 Nov 2017 15:33:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <e8ea3e89-3517-12c1-8619-2fbac8641b58@les7arts.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
archived-at: Thu, 30 Nov 2017 14:33:50 -0000

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.brohl@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.brohl@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>