102 ms·

Android development has its own Swift

45 points by hasseg 12y ago

newgame 12y ago
Another, imho, more appealing Swift on Android is Kotlin http://kotlinlang.org/ http://kotlinlang.org/ It shares many features with Xtend but offers more. It has the opposite "problem" wrt IDE support though: Great IDEA support but no Eclipse support.
- staltz 12y ago
  Does it compile to Java source code?
  - theGimp 12y ago
    According to the FAQ page, it compiles to Java bytecode. Is it Java Compatible? Yes. The compiler emits Java byte-code. http://kotlin-web-site.jetbrains.org/docs/reference/faq.html http://kotlin-web-site.jetbrains.org/docs/reference/faq.html
    - higherpurpose 12y ago
      Does that violate the new ruling in favor of Oracle lately? If not, what if Oracle pursues that in the future, too? If I were Google I'd be like on needles about continuing to support Java on Android, and I'd start looking for a complete replacement (which will take years to come to fruition anyway, so all the more reason to start now).
  - sspiff 12y ago
    I can't find any information right now, but I believe it statically compiles to Java bytecode, which means it can easily be dex'ed offline. It wouldn't make sense to not support Android in a JVM language of 2014, honestly.
- artificialidiot 12y ago
  I don't know how kotlin fares in practice for android, but I experimented with scala on android a few years back successfully. The thing is, android doesn't really need a marketing blitz as big for alternative languages to be usable. dex converter did well enough on jvm bytecode.
- jtietema 12y ago
  I am building a side project app in Kotlin right now and so far it goes well. There are some minor problems with IDE support (kotlin source folder is not marked as a source folder when mixing Android and Kotlin together), but that is fixed with one click of a button. I really like it!
- billylindeman 12y ago
  Kotlin looks amazing! I'm about to try it out.
- lobo42 12y ago
  Kotlin for instance doesn't support something similar to active annotations aka compile-time macros. This is a very powerful concept. Here's an example of an annotation from the Xtendroid project (https://github.com/tobykurien/Xtendroid/blob/master/examples/HandlerExample/src/org/xtendroid/example/handlerexample/ProgressTestActivity.xtend https://github.com/tobykurien/Xtendroid/blob/master/examples...)
k__ 12y ago
> It is best understood as “CoffeeScript for Java”, or as “Java 10″. I wish it would look like CoffeeScript
ytch 12y ago
How about golang?
- izacus 12y ago
  What's with this Go obsession in connection with Android? Go's design and the way it works is terribly suited for Android development and currently isn't even capable of plugging into JNI bridging architecture of Dalvik/ART. Not to mention that Go is a language built for static binaries running on a distributed server and the code running with alot of callbacks, external exceptions and user-input looks horrible.
  - jamieomatthews 12y ago
    This is a proposal that's starting to get some serious traction. https://docs.google.com/document/d/1y9hStonl9wpj-5VM-xWrSTuEJFUAxGOXOhxvAs7GZHE/mobilebasic?pli=1 https://docs.google.com/document/d/1y9hStonl9wpj-5VM-xWrSTuE... In theory, Go could absolutely be used for android development
    - izacus 12y ago
      In theory, anything can be used for Android development. In reality, the cost of JNI bridging, reboxing objects and the fact that Android APIs heavily use Java objects as parameters makes usage of any non-JVM compatible languages horribly ugly, clunky and rather pointless performance and code-quality wise.
izacus 12y ago
The question about those code-generating languages in connection with Android is always: How HARD is it to debug? Because most of them fail badly as soon as you need to do any complicated breakpoint debugging (non-matching line numbers, broken local variable inspection, useless and misleading stack traces) and that loses more time than the language change will ever gain. After all, most of the time we're developing for Android, we're dealing with Android API's and another language does not address warts connected with those. Also powerful utilities like IDEA/AS provide alot of assistance with writing / folding / managing Java 6 issues without debugging issues. The other important questions: how big of a space hit is the standard library? E.g. Scala on Android will generate/include alot of methods which means you hit the 64k method limit of DEX format pretty quickly. That means you have to use Proguard for each build (even development) and Proguard pass can easily run for several minutes even on a 16G SSD equipped machine - killing development speed.
- lobo42 12y ago
  Debugging Xtend is straight forward. On a normal JVM you can even switch between generated Java and original Xtend source during debug, depending on what level you would like to step through. On Android you need to decide using a compilation flag whether you want to step through the generated Java or the original Xtend source. This is because Dalvik doesn't support JSR-45 which Xtend uses by default. So it basically just works.
- frowaway001 12y ago
  > That means you have to use Proguard for each build (even development) and Proguard pass can easily run for several minutes even on a 16G SSD equipped machine - killing development speed. No, not really. You can just install the standard library on your Android device for development, and only use ProGuard on the final release.
  - izacus 12y ago
    Not when you reach 64k methods together with libraries for a debug build. Of course, unless you want to go through the joy that is loading another .dex file :)
izacus 12y ago
The question about those code-generating languages in connection with Android is always: How HARD is it to debug? Because most of them fail badly as soon as you need to do any complicated breakpoint debugging (non-matching line numbers, broken local variable inspection, useless and misleading stack traces) and that loses more time than the language change will ever gain. After all, most of the time we're developing for Android, we're dealing with Android API's and another language does not address warts connected with those. Also powerful utilities like IDEA/AS provide alot of assistance with writing / folding / managing Java 6 issues without debugging issues. The other important questions: how big of a space hit is the standard library? E.g. Scala on Android will generate/include alot of methods which means you hit the 64k method limit of DEX format pretty quickly. That means you have to use Proguard for each build (even development) and Proguard pass can easily run for several minutes even on a 16G SSD equipped machine - killing development speed.
eddieroger 12y ago
Article is down for me. Here's a mirror (minus graphics and CSS): http://webcache.googleusercontent.com/search?q=cache:http://blog.futurice.com/android-development-has-its-own-swift http://webcache.googleusercontent.com/search?q=cache:http://... The article felt like it was trying to rationalize something, like Android needs a Swift. I'm not sure that's the case. The main point of the argument by my reading was "less lines of code are possible," but that's not what Swift is trying to bring the to the table (although no header files are nice). Swift's biggest advantage is that since Apple has redefined the rules of the language and don't need to stay C compliant, they can change the optimizer and enforce rules differently. Less lines of code are a side effect.
- DCKing 12y ago
  > The article felt like it was trying to rationalize something, like Android needs a Swift. Android probably doesn't need a Swift as much as iOSX did, but there's still a lot to be gained from having a less verbose programming language (and corresponding platform API). Objective C, despite its older features and unfamiliar syntax, was more expressive already than Java was. With Swift, they removed the legacy and made the syntax familiar. But I don't think this is the answer. If you debug Scala on Android at least you don't have to make a mental mapping of what the corresponding Java translation of your function would look like. A true new language with good features and 'light' syntax would be great. Google already has such a language: Dart. But Google has already said that at IO 2014 that Java is the language for Android and it will stay that way.
  - lobo42 12y ago
    > But I don't think this is the answer. If you debug Scala on Android at least you don't have to make a mental mapping of what > the corresponding Java translation of your function would look like. Again, this is also not the case with Xtend. See this screencast : https://vimeo.com/38425995 https://vimeo.com/38425995
    - DCKing 12y ago
      Ah, my apologies. The CoffeeScript metaphor is not completely valid.
mncolinlee 12y ago
My question is why Xtrend instead of Kotlin or Scala? Both languages have good reasons to recommend them and both already support Android today.
- rsynnott 12y ago
  Mentioned in the article; many JVM languages have substantial performance issues under Dalvik. Scala certainly does; not sure about Kotlin.
  - eeperson 12y ago
    Is this actually true for Scala? I was under the impression that statically typed languages run basically the same as Java on Android. Granted it has some other issues (such as running in to limits on the number of classes).
  - frowaway001 12y ago
    > Scala certainly does; not sure about Kotlin. How did you measure that?
- LeonidasXIV 12y ago
  Because Xtend compiles to plain Java code that is, mostly, readable. So the investmet in Xtend is low: in case it fails, you can compile your codebase into Java and continue from there. Basically, it is very similar to what CoffeeScript does. A better syntax with (largely) same semantics. Which can have massive advantages.
  - mncolinlee 12y ago
    I'm not sure this answers the question or even explains why Xtend is better than say, RetroLambda. It sounds like lambda support is already being backported from Java 8 by the Android team and since you can use lambdas today, any investment in Xtend is questionable.
programminggeek 12y ago
If I were to pick any language to do Android dev that wasn't Java, it would be Kotlin. It's a great language with a great IDE. I haven't done Android projects with it, but if I were hell bent on not using Java, that'd be my choice.
rdtsc 12y ago
There is the scripting layer so you can use kivy and Python. But I am really hoping Dart would get there, it is just a really nice language.
lobo42 12y ago
The second part of this InfoQ article features a getting started on Xtend and Android: http://www.infoq.com/articles/unusual-ways-to-create-a-mobile-app http://www.infoq.com/articles/unusual-ways-to-create-a-mobil...
jo_ 12y ago
I feel like this overlooks one of the more fundamental problems to Android development. It's not an issue with Java, it's an issue of Android being a cathedral of complexity. There are four dozen ways to accomplish the same tasks, each of which utilizes a different (but ultimately incompatible) piece of the API. You can build your Activity and embed your Fragment in it which houses a ListView to display your--- wait no maybe I should override ListView. No, people say that's a bad idea. Okay I'll override this object which ListView displays. Okay that kinda' works well enough. I'll figure out how to style that later. Okay now I need this thing to go to this other activity when cli-- maybe I should just replace the Fragment, since we're kinda' using the same data. No wait. I'll change the activity. Okay it looks like there's no function to do that. I'll go back to changing the Fragment to something else. Okay, that's giving me an exception. Lemme find where I can change the Activity... Oh, I have to do it elsewhere. Well I can hack my way around that. It doesn't end. "Button is actually a special type of view with extra properties." Great, so everything is a... You know what, I don't care. I feel like I did in the mid 2000's with game development: there are a thousand libraries which each are so complex that it's impossible to get good work out of them. Instead, I always ended up falling back to the simplest home-rolled solution. Except in the case of Android, there's really nothing more fundamental. I can (and do) use PhoneGap because it makes my life _significantly_ easier in many respects, but I think Android really needs to be restructured on a more fundamental level.
- agumonkey 12y ago
  It reminds me of Eclipse Plugin development. So maybe it's a Java thing after all :)
- kllrnohj 12y ago
  No, if you're reaching for PhoneGap it's because you already know HTML/CSS/JS and just don't want to learn Android's UI. Android's building blocks are simpler and more predictable than HTML/CSS is, so clearly complexity is very much not the issue you are having. It's just lack of knowledge and a lack of motivation to learn it. Which is fine, just not at all what you are claiming. Android's pieces do force you in to a significant amount of upfront complexity which makes rapid prototyping hard, but that complexity pays off a hundred times over when you start fleshing out the application into a real project. It's very critical infrastructure as the app complexity increases.
donniezazen 12y ago
As someone new to both programming and Android development, I think the biggest help is not some easy language but the questions and problems that have been asked on sites like StackOverflow. You can replace the language but how do you replace that whole stack of help articles written for Java for Android.
artribou 12y ago
Annnnddd... we killed it.
curtis17 12y ago
Imo Android needs a Swift because: 1. Java is too verbose/tedious. Developers are looking for something richer/more expressive. 2. Oracle. Java is non-open. Ultimately, the language that will become the Swift on Android is the language that makes it a core goal. This alt-Java could even be blessed by Google. Google could eventually cut Java out of the picture: Swift4Java -> Dalvik/ART. Xtend, Kotlin and Scala are possibilities. Kotlin has the Jetbrains Android Studio relationship going for it. Also compiles down to JS so could target Chrome/ChromeOS as well. Not as heavy as Scala - less of a learning curve. Xtend is good, and compiling to Java source could be an advantage. But Google do seem to be leaning towards Jetbrains rather than Eclipse.
hrjet 12y ago
The nice thing about Xtend is that it has a light run-time library. I wish Scala had a core-library that could be used in Android and such other constrained projects. Perhaps a library without specialisation and/or without collections could be made. About Xtend, I think it is not production ready yet. Having tried it in some POCs I hit several snags, such as incomplete support for inner classes and anonymous classes. (Some support has been added recently, though not sure if it handles all cases fine).
- frowaway001 12y ago
  Scala modularized its standard library recently, so it should be smaller by default already. Remember that deploying on Android involves a ProGuard step, so the size of the standard library doesn't matter that much anyway.
  - hrjet 12y ago
    The modularization reduced the API surface, but in terms of size of binary, didn't have much effect (about 20% size reduction). ProGuard is useful during deployment but cumbersome during development cycle.
    - frowaway001 12y ago
      As already mentioned, it's not necessary to use ProGuard during the development cycle.
cferreyra 12y ago
Seems like the link is broken
ethagnawl 12y ago
I've always been intrigued by the possibility of using Clojure or JRuby to build Android applications. There are toolkits (Lein Droid, Ruboto, etc.) and tutorials for both, but the edges are still _very_ rough.

45 points by hasseg 12y ago

Another, imho, more appealing Swift on Android is Kotlin http://kotlinlang.org/ http://kotlinlang.org/ It shares many features with Xtend but offers more. It has the opposite "problem" wrt IDE support though: Great IDEA support but no Eclipse support.

staltz 12y ago
Does it compile to Java source code?
- theGimp 12y ago
  According to the FAQ page, it compiles to Java bytecode. Is it Java Compatible? Yes. The compiler emits Java byte-code. http://kotlin-web-site.jetbrains.org/docs/reference/faq.html http://kotlin-web-site.jetbrains.org/docs/reference/faq.html
  - higherpurpose 12y ago
    Does that violate the new ruling in favor of Oracle lately? If not, what if Oracle pursues that in the future, too? If I were Google I'd be like on needles about continuing to support Java on Android, and I'd start looking for a complete replacement (which will take years to come to fruition anyway, so all the more reason to start now).
- sspiff 12y ago
  I can't find any information right now, but I believe it statically compiles to Java bytecode, which means it can easily be dex'ed offline. It wouldn't make sense to not support Android in a JVM language of 2014, honestly.
artificialidiot 12y ago
I don't know how kotlin fares in practice for android, but I experimented with scala on android a few years back successfully. The thing is, android doesn't really need a marketing blitz as big for alternative languages to be usable. dex converter did well enough on jvm bytecode.
jtietema 12y ago
I am building a side project app in Kotlin right now and so far it goes well. There are some minor problems with IDE support (kotlin source folder is not marked as a source folder when mixing Android and Kotlin together), but that is fixed with one click of a button. I really like it!
billylindeman 12y ago
Kotlin looks amazing! I'm about to try it out.
lobo42 12y ago
Kotlin for instance doesn't support something similar to active annotations aka compile-time macros. This is a very powerful concept. Here's an example of an annotation from the Xtendroid project (https://github.com/tobykurien/Xtendroid/blob/master/examples/HandlerExample/src/org/xtendroid/example/handlerexample/ProgressTestActivity.xtend https://github.com/tobykurien/Xtendroid/blob/master/examples...)

k__ 12y ago

> It is best understood as “CoffeeScript for Java”, or as “Java 10″. I wish it would look like CoffeeScript

ytch 12y ago

How about golang?

izacus 12y ago
What's with this Go obsession in connection with Android? Go's design and the way it works is terribly suited for Android development and currently isn't even capable of plugging into JNI bridging architecture of Dalvik/ART. Not to mention that Go is a language built for static binaries running on a distributed server and the code running with alot of callbacks, external exceptions and user-input looks horrible.
- jamieomatthews 12y ago
  This is a proposal that's starting to get some serious traction. https://docs.google.com/document/d/1y9hStonl9wpj-5VM-xWrSTuEJFUAxGOXOhxvAs7GZHE/mobilebasic?pli=1 https://docs.google.com/document/d/1y9hStonl9wpj-5VM-xWrSTuE... In theory, Go could absolutely be used for android development
  - izacus 12y ago
    In theory, anything can be used for Android development. In reality, the cost of JNI bridging, reboxing objects and the fact that Android APIs heavily use Java objects as parameters makes usage of any non-JVM compatible languages horribly ugly, clunky and rather pointless performance and code-quality wise.

izacus 12y ago

The question about those code-generating languages in connection with Android is always: How HARD is it to debug? Because most of them fail badly as soon as you need to do any complicated breakpoint debugging (non-matching line numbers, broken local variable inspection, useless and misleading stack traces) and that loses more time than the language change will ever gain. After all, most of the time we're developing for Android, we're dealing with Android API's and another language does not address warts connected with those. Also powerful utilities like IDEA/AS provide alot of assistance with writing / folding / managing Java 6 issues without debugging issues. The other important questions: how big of a space hit is the standard library? E.g. Scala on Android will generate/include alot of methods which means you hit the 64k method limit of DEX format pretty quickly. That means you have to use Proguard for each build (even development) and Proguard pass can easily run for several minutes even on a 16G SSD equipped machine - killing development speed.

lobo42 12y ago
Debugging Xtend is straight forward. On a normal JVM you can even switch between generated Java and original Xtend source during debug, depending on what level you would like to step through. On Android you need to decide using a compilation flag whether you want to step through the generated Java or the original Xtend source. This is because Dalvik doesn't support JSR-45 which Xtend uses by default. So it basically just works.
frowaway001 12y ago
> That means you have to use Proguard for each build (even development) and Proguard pass can easily run for several minutes even on a 16G SSD equipped machine - killing development speed. No, not really. You can just install the standard library on your Android device for development, and only use ProGuard on the final release.
- izacus 12y ago
  Not when you reach 64k methods together with libraries for a debug build. Of course, unless you want to go through the joy that is loading another .dex file :)

izacus 12y ago

eddieroger 12y ago

Article is down for me. Here's a mirror (minus graphics and CSS): http://webcache.googleusercontent.com/search?q=cache:http://blog.futurice.com/android-development-has-its-own-swift http://webcache.googleusercontent.com/search?q=cache:http://... The article felt like it was trying to rationalize something, like Android needs a Swift. I'm not sure that's the case. The main point of the argument by my reading was "less lines of code are possible," but that's not what Swift is trying to bring the to the table (although no header files are nice). Swift's biggest advantage is that since Apple has redefined the rules of the language and don't need to stay C compliant, they can change the optimizer and enforce rules differently. Less lines of code are a side effect.

DCKing 12y ago
> The article felt like it was trying to rationalize something, like Android needs a Swift. Android probably doesn't need a Swift as much as iOSX did, but there's still a lot to be gained from having a less verbose programming language (and corresponding platform API). Objective C, despite its older features and unfamiliar syntax, was more expressive already than Java was. With Swift, they removed the legacy and made the syntax familiar. But I don't think this is the answer. If you debug Scala on Android at least you don't have to make a mental mapping of what the corresponding Java translation of your function would look like. A true new language with good features and 'light' syntax would be great. Google already has such a language: Dart. But Google has already said that at IO 2014 that Java is the language for Android and it will stay that way.
- lobo42 12y ago
  > But I don't think this is the answer. If you debug Scala on Android at least you don't have to make a mental mapping of what > the corresponding Java translation of your function would look like. Again, this is also not the case with Xtend. See this screencast : https://vimeo.com/38425995 https://vimeo.com/38425995
  - DCKing 12y ago
    Ah, my apologies. The CoffeeScript metaphor is not completely valid.

mncolinlee 12y ago

My question is why Xtrend instead of Kotlin or Scala? Both languages have good reasons to recommend them and both already support Android today.

rsynnott 12y ago
Mentioned in the article; many JVM languages have substantial performance issues under Dalvik. Scala certainly does; not sure about Kotlin.
- eeperson 12y ago
  Is this actually true for Scala? I was under the impression that statically typed languages run basically the same as Java on Android. Granted it has some other issues (such as running in to limits on the number of classes).
- frowaway001 12y ago
  > Scala certainly does; not sure about Kotlin. How did you measure that?
LeonidasXIV 12y ago
Because Xtend compiles to plain Java code that is, mostly, readable. So the investmet in Xtend is low: in case it fails, you can compile your codebase into Java and continue from there. Basically, it is very similar to what CoffeeScript does. A better syntax with (largely) same semantics. Which can have massive advantages.
- mncolinlee 12y ago
  I'm not sure this answers the question or even explains why Xtend is better than say, RetroLambda. It sounds like lambda support is already being backported from Java 8 by the Android team and since you can use lambdas today, any investment in Xtend is questionable.

programminggeek 12y ago

If I were to pick any language to do Android dev that wasn't Java, it would be Kotlin. It's a great language with a great IDE. I haven't done Android projects with it, but if I were hell bent on not using Java, that'd be my choice.

rdtsc 12y ago

There is the scripting layer so you can use kivy and Python. But I am really hoping Dart would get there, it is just a really nice language.

lobo42 12y ago

The second part of this InfoQ article features a getting started on Xtend and Android: http://www.infoq.com/articles/unusual-ways-to-create-a-mobile-app http://www.infoq.com/articles/unusual-ways-to-create-a-mobil...

jo_ 12y ago

I feel like this overlooks one of the more fundamental problems to Android development. It's not an issue with Java, it's an issue of Android being a cathedral of complexity. There are four dozen ways to accomplish the same tasks, each of which utilizes a different (but ultimately incompatible) piece of the API. You can build your Activity and embed your Fragment in it which houses a ListView to display your--- wait no maybe I should override ListView. No, people say that's a bad idea. Okay I'll override this object which ListView displays. Okay that kinda' works well enough. I'll figure out how to style that later. Okay now I need this thing to go to this other activity when cli-- maybe I should just replace the Fragment, since we're kinda' using the same data. No wait. I'll change the activity. Okay it looks like there's no function to do that. I'll go back to changing the Fragment to something else. Okay, that's giving me an exception. Lemme find where I can change the Activity... Oh, I have to do it elsewhere. Well I can hack my way around that. It doesn't end. "Button is actually a special type of view with extra properties." Great, so everything is a... You know what, I don't care. I feel like I did in the mid 2000's with game development: there are a thousand libraries which each are so complex that it's impossible to get good work out of them. Instead, I always ended up falling back to the simplest home-rolled solution. Except in the case of Android, there's really nothing more fundamental. I can (and do) use PhoneGap because it makes my life _significantly_ easier in many respects, but I think Android really needs to be restructured on a more fundamental level.

agumonkey 12y ago
It reminds me of Eclipse Plugin development. So maybe it's a Java thing after all :)
kllrnohj 12y ago
No, if you're reaching for PhoneGap it's because you already know HTML/CSS/JS and just don't want to learn Android's UI. Android's building blocks are simpler and more predictable than HTML/CSS is, so clearly complexity is very much not the issue you are having. It's just lack of knowledge and a lack of motivation to learn it. Which is fine, just not at all what you are claiming. Android's pieces do force you in to a significant amount of upfront complexity which makes rapid prototyping hard, but that complexity pays off a hundred times over when you start fleshing out the application into a real project. It's very critical infrastructure as the app complexity increases.

donniezazen 12y ago

As someone new to both programming and Android development, I think the biggest help is not some easy language but the questions and problems that have been asked on sites like StackOverflow. You can replace the language but how do you replace that whole stack of help articles written for Java for Android.

artribou 12y ago

Annnnddd... we killed it.

curtis17 12y ago

Imo Android needs a Swift because: 1. Java is too verbose/tedious. Developers are looking for something richer/more expressive. 2. Oracle. Java is non-open. Ultimately, the language that will become the Swift on Android is the language that makes it a core goal. This alt-Java could even be blessed by Google. Google could eventually cut Java out of the picture: Swift4Java -> Dalvik/ART. Xtend, Kotlin and Scala are possibilities. Kotlin has the Jetbrains Android Studio relationship going for it. Also compiles down to JS so could target Chrome/ChromeOS as well. Not as heavy as Scala - less of a learning curve. Xtend is good, and compiling to Java source could be an advantage. But Google do seem to be leaning towards Jetbrains rather than Eclipse.

hrjet 12y ago

The nice thing about Xtend is that it has a light run-time library. I wish Scala had a core-library that could be used in Android and such other constrained projects. Perhaps a library without specialisation and/or without collections could be made. About Xtend, I think it is not production ready yet. Having tried it in some POCs I hit several snags, such as incomplete support for inner classes and anonymous classes. (Some support has been added recently, though not sure if it handles all cases fine).

frowaway001 12y ago
Scala modularized its standard library recently, so it should be smaller by default already. Remember that deploying on Android involves a ProGuard step, so the size of the standard library doesn't matter that much anyway.
- hrjet 12y ago
  The modularization reduced the API surface, but in terms of size of binary, didn't have much effect (about 20% size reduction). ProGuard is useful during deployment but cumbersome during development cycle.
  - frowaway001 12y ago
    As already mentioned, it's not necessary to use ProGuard during the development cycle.

cferreyra 12y ago

Seems like the link is broken

ethagnawl 12y ago

I've always been intrigued by the possibility of using Clojure or JRuby to build Android applications. There are toolkits (Lein Droid, Ruboto, etc.) and tutorials for both, but the edges are still _very_ rough.