This behavior is similar to what Cedric and I saw when playing with RoboVM:

https://github.com/msgilligan/robovm-groovy-test/blob/master/src/main/groovy/HelloWorld.groovy

I like the approach that Mike Hearn proposed for Kotlin in this blog entry:

https://blog.plan99.net/kotlin-native-310ffac94af2

This is not the path that JetBrains chose, but Mike is privately working on it (with a Kotlin focus, obviously). I wonder of such an approach might work for Groovy (with the appropriate Groovy compiler support, of course)


-- Sean



On 5/8/17 8:02 AM, Paolo Di Tommaso wrote:
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