Dear Paolo, Could you please share an example project? I would like to play with it :)
Best Regards, Sergei On Tue, May 9, 2017 at 1:04 AM Paolo Di Tommaso <[email protected]> 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 ? > > > p > > On Tue, May 9, 2017 at 12:29 AM, Paul King <[email protected]> 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 < >> [email protected]> 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 >>> <https://github.com/apache/groovy/blob/GROOVY_2_4_11/src/main/org/codehaus/groovy/runtime/InvokerHelper.java#L607> >>> method that the AOT compiler is unable to translate to native code >>> >>> Method serialize = >>> Class.forName("groovy.xml.XmlUtil").getMethod("serialize", Element.class); >>> >>> >>> >>> p >>> >>> On Mon, May 8, 2017 at 5:35 PM, Winnebeck, Jason < >>> [email protected]> 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? >>>> >>>> >>>> >>>> Jason >>>> >>>> >>>> >>>> *From:* Paolo Di Tommaso [mailto:[email protected]] >>>> *Sent:* Monday, May 08, 2017 11:02 AM >>>> *To:* [email protected] >>>> *Subject:* Groovy AOT compilation >>>> >>>> >>>> >>>> Dear all, >>>> >>>> >>>> >>>> I just want to share with you my experience with the Java AOT compiler >>>> <http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html> >>>> 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: >>>> >>>> >>>> >>>> @groovy.transform.CompileStatic >>>> >>>> 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 ? >>>> >>>> >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Paolo >>>> >>>> >>>> >>>> >>>> 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. >>>> >>> >>> >> >
