It's probably impossible to replace Dalvik because you need the bytcode but maybe replacing the language might shield Google from Oracle.
Dalvik -> it is already replaced by ART, but it is still a VM (for ART the bytecode is compiled AOT though).
AFAIK, there is no public plan to replace java, neither are there any public commit on AOSP indicating a move in that direction.
Many Android devs are following Kotlin very closely (it is a boon for Android app development) but again there is no known plan from the Android frameworks team to switch to it.
I hope that Google will reconsider. Being stuck with Java 6.5 is more and more of an issue. You can use ThreeTenABP, Retrolambda and some other libs to get past some of the languages limitations but that's far from ideal.
Even if Google switches to OpenJdk 8 (or even 9 or 10), if the adoption times stay consistent, we will have to wait 3 years before being able to use their new features in mature apps.
I do hope that either the android team is working on a new language (along with a framework revamp) or will reconsider its position on Kotlin and starts adopting it.
Just like right now most of us can't use try with resources.
It's a very well-designed language (with non-nullable types and immutability!). It's now open-source, and development model is even more open than Android's throw-over-the-wall.
Swift's type inference and ARC makes it feel very script-like, but it supports AOT compilation and tighter control over memory usage.
While Cocoa won't be available on Android, having a single language that's usable on iOS, Android and server-side would be great for reusing as much as possible.
So, you can have Kotlin on iOS via RoboVM. But that's kind of expensive. Also, RoboVM brings its own heavy runtime environment with its own class hierarchy, garbage collector, and the need to bridge between that world and the ObjC runtime.
Or you can have RemObjects's almost-Swift (http://www.elementscompiler.com/elements/silver/) on Apple platforms, Android/JVM, and .NET as well. I call Silver almost-Swift because some permanent differences from real Swift are documented here: http://docs.elementscompiler.com/Silver/DifferencesAndLimita... For that reason, though I like the Elements compiler's approach of targeting each platform in the most native possible way, I'd recommend using their C# front-end or even their Oxygene language (a Pascal derivative) instead.
Sure, but as we've seen from the WebKit/Blink fork, Google and Apple aren't capable of sharing stewardship of something that central to both of their platforms in the long run. So it's not going to happen.
iOS and Android both disappoint me as being one-language-dominates platforms; I much prefer the paradigm of Windows, Linux or OS X, where you can have apps in Python, apps in C, apps in VB or Lisp or FORTRAN or Brainfuck, all running as first-class citizens. It feels like a real step back for me.
Not only is Kotlin a great language, it is also a good fit for Android since it outputs bytecode and is entirely interoperable with java. The only cost of using Kotlin are the 6k methods that it adds to the apk. You can call all the native Android APIs. Of course they are not idiomatic kotlin code, but you can cope with that, especially since the Kotlin team has written some Extensions methods in order to facilitate this process.
>Are there some successful apps written in Kotlin?
I know that Expedia uses some Kotlin for its new features (since there is full interop, you can switch gradually). I am working alongside 12 or so other engineers on a successful Android app. Most of us (especially the more experimented) would like to switch to Kotlin but we get a lot of resistance from an extremely change averse team leader (we have just convinced him to start using EventBus and are still pushing for Dagger 2 & Rx).
This kind of move is always complex for a large team though. You need to get everyone on board and up to speed with this new language. Even though I think that kotlin is very easy to learn (especially for a java dev), this is still a significant effort.
And Kotlin is very well suited for tests, because it's so expressive, DSL-friendly etc. There's also this pleasant framework: http://jetbrains.github.io/spek/
If you can't convince your team (or bosses) to switch to Kotlin, start writing unit tests in Kotlin. They can even coexist with Java ones, so I believe this is an easy way in. And once people get to see it at work...
we already have started making more and more tests several months ago (the code base we inherited is awfully architectured and entirely untested), I will try to win over our test engineer with that idea.
http://blog.jetbrains.com/kotlin/2015/11/the-kotlin-language...
JetBrains has been using Kotlin in production of IntelliJ IDEA, YouTrack and other products for quite a long time now. We have more than 250’000 LOC of Kotlin in production at the moment (plus about as much in the Kotlin project itself). While some of our projects are entirely written in Kotlin (account.jetbrains.com), others have introduced it to existing Java codebases, as we planned initially. We reached the level of interoperability where freely putting Kotlin alongside Java is transparent for Java clients: Java can be called from Kotlin and vice versa, sources can be mixed in one project, resulting .class files are totally compatible with Java tooling.
Pretty much as well as Java. No other alternative language comes close on Android.
In my opinion, the only two credible future languages of Android are either Kotlin or Java 8.
It's not quite 1.0 yet, but getting close.
My guess is that they'll wait and see how that move pans out first.
There are very few languages choices where I prefer to keep using Java. Go and Dart are two of these.
I'm a dedicated Apple skeptic, but Swift is nicer than both of these trainwrecks.
If what the article claims is true (that Dart can be used to target µCs), which I highly doubt, it might become interesting for me. My doubts arise from the fact that the standard library for a language makes some opinionated design choices, and in my opinion it's impossible to make an idiomatic library that works the same (and is usable!) in a GC context (existing deployment) and a non-GC context (embedded).
It's sad that of the dynamic languages, Python and Ruby are performance deadends, and LuaJIT is too obscure for most people.
What microcontrollers you have in mind? He mentioned Arduino in the post. It's not like we need Dart for extremely low spec-ed mCs, and we could run GC just fine in higher level mCs for ages...
STM32F7
* high-performance MCU with ARM Cortex-M7 core
* 32-bit ARM CPU @ 216 MHz
* 320 KB of RAM
* 512-1024 KB of Flash
* Single precision FPU and no fancy MMU
https://github.com/dart-lang/fletch
https://www.youtube.com/watch?v=Hx2iGEAvZRk
http://gotocon.com/dl/goto-cph-2015/slides/KasperLund_Intern...
Edit: Sounds like they plan to support the Arduino Due, but this is not implemented yet. They do not intend to support 8bit or 16bit MCUs.
The article mentions the Arduino, which in its original incarnation is an extremely tiny AVR. Maybe the author has a more powerful Arduino variant in mind, but I'm pretty sure you cannot run a GC runtime on the AVR Arduino. The only language that runs on such tiny devices is probably eLua.
> , and we could run GC just fine in higher level mCs for ages...
Yes, RPi/BBB won't have a problem.
Anything else isn't related to Android's roadmap, at least from their public statements.
The NDK isn't going anywhere, of course, and the recent switch from a GCC based toolchain to a LLVM based toolchain is an indicator that a lot of things are going on in native land.
"The NDK is not appropriate for most novice Android programmers, and has little value for many types of Android apps."
"Squeeze extra performance out of a device for computationally intensive applications like games or physics simulations."
"Reuse your own or other developers' C or C++ libraries."
Versus the Windows Phone and iOS that allow full use of the OS APIs via their Objective-C++ and C++/CX, instead of a thin set of libraries + JNI boilerplate.
Then we have the way the whole Eclipse CDT -> Android Studio process has been handled and Gradle still cannot handle the majority of ndk builds.