groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alain Stalder <>
Subject Re: [ANN] Grengine 1.0.3
Date Sat, 09 May 2015 06:09:53 GMT

On 09.05.15 01:33, Rhangaun . wrote:
> Hi,
> I use GroovyClassLoader to load, compile and run my scripts (groovy 
> source files only, no runtime strings), could you explain why I should 
> swich to Grengine ? I gave a look to the User Manual and it didn't 
> appear clearly to me.
> Thanks.

Hi Rhangaun,

Should you switch?

   Well, that depends a whole lot on your specific use case. :)

   First of all, if it ain't not broken, don't fix it. :)
   If you already have code that works and performs and can
   be maintained, you could simply stick with it.

   Secondly, in many use cases there is a good solution using the
   classes GroovyClassLoader, GroovyScriptEngine or GroovyShell
   that come with Groovy.

What can Grengine offer?

   Grengine also covers a very broad range of use cases, i.e.
   it is also in general a very generic possible solution.

   With Grengine the approach is maybe overall a bit more uniform
   and you can control things very precisely when needed, a lot can
   be configured in constructors and almost everything by overriding
   single components.

   Grengine's *unique feature* is that it keeps the compiled bytecode
   even of script expressions in memory so that reloading the same script
   in a different context (different class loader) performs better.

   This makes it maybe somewhat predestined for use in a "container"
   of Groovy scripts, especially if different users/session want to
   use the same script base without a need to recompile per user.

   For this general use case, see e.g. a specific use case that I
   solved at work using Grengine:

   * A Case Story with Groovy (and Grengine)

   All of this is not to say that Grengine is complex to use in most
   cases, it just means if you get stuck with a default, you can
   tweak things almost infinitely.

How about some specific differences?

   If you have a GroovyClassLoader and you add a directory of scripts
   to its Groovy class path, exact behavior depends on the order in
   which you then compile scripts. This is very dynamic and often the
   desired behavior, especially in an interactive environment.

   With Grengine, you typically define sets of scripts that you want
   to have in your classpath, for example all scripts in a directory,
   and compile them at once with script interdependencies fully checked
   (c.f GroovyScriptEngine).

   Grengine gren = new Grengine(scriptDir);
   if (gren.getLastUpdateException() != null) {
     // handle...

   This means, that if one of the scripts does not compile, things
   fail early, which may or may not be desired. Note that this is not
   really an issue for a container when changing scripts at runtime.
   If the set of scripts initially compiled, you can stick to that
   compiled version even if the set changes to one that does not
   compile, or not, depending on how you configure Grengine.

   But that does not mean that Grengine is that much more static.

   You can run single scripts by file or text etc. on top of an
   already compiled set of scripts such that only that additional
   script is compiled and only whenever it changed or whenever the
   underlying set of compiled set of scripts changed.;

Once more, should you switch?

   Still depends a lot on the specific use case.

   Very broadly speaking, the more Groovy scripts are used in a
   "productive" environment where someone configures the scripts
   and others use them (maybe with the option to add some custom
   extra scripts for users?), the more Grengine might allow
   operators and developers to sleep a little better? ;)

   But then again, there is Grails and Gradle, for example, which
   (as far as I know) don't use Grengine... ;)

Will Grengine work with future versions of Groovy?

   I say yes, for the reasons outlined in this text on Grengine's
   web site:

   * Grengine Long-term Support

   In a nutshell, the interface between Groovy and Grengine is
   so narrow that definitely with Groovy 2.x.x you should have
   no troubles resp. restoring compatibility would be *very* easy.

   As for a Groovy 3, I don't know how imminent that might be
   and how much might change "under the hood", i.e. regarding the
   classes that Grengine uses. In any case, as long as Groovy 3
   will have a way to compile scripts and a way to configure
   compilation with something broadly similar to today's
   CompilerConfiguration, writing a Grengine 2 that supports
   Groovy 3, should be simple and straightforward.

   On the other hand, overall it might also be interesting to maybe
   include some of Grengine's features or ideas into Groovy 3 itself?

   But so far no specific thoughts/activity from my side... :)

PS: Thanks for asking, I will probably put ~ the above text on
my web site, maybe others are similarly "puzzled" by Grengine,
I definitely suck at "marketing"! :)

Best wishes,

> > Date: Fri, 8 May 2015 23:51:50 +0200
> > From:
> > To:
> > Subject: [ANN] Grengine 1.0.3
> >
> > Grengine Release Notes (1.0.3, 9 May 2015)
> >
> > - New: Convenience Grengine constructors that allow to set the parent
> > class loader
> > of the engine more easily (for easier Grape support, see User Manual).
> >
> >
> >
> > Grengine is an engine for running and embedding Groovy in a Java VM.
> >
> > Fast, easy-to-use and highly customizable.
> >
> > Uses only the compiler from the Groovy JDK, not the GroovyClassLoader,
> > GroovyShell or GroovyScriptEngine.
> >
> > Java, Open Source (Apache 2.0 License).
> >
> >

View raw message