I'll let Jochen answer that, I don't recall the reasons why it was a
breaking change. I think part of the answer is that Groovy classes
implement GroovyObject, but I miss the details, I'm no dynamic expert ;)
2017-05-09 8:34 GMT+02:00 Graeme Rocher <graeme.roc...@gmail.com>:
> 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
> <cedric.champ...@gmail.com> 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 <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 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
> >>>>>> 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
>
