Android – bad or evil?

The point is: is Android creating a precedence that could endanger the Java ecosystem?

Yes, you read it right. There is already a name or it – the “android effect“.

So what is the “android effect” and why should we, Java developers be afraid of it? Well, today we know for sure that Java is a very successful technology. But – tell me – what is Java? There is the Trademark, there is the API, the Virtual Machine, there are open source projects. It obviously is not the language syntax, since there are other interesting ways (Groovy, JRuby, JPython) to create Java byte code. So is it the virtual machine? Or is it the “write once, run everywhere” approach? Well, IMHO, it is much of the latter one.

This explains also why I do not like the Java ME edition – it’s a different Java. I need other VMs, other APIs, other Tools – everything feels different. So why should I stick to Java when it comes to the mobile devices. I didn’t. I had a look at other technologies. I skipped the the whole ME, the whole mobile device world, that pains. But it was not Java.

Well, Android might feel more like Java then Java ME ever did – the Tooling, the API, the coolness. But it is not Java – either. It is using the Java Syntax, and creating something non-Java out of it. This is, and I agree with Richard, Java fragmentation. And I do not like this precedence either. Where is this road taking us? To lots of Java that run almost nowhere, only in a special target Platform.

On the other hand, ME is awful. Dozens of JCRs do not make it right. If Android is the pill we have to swallow, so I hope, it is the least evil of them.

“Android also sets a precedent that is seriously detrimental to the Java Community Process. It asserts that creating non-compatible implementations, forks if you will, is a viable business model. If other vendors pursue this same strategy, the JCP’s ability to enforce compatibility and standards will diminish. Over time the JCP could be rendered completely irrelevant.”

Richard Monson-Haefel

In the blog postings from Richard Monson-Haefel and the answers from Ed Burnette you can read it in more detail:

Hope for increased processor clockspeeds?

There seems to be hope left for faster processors with clockspeed far above 20GHz – upto 50GHz. The new technology is called STG – stacked transistor gate – a three dimensional design, an eventual successor to the standard planar transistor design. I found this article with a bird’s eye view from the STG design.

But even if this technology makes it into commercial products – it will be to late to us programmers dealing with the multi-core race. We will probably be fighting above 10 processors per die before we get such fast processors:

The company is touting the device as an eventual successor to the standard planar transistor design, a design whose well-known clockspeed scaling problems have put the brakes on the clockspeed race and have forced the entire computer industry into the parallel computing paradigm that programmers are still struggling with.

If the SGT is able to get the per-thread performance train rolling again, then this would shift some of the burden of providing overall software performance increases off of programmers and back onto process engineers. However, the SGT is an unspecified length of time away from commercialization, and, by the time it gets here, it’s possible that most programmers will be grappling with core counts well north of 10 cores per die (i.e., a Nehalem successor that has moved down into the mainstream). So whatever relief the SGT may eventually provide is almost too far off to matter in terms of slowing down the multicore revolution.

This is just another article pointig out what we are facing today. The multi-core dilemma has left the workspace of application server developers: most developers working on rich clients are deploying their products in similar hardware configuration.

It could be the reason why we – and other speakers and authors – are getting so much attention in talks about concurrency.

Steffen and I will be speaking again about java and concurrency on the upcoming OOP 2008 conference.