Submitted by It’s fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven’t aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That’s why Google’s developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.
This will be one of the defining changes in Android over the coming years. Android 5.0, perhaps?
…it is *still* Java, though :/
Switching to Erlang would improve things, forcing everyone to message passing, concurrent processes with no semaphore/mutex, massive network parallelism, etc
Kochise
Exactly. Still AOT compilation is a huge step forward.
AOT has been available for Java too. Check out the J9 and Jet JVMs.
I guess it is because Oracle started to sue Google. Java and Flash have become toxic and nobody wants to touch it.
I’d agree with about about Flash but Java is very, very popular.
Personally, I wish Java with all its ‘ClassNotFound’ crapware would die a particularly nasty death.
I share the same feeling about C and all its unsecure by design loopholes.
Why the hate? Why should it die?
It seems a bit naive to call it “ClassNotFound crapware”, since a ClassNotFound error would not be a language “feature” but a programmer error.
If you don’t like the Java language, then don’t use it. In my opinion it’s one of the strongest languages for development of backend systems, or maybe not the Java language itself, but the whole eco system of the JVM, the application servers, and all the languages that run on top of the JVM (ranging from Java, Scala, Clojure up to JRuby).
Many developers seem to keep on mixing languages with implementations, hence unaware of the variety of Java VMs and AOT compilers available on the market.
I was speaking of a huge step for Android. Otherwise I don’t care Java with all its VMs and its market.
Edited 2013-11-08 10:38 UTC
I would rather use Scala.
+1 for Scala.
The problem is how to get the typical developer to use Scala, when they barely manage with more mainstream languages.
Scala’s main strength is that you can grow into it. Start with OOP, then move on to a more functional reactive style.
That is all fine and good when you have good developers on team.
I happen to have met a lot of them that still write code as if 48K BASIC was bleeding edge programming.
If you work on your own, that is a possibility. In most cases however, one will have to work with code that is written by other (possibly more advanced) people, and then the “typical developer” will get into trouble. Not to mention that I have my doubts about the “typical developer” growing into it.
It is my impression that the “typical developer” already has a lot of trouble with really understanding lambda expressions, C# LINQ and writing correctly working parallel code. Yes, 95% of C# developers actually use LINQ-to-objects all over their code. In my experience however, only a small percentage correctly knows/understands the semantics.
Now that I think about it… a lot of programmers do understand and “get” OOP, but only few can make a good OOP design and can apply good OOP principles to their code when they have to create something from scratch.
Edited 2013-11-08 08:05 UTC
Well the programming language is still java, not the run-time.
Switching to Erlang would be disruptive and lower the number of developers.
Everybody has it’s favorite programming language, and they have very good reasons to, but does it apply to others?
If I wore Google I would encourage people to develop alternative languages for there SDK.
No it wouldn’t. It would make things immeasurably worse.
Java’s already got – in the form of Akka – all of the things you suggest Erlang brings to the table. You’re equally free to develop Android apps in C#/F# if async is your thing.
Don’t you think that’s a little too early? I am not sure if developers are ready yet!
You need to remember that JVM/ART != Java the language. ART is AOT compiler that ‘converts’ bytecode into machine code. The bytecode can be generated by any compatible language.
Here is an Erlang implementation …
https://github.com/trifork/erjang/wiki
Now go forth an built your Android apps in Erlang (or Smalltalk or Ruby or any number of other languages).
While Erlang and it’s runtime have incredible design benefits, it’s syntax is just plain auful.
I’d prefer Haskel.
I prefer interpreted Logo…really folks using weird languages as the backbone of a phone platform? I prefer .NET in reality.
Will apps still be distributed as Dalvik bytecode and compiled on install time?
I don’t see why they wouldn’t be.
Why go to the trouble of having two different architecture-independent intermediate formats when developers want to support devices still stuck on older versions of Android?
To do expensive optimizations.
Its the only way to maintain processor compatibility ( all of the arm variants and x86) as well as version compatibility ( So all those wonderful gingerbread phones will still work with the dalvik bytecode years from now).
Well, I guess Google could solve that by giving out pre compiled versions from the google store to phones/tablets that supported ART, but you’d still want something that would allow you to use apps from non play store sources as well.
But this is also sexy..
In case you have not read the article linked in the topic, ART is already available on the new Android 4.4 release. Follow the link in the article to see how to enable it to give it a whirl.
I was hoping Google would replace Dalvik, but I pegged them to switch to Go lang to get rid of Java altogether.
I doubt it will ever happen, anyway here is the ticket for it:
http://code.google.com/p/android/issues/detail?id=39482&can=4&colsp…
Last real comment regarding implementation issues, November 2012.
Not really meaning to troll, but my Windows Phone has barely changed in a year. Latest update brigs stuff like.. rotation lock.
In comparison Android improves ages each year, there’s just no point of comparison anymore..
That’s because Microsoft has been AOTing MSIL since WP8 launched.
Its actually a little more involved than your run of the mill AOT.
But hey, apparently its so innovative in Android it deserved an entirely new acronym.
Microsoft’s VM, JIT, and compiler infrastructure is miles ahead of Dalvik.
Who cares about AOT? Users don’t even know what that is and as a developer, I couldn’t care less about that.
Give me C++ and OpenGL ES and I’m fine. All platforms offer that, Linux, Desktop Windows, Mac, Android iOS, BB10, Emscripten, and Chrome Store.. and oh wait Windows Phone doesn’t.
Hope it does soon. I mean, Microsoft could:
1) Offer a not shitty DX9 profile and allow real time shader compilation, so people can write a wrapper.
2) Use the same wrapper are using in their WebGL support for IE11 in Windows Phone
3) Support OpenGL since hardware manufacturers have the drivers done anyway.
But nooo. Keep developers away. Great idea.
This article is about AOT, your comment is a little odd.
Anyone that cares about performance.
PS3, Wii, XBox, PS2, PS One, PSP, PS Vita also don’t offer OpenGL ES support.
And before anyone mentions it, the OpenGL ES support on the PS3 is not fully standard and slower than libCGM.
Commercial game developers just write an engine that uses the best 3D API each platform uses.
reduz,
“Who cares about AOT? Users don’t even know what that is and as a developer, I couldn’t care less about that.”
moondevil,
“Anyone that cares about performance.”
I think his point was that he doesn’t care because he prefers native C++ anyways, which is already high performance. Traditionally, people who need performance prefer native, still the battles between native and VM devs are largely superfluous.
“Commercial game developers just write an engine that uses the best 3D API each platform uses.”
Do they though? Maybe I’m wrong, but I would have assumed that most of them stick to one official API in the game and create wrappers to support other platforms. In software engineering terms, this is the best approach for achieving portability and not making the game engine itself more complex than it needs to be. The downside is less performance on platforms without the API and possibly a suboptimal use of features on those platforms.
Edited 2013-11-09 10:03 UTC
Agree, after all language and implementation are separate issues, almost any language can have a native implementation. It is always a matter of ROI of required effort vs desired performance for the language use cases.
The games industry has no place for religion regarding languages and APIs, it is always about getting the game done.
You have either studios investing in middleware in the way I mentioned, or developing to a specific plaftorm and leaving the others to sub-contractors specialised in porting.
This second case would be what you say.
I used to have a naïve idea how the game industry works, and how good it would be for using FOSS and open standards, until I got a foot into the industry and got to know a little bit more how everything works.
It was also an eye opener, that I rather have a cosy consulting life than a game studio one.
You forgot to add the original Gameboy, the Supernintendo and the Sega genesis. I’m quite certain neither of those totally relevant and current mobile platforms offered OpenGL ES either.
Edited 2013-11-11 03:29 UTC
Sure, I just didn’t want to refer all the remarkable consoles since the Atari 2600.
What specifically makes it more involved than AOT ?
Also I don’t think anyone here is suggesting it is new and innovative, just that it is new for Android and is interesting.
Edited 2013-11-09 01:13 UTC
It defers the final lightweight compilation step which takes a lower level MDIL (with complex optimizations performed) and replaces architecture agnostic façades with specialized assembly.
This last step takes 75% less time than install time AOT because the heavy lifting as already been done with cloud compute turning MSIL to MDIL.
Microsoft calls it cloud compilation, and apparently they have a patent on it.
The only thing that they defer for installation time is linking.
MDIL is native code with symbolic names for jump targets and method invocations kept on place.
It is not much different than a normal native DLL.
You are correct. .NET on WP8 is a way more advanced programming environment in many ways.
I hope this is the first step.
The next would be to have ART compile both Dalvik Bytecode and LLVM Bytecode to native.
Then developers can simply program in any LLVM language and Google can provide an alternative for Java/JDK development requirement.
LLVM BC can become the new intermediate. Even Chrome apps maybe compiled to LLVM and native. Would that not be nice!
Give that freaking sound system sound love. It’s pathetic to not have a sound system with low latency in 2014.
ART sounds good, I don’t care too much about it though, as I mainly use NDK. Which, btw, sucks. Give NDK some love, too, pretty please.