[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-dev
Subject:    [groovy-dev] Re: leanengine - A lean engine for running Groovy scripts inside a Java VM
From:       "Jex Jexler $(whois jexler.net)" <jex () jexler ! net>
Date:       2014-08-15 16:37:56
Message-ID: 1408120676488-5720846.post () n5 ! nabble ! com
[Download RAW message or body]

I found out how to compile such that it finds the other classes correctly:
- I indicate a GroovyClassLoader as the third argument of the
CompilationUnit constructor (needed to get the compiler to try to load
classes from there)
- After compiling I call defineClass(name, bytes) for all generated classes
on the GroovyClassLoader (needed for later compilations to find the just
compiled classes)

A redesign of leanengine is still unavoidable, because the order in which
scripts are compiled impacts the bytecode in general.

In the redesigned implementation, you can define sets of sources that are
compiled in one step and you can compile and add more sets afterwards, which
see the already compiled classes.

Maybe the little unit test explains it better...

So, will keep evolving it and presumably make a "LeanEngine 2.0" release
when its ready.

    @Test
    public void test() throws Exception {
        String text1 = "public class Script2 extends Script { public run() {
return Util.get() } }";
        String text2 = "public class Util extends Script { static def get()
{ return 111 }; public run() { return 9999 } }";
        String text3 = "public class Script3 extends Script { public run() {
return Util.get() } }";

        LeanEngine lean = new LeanEngine();
        lean.setTracer(new LeanEngine.StdoutTracer());
        
        Source source1 = lean.fromText(text1);
        Source source2 = lean.fromText(text2);
        Set<Source> sources = new HashSet<Source>();
        sources.add(source1);
        sources.add(source2);
        lean.add(sources);
        Class<?> clazz1 = lean.load(source1);
        Script script1 = lean.create(clazz1);
        Object obj1 = lean.runScript(script1, new Binding());
        assertEquals("must be same", 111, obj1);

        Source source3 = lean.fromText(text3);
        sources.clear();
        sources.add(source3);
        lean.add(sources);
        Class<?> clazz3 = lean.load(source3);
        Script script3 = lean.create(clazz3);
        Object obj3 = lean.runScript(script3, new Binding());
        assertEquals("must be same", 111, obj3);
        
        assertEquals("must be same", 111, lean.run("return Util.get()", new
Binding()));
    }



Jex Jexler $(whois jexler.net) wrote
> > have released version 1.0.0 of leanengine
> 
> Unfortunately, I may have to crab back from this and put the whole
> thing on hold, due to an issue I only discovered since then.
> 
> The immediate effect is that Scripts do not see each other's classes,
> e.g. if you compile the following script texts using leanengine:
> 
> - class Util { static def get() { return 111 } }
> - public class MyScript extends Script { public run() { return Util.get()
> } }
> 
> Running MyScript will fail with
> 
> groovy.lang.MissingPropertyException: No such property: Util for class:
> MyScript
> 
> My assumption (which I obviously did not verify deep enough) had been that
> what class "Util" is would be evaluated at runtime, i.e. duck typing for
> class names.
> 
> If I compile the two classes using a GroovyClassLoader (in that order),
> I see that during compilation there are lookups using:
> 
> loadClass(className, lookupScriptFiles=false,
> preferClassOverScript=true,
> resolve=false)
> 
> for
> 
> java.lang.Util, java.io.Util, java.net.Util, java.util.Util,
> groovy.lang.Util, groovy.util.Util, Util
> 
> in that order.
> 
> In principle I could probably address the issue in leanengine by having
> (at least a minimal) GroovyClassLoader there while compiling, but on a
> deeper level this totally messes up my design, which assumes that you can
> compile scripts totally independently of each other because classes will
> be resolved at runtime.
> 
> So, unless there is a way to configure the compiler differently such that
> classes are resolved at runtime, the current design of leanengine will
> probably have no future nor even a present.
> 
> Is there a way to compile such that classes are looked up at runtime?
> Or is there may an other way out?
> 
> If not, sorry for all the back and forth with no result in the end...





--
View this message in context: \
http://groovy.329449.n5.nabble.com/leanengine-A-lean-engine-for-running-Groovy-scripts-inside-a-Java-VM-tp5720762p5720846.html
 Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


[prev in list] [next in list] [prev in thread] [next in thread]