During the recent GR8Conf Europe 2014, Cédric Champeau, Senior Software Engineer working on Groovy for SpringSource/Pivotal, has performed a live merging of the pull request that brings support for Groovy on Android.
Groovy developers have waited for this option for several years, its implementation being delayed by difficulties introduced by the different bytecode format used by Android Dalvik' VM and the dynamic nature of Groovy's code. Official support for Android will be made available in Groovy 2.4.
InfoQ has interviewed Champeau to find out more about this and the future of Groovy on Android.
InfoQ: What was the hardest part in making Groovy work on Android?
CC: There were actually multiple issues, and that's the combination that made it a bit hard. The first issue is that Groovy is a dynamic language which is generating classes at runtime. The problem is that those classes are generated using the "standard" JVM format, although Android uses its own class format (for the Dalvik VM). The Dalvik VM is not meant to create classes at runtime, and it makes it very hard, because each file using the standard JVM bytecode needs to be processed through the "dex" tool to be loadable. Even if you manage to do it on the device, it's still a pain to load a class at runtime. It requires, for example, writing a class in a jar file, then loading this jar. In the end, we decided that it wasn't the main focus for Groovy on Android, and that we would rather focus on writing a full application in Groovy, without involving the creation of any class at runtime. This means that there are some limitations, but they should be invisible for most of the users. In the end, if you use the @CompileStatic to have statically compiled Groovy on Android, performance, as well as memory consumption, is comparable, or the same as native Android applications.
The second issue was actually with the build system. The new Android build system uses Gradle and a custom plugin, "android", which bypasses the normal "java" and "groovy" plugins to offer functionalities like the application variants. It required a bit of work to figure out how we could plug into it to add Groovy support. The good thing is that since the announcement, a Gradle plugin for Groovy and Android was released and makes things easier [1]. Last but not least, I learnt Android as I was writing support for Groovy. That was a good thing, because I could see where you could benefit from using Groovy, but it actually took me more time than adapting Groovy itself!
InfoQ: Any chance to extend this work to iOS or at least Windows Phone for a cross platform solution?
CC: I would definitely love to see Groovy on iOS, but I have no hardware to test it ;) Even if the recently announced Swift language looks very close to Groovy and is far more appealing than Objective-C, people could use it as a substitute for Groovy. But, there's one thing to consider: Swift is closed software and in the line of vendor lock-in. Groovy is totally open-source, and if you could use the same code for both iOS and Android, people would mostly only have to rewrite the UI part of their applications for example, making it a better fit for generic mobile development. As for Windows Phone, I have no idea if it is doable, I'm lacking knowledge on the platform actually :)
InfoQ: What are the current shortcomings? What's not working yet?
CC: Until very recently, only @CompileStatic classes could run on Android. But it is now possible to run dynamic code too, so pretty much everything works, including builders. It should be known that using dynamic code should be limited to non CPU intensive parts of the application, since it involves reflection. That said, the current limitation is that it is not (easily) possible to generate classes at runtime, so some specific constructs like map to class coercion or runtime traits will not work. The good thing is that there are workarounds for this. Eventually, there's also the problem of the number of method descriptors. Android, by default, has a limitation of 65536 methods in total, which is pretty low, and Groovy would consume around 8k without optimizations (with ProGuard, for example). So this means that you can reach the limit faster than with a normal Java application, even though there are ways to work around thing (such as using the multidex option).
InfoQ: Any plans for the future of Groovy/Android?
CC: Official support for Android will come with a first beta of Groovy 2.4. Currently, you can already use it for your own applications, and it's actually already on production, as the first example app shows ([2]). Only it's based on a snapshot version of Groovy. But what I would really like to see is new libraries or frameworks written in Groovy that facilitate Android application development. Android is very verbose and Groovy can make things much easier to write. For that, we can rely on a large community of developers who have already written lots of libraries like this for Java, so it's only a matter of time. I am convinced that once users will have tasted Groovy on Android, it's pretty unlikely they will switch back to Java ;)
[1] https://github.com/melix/groovy-android-gradle-plugin
[2] https://play.google.com/store/apps/details?id=me.champeau.gr8confagenda.app
Community comments
Very cool
by Jordan Bortz,
When will we learn about scripting languages?
by Dean Schulze,
Re: When will we learn about scripting languages?
by Rakesh Smith,
Typical Java dev's pitfalls
by Olaf Geibig,
Re: Typical Java dev's pitfalls
by Faisal Waris,
Now for iOS
by Victor Grazi,
Very cool
by Jordan Bortz,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm glad to see Groovy make it's way to android!
When will we learn about scripting languages?
by Dean Schulze,
Your message is awaiting moderation. Thank you for participating in the discussion.
I "tasted" Groovy on Grails and I was very glad to get back to Java. Scripting languages invite developers to make a mess of things and lead to code that is very hard to maintain.
Maintenance on the Grails project was so difficult that the architect mandated that every method that we worked on would be refactored to use typed variables so that our IDE (IntelliJ) could be of some use in helping us avoid errors that only show up at runtime. The one Groovy Kood-Aid drinker on that Grails project defended Groovy on the basis that it gave him more flexibility in writing unit tests, but he could not argue with compile time type checking.
The compiler is your friend.
Scripting languages have their place. I like Groovy for writing and testing SQL queries where the results needed a little bit of parsing when you are prototyping moderately complex SQL. But using a scripting language for a large project invites huge maintenance costs.
Re: When will we learn about scripting languages?
by Rakesh Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Dean,
no expert myself but the dynamic nature of Groovy can indeed be a curse as well as blessing.
My choice (in Enterprise apps) is to limit using dynamic features too much (I declare types for example).
I believe the Groovy people have known about its adoption being stalled because of this and have introduced @CompileStatic. I really see no reason now not to use Groovy over Java if possible.
Grails is a whole framework built on top of Groovy. My early dealing with Groovy was via Grails and I was not a fan. Once I separated out the language for my projects I was much happier and in control.
Groovy on Android, will be a huge bonus for developer productivity IMHO.
Now for iOS
by Victor Grazi,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hoping we will see a compatible iPhone/iPad version as well; true wora compatibility!
Typical Java dev's pitfalls
by Olaf Geibig,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Dean, I'm sorry that you had a negative experience with Groovy and Grails. I'm using it professionally since 2009 and I've done a lot of projects with Grails. First of all Groovy is not a scripting language. It is a full scale compiling programming language which can be interpreted for scripting as well.
I also had a learning curve to master when I started using Groovy, not so much because of the language but because of the paradigm shift from static to dynamic. One of the countless great things about Groovy is that you can mix static and dynamic typing and according to my experiences it is a good practice to use static typing with certain parts of your software, e.g. method signatures of APIs. I can't quite understand how IntelliJ didn't offer you good completion on dynamically typed variables as this is working perfectly for me. Maybe your project was some years ago?
The compiler is your friend - right, but a high test coverage is an even better friend. When working with dynamically typed languages it is mandatory to extensively write unit tests - fullstop. If your code is executed by unit tests all your type related errors and typos will usually be noticed and moreover you are gaining higher code quality as no compiler can save you from mistakes in your logic. You can afford the extensive test coverage as you are usually more productive with Groovy.
Groovy code is much more expressive and thus better readable. Very often you can write code which is almost plain English sentences. It is much more clean and usually has much less lines of code compared to Java code. This makes Groovy code much better and cheaper to maintain.
Anyway, if you want to or have to use Java then it is still an option to write tests in Groovy, e.g. with the Spock framework. Just add a Groovy compiler to your Maven or Gradle test compilation stage. I did this many times. With the power of Groovy's meta programming and dynamic typing also Java classes are like wax in your hands and it's so easy to mock things up or setup a test scenario.
Re: Typical Java dev's pitfalls
by Faisal Waris,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well, if we could get strong type checking at compile time AND the clean, uncluttered syntax of dynamically typed languages, that would be the ideal situation.
An alternative to Groovy and Ruby is F# for mobile development via Xamarin (Android and IOS). F# (like OCaml and Haskell) has strong type inference. You 'sprinkle' type annotations in your code to resolve any ambiguities, as needed. Typically only 10% of the type information needs to be explicitly coded for.
F# is statically typed but has the feel of a dynamically typed language; plus it has many other features such as meta-programming, async, pattern matching, etc. that any contemporary language should.
I am new to mobile development but my own experience with F# / Xamarin and Android has been very positive. I have blogged about it here: wp.me/p1buGO-8H. And some IOS early work here: wp.me/p1buGO-8S.