groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: Groovy AOT compilation
Date Mon, 08 May 2017 22:29:26 GMT
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.ditommaso@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.Winnebeck@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.ditommaso@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.
>>
>
>

Mime
View raw message