Also, Java as a language is - unless I've missed something in my experience of it - a very bad fit for interacting with the OpenGL API. In particular specifying data in tightly packed or otherwise specifically arranged (interleaved, in particular) forms is next to impossible to achieve without making your code look like a dogs dinner (if you can do it at all). Much easier to do in C, so that's another reason to go native on Android.
Can we get more respect for "game" developers, please?
What Tim calls game developers are actually just systems programmers and performance-conscious hackers, including people doing multimedia DSP apps critical for making the platform a hit, along with traditional game developers.
Tim, if you're reading this, can we please get some closure for 3434? Even Mono has OpenTK. Just adopt more of the Khronos stuff and get out of the way. Would be nice if you could beef up the CDD and demand just a bite more from the telcos.
Given my Java hatred (perhaps irrational), and no real allegiance to iOS & Cocoa Touch (other than it works very well, and has paid off somewhat for our efforts), I wonder if it would make sense, long-term, to mount an OSS effort to build a truly wonderful dynamic language environment as an alternative to Dalvik?
E.g., something based on Javascript, with a fully dynamic remote IDE/editor (along the lines of SLIME)?
I guess then you'd run into the problem that the whole Dalvik UI scheme is so heavily intertwined with their Java-based toolkit (just as iOS is heavily dependent on Obj-C) that there's no real gain in the end?
Why not build a great dynamic language on top of Dalvik? All the alternate language projects for Android that I'm aware of are either native code (that uses JNI to talk to the UI code in Dalvik) or are existing JVM languages that are poorly matched to the Dalvik VM.
Dalvik isn't a Java JVM, it doesn't use Java bytecode and it has a significantly different architecture than JVM's. It's possible you might be able to make a language that's a better fit for Dalvik than Java is.
One possible candidate - Qt Lighthouse Android port: http://code.google.com/p/android-lighthouse/
Hypothetically Qt could be a robust cross-platform solution for mobile phones just like it is on desktop. But mobile platforms are more closed. And Qt is owned by Nokia now which brings in a lot of politics in the game.
The good news is that the Qt team has seemingly been very enthusiastic about the Qt Lighthouse project so far.
"OSS effort to build a truly wonderful dynamic language environment as an alternative to Dalvik?"
You could save yourself quite a lot of time and start with Squeak or Pharo. MIT license, VM built for the dynamic, good tools, and no real reason you couldn't put another language on top of it.
If your talking building a language/IDE to compile to Dalvik (seems the next paragraph leans that way), then I think you really need to get a feel for how dynamic the Dalvik VM is and what you need in a language to call the shipping runtime.
SL4A (formerly known as ASE)[1] and Groovy both come to mind, although a 30 second Google couldn't find me a good resource on how/whether you can use Groovy to build Android apps.
I know SL4A has some GUI support, but I don't think it's as rich as the full Android UI framework. However, it seems like it could be a good base to build a UI layer on top of.
At least on iOS, recreating the "feel" of the scroll views is actually impossible with reasonable performance (the CSS 2d transitions don't have the correct interpolation options), so you can't make anything, at least there, that "feels" native.
So the browser doesn't scroll natively? Don't know the iOs scroll views... Still, an approximation would be nice, it doesn't have to mimic every teeny detail.
It does, but you can't scroll part of the page in the native way -- iOS users are very accustomed to the kinetic scrolling, anything even slightly different is enough to throw them off and make your app seem "weird".
"E.g., something based on Javascript, with a fully dynamic remote IDE/editor (along the lines of SLIME)?"
What about WebOS? It will get you at least halfway there. Unfortunately, it doesn't have the reach that Android or iOS have. It's still fun to play with, though.
Remember, you can also use any language that compiles to Java bytecode on a JVM. A short list includes Scala, Clojure, Ruby, Python, Groovy and even Javascript(via Rhino). So the JVM and Java are very much separate things.
Unfortunately, the Dalvik VM and JVM are quite different too. Dalvik may act like a JVM and talk like a JVM but it isn't a JVM (not according to Google, at least; Oracle thinks otherwise).
This is the most useful short summary of Android's pieces I've read--it's part summary and part correction.
The "How It’s Generated" section is interesting because Bray points out that it's not important to Android how the native or Dalvik code is generated so long as it uses the APIs. Currently it's most convenient to program in Java but I wonder how long that will remain so.
I wondered though how much of this recent change in emphasis is inspired by recent, ehm, 'changes' in the Java landscape. I seem to remember that Google/Android evangelists put much more emphasis on Java being the language to code for Android, and how the overall picture seemed to be much more Java-centered back then (well only 2 or 3 years ago). Recently I see a bit of 'backpedaling' in that department.
I guess by now there's a team at Google working on a replacement for the Java Android development environment, to be able to move away from what is now a tainted platform, so it's all perfectly understandable, and I can understand they need to phase in this transformation to not create shocks in the Android ecosystem; but I still feel a bit manipulated, being talked to in a way that both parties know is doublespeak but nobody being able to do anything about it.
There's absolutely zero evidence for your assertion that Google is "moving away" from Java for Android development. Java is still the only official route for creating Android app (I haven't looked at the NDK, but I am under the impression it requires at least a little Java for glue code.. I could be wrong there).
There's nothing in Bray's post that would indicate anything other than a continuation of the same public roadmap Android has had since at least v1.5 was released on the old G1 phones.
No, of course there's no evidence, but Google would be stupid no to be preparing for a backup route, and if there's one thing that Google isn't, it's stupid.
And yes, of course there always was the possibility that other languages would target Dalvik, but it was never mentioned as something Google would do, or as something that Google would consider beneficial to anyone. That tone is changing as of late I feel. That's what I meant - I feel that recent public talks about Android from prominent Google evangelists is slowly preparing the Android world for a gradual change. Not that they'll drop Java like a hot potato next year - that'd be infanticide. It's just that the initial message of 'Java all the way for all things Android' (which was meant to provide developers reassurance that they wouldn't have to work with a myriad of libraries in all sorts of languages, leading to a fragmented landscape on the development side) is not said as loudly any more.
Then again, maybe that was the plan all the way, to provide a broader development environment once the developer base and tools were broad and mature enough. I mean, what do I know, right.
I think you're right. It seems odd that Bray would emphasize the code generation point apropos of nothing. It'd be as if he decided now would be a good time to point out that Android devices are in fact Turing-complete and that the language used to program for them is not an innate part of their nature.
It could be that he is just making an observation. But I read it as a hint of things to come or possibly a gentle suggestion for others to follow. I think it would be interesting to use Google's Go for the native work, for example.
Well, in theory, it should be possible to create another language that targets the Dalvik VM (or port an existing language). In practice, I don't know how easy that would be.
Keep in mind though that Android isn't intended to be a Linux distro or even a Posix'ish OS. It's closer to something like DD-WRT. It is it's own, non-unix embedded OS that just happens to use the Linux kernel as it's base (because really, where's the value in writing your own kernel these days?)
I don't know about you personally, but I've seen a lot of people confused about exactly this - "what Android is": its architecture, what's its relationship to Linux is, its relationship to Java, its relationship to open source & GPL, etc.
This seems to lay a lot of that out fairly cleanly and simply.
Very true. There are a lot of discussions, blog posts, etc. online where people seem to think that Android either is a Linux distribution of some sort, or that it's a Java JVM (like J2SE, etc). In reality it's neither.
Maybe ... "If you’re writing code in the Java programming language you can use Eclipse and a pretty nice toolchain that makes the barrier to entry remarkably low."
or maybe (as a commentator on the blog mentions) ...
a) I wasn't indicating any negative sentiment against Android, just quoting an amusingly awkward juxtaposition.
b) I was kind of expecting the downvotes, so thanks to those who upvoted me back to breakeven (at time of writing)!
c) Tim has now amended the article to render "And that's what Android is" like a header instead of body text, indicating he too thought the juxtaposition altered the meaning of the post.
No, we revel in portability and performance :)
Really good article though.