Discussion: Improved Groovy Support

[Adrian Crum]

I have been working on some ideas with the goal of making Groovy a
viable alternative to mini-language. I already committed some code that
allows methods within a Groovy script to be called, so that multiple
services can be included in one file - just like in Java or mini-language.

My next step is to create a Groovy script that contains utility methods
that mimic many of the existing mini-language elements - particularly
the ones that do a lot of work in one line. The utility script
(ScriptUtil) will be in the Groovy context so it will be easy to access.
For example:

<simple-method method-name="createPartyRole">
     <entity-one entity-name="PartyRole" value-field="partyRole"/>
     <if-empty field="partyRole">
         <make-value entity-name="PartyRole" value-field="newEntity"/>
         <set-pk-fields map="parameters" value-field="newEntity"/>
         <create-value value-field="newEntity"/>
     </if-empty>
</simple-method>

becomes

Map createPartyRole() {
     partyRole = ScriptUtil.entityOne("PartyRole");
     if (partyRole == null) {
         partyRole = ScriptUtil.makeValue("PartyRole");
         partyRole.setPKFields(parameters, true);
         delegator.create(partyRole, true);
     }
     return ServiceUtil.returnSuccess();
}

The ScriptUtil methods will duplicate the mini-language Java code so
they will be interchangeable.

The bottom line is, I'm trying to bring some of mini-language's ease of
use to Groovy. Before I proceed any further, I wanted to find out if
there was any interest in it.

What do you think?

-Adrian

[Adam Heath-2]

Adrian Crum wrote:
> I have been working on some ideas with the goal of making Groovy a
> viable alternative to mini-language. I already committed some code that
> allows methods within a Groovy script to be called, so that multiple
> services can be included in one file - just like in Java or mini-language.

Be very very careful.  If you do this, you'll increase permgen usage.
 Each groovy script is a class, and if those classes are kept around,
they'll take up precious permgen space.

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

>I have been working on some ideas with the goal of making Groovy a viable alternative to mini-language. I already committed some
>code that allows methods within a Groovy script to be called, so that multiple services can be included in one file - just like in
>Java or mini-language.
>
> My next step is to create a Groovy script that contains utility methods that mimic many of the existing mini-language elements -
> particularly the ones that do a lot of work in one line. The utility script (ScriptUtil) will be in the Groovy context so it will
> be easy to access. For example:
>
> <simple-method method-name="createPartyRole">
>     <entity-one entity-name="PartyRole" value-field="partyRole"/>
>     <if-empty field="partyRole">
>         <make-value entity-name="PartyRole" value-field="newEntity"/>
>         <set-pk-fields map="parameters" value-field="newEntity"/>
>         <create-value value-field="newEntity"/>
>     </if-empty>
> </simple-method>
>
> becomes
>
> Map createPartyRole() {
>     partyRole = ScriptUtil.entityOne("PartyRole");
>     if (partyRole == null) {
>         partyRole = ScriptUtil.makeValue("PartyRole");
>         partyRole.setPKFields(parameters, true);
>         delegator.create(partyRole, true);
>     }
>     return ServiceUtil.returnSuccess();
> }

>     if (partyRole == null) {
should better be
if (!partyRole) {

Else sounds promising (especially for new comers): less verbose, and well known syntax.
But as I already said before replacing minilang (or even being used besides) we need to be sure that a DSL language based on groovy
does not introduce any problems.

Jacques

>
> The ScriptUtil methods will duplicate the mini-language Java code so they will be interchangeable.
>
> The bottom line is, I'm trying to bring some of mini-language's ease of use to Groovy. Before I proceed any further, I wanted to
> find out if there was any interest in it.
>
> What do you think?
>
> -Adrian
>

[Adrian Crum]

Adam Heath wrote:
> Adrian Crum wrote:
>> I have been working on some ideas with the goal of making Groovy a
>> viable alternative to mini-language. I already committed some code that
>> allows methods within a Groovy script to be called, so that multiple
>> services can be included in one file - just like in Java or mini-language.
>
> Be very very careful.  If you do this, you'll increase permgen usage.
>  Each groovy script is a class, and if those classes are kept around,
> they'll take up precious permgen space.

They are kept in the script.GroovyLocationParsedCache cache. Is there
anything we can do to mitigate permgen space usage?

-Adrian

[Adrian Crum]

Jacques Le Roux wrote:
> Else sounds promising (especially for new comers): less verbose, and
> well known syntax.
> But as I already said before replacing minilang (or even being used
> besides) we need to be sure that a DSL language based on groovy
> does not introduce any problems.

It is not my intention to replace mini-language. It will be an alternative.

[Adam Heath-2]

Adrian Crum wrote:

> Adam Heath wrote:
>> Adrian Crum wrote:
>>> I have been working on some ideas with the goal of making Groovy a
>>> viable alternative to mini-language. I already committed some code that
>>> allows methods within a Groovy script to be called, so that multiple
>>> services can be included in one file - just like in Java or
>>> mini-language.
>>
>> Be very very careful.  If you do this, you'll increase permgen usage.
>>  Each groovy script is a class, and if those classes are kept around,
>> they'll take up precious permgen space.
>
> They are kept in the script.GroovyLocationParsedCache cache. Is there
> anything we can do to mitigate permgen space usage?

That has nothing to do with any kind of jit'ed bytecode.

[Adrian Crum]

Adam Heath wrote:

> Adrian Crum wrote:
>> Adam Heath wrote:
>>> Adrian Crum wrote:
>>>> I have been working on some ideas with the goal of making Groovy a
>>>> viable alternative to mini-language. I already committed some code that
>>>> allows methods within a Groovy script to be called, so that multiple
>>>> services can be included in one file - just like in Java or
>>>> mini-language.
>>> Be very very careful.  If you do this, you'll increase permgen usage.
>>>  Each groovy script is a class, and if those classes are kept around,
>>> they'll take up precious permgen space.
>> They are kept in the script.GroovyLocationParsedCache cache. Is there
>> anything we can do to mitigate permgen space usage?
>
> That has nothing to do with any kind of jit'ed bytecode.

Did that answer my question? I'm lost.

-Adrian

[Chris Snow-3]

Hi Adrian,  I've been thinking about this too.  I think there will be a
lot of merit in combining the power of minilang + the power of groovy.

I'm still reading about groovying meta programming and DSL's, and I
don't yet understand the service engine under the hood, so I'm really
just thinking aloud here:

Could the groovy service class instance have the following methods
injected: entityOne(), makeValue(), returnSuccess(), createEntity(),
etc?  That way, we wouldn't need a reference to the ScriptUtil class:

Map createPartyRole() {
    partyRole = entityOne('PartyRole')
    if (partyRole == null) {
        partyRole = makeValue('PartyRole')
        partyRole.setPKFields(parameters, true)
        createEntity(partyRole, true)
    }
    returnSuccess()
}

Also, I was wondering whether we could manipulate the lists returned by
GenericValue like so:

party.getRelated("PartyRole").each() { roleTypeId ->
   switch roleTypeId
   {
      case 'CONTENT_USER':
        // doSomething(party)
        break
      case 'XYZ':
        // doSomethingElse(party)
        break
   }
}

... just some thoughts

Chris

Adrian Crum wrote:

> I have been working on some ideas with the goal of making Groovy a
> viable alternative to mini-language. I already committed some code
> that allows methods within a Groovy script to be called, so that
> multiple services can be included in one file - just like in Java or
> mini-language.
>
> My next step is to create a Groovy script that contains utility
> methods that mimic many of the existing mini-language elements -
> particularly the ones that do a lot of work in one line. The utility
> script (ScriptUtil) will be in the Groovy context so it will be easy
> to access. For example:
>
> <simple-method method-name="createPartyRole">
>     <entity-one entity-name="PartyRole" value-field="partyRole"/>
>     <if-empty field="partyRole">
>         <make-value entity-name="PartyRole" value-field="newEntity"/>
>         <set-pk-fields map="parameters" value-field="newEntity"/>
>         <create-value value-field="newEntity"/>
>     </if-empty>
> </simple-method>
>
> becomes
>
> Map createPartyRole() {
>     partyRole = ScriptUtil.entityOne("PartyRole");
>     if (partyRole == null) {
>         partyRole = ScriptUtil.makeValue("PartyRole");
>         partyRole.setPKFields(parameters, true);
>         delegator.create(partyRole, true);
>     }
>     return ServiceUtil.returnSuccess();
> }
>
> The ScriptUtil methods will duplicate the mini-language Java code so
> they will be interchangeable.
>
> The bottom line is, I'm trying to bring some of mini-language's ease
> of use to Groovy. Before I proceed any further, I wanted to find out
> if there was any interest in it.
>
> What do you think?
>
> -Adrian

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> Adam Heath wrote:>> Adrian Crum wrote:
>>> Adam Heath wrote:
>>>> Adrian Crum wrote:
>>>>> I have been working on some ideas with the goal of making Groovy a
>>>>> viable alternative to mini-language. I already committed some code that
>>>>> allows methods within a Groovy script to be called, so that multiple
>>>>> services can be included in one file - just like in Java or
>>>>> mini-language.
>>>> Be very very careful.  If you do this, you'll increase permgen usage.
>>>>  Each groovy script is a class, and if those classes are kept around,
>>>> they'll take up precious permgen space.
>>> They are kept in the script.GroovyLocationParsedCache cache. Is there
>>> anything we can do to mitigate permgen space usage?
>>
>> That has nothing to do with any kind of jit'ed bytecode.
>
> Did that answer my question? I'm lost.
>
> -Adrian

Is there any help from http://docs.codehaus.org/display/GROOVY/Writing+Domain-Specific+Languages ?

Jacques

[Chris Snow-3]

Is there any help from
http://docs.codehaus.org/display/GROOVY/Writing+Domain-Specific+Languages ?
>
> Jacques
>
There is some scattered information on that site, I have found a much
more thorough treatment on Meta Object Programming and DSL in the book:
"Programming Groovy - Dynamic Productivity for the Java Developer by
Venkat Subramaniam"

[Adrian Crum]

Christopher Snow wrote:

> Hi Adrian,  I've been thinking about this too.  I think there will be a
> lot of merit in combining the power of minilang + the power of groovy.
>
> I'm still reading about groovying meta programming and DSL's, and I
> don't yet understand the service engine under the hood, so I'm really
> just thinking aloud here:
>
> Could the groovy service class instance have the following methods
> injected: entityOne(), makeValue(), returnSuccess(), createEntity(),
> etc?  That way, we wouldn't need a reference to the ScriptUtil class:
>
> Map createPartyRole() {
>    partyRole = entityOne('PartyRole')
>    if (partyRole == null) {
>        partyRole = makeValue('PartyRole')
>        partyRole.setPKFields(parameters, true)
>        createEntity(partyRole, true)
>    }
>    returnSuccess()
> }

I considered method injection, but the drawback is name clash with
existing script methods.

> Also, I was wondering whether we could manipulate the lists returned by
> GenericValue like so:
>
> party.getRelated("PartyRole").each() { roleTypeId ->   switch roleTypeId
>   {
>      case 'CONTENT_USER':
>        // doSomething(party)
>        break
>      case 'XYZ':
>        // doSomethingElse(party)
>        break
>   }
> }

Probably. I'm sure you can do anything Groovy supports.

[Adrian Crum]

Jacques Le Roux wrote:

> From: "Adrian Crum" <[hidden email]>
>> Adam Heath wrote:>> Adrian Crum wrote:
>>>> Adam Heath wrote:
>>>>> Adrian Crum wrote:
>>>>>> I have been working on some ideas with the goal of making Groovy a
>>>>>> viable alternative to mini-language. I already committed some code
>>>>>> that
>>>>>> allows methods within a Groovy script to be called, so that multiple
>>>>>> services can be included in one file - just like in Java or
>>>>>> mini-language.
>>>>> Be very very careful.  If you do this, you'll increase permgen usage.
>>>>>  Each groovy script is a class, and if those classes are kept around,
>>>>> they'll take up precious permgen space.
>>>> They are kept in the script.GroovyLocationParsedCache cache. Is there
>>>> anything we can do to mitigate permgen space usage?
>>>
>>> That has nothing to do with any kind of jit'ed bytecode.
>>
>> Did that answer my question? I'm lost.
>>
>> -Adrian
>
>
> Is there any help from
> http://docs.codehaus.org/display/GROOVY/Writing+Domain-Specific+Languages ?

I don't see where that page talks about permgen space usage.

[Adrian Crum-2]

--- On Thu, 3/25/10, Adam Heath <[hidden email]> wrote:

> Adrian Crum wrote:
> > I have been working on some ideas with the goal of
> making Groovy a
> > viable alternative to mini-language. I already
> committed some code that
> > allows methods within a Groovy script to be called, so
> that multiple
> > services can be included in one file - just like in
> Java or mini-language.
>
> Be very very careful.  If you do this, you'll increase
> permgen usage.
>  Each groovy script is a class, and if those classes are
> kept around,
> they'll take up precious permgen space.

One of the things I noticed about the existing GroovyUtil code is that a class loader instance is created for each class. I'm sure the code was copied from a Groovy tutorial or code example. Each class loader instance holds a reference to the thread's class loader. I'm not a permgen memory expert, but it appears to me that way of doing things will result in memory leaks.

I can't use jmap because I'm running Windows, otherwise I would do some research. Any hints or suggestions would be welcome.

-Adrian

[Adam Heath-2]

Adrian Crum wrote:

> --- On Thu, 3/25/10, Adam Heath <[hidden email]> wrote:
>> Adrian Crum wrote:
>>> I have been working on some ideas with the goal of
>> making Groovy a
>>> viable alternative to mini-language. I already
>> committed some code that
>>> allows methods within a Groovy script to be called, so
>> that multiple
>>> services can be included in one file - just like in
>> Java or mini-language.
>>
>> Be very very careful.  If you do this, you'll increase
>> permgen usage.
>>  Each groovy script is a class, and if those classes are
>> kept around,
>> they'll take up precious permgen space.
>
> One of the things I noticed about the existing GroovyUtil code is that a class loader instance is created for each class. I'm sure the code was copied from a Groovy tutorial or code example. Each class loader instance holds a reference to the thread's class loader. I'm not a permgen memory expert, but it appears to me that way of doing things will result in memory leaks.

No, that's on purpose, and as designed.  If they all share the same
classloader, then you can't garbage collect any class, without
throwing them *all* away.