Linked by Thom Holwerda on Thu 7th Nov 2013 10:11 UTC, submitted by nej_simon
Google

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?

Order by: Score:
Dalvik, ART, ...
by Kochise on Thu 7th Nov 2013 10:15 UTC
Kochise
Member since:
2006-03-03

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

Reply Score: 1

RE: Dalvik, ART, ...
by ddc_ on Thu 7th Nov 2013 10:45 UTC in reply to "Dalvik, ART, ..."
ddc_ Member since:
2006-12-05

Exactly. Still AOT compilation is a huge step forward.

Reply Score: 3

RE[2]: Dalvik, ART, ...
by adkilla on Thu 7th Nov 2013 10:46 UTC in reply to "RE: Dalvik, ART, ..."
adkilla Member since:
2005-07-07

AOT has been available for Java too. Check out the J9 and Jet JVMs.

Reply Score: 3

RE[3]: Dalvik, ART, ...
by Fergy on Thu 7th Nov 2013 10:52 UTC in reply to "RE[2]: Dalvik, ART, ..."
Fergy Member since:
2006-04-10

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.

Reply Score: 6

RE[4]: Dalvik, ART, ...
by shotsman on Thu 7th Nov 2013 14:02 UTC in reply to "RE[3]: Dalvik, ART, ..."
shotsman Member since:
2005-07-22

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.

Reply Score: 1

RE[5]: Dalvik, ART, ...
by moondevil on Thu 7th Nov 2013 17:12 UTC in reply to "RE[4]: Dalvik, ART, ..."
moondevil Member since:
2005-07-08

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.

Reply Score: 4

RE[5]: Dalvik, ART, ...
by snowbender on Thu 7th Nov 2013 19:53 UTC in reply to "RE[4]: Dalvik, ART, ..."
snowbender Member since:
2006-05-04

Personally, I wish Java with all its 'ClassNotFound' crapware would die a particularly nasty death.


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

Reply Score: 5

RE[3]: Dalvik, ART, ...
by moondevil on Thu 7th Nov 2013 17:10 UTC in reply to "RE[2]: Dalvik, ART, ..."
moondevil Member since:
2005-07-08

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.

Reply Score: 3

RE[4]: Dalvik, ART, ...
by ddc_ on Fri 8th Nov 2013 10:37 UTC in reply to "RE[3]: Dalvik, ART, ..."
ddc_ Member since:
2006-12-05

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

Reply Score: 2

RE: Dalvik, ART, ...
by adkilla on Thu 7th Nov 2013 10:45 UTC in reply to "Dalvik, ART, ..."
adkilla Member since:
2005-07-07

I would rather use Scala.

Reply Score: 2

RE[2]: Dalvik, ART, ...
by Shane on Thu 7th Nov 2013 12:04 UTC in reply to "RE: Dalvik, ART, ..."
Shane Member since:
2005-07-06

+1 for Scala.

Reply Score: 2

RE[2]: Dalvik, ART, ...
by moondevil on Thu 7th Nov 2013 17:13 UTC in reply to "RE: Dalvik, ART, ..."
moondevil Member since:
2005-07-08

The problem is how to get the typical developer to use Scala, when they barely manage with more mainstream languages.

Reply Score: 3

RE[3]: Dalvik, ART, ...
by Shane on Fri 8th Nov 2013 02:12 UTC in reply to "RE[2]: Dalvik, ART, ..."
Shane Member since:
2005-07-06

Scala's main strength is that you can grow into it. Start with OOP, then move on to a more functional reactive style.

Reply Score: 2

RE[4]: Dalvik, ART, ...
by moondevil on Fri 8th Nov 2013 07:54 UTC in reply to "RE[3]: Dalvik, ART, ..."
moondevil Member since:
2005-07-08

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.

Reply Score: 2

RE[4]: Dalvik, ART, ...
by snowbender on Fri 8th Nov 2013 08:02 UTC in reply to "RE[3]: Dalvik, ART, ..."
snowbender Member since:
2006-05-04

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

Reply Score: 4

RE: Dalvik, ART, ...
by dragos.pop on Thu 7th Nov 2013 10:52 UTC in reply to "Dalvik, ART, ..."
dragos.pop Member since:
2010-01-08

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



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.

Reply Score: 5

RE: Dalvik, ART, ...
by BeamishBoy on Thu 7th Nov 2013 11:44 UTC in reply to "Dalvik, ART, ..."
BeamishBoy Member since:
2010-10-27

...it is *still* Java, though :/

Switching to Erlang would improve things...


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.

Reply Score: 4

RE: Dalvik, ART, ...
by mmrezaie on Thu 7th Nov 2013 14:09 UTC in reply to "Dalvik, ART, ..."
mmrezaie Member since:
2006-05-09

Don't you think that's a little too early? I am not sure if developers are ready yet!

Reply Score: 1

RE: Dalvik, ART, ...
by kristoph on Fri 8th Nov 2013 01:05 UTC in reply to "Dalvik, ART, ..."
kristoph Member since:
2006-01-01

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

Reply Score: 5

RE: Dalvik, ART, ...
by JAlexoid on Sun 10th Nov 2013 20:09 UTC in reply to "Dalvik, ART, ..."
JAlexoid Member since:
2009-05-19

While Erlang and it's runtime have incredible design benefits, it's syntax is just plain auful.
I'd prefer Haskel.

Reply Score: 3

RE[2]: Dalvik, ART, ...
by Dano on Sun 10th Nov 2013 23:52 UTC in reply to "RE: Dalvik, ART, ..."
Dano Member since:
2006-01-22

I prefer interpreted Logo...really folks using weird languages as the backbone of a phone platform? I prefer .NET in reality.

Reply Score: 2

Bytecode
by Luke McCarthy on Thu 7th Nov 2013 12:05 UTC
Luke McCarthy
Member since:
2005-07-06

Will apps still be distributed as Dalvik bytecode and compiled on install time?

Reply Score: 2

RE: Bytecode
by ssokolow on Thu 7th Nov 2013 12:10 UTC in reply to "Bytecode"
ssokolow Member since:
2010-01-21

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?

Reply Score: 4

RE[2]: Bytecode
by jgfenix on Thu 7th Nov 2013 22:24 UTC in reply to "RE: Bytecode"
jgfenix Member since:
2006-05-25

To do expensive optimizations.

Reply Score: 2

RE: Bytecode
by Bill Shooter of Bul on Thu 7th Nov 2013 17:13 UTC in reply to "Bytecode"
Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Score: 4

I read MetArt
by lucas0 on Thu 7th Nov 2013 14:23 UTC
lucas0
Member since:
2012-04-20

But this is also sexy..

Reply Score: 4

ART already available on KitKat
by adkilla on Thu 7th Nov 2013 19:09 UTC
adkilla
Member since:
2005-07-07

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.

Reply Score: 5

Not what I was hoping for...
by Flatland_Spider on Thu 7th Nov 2013 21:26 UTC
Flatland_Spider
Member since:
2006-09-01

I was hoping Google would replace Dalvik, but I pegged them to switch to Go lang to get rid of Java altogether.

Reply Score: 0

RE: Not what I was hoping for...
by moondevil on Fri 8th Nov 2013 08:01 UTC in reply to "Not what I was hoping for..."
moondevil Member since:
2005-07-08

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.

Reply Score: 2

Geez
by reduz on Thu 7th Nov 2013 21:29 UTC
reduz
Member since:
2006-02-25

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

Reply Score: 3

RE: Geez
by Nelson on Fri 8th Nov 2013 18:34 UTC in reply to "Geez"
Nelson Member since:
2005-11-29

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.

Reply Score: 4

RE[2]: Geez
by reduz on Fri 8th Nov 2013 19:12 UTC in reply to "RE: Geez"
reduz Member since:
2006-02-25

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.

Reply Score: 3

RE[3]: Geez
by Nelson on Fri 8th Nov 2013 20:16 UTC in reply to "RE[2]: Geez"
Nelson Member since:
2005-11-29

This article is about AOT, your comment is a little odd.

Reply Score: 3

RE[3]: Geez
by moondevil on Sat 9th Nov 2013 07:19 UTC in reply to "RE[2]: Geez"
moondevil Member since:
2005-07-08

Who cares about AOT? Users don't even know what that is and as a developer, I couldn't care less about that.


Anyone that cares about performance.

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.


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.

Reply Score: 3

RE[4]: Geez
by Alfman on Sat 9th Nov 2013 09:58 UTC in reply to "RE[3]: Geez"
Alfman Member since:
2011-01-28

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

Reply Score: 2

RE[5]: Geez
by moondevil on Sat 9th Nov 2013 10:52 UTC in reply to "RE[4]: Geez"
moondevil Member since:
2005-07-08

Traditionally, people who need performance prefer native, still the battles between native and VM devs are largely superfluous.


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.

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

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

Reply Score: 3

RE[4]: Geez
by tylerdurden on Mon 11th Nov 2013 03:29 UTC in reply to "RE[3]: Geez"
tylerdurden Member since:
2009-03-17


PS3, Wii, XBox, PS2, PS One, PSP, PS Vita also don't offer OpenGL ES support.


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

Reply Score: 2

RE[5]: Geez
by moondevil on Mon 11th Nov 2013 09:31 UTC in reply to "RE[4]: Geez"
moondevil Member since:
2005-07-08

Sure, I just didn't want to refer all the remarkable consoles since the Atari 2600. ;)

Reply Score: 2

RE[2]: Geez
by _txf_ on Sat 9th Nov 2013 01:11 UTC in reply to "RE: Geez"
_txf_ Member since:
2008-03-17

Its actually a little more involved than your run of the mill AOT.


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

Reply Score: 3

RE[3]: Geez
by Nelson on Sat 9th Nov 2013 02:19 UTC in reply to "RE[2]: Geez"
Nelson Member since:
2005-11-29

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.

Reply Score: 3

RE[4]: Geez
by moondevil on Sat 9th Nov 2013 07:11 UTC in reply to "RE[3]: Geez"
moondevil Member since:
2005-07-08

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.


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.

Reply Score: 3

RE[2]: Geez
by Dano on Sun 10th Nov 2013 12:41 UTC in reply to "RE: Geez"
Dano Member since:
2006-01-22

You are correct. .NET on WP8 is a way more advanced programming environment in many ways.

Reply Score: 2

First Step?
by dindin on Thu 7th Nov 2013 22:01 UTC
dindin
Member since:
2006-03-29

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!

Reply Score: 5

Hey Google
by twitterfire on Fri 8th Nov 2013 19:19 UTC
twitterfire
Member since:
2008-09-11

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.

Reply Score: 2