Would it make sense to have the metaClass field of GroovyObject initialise lazily? In what circumstance would that be a breaking change? Concurrency?
On Tue, May 9, 2017 at 8:25 AM, Cédric Champeau <[email protected]> wrote: > 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 <[email protected]>: >> >> 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 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 >>>>>> 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. >>>>> >>>>> >>>> >>> > -- Graeme Rocher
