GROOVYCLASSLOADER
GroovyClass
Loader .addClassPath(“/home/groovy”)
.loadClass(“com.manydesigns.Foo”) Class
.parseClass(“/home/groovy/com/manydesigns/Foo.groovy”)
Class
IT MAKES SENSE TO DEAL WITH
SCRIPTS AND CLASSES SEPARATELY
} Classpath, packages, classes,
reuse, engineering
} Scripts, files, “spot” usage,
hacking
Groovy is groovy because it supports both perspectives!
Groovy actions:
URL structure same as directory
structure
One action.groovy per directory
Packages are not required
URL’s can be moved/renamed
by moving/renaming the
directories
Nobody can depend on an
action
No refactoring is required
Editable from browser or IDE
Each action.groovy is self-
contained. We treat it as a script.
Groovy classpath:
A real classpath with packages
and classes
Contains beans, base classes for
actions, utility classes invokable
by actions
Typically edited from an IDE
Refactoring
Groovy classpath: similar to a
Java classpath but dynamically
reloadable
CLASS LOADING
ClassLoader Loads Java classes only
parent
classloader
GroovyClassLoader Loads Java & Groovy classes
This is the main problem of embedding.
If Groovy was compiled, Java and Groovy
would live in the same class loader
CLASS LOADING: OGNL
OGNL: %{@org.example.MyGroovyClass@myMethod()}
... does not work because OGNL uses the Java classloader
and cannot resolve Groovy classes
CLASS LOADING: HIBERNATE
In Groovy this works:
From Java it works only if we retrieve Book from the
GroovyClassLoader
PERFORMANCE:
CACHING & RELOADING
Test strategy:
1. “engine warm up”
2. measure the first run
3. measure the second run
4. “touch” the script
5. measure the third run
PERFORMANCE:
CONCLUSIONS
Caching Reloading
GroovyShell.evaluate(String) No --
GroovyShell.run(File) Yes No
GroovyClassLoader Yes No
GroovyScriptEngine Yes Yes
DEPENDENCY RELOADING
A
A depends on B
B is modified
B is reloaded
B
Also A should be reloaded
In theory, but until Groovy 1.8.8/2.0.4 there was a bug:
http://jira.codehaus.org/browse/GROOVY-4975