groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kerridge, Jon" <>
Subject Re: Re-entrant and multi-entrant Groovy calls
Date Fri, 20 Apr 2018 14:36:27 GMT

Not really, becasue you have just specified the groovy the crucial bit is how this is called
and how data is shared / passed between between the Java and Groovy


Professor Jon Kerridge
School of Computing
Edinburgh Napier University
Merchiston Campus
Edinburgh EH10 5DT

0131 455 2777<>

From: Blake McBride <>
Sent: 20 April 2018 13:32:17
Subject: Re: Re-entrant and multi-entrant Groovy calls

Every time I call Groovy from Java I do the following code snippets.  Does this have the problem
you are referring to?

public void runGroovy(String fileName) {

    JSONObject injson = ...

    JSONObject outjson = ...

    HibernateSessionUtil hsu = ...

GroovyClass gclass = loadClass(fileName, true);
if (gclass != null) {
Class[] ca = {

try {
Method methp = gclass.getMethod(_method, ca);
if (methp == null) {
errorReturn(response, "Method " + _method + " not found in class " + this.getClass().getName(),
methp.invoke(null, injson, outjson, hsu, this);
} catch (Exception e) {
errorReturn(response, "Error running method " + _method + " in class " + this.getClass().getName(),
} else {
errorReturn(response, "Error loading " + fileName, null);

public synchronized static GroovyClass loadClass(String fileName, boolean report) {
    GroovyClass gclass;
    [some class cacheing code]
    try {
        gclass = new GroovyClass(false, fileName);
        classCache.put(fileName, new ClassInfo(gclass, (new File(fileName)).lastModified()));
    } catch (FileNotFoundException e) {
        if (report)
            logger.error("File " + fileName + " not found", e);
        return null;
    } catch (Exception e) {
        if (report)
            logger.error("Error loading " + fileName, e);
        return null;
    return gclass;

On Fri, Apr 20, 2018 at 7:15 AM, Wolfgang Pedot <<>>
For Groovy-scripts you need to know that each instance of a script has a Binding to store
variables in it and that may cause re-entrance or concurrency issues if you dont create a
new script instance for each call.


Am 20.04.2018 um 11:21 schrieb Blake McBride:

Does Groovy safely support re-entrant and multi-entrant calls? What I mean by that is the

Re-entrant: on a single OS thread - my Java program calls into Groovy, then Groovy calls into
my Java application, and then the Java application calls back into Groovy. So the stack has
Java, Groovy, JAVA, and then Groovy again.

Multi-entrant: my Java application has many threads.  One of my threads calls into Groovy.
Then, while one thread is still in Groovy, another thread evokes Groovy. So now we have two
calls into Groovy by two independent Java/OS threads running at the same time.

I understand the typical problems associated with application-level shared variables.  This
is expected.  The question revolves around Groovy's internals.  I presume Groovy may have
some shared data that is internal to Groovy. That's what I am unclear about. Groovy would
have had to be designed for these scenarios from the ground up.

This is a little hard to test because if it can't always correctly handle these situations,
it may not become clear until certain scenarios arrive.  It may be hard for any "test" program
I write to cause those scenarios, so I thought this may be a known answer.


Blake McBride

This message and its attachment(s) are intended for the addressee(s) only and should not be
read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s)
without the permission of the sender. If you are not the intended addressee you must not take
any action based on this message and its attachment(s) nor must you copy or show them to anyone.
Please respond to the sender and ensure that this message and its attachment(s) are deleted.

It is your responsibility to ensure that this message and its attachment(s) are scanned for
viruses or other defects. Edinburgh Napier University does not accept liability for any loss
or damage which may result from this message or its attachment(s), or for errors or omissions
arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier
University's system are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373

View raw message