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. >> > >
