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)
http://grengine.ch/grey.html
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.
gren.run(scriptFile);
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
http://grengine.ch/support.html
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,
Alain
> Date: Fri, 8 May 2015 23:51:50 +0200
> From: [email protected]
> To: [email protected]
> 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).
>
> http://grengine.ch/manual.html#grengine-and-grape
>
> 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).
>
> http://www.grengine.ch/
