Hacker News Reader

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.

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.

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.

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