I guess Google did make the wrong choice back then. I certainly prefer C# over Java any day, even by the most basic test like "language features". Using Mono would've certainly resulted in _less_ fragmentation than they have with Dalvik today.
> Using Mono would've certainly resulted in _less_ fragmentation than they have with Dalvik today
Why would using Mono result in less fragmentation? Most of their "fragmentation problem" comes from having developers having to develop for multiple devices (screen size, performance, GPU, android versions, etc.), and changing the language won't magically fix it.
Ah, that makes much more sense. Having said that, where do you see fragmentation in the Java ecosystem? I don't use Java to write anything but Android apps, but I've used a few pure Java libs with Android and they all seem to work great.
That isn't to say it isn't happening, I just don't experience and would be interested in knowing where it does occur.
Blackberry is more J2ME-ish and Android is more J2SE-ish. It's possible to share engine code (I've done it) -- you'd still have to do custom UI code for each.
given that the phenomena runs rampart in Android world, I should have been clearer.
It has become evidently clear that 9 out 10 times that the word "fragmentation" is uttered on HN or any comment board regarding Android, it is by people who have never developed a line of Android code and whose knowledge of the platform is what they picked up on advocacy sites.
Dalvik isn't fragmented at all. It is, in fact, a bloody marvel. Implementations of hardware specific APIs of course differ, exactly as expected.
But really, it is astonishing seeing the claims that we see. Microsoft struggles to run WP on a single reference hardware platform with the most trivial of variances. Android runs on friggin' everything with an overwhelmingly high level of compatibility that is so refined that those few outliers become a really big deal.
As someone who admittedly isn't an Android developer, isn't the point that Dalvik's very existence has fragmented the Java ecosystem? That's how I read the GP comment.
isn't the point that Dalvik's very existence has
fragmented the Java ecosystem
Yes and no.
Dalvik is not Java, being a totally different VM, just as .NET's CLR is. And just as .NET's CLR, you can transform Java's bytecode to Dalvik bytecode by means of a compiler. The equivalent project in the .NET world would be IKVM, which allows you to transform Jars into .NET dlls.
It is true that Google relies on the Java ecosystem for fueling Android ... they rely on Eclipse for IDE support, they rely on Harmony for the base classes and so on. But everybody working with Android knows that Dalvik is not Java and that Java libraries that are doing bytecode manipulations do not work on Dalvik out of the box, because Dalvik is not a JVM.
So really, Dalvik is fragmenting Java in the same way .NET did.
The .net ecosystem is already far more fragmented; it's gone through four incompatible revisions in about half the time java's been around, and that's before you talk about things like the compact framework (which, to be fair, java has an equivalent of).
In fact, depending on the language features you use, it may even be possible to compile down to an older CLR version, as the new language features are often simply syntactic sugar for some code generation that happens behind the scenes.
That's exactly what's happening. All versions of .NET since version 2.0 are primarily library updates. They can all safely run on the same CLR, and there haven't had to be any changes to the CLR to enable new language features. A computer really only needs to have a second version of the CLR installed in order to run code that targets .NET 1.x
That's pretty much how Java works too. In general, you can't take code compiled with a newer version and run it on an older VM. You will get class version mismatch errors.. they update the class version every time there's an incompatible change, such as when 'enum' became a keyword.
The compatibility that Sun, err.. Oracle, strives for is to be able to mix code compiled with old & new versions without issues.
Exactly! I don't think language choice has anything to do with Android fragmentation. It's because of the hardware manufacturers and the carriers who never push any updates.
I think it's business model. Because of the incentives (branding, revenue streams, etc.) an android handset maker makes its money when the phone is sold, and ceases to care. Because the phone is branded "Verizon" first, "Android" second, and "HTC" (say) third they don't care about the user once the phone is sold. Arguably, Verizon and Google should care more, but Verizon clearly doesn't and Google has too little influence. In essence it's a tragedy of the commons where the commons is Android (as a platform/brand).
Android was definitely written with multiple hardware configurations in mind. What I don't understand is why phone carriers and manufacturers simply provide the drivers for Google (and consumers) to work with. Essentially how one would install drivers on Windows. I don't understand the need for the drivers to be proprietary.
I also prefer C# and I think the .NET CLR is a solid platform.
However, I feel that Google did not make the "wrong choice" because they were likely trying to leverage two (interdependent) advantages: existing Java programmers and the overwhelming number of Java libraries.
I haven't made it through all the threads here, but I'm fully expecting to find a post containing "yeah, and we can just run the Java-to-C# translator on all those libraries", and then I'm hoping to find a reply that says that machine translation is not the same as porting a library.
