Hi Sergei, 

Sure, but there's no need for a build project. It's very easy:
./bin/aot-image -cp $PWD:$PWD/groovy-all-2.4.11.jar -H:Name=hello-groovy -H:Class=Hello

It will produce a binary executable `hello-groovy`, that's it. 


On Tue, May 9, 2017 at 8:16 AM, Sergei Egorov <bsideup@gmail.com> wrote:
Dear Paolo,

Could you please share an example project? I would like to play with it :)

Best Regards,

On Tue, May 9, 2017 at 1:04 AM Paolo Di Tommaso <paolo.ditommaso@gmail.com> wrote:
That would make sense. However apart of that there's still a lot of reflection behind the scene even when using StaticCompile. For example just replacing the println statement with a `new Hello()` in the previous snippet, I'm getting the following errors when trying to compile with the AOT compiler: 

groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(Class, MetaClassRegistry): Method is marked as deleted: HotSpotMethod<Class.getConstructor(Class[])>
at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:149)
at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:144)
at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:259)
at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:302)
at Hello.$getStaticMetaClass(Hello.groovy)
at Hello.<init>(Hello.groovy)
at Hello.main(Hello.groovy:5)
at com.oracle.svm.core.JavaMainWrapper.run(stripped:111)

org.codehaus.groovy.reflection.CachedClass$8.initValue(): Method is marked as deleted: HotSpotMethod<Class.getInterfaces()>
at org.codehaus.groovy.reflection.CachedClass$8.initValue(CachedClass.java:216)
at org.codehaus.groovy.reflection.CachedClass$8.initValue(CachedClass.java:214)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:49)
at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:40)
at org.codehaus.groovy.reflection.CachedClass.getMethods(CachedClass.java:274)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.initialize(ClosureMetaClass.java:474)
at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:260)
at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:302)
at Hello.$getStaticMetaClass(Hello.groovy)
at Hello.<init>(Hello.groovy)
at Hello.main(Hello.groovy:5)
at com.oracle.svm.core.JavaMainWrapper.run(stripped:111)

Here the offending methods are Class.getConstructor(Class[]) and Class.getInterfaces().

Does the MetaClassRegistry mechanism is really needed when using the Groovy static compilation ? 

On Tue, May 9, 2017 at 12:29 AM, Paul King <paulk@asert.com.au> wrote:
That line was added to break a hard-dependency on the groovy-xml module by the core groovy module. With Java 9's "real" modules, we'd potentially want to rework that. I haven't really thought about what we might do instead but welcome to suggestions/ideas/PRs.

Cheers, Paul.

On Tue, May 9, 2017 at 6:35 AM, Paolo Di Tommaso <paolo.ditommaso@gmail.com> wrote:
Good question. I leave the answer to Groovy core developers, however as far as I've understood even when the code is statically compiled, Groovy still uses reflection in runtime helper methods. For example one of the first issue I've encountered it's raised by the following line in the InvokeHelper.format method that the AOT compiler is unable to translate to native code 

  Method serialize = Class.forName("groovy.xml.XmlUtil").getMethod("serialize", Element.class);


On Mon, May 8, 2017 at 5:35 PM, Winnebeck, Jason <Jason.Winnebeck@windstream.com> wrote:

I think a biggest question than AOT compatibility is why does compile static still need to do reflection? I thought that was the point was to disable it, especially for Android support…? Unless the issue is the metaclass generation, does compile static still generate metaclasses?




From: Paolo Di Tommaso [mailto:paolo.ditommaso@gmail.com]
Sent: Monday, May 08, 2017 11:02 AM
To: users@groovy.apache.org
Subject: Groovy AOT compilation


Dear all, 


I just want to share with you my experience with the Java AOT compiler a came across a few days ago. 



Although they said clearly that it still an experimental project and it does not support dynamic class loading and most of reflection, I turns out it's possible to compile a basic static Groovy class, eg: 



class Hello {


  static void main( String... args ) {

    System.out.println "Hello world!"





This mean that it creates a native 5MB binary executable, that can run on any machine without the need of the Java VM nor the Groovy runtime! in 12 millisecond! cool!! 



Unfortunately the good news stops here. I was unable to successfully compile any other piece of code, which for example uses a Groovy "println" method or just instantiate a class. The problem seems to be that, even though the code is statically compiled, Groovy uses reflection behind the scene to instantiate classes and performs other operations. 


Now, I guess this is certainly not a Groovy top priority, however since there is an on-going discussion around a major Groovy reengineering to make it compatible with the upcoming Java 9 module system, I was wondering if it would not make sense to include the support for the Java AOT compiler as a goal for a future Groovy 3/4 release? 


Personally I think it would be an extremely useful feature and a major achievement for the project. 



What do you think ?  







This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.