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
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
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
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
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
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
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
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
+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
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
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
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,
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
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
: Michael Brohl [mailto:michael.br...@ecomify.de]
发送时间: 2017年5月19日 18:39
收件人: dev@ofbiz.apache.org
主题: [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
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
16 matches
Mail list logo
