

Groovy language support for Android - anielsen
https://github.com/melix/groovy-android-gradle-plugin

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

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

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

------
vorg
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-...](http://groovy.329449.n5.nabble.com/On-static-compilation-of-Groovy-
tt347670.html#a347685)

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

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

