The reason is that even with static compilation, constructors include metaclass initialization. This is something that have been bothering me for a long time, and I wish we could rework that, but it's a behavioral breaking change (however, really unlikely to break things in real world).
2017-05-09 8:16 GMT+02:00 Sergei Egorov <bsid...@gmail.com>: > 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 <paolo.ditomm...@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 ? >> >> >> p >> >> On Tue, May 9, 2017 at 12:29 AM, Paul King <pa...@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.ditomm...@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 >>>> <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 < >>>> jason.winneb...@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? >>>>> >>>>> >>>>> >>>>> Jason >>>>> >>>>> >>>>> >>>>> *From:* Paolo Di Tommaso [mailto:paolo.ditomm...@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 >>>>> <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. >>>>> >>>> >>>> >>> >>
