Groovy language support for Android | Hacker News Reader

Groovy language support for Android

github.com

41 pointsanielsen20 comments

Google needs to decide if they want to be compatible with the JVM or not. If they do, then that opens the door for Groovy, Scala, Clojure, and all the other JVM languages. Plus it allows the full ecosystem of tools & libraries. There are plenty of Gradle build plugins that Android developers could tap into.

Many great things from the Java ecosystem do work when brought over to Android: Guava, Jackson, GSON, Joda-Time are some common libaries that are pure Java. Dagger is an Android library implemented in pure Java that is starting to work its way back into 'regular Java'. And of course the tools like IntelliJ, ProGuard, Maven, Gradle are all from the Java ecosystem.

But many of the best things are not compatible. The Android Gradle plugin has a different interface than the Java Gradle plugin, so other existing Gradle plugins (this one being an example) all have to be re-written specifically for Android. Even some of the seemingly obvious ones like pure Java/JUnit 4 testing on x86 are impossible. Some Java 7 syntax is available on Android, but the major SDK improvements like the new file I/O API are not. Nothing from Java 8 is available, including blocks and the new time API.

In light of the recent advances by Apple on the tooling & language front, Google needs to decide if half-baked Java compatibility is worth the cost of being handcuffed. Either go all-in on Java, pay whatever Oracle wants and get full Java 8 compatibility now, or fork out on their own and move faster.

What do you mean by "compatible with the JVM"? Android is compatible with the JVM. Android's dx tool converts the JVM bytecode in your JAR files to Dalvik/ART compatible DEX files. You probably mean that is not compatible with all parts of Oracle Java.

You can make Android apps using Scala, Kotlin, and Clojure. To my knowledge can use the 'native' build tools for Scala (SBT) and Clojure (Leiningen) already. I'm building an Android app using Scala libraries of which the authors never even thought about running it in an environment as alien as Android.

So yeah, I think that the door is open already. What is still lacking is official support for better languages than Java. That would be great.

Those are based on hacks with slower execution and bulkier APKs as the Java tooling.

At least for Scala it's not based on hacks, it's not slower and the reason the APKs are bulkier is because if you don't use proguard you'll be embedding the whole Scala library. It's not specific to Android, the only difference is that on Android we care about the whole package size while on a server it's not a problem.

Groovy is probably slower, but it's slower on a regular JVM as well.

So nothing specific to Android here.

How come it is not hacks?

I have to download plugins from multiple sources, compile them if the binaries for the latest release aren't available, glue everything together and hope for the best while coding and deploying to Android.

Not to mention the bugs while interacting both with Eclipse and Android Studio tooling.

They're not based on hacks.

Until they are packaged in a single "Android Support" package instead of being scattered across multiple project sites that one needs to manually glue together without Google sponsorship[1], they are hacks.

[1] At least Oracle sponsors alternative JVM languages.

> Either go all-in on Java, pay whatever Oracle wants and get full Java 8 compatibility now, or fork out on their own and move faster.

This pisses me off. Google seems to care more about half baked solutions to sell their services than proper tooling.

Renderscript instead of OpenCL, with bad Java idioms for the generated code, with no debugger support.

No editor support for Renderscritp and GLSL files.

The NDK is a joke when comparing with what iOS and WP SDKs offer.

The Games API was only made available to NDK developers after enough pressure was done from game studios that were forced to write their own JNI wrappers.

So I wonder what they will present at this year's Google IO.

> Even some of the seemingly obvious ones like pure Java/JUnit 4 testing on x86 are impossible

This is actually possible, albeit through a third party framework - Robolectric.

> The Android Gradle plugin has a different interface than the Java Gradle plugin, so other existing Gradle plugins (this one being an example) all have to be re-written specifically for Android

This is probably the single most aggravating thing about the new build system. It's a serious pain point. Nothing works except what Google's developers have spent time on integrating - sure, there are third party libraries and hacks to bring some more of the Java ecosystem, but only the things Google has deemed worthy integrate nicely with the build tool and the IDE.

Robolectric testing with the new build system is such a pain in the ass I don't even know where to start. Jake Wharton - author of god knows how many Android libraries - even threw up his hands on it: https://github.com/JakeWharton/gradle-android-test-plugin.

It's not that hard to get started: https://github.com/zofrex/gradle-template-android-robolectri...

And the Robolectric team adopted Jake's plugin, by the way: https://github.com/robolectric/robolectric-gradle-plugin

Also, it is going to get better. At the moment one of the biggest issues is that there is no way for Gradle to expose extra sourcesets to the IDE, this is a limitation of Gradle and not just the Android plugin I believe, and the tools team want the Gradle build to be the single source of truth. They are working to get that added to Gradle (and they have made a lot of positive changes to Gradle already as they build the new tools), and then things like Robolectric will be able to hook in with the IDE just fine.

I think a lot of the incompatibility you are seeing in the Gradle plugin ecosystem is a problem specific to Gradle. My experience has been that Gradle plugins aren't isolated very well and as such tend to have conflicts. This combined with the fact certain pieces of core functionality tends to be tied to specific plugins (such as the 'provided' scope being tied to the 'war' plugin), results in situations like this where you need different plugins depending on what other plugins you have installed. I haven't seen this same problem on build tools that have more clearly defined integration points.

I suspect this isn't as big of a deal as you think it is in terms of making Android more successful. I'm not saying it wouldn't be nice, I'm just saying: why should this be a priority in the grand scheme of things? A better programming language doesn't make the Android APIs easier to learn in the short term.

I get the sense that what is going to Swift great isn't going to be that it's better than Objective-C. CocoaTouch is still hard to learn. It's the tooling that can be built around it. The playground is a good peek at some of the things to come.

Ruboto is a JRuby implementation on Android so I think the the opportunity has been there...just not much developer interest.

It's really not half-baked. As for gradle support, the less I see gradle the better. If I wanted slow builds with a here no there language I'd write my own build tool in Javascript.

I agree that Google needs to either move on with their Dalvik VM, or switch to something else. I vote for the latter.

They actively work on it and starting in Kit Kat there is an alternate runtime disabled by default.

They already did. Dalvik has been replaced by ART, a native AOT compiler for Java.

Now the question is which languages will they officially support.

So far, there are at least two talks at Google IO about ART.

This link is really a call for people to alpha test Groovy's Android support, which is likely a long time coming before it's not buggy. Just look at the 5 years it's taken for Groovy to ship with static typing actually used by Grails (though with an official Use With Caution attached) ...

mid 2009: Alex Tkachman began work on Groovy++, a statically typed plugin to Groovy's AST, which the Groovy project management said they didn't want [1]

mid 2010: Groovy 1.8 beta 2 broke Groovy++ which had to switch back to Groovy 1.7

late 2011: SpringSource employed Cedric Champeau to duplicate most of the Groovy++ code and renamed Groovy 1.9 to 2.0.0-beta-1, dropping other features like the Java 8 lambda retrofit and meta-object protocol cleanup

mid 2012: Official standalone release of Groovy 2.0 was really just another beta to encourage more people to test it

Dec 2012: Grails 2.2 released with groovy 2.0.5 bundled, after being tested by programmers who thought Groovy had any real intended use as a standalone language outside of Grails. Grails 2.2 doesn't, however, actually use the static compilation features of Groovy, just wanted to know it would run with Groovy 2.0 bundled without breaking.

mid 2013: Groovy 2.1 was the first release with most @CompileStatic bugs fixed

May 2014: Grails 2.4 released, the first to actually use any of the @CompileStatic features of Groovy, but with this strong caution in the doco: "Care must be taken when deciding to statically compile code." [2]

[1] http://groovy.329449.n5.nabble.com/On-static-compilation-of-...

[2] http://grails.org/doc/2.4.0.M1/guide/introduction.html#whats...

vorg (aka Gavin), can you proof your 2011 statement about the duplication? Neither was there a copy&paste, nor is there a big overlap in concepts that goes beyond what these would have in common with javac for example.

And another thing... Grails has nothing to do with Groovy on Android. And thanks to some fixes I did with Cedric you don't need to statically compile the groovy code either.

Reply on news.ycombinator.com