Hacker News Reader

Comment by revelation | Hacker News Reader

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.

View on HN

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

Not that kind of fragmentation; sorry, given that the phenomena runs rampart in Android world, I should have been clearer.

SUN and Google have both expressed concerns over fragmenting the Java ecosystem. And with Dalvik, that has certainly happened.

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 OS and Android are both Java-based, but try writing an app that runs on both.

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.

You could achieve the same sharing you can with C# via MonoTouch (iOS) and MonoDroid (Android).

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.

>Dalvik isn't fragmented at all

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

Older code still runs in newer CLR vms -- which is the important part.

This translates to "compatible, except in the case most people would and should not care about" (running newer code in older vms).

This is far better than SUN's idea of Java forever keeping compatibility with old VMs with makes the language stagnate.

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

This isn't true. .NET 4.0 and on use a different runtime than 2.0, 3.0, and 3.5.

I stand corrected. Thanks.

> (running newer code in older vms).

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.

To be fair to Google, when they bought Android it's not as if there was another mobile startup with a competing .Net-based product.

Reply on news.ycombinator.com