You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Michael Brohl <mi...@ecomify.de> on 2017/05/19 10:38:44 UTC
[DISCUSSION] migrate mini lang to Java and/or groovy
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/253b41060a295b8ab68bc78763cc129fc74b712cf776f8716022097f@%3Cdev.ofbiz.apache.org%3E
[2] https://issues.apache.org/jira/browse/OFBIZ-9350
[3]
https://lists.apache.org/thread.html/6ce592d253c102e50f25f5f2095dab1e9b7c54e48260b9e6d1cda9e1@%3Cdev.ofbiz.apache.org%3E
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Taher Alkhateeb <sl...@gmail.com>.
Fair enough, your solution is cleaner for sure. I put forward my idea to
speedup the transition but no rush!
Java or Groovy or any other programming language is fine by me. I don't
think we need to restrict what people can write to replace minilang because
frankly all options are 1000% better than XML. As long aa you write in a
real programming language, we're getting progress
On May 19, 2017 6:54 PM, "gil portenseigne" <gi...@nereide.fr>
wrote:
Hi Taher
I tend to prefer rewriting old and messy mini-lang to proper groovy DSL or
java.
I fear that code generation from poor designed minilang (beside the
technical interest :) ) could lead to have a lot of bad java with a lot of
cleaning required.
Gil
Le 19/05/2017 à 15:15, Taher Alkhateeb a écrit :
> My recommendation if you want to achieve something significant for this
> task is the following:
>
> - Focus first on services and tests, the bulk of messy minilang is living
> there
> - Maybe we shouldn't reinvent the wheel. We already have the minilang
> parsing logic, why not just use it to convert everything to Java? Yeah it
> might look a bit odd, but we can do a full migration of all minilang
> scripts in one shot. Then we can slowly focus on cleanup.
>
> On Fri, May 19, 2017 at 2:59 PM, Nicolas Malin <ni...@nereide.fr>
> wrote:
>
> Hi Michael,
>>
>> My preference go to convert the mini-lang to Groovy with the following
>> reason :
>>
>> * Ensure the DSL cover all mini-lang functionnality and if not why
>>
>> * Implement some services in groovy
>>
>> * Do it manually at the beginning, convert automatically it's just a
>> nightmare if you are not sure that all functionality are convertible.
>>
>> Cheers,
>>
>> Nicolas
>>
>>
>>
>> Le 19/05/2017 à 12:38, Michael Brohl a écrit :
>>
>> 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
>>>
>>>
>>>
>>>
>>>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by gil portenseigne <gi...@nereide.fr>.
Hi Taher
I tend to prefer rewriting old and messy mini-lang to proper groovy DSL
or java.
I fear that code generation from poor designed minilang (beside the
technical interest :) ) could lead to have a lot of bad java with a lot
of cleaning required.
Gil
Le 19/05/2017 à 15:15, Taher Alkhateeb a écrit :
> My recommendation if you want to achieve something significant for this
> task is the following:
>
> - Focus first on services and tests, the bulk of messy minilang is living
> there
> - Maybe we shouldn't reinvent the wheel. We already have the minilang
> parsing logic, why not just use it to convert everything to Java? Yeah it
> might look a bit odd, but we can do a full migration of all minilang
> scripts in one shot. Then we can slowly focus on cleanup.
>
> On Fri, May 19, 2017 at 2:59 PM, Nicolas Malin <ni...@nereide.fr>
> wrote:
>
>> Hi Michael,
>>
>> My preference go to convert the mini-lang to Groovy with the following
>> reason :
>>
>> * Ensure the DSL cover all mini-lang functionnality and if not why
>>
>> * Implement some services in groovy
>>
>> * Do it manually at the beginning, convert automatically it's just a
>> nightmare if you are not sure that all functionality are convertible.
>>
>> Cheers,
>>
>> Nicolas
>>
>>
>>
>> Le 19/05/2017 à 12:38, Michael Brohl a écrit :
>>
>>> 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
>>>
>>>
>>>
>>>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 19/05/2017 à 15:15, Taher Alkhateeb a écrit :
> - Maybe we shouldn't reinvent the wheel. We already have the minilang
> parsing logic, why not just use it to convert everything to Java? Yeah it
> might look a bit odd, but we can do a full migration of all minilang
> scripts in one shot. Then we can slowly focus on cleanup.
I like the idea but I have to disagree. I'm against "blindly" converting Minilang to Java.
One of the reason, and I guess the main reason, why Minilang was created is because the need to compile for simple events and even services is a pain
when you want to develop fast (who don't?)
I explained that POV at https://s.apache.org/VDbJ
There were other reasons we should not forget https://s.apache.org/IVFH
So we need to check if we have an as complete DSL with Groovy DSL before switching https://s.apache.org/xLl0
BTW, I don't recall we discussed about a replacement of "Simple Map Processor", did we?
Jacques
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Taher Alkhateeb <sl...@gmail.com>.
My recommendation if you want to achieve something significant for this
task is the following:
- Focus first on services and tests, the bulk of messy minilang is living
there
- Maybe we shouldn't reinvent the wheel. We already have the minilang
parsing logic, why not just use it to convert everything to Java? Yeah it
might look a bit odd, but we can do a full migration of all minilang
scripts in one shot. Then we can slowly focus on cleanup.
On Fri, May 19, 2017 at 2:59 PM, Nicolas Malin <ni...@nereide.fr>
wrote:
> Hi Michael,
>
> My preference go to convert the mini-lang to Groovy with the following
> reason :
>
> * Ensure the DSL cover all mini-lang functionnality and if not why
>
> * Implement some services in groovy
>
> * Do it manually at the beginning, convert automatically it's just a
> nightmare if you are not sure that all functionality are convertible.
>
> Cheers,
>
> Nicolas
>
>
>
> Le 19/05/2017 à 12:38, Michael Brohl a écrit :
>
>> 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
>>
>>
>>
>>
>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Nicolas Malin <ni...@nereide.fr>.
Hi Michael,
My preference go to convert the mini-lang to Groovy with the following
reason :
* Ensure the DSL cover all mini-lang functionnality and if not why
* Implement some services in groovy
* Do it manually at the beginning, convert automatically it's just a
nightmare if you are not sure that all functionality are convertible.
Cheers,
Nicolas
Le 19/05/2017 à 12:38, Michael Brohl a écrit :
> 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/253b41060a295b8ab68bc78763cc129fc74b712cf776f8716022097f@%3Cdev.ofbiz.apache.org%3E
>
> [2] https://issues.apache.org/jira/browse/OFBIZ-9350
>
> [3]
> https://lists.apache.org/thread.html/6ce592d253c102e50f25f5f2095dab1e9b7c54e48260b9e6d1cda9e1@%3Cdev.ofbiz.apache.org%3E
>
>
>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Jacques Le Roux <ja...@les7arts.com>.
Of course, as retweeted Sharan, we can still hope the Groovy community will resolve these issues as planned
https://twitter.com/ApacheGroovy/status/937684077045481475
Jacques
Le 30/11/2017 à 15:51, Jacques Le Roux a écrit :
> Le 30/11/2017 à 15:33, Jacques Le Roux a écrit :
>> 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...
> And if you get some time you might appreciate to read https://lists.apache.org/list.html?users@groovy.apache.org:gte=1d:java%209 and the related Jira
>
> Jacques
>
>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 30/11/2017 à 15:33, Jacques Le Roux a écrit :
> 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...
And if you get some time you might appreciate to read https://lists.apache.org/list.html?users@groovy.apache.org:gte=1d:java%209 and the related Jira
Jacques
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <mi...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <mi...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Taher Alkhateeb <sl...@gmail.com>.
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 <mi...@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
>>>
>>>
>>>
>>>
>>>
>
>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Michael Brohl <mi...@ecomify.de>.
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 <mi...@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
>>
>>
>>
>>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Jacques Le Roux <ja...@les7arts.com>.
Nicely said, +1
Jacques
Le 19/05/2017 à 16:20, Jacopo Cappellato a écrit :
> 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 <mi...@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
>>
>>
>>
>>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by gil portenseigne <gi...@nereide.fr>.
+1
I like the work done with the Groovy DSL and i see no drawback using it
compared to java.
Gil
Le 19/05/2017 à 16:20, Jacopo Cappellato a écrit :
> 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 <mi...@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
>>
>>
>>
>>
Re: [DISCUSSION] migrate mini lang to Java and/or groovy
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
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 <mi...@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
>
>
>
>