The Android team did a AMA on Reddit this week, they were pretty clear that regardless of people wishes only Java, C and C++ matter on Android.
Anything else it is up to the respective language communities to make it work.
Right now only Kotlin seems to be improving their Android support, but that is because JetBrains needs a killer application for it, which appears to be improving the world of those stuck in Java 6.
"Anwar: We don’t have any plans to officially support a new language in Android, so we’d encourage folks to continue to use Java:) That said, you should continue to use what works for you."
People have to get over the fact that regardless of what happens in the Oracle vs Sun, the Android team which has a quite a few Sun alumnis, doesn't want to use anything else.
Even the NDK is designed in a way that native C and C++ code is always exposed via Java native. The example code on the NDK start page is pretty clear how they see the NDK.
"The Android NDK is a toolset that lets you implement parts of your app using native-code languages such as C and C++. For certain types of apps, this can help you reuse code libraries written in those languages."
And another fun fact is that given the NDK constraints, having Linux as kernel doesn't matter that much, they could change to something else and only OEMs would notice.
I don't understand why Scala would drop the Java 6 backend. Surely Android is a big enough "market" to be worth maintaining it as a compilation target? Particularly now that Scala is expanding to be very clearly multi-backend (ScalaJS as first class, Scala Native starting up).
> Every time I think about using Scala and go through the list of configurations I need to do, I just give up.
It's pretty easy. You have to setup less things than with Gradle, because SBT deals with all the downloading, installing and managing of the two dozen SDKs Google wants you to use.
> I want a setup that embraces Gradle (even though we love to hate it), Android Studio GUI designers, plugins and annotations.
You can keep all you Gradle configuration. SBT-Android has a Gradle support mode so you can e. g. use the Gradle definitions for your IDE, but enjoy the fast turn-around and compile-times of compilation with SBT.
"The update includes the Android Studio 2.0 features: faster Emulator, experiment GPU Debugger, faster full builds, and code generation and testing for App Indexing. Note, Instant Run is not fully-merged yet."
If you want to drive adoption, it should work on Android Studio as well.
This is what I usually mean by using first party platform languages versus relying on third party support.
For Kotlin, all I need is to install the plugin on Android Studio and am off to the races.
And still I am not using it, because there are a few rough edges with all the Android workflows.
> For Kotlin, all I need is to install the plugin on Android Studio and am off to the races.
What is preventing you from doing that with Scala?
I see that you filed a ticket that the setup of IntelliJ != Android Studio, but is there anything that works in one, but not the other? (Except having to skip the "install android support" from the install guide?)
I guess no-one cares enough to support it? Definitely a shame though. (In the rare cases where I write Android apps I stick to Eclipse, stick to Maven, use Scala, and for me it all works - but presumably people have their reasons for preferring android studio/intellij).
Fair enough, but there are bugs/missing features in Scala 2.11 that I want fixed, and they're going to be fixed in Scala.js and Scala-Native so it would be a real shame if they weren't fixed in Scala-for-Android at the same time.
The usual ones, I'm sure. Poor syntax for type lamdbas. Unification across kinds (hopefully possibly going to be backported to 2.11). All the ways of expressing union types (or indeed basic enums) are a bit clunky. Irrefutable patterns in for/yield constructs compile to a silly withFilter call. PartialFunction/Function having the wrong subtyping relationship. mapValues being lazy when all the other functions on the same interface are strict. Stream implementing the collection interface.
More than anything specific though, I don't want to be stuck on an old version as the language moves forward.
Huh? None of that will be in 2.12 except unification, and that's already planned for backporting to 2.11 (and you can just use the compiler plugin until then).
> I don't want to be stuck on an old version as the language moves forward.
How are you going to be stuck? You might need to stay on 2.11 a bit longer until Google gets their shit together. Most likely this will be during 2.12. Sure, you might miss the first few minor releases of 2.12 ... but stuck?
Where are you getting this confidence that Google will "get their shit together" quickly, or ever? I can easily imagine Google not shipping Java 8 for as long as Oracle remains in business.
Hi, Scala team lead at Lightbend here (I left academia in 2012 to lead the team). We dropped Java 6 because we did not anticipate any business case for it, based on surveying our customers (we have continued to monitor the adoption of Java 8 amongst our customers, and everyone is upgrading, save for android).
We did consider (and regret) potentially leaving android behind, but we were (perhaps naively) hoping that something like retrolambda would suffice, or that android would catch up. In any case, it doesn't make a lot of sense to have 2.12 still support Java 6, since most of its features require Java 8 (those that don't, we first implemented in 2.11.x).
As announced in http://scala-lang.org/news/2.12-roadmap/, we will continue to support 2.11 for a bit longer than most releases, and we welcome community backports of 2.12 features that you'd like to see in 2.11.
> We did consider (and regret) potentially leaving android behind, but we were (perhaps naively) hoping that something like retrolambda would suffice, or that android would catch up. In any case, it doesn't make a lot of sense to have 2.12 still support Java 6, since most of its features require Java 8 (those that don't, we first implemented in 2.11.x).
Presumably 2.11 won't be supported going forward? Or as someone who would like my libraries to work on android and doesn't particularly care about them being callable from Java 8, should I just stay on 2.11 indefinitely?
Yes, if you're tied to Java 6, you're also tied to Scala 2.11. Why is the former version peg ok but not the latter? We do everything we can to enable 2.11.x maintenance by the community (and contributions are trending up!), as well as doing some of our own -- time permitting. If you'd like to get commercial support, we do offer that to our customers.
> Yes, if you're tied to Java 6, you're also tied to Scala 2.11. Why is the former version peg ok but not the latter?
a) Java 6 is forward binary compatible with later versions
b) Google has a reasonable excuse in terms of the Oracle lawsuit. Don't get me wrong, I'm not happy about Android being stuck on Java 6, but there are extenuating circumstances.
c) Scala 2.11 has issues that affect me and I want to see fixed. Java 6 doesn't, at least not that I've noticed. (If JVM 8 were necessary to the implementation of a Scala feature I cared about I would understand that, but as far as I can see it's irrelevant to my use cases)
Yes, but from a "business" standpoint, Java 6 hasn't EOL'd. If your business needs to build Android applications, it doesn't matter that it's technically EOL'd.
I would guess there's probably quite a few VB6 applications out there in business-land, and it's been EOL'd since 2012 IIRC. Not that most people would want to deal with them, but they exist, just like Java 6 in Android.
In addition to being supported by the community, we (Lightbend) offer commercial support for Scala 2.11. If you're paying Oracle for Java 6 support beyond its EOL, perhaps you'd be willing to establish a commercial relationship with us as well? That said, the vast majority of our customers are eagerly upgrading to Java 8 (https://news.ycombinator.com/item?id=7346224, https://info.lightbend.com/COLL-2014-10-20-Java-8-II-Survey-...)
The code emitted by 2.12.0-M5 is slower in certain benchmarks, but I don't expect this to be the case for the final 2.12 release.
We're working on the performance issue, with help from the team at Oracle. The problem is likely the JIT having trouble optimizing the bytecode we emit in M5 (we know of other schemes that don't suffer this slowdown, but require more bytecode).
However the comparison beyond language features is very much relevant, including the lack of Android support in Scala 2.12
Adding to the woes, the code emitted by 2.12 is slower ( https://news.ycombinator.com/item?id=12066653 )
Not to say things can't improve. After the initial announcement of 2.12 at ScalaDays 2015 and 2016, expect more at ScalaDays 2017.