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.

I've heard that Swift is getting serious attention from the Android team as a first-class language there.

Not at all. That is just rumours.

They were very clear at the AMA:

"Anwar: Nope, not happening."

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

https://www.reddit.com/r/androiddev/comments/4tm8i6/were_on_...

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.

https://developer.android.com/ndk/index.html

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

Articles like this certainly don't help spread false rumors: http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swi...

Right now the only big name betting on Swift outside Apple for other OSes is IBM.

Even Microsoft is only improving the Objective-C support on their iOS bridge, in spite of the Swift support requests, at least for the time being.

If you check Brillo, which is basically Android without the Java layer, their plans are to create a C++ Frameworks layer not Swift and not Go.

Oops I meant Oracle vs Google, cannot edit it anymore.

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.

I don't want a SBT based build that eschews the way Android developers work.

I want a setup that embraces Gradle (even though we love to hate it), Android Studio GUI designers, plugins and annotations.

Last time I mentioned this, someone pointed me to

http://scala-on-android.taig.io/editor/android-studio/

which hasn't been updated in ages.

Using InteliJ with Android support means always being outdated as it is usually two versions behind from Google's fork.

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

> Last time I mentioned this, someone pointed me to http://scala-on-android.taig.io/editor/android-studio/ which hasn't been updated in ages.

Yeah. The documentation is at scala-android.org. If you feel something is missing, I think the maintainers are happy to read your ticket.

> Using InteliJ with Android support means always being outdated as it is usually two versions behind from Google's fork.

The current IntelliJ is pretty much up-to-date with current Android Studio.

> The current IntelliJ is pretty much up-to-date with current Android Studio.

Sorry but it is not.

Android Studio 2.2 is about to be released and IntelliJ IDEA 2016.2 only supports the plugins from Android 2.0 with caveats.

https://www.jetbrains.com/idea/whatsnew/#v2016-2-android

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

There is no "dropping" except if you assume that Scala 2.11 will just disappear tomorrow.

I don't get the whole dooms day scenario.

- Google is working on Java 8 support.

- The current version of Scala supports the current Android stack.

- Depending on the timing, the next version of Scala might also support the then-current Android stack.

- You can always use Scala-for-Android (aka 2.11). Just think of it as a flavor like Scala-JVM, Scala.js or Scala-Native.

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.

Which ones?

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.

Perhaps they dropped it because Scala is driven more by academics who didn't take that into account (or did and dismissed it).

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)

Or perhaps they dropped it because Java 6 was end-of-life 3 years ago.

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

Java6 is even less end-of-life'd than python 2.7.

My best guess is that Scala has a limited amount of support and Android never really took off for them–their killer app is Spark.

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

> Adding to the woes, the code emitted by 2.12 is slower ( https://news.ycombinator.com/item?id=12066653 )

Read the article and you will notice that Scala 2.12-M5 will solve some of this slower code emittion. It's in the middle of your linked article.