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.
SUN and Google have both expressed concerns over fragmenting the Java ecosystem. And with Dalvik, that has certainly happened.