Slashdot Mirror
Android's "Non-Fragmentation Agreement"
superglaze writes "The biggest doubt cast over Android (whose SDK was released yesterday) has been the fact that much of it is licensed under Apache. There have been worries that manufacturers might fork the code road in a non-interoperable kind of way. I.e., they would have no obligation to feed back code to the wider Open Handset Alliance, or even tell the other members what alterations have been made. However, it turns out that Google made all the members sign a 'non-fragmentation agreement' to make sure everything works with everything. In theory at least. 'All of the partners have signed a non-fragmentation agreement saying they won't modify [the code] in non-compatible ways ... That is not to say that a company that is not part of the OHA could not do so.' Google's spokesperson highlighted the historical dangers of working with Java, the programming language that lies at the heart of Android. 'One of the current problems with mobile Java development is that Java has fragmented ... Java virtual machines have fragmented, but all the members of the OHA have agreed to use one virtual machine that can run script in Java'"
In a strange kind of way, this is Google versus Apache. Or, commercial versus non-commercial. I know that this is a ridiculous simplification but it kind of smells that way to me.
Normally Google and open source play together well. But, in this case, we have the potential for a real issue down the road.
With all of that aside, here's a question for you...
If you absolutely had to choose, would you pick to align yourself with Google or Apache?
This isn't a "real" question. It's more of a thought question about who you like and what you believe in. I'm just wondering what people value the most.
How to Download YouTube Videos
How is this google vs apache? I don't understand (its early and I'm feeling fuzzy headed so forgive me). Google is using an apache license to release this... other than that I don't see asf involvement in the project. Maybe I'm missing something here? This article talks about all the involved parties signing an additional agreement separate from the license agreeing not do what MS did to Java before being sued.
So... how is this google vs apache?
I took a look at the SDK yesterday and some of the videos - having done windows mobile development it looks like it will be almost as easy and have a number of similar features.
My concern with all of this though - is that there is no hardware available.
One of the things about emulators is that they run really fast, much faster than the actual hardware runs - so it's hard to tell how responsive an application will be. So given that google has been plowing ahead on development but not been testing on real hardware, one has to wonder if things are going to get seriously challenging when they move to hardware...
I'm going to lose all my karma points, but here goes...
From this (and other comments in the previous postings about Android), one might get the impression that the people at Google are a bunch of idiots who just didn't do any basic research. Why, if only they had read Slashdot occasionally, they'd know that Java is slow, has 10^6 different versions, is very slow, is inferior to C++, is extremely slow, takes up too much memory, is abominably slow, is a programming language that no real programmer uses any more, and in general is teh sux0rz. <grin/>
Isn't the scenario above EXACTLY what this non-fragmentation agreement should help to avoid? Seems like a reasonable way to ensure device compatibility to me. If a non-OHA entity fragments the code, that's fine, because their code/app/SDK/whatever isn't guaranteed to run on all of the devices anyway. If some hobbyists want to create their own derivative platform for device X, they're perfectly free to do so. Seems like all of the benefits of the open source model to me.
This guy's the limit!
Whoa, he-llo? That's a rather interesting (and bold!) statement to be making there. I don't know if Google has noticed, but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs. Which isn't that huge of a deal when you consider that "porting" then becomes a straightforward matter of applying a minor patch between "versions". (Often you can just inline the workarounds and have a single version that works everywhere.)
Meanwhile, Google has created a JVM that's not actually a JVM, that's incompatible with the J2ME/MIDP standard, and then has the gall to claim they're the solution to a more or less non-existent problem? That's ballsy even for Google.
Javascript + Nintendo DSi = DSiCade
Sounds to me like they don't want anyone forking it.
This is not as bad as Tivo ... or is it?
Non-fragmentation my you-know-what.
I am with Linus on this one. For the life of me I can't understand what this sucking up to RMS is about. Linus himself does not think GPLv3 is a good thing. So why do people keep adopting it.
Without Linus FOSS is tossed. Not following Linus is dangerous for the survival of FOSS.
to develop in non-java. Of course, it may not work on ALL handsets (in fact, all but certain that it will not). But if you do the work in Java, AND use their API, it is being guaranteed to work across all of the handsets. So, what is your gripe?
I prefer the "u" in honour as it seems to be missing these days.
Agreed 100% about the unfair commentary that there usually is on Java. But, Google are behaving rather bizarrely by on the one hand warning about the problems of forking and then on the other releasing their own JVM Dalvik instead of using JavaME. So they're going with Apache's dodgy non-GPL approach and further causing fragmentation of the Java platform right when sun is doing the right thing by releasing a GPL'ed Java and Red Hat and others have stepped up to the plate to integrate the OpenJDK work with IcedTea. Google aren't stupid, I wonder what they're game is? I suspect they're trying to GPLv3-proof themselves.
I agree that the use of the Apache licence is the biggest problem with Android.
If Android had just used the GPL (which prohibits forking), then this problem would have avoided. There are lots of examples to back this up. For example, if Emacs had used the GPL, instead of the Apache licence, the XEmacs fork would never have occurred. And if Gnome and KDE would both switch to using the GPL licence, then the projects would just magically merge into one, and we wouldn't have the duplication of effort and lack of standards that you currently see on the Linux desktop.
Oh, wait... (consults Google). Never mind.
I have written a truly remarkable program which this sig is too small to contain.
behaving rather bizarrely by on the one hand warning about the problems of forking and then on the other releasing their own JVM Dalvik instead of using JavaME.
You've never written a JavaME (J2ME) app, have you? Getting a J2ME application to work properly on all phones is a huge nightmare. Just when you have it working on your phone, and all of your coworkers phones, you try it on your wife's phone, and find that it completely doesn't work. There's plenty of fragmentation just within J2ME, and it's made worse by the fact that it's almost impossible to test an application on every different phone that's out there. If Google can come up with an SDK that makes "write once run anywhere" a reality in the mobile world, I'm all for it.
ZuluPad, the wiki notepad on crack
Lets just get it over with - all "GOOG is the AntiChrist" posts please file under this one, so as to have a neat and orderly flamefest.
Brought to you by the Lawful Neutral alignment since 1984 - "I don't care what you do, just as long as it's in a neat and orderly fashion"
"As God is my witness, I thought turkeys could fly." A. Carlson
Say it isn't so! It's all these guys can do!
...it is largely because cellphone mfgs are so tightly wedded to telecoms that they have little interest in offering a platform that attracts 3rd party development.
Open up the network, as Google is proposing, and mfgs have to compete more in terms of coherent feature sets and what 3rd party apps they can attract.
Can a kind Slashdotter educate an ignorant soul about the gist of the Apache license? I sincerely would like to know.
That's fine, but you're avoiding the central point: Google are causing further fragmentation and forking within Java at a time when there are significant efforts being made to re-unify and stabilize the platform. Also they've chosen a license which has the potential to allow leachers to benefit from any work anyone does on the distributed code. A pity that they didn't put their efforts into improving J2ME instead.
Symbian was developed on hardware, on the lowest hardware then available so that it would be sure to run on everything. This made the design obsolete at launch and now it is so archaic(?) that people really resent that original decesion.
Perhaps Google wants to avoid this. Wants apps that push the hardware requirements so that the Android phones will HAVE to be powerhouses, and it doesn't get trapped in the symbian or even MS trap of having to work on the cheapest shit some company can throw together.
Apparently (I only have this from hearsay) symbian phones often miss basic hardware capabilties that drive a pc programmer up the wall because he suddenly has to code for features that have been present in PC's from the dawn of computing.
All google now has to do, is convince mobile phone makers that it is in their best interest to make their phones capable of actually running the software currently being developed.
Don't forget mobile tech moves fast but is expensive. If the companies could get away with yesterdays tech they would. That ain't good for us consumers, we want them to be pushed so we finally get some fully capable smart phones and not the same crippled yunk they have pushing on us.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I don't know about you others, but I seriously think that Android is over hyped. Yes, it's Linux based platform for mobile devices, but so what? There's already Maemo, but you don't see it hyped to death. Yes, the Android can also run Java ME applications, so what? All mobile phones can run Java ME applications...
And one last thing... there are no devices yet! No nothing! And you know what, there probably won't be even many of them. If you look at the alliance that Google has put together, the only serious vendors are Motorola and Samsung. But hey hey hey, Motorola just bought half of UIQ from Sony-Ericsson. UIQ is an user interface used primarily by Sony-Ericsson on top of Symbian. How serious Motorola is about Android when they have just made an serious investment into an Symbian company? And Samsung... they are just as much flip flopping as Motorola.
You know I'm not saying that you should not discuss about Android or not develop applications to it. I just say that Android seems to be again an over hyped thing. If I would be developing mobile applications running native in a phone, I would be damn sure that there is adequate installation base before jumping in, otherwise it could be very well be just seriously wasted time.
Survey research tool for commercial and scientific use
If Android had just used the GPL (which prohibits forking), then this problem would have avoided.
The GPL solves the problem by giving you freedom not by taking it away. Forking is not a problem when code is free as you can tell by looking at the hundreds of "forks" in the Debian repository, or if you look at the thousands of distributions that all get along famously. Java has problems because it was not free and two or three companies were able to control it's destiny. Real community developed and owned software does not have this problem because everyone is free to ignore, remove or otherwise fix problems that an antisocial person might add.
For example, if Emacs had used the GPL, instead of the Apache licence, the XEmacs fork would never have occurred.
The XEmacs fork was permitted under the GPL and would not have been a problem if the XEmacs people had been careful about licensing. The problem came when they were unable to verify that all of their code was free. This allowed anti-social contributors to deny distribution of the whole until all of the code was replaced with GPL'd versions.
if Gnome and KDE would both switch to using the GPL licence, then the projects would just magically merge into one, and we wouldn't have the duplication of effort and lack of standards that you currently see on the Linux desktop.
Gnome and KDE are GPL'd, work very well with each other and are good as separate projects. I run Gnome and KDE applications under other window managers without problem. The "Linux Desktop" is far more unified than non free equivalents from M$ and others where you can't be sure the clipboard is going to work across applications or the network. GNOME and KDE have different approaches to the same problems, so the user gets to chose what works best for them. Users can also chose from a dozen other good window managers and frameworks. This is a wonderful thing because one size does not fit all. Once again, this is because the software is free and the community can make things work.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
Forking - and even just the threat of forking - can be powerful forces for coordination. Reducing the freedom to fork tends to centralize control and reduce the size of the community for a project, while also restricting potential innovation. From Stephen Weber's The Success of Open Source (pp. 169-170):
Forking helps distribute influence and the freedom to make choices about development (pp. 180-181):
So by preventing forking, Google maintains control. The relationship seems to go the other way too - open communities may tend to fork less (p. 160, 227):
or we could say you're missing the point, java is so very fragmented already one more little fragment in the broken heap of glass won't make any difference at all. java: write once, run well only in the IDE of the developer.
So long as the person fragmenting the platfrom hasn't used a Java obfuscator then it would be incredibly easy to decompile the bytecode back to Java source.
Run your emulator in another emulator, maybe two or three levels deep. Emulators, not virtualizers. That should make it run slowly enough for you.
(I'm sure there's a way to simply slow down the one emulator, but I just had to post the Rube Goldberg solution...)
Don't thank God, thank a doctor!
I'm not sure if I should mod you flamebait, insightful, or funny. Well I guess it doesn't really matter now...
EvilCON - Made Famous by
I could go into all the reasons you're shortsighted, wrong, and really a fanboy -- is sucking up to Linus so much better than sucking up to RMS?
But I have a bigger question. What the fuck does the GPLv3 have to do with Android?
Someone slap this tool with -1 offtopic, please.
Don't thank God, thank a doctor!
The first comment to any article about Java on slashdot is by someone who always trolls Java as Anonymous Coward.That's up to the SUN Java Runtime Environment developers not the public that codes in Java
Toy? Where have you been, it's been a "toy" in japan since the late 90s. The United States is just now catching up to the innovations of the cellular phone in Japan.
This is the age of information and there are many that want information on the go or entertainment while waiting for the bus.
----- You know you have ego issues when you register a domain in your name.
'Write once, run anywhere'. Hmm, I'm a java programmer and have been for 10 years. I know, as every java developer knows and realises, it actually means 'write once, run on the important places'. Meaning something that works on your desktop PC will also work on the Solaris server you intend to deploy it to.
Mostly people who use 'but I thought you said run ANYWHERE' argument should actually try to think about what that would mean in real terms. For example, should you expect a huge Swing application or something like Weblogic 9 to run on your 8 year old J2ME phone? Be sensible please...
And I could respond that again you're missing the point which is that there are very significant recent moves towards unifying the java platform which had mostly fragmented because of Sun's licensing policies which have now changed. There is significant potential right now to create Free software community around Sun's version and yet right at this time Google chooses to make this move.
There are Java profiles that work across most cellphones. Most of the new phones implement the profiles with ease.
----- You know you have ego issues when you register a domain in your name.
Sorry, that I go to a different subject, but do I miss something?
(50 * $25.000) + (10 * $100.000) + (10 * $275000) = $5 million
Where are the $10 million ???
No idea why you got modded off topic. You are correct. Normal J2ME commands will work across all phones. It is when you get into graphics or messing with screen resolution that you have to be aware of different devices. That is why you can get emulators for different screen/phones and test.
Java is slow, has 10^6 different versions, is very slow, is inferior to C++, is extremely slow, takes up too much memory, is abominably slow, is a programming language that no real programmer uses any more, and in general is teh sux0rz. There, just proved your point.
That is why you can get emulators for different screen/phones and test.
The emulators I've found don't adequately emulate the various limitations of these phones. You're probably right that basic J2ME commands will work across most phones, but writing games, for instance, can be a huge headache.
ZuluPad, the wiki notepad on crack
A pity that they didn't put their efforts into improving J2ME instead.
Improving J2ME would mean updating he basic standards of what it takes to be considered a J2ME phone. Right now, the standards are so out of date as to be completely useless, so you end up writing for what you think will work on most current phones, and then testing to find out...available emulators don't adequately emulate phone limitations, and not all manufacturers publish all of the relevant implementation specifications, so testing requires actually having a wide array of phones, which can be pretty expensive.
ZuluPad, the wiki notepad on crack
the impression that the people at Google are a bunch of idiots who just didn't do any basic research
They did do research, which is why they replaced most of the Sun bloat with native C libraries.
they'd know that Java is slow, has 10^6 different versions
They know that; it's one of the reasons they created Android in the first place.
Java is slow
They know that, too, which is why only the high-level apps are written in Java and why they replaced the JVM with Dalvik.
So you still can't modify the source code on your phone and run the changes. I bet they are still going to lock down the phone software with DRM (Example.. Motorola A1200)
Forking is not a problem when code is free as you can tell by looking at the hundreds of "forks" in the Debian repository, or if you look at the thousands of distributions that all get along famously.
Yeah, cos Ian Murdock didn't say that he wished Ubuntu hadn't forked so far from Debian as to be entirely incompatible.
Oh, wait. He did.
*complete shite about Java*
What? What are you talking about?
The problem came when they were unable to verify that all of their code was free.
Bollocks, frankly. XEmacs has always been GPL. The problem came because the FSF wanted copyright assigned to them for XEmacs. So yes, complete horseshit, Twitterris.
The "Linux Desktop" is far more unified than non free equivalents from M$ and others where you can't be sure the clipboard is going to work across applications or the network.
I haven't had a single problem copying and pasting between any application in Windows. Or for that matter, Mac OS X and Linux. Care to explain more about this mythical uncertainty? And no, the *NIX desktop isn't more unified than Windows or the non-free equivalent. Windows and OSX have visual styles which export the global style to all applications that are coded to use it. The *nix world has 2 major APIs and numerous other smaller ones. Slightly different, no?
I write bullshit
Whoever modded him offtopic was either being childish or desperate to hide the information. Probably just a fanboy.
Reading further on this, the interesting thing about Dalvik is that it's a non-Sun-controlled JVM. The thing about JavaME (aka PhoneME) is that although it (like JavaSE and JavaEE (Glassfish)) is released under GPLv2, there is no exception clause (there is for JavaSE). This means that you can only run GPLv2 code on PhoneME. Obviously Google and it's partners didn't like this, so they wrote their own JVM. In order to avoid infringing on Sun's IP they've made the bytecode unique to Dalvik. So Java goes in ---> Dalvik bytecode comes out, runs on Dalvik. Very clever.
As I've said before, I think you're missing the point. And having read a bit more about Dalvik I think that Google needed their own fragmented platform because the GPLv2 (sans-exception) license of JavaME/PhoneME meant that if they want to encourage partners to write proprietary, non-Free code then they had to get their own JVM. See my post here for more information. This is a license war. It has fuck all to do with technical excellence or the ease-of-development on the platform. The only reason I care is that I don't like non-Free stuff. It doesn't really matter a fuck to me whether I get proprietary apps from the OHA or from Microsoft. I also dislike fragmentation of Java, especially when it has the chance of being an even more viable platform.
It's a good thing no one gives a shit what you think then...
v4sw6PU$hw6ln6pr4F$ck 4/6$ma3+6u7LNS$w2m4l7U$i2e4+7en6a2X h
Wow, that was quick. I posted an hour ago on the other thread about my worries about Device Fragmentation.
IMHO the differences in the J2ME API is not the main issue for a developer. Differences in screen size, processing power and keypad layout is much more important.
Is google going to force 240x320 (or whatever) on everyone? Is it going to prevent a manufacturer to heavily customize the look and feel? Are we going to have a split between devices having a touch screen and devices not having it?
Since Google is doing this, my guess is they looked into J2ME, found a mess of legacy code and outdated standards, and decided it wasn't worth it.
Even Microsoft was wise enough to do something similar when they decided to scrap the whole pre-NT platform and start anew.
So then it sounds like..
- Many of the "2000" classes were reimplementations of the base libraries
- Google cannot use the Java trademark or refer to their VM as Java.
The fact that they are calling it Java makes me think Google is willing to break the license because they're big enough and can spread enough FUD to make Sun think twice about suing.
What?! Do you have an actual example of clipboard problems in Windows? Or have you been reduced to inventing Windows problems whole-cloth to support your crusade?
Whoever modded this as "redundant" is on crack. There was absolutely nothing else posted on this thread about the JavaSE exception licensing and it's the heart of the matter.
The core J2ME API was made by several commities and "evolved" rather than was designed. Those commities were controlled by the operertors who were more concerned about using the API to generator revenue for themselves than advancing technology. Google is right in starting from scratch rather than building on J2ME.
However, some extension apis are rather well designed (for instance bluetooth and mg3), it would be not be a bad way to re-use those apis.
Football Odds
Do I have to stop it forking? After all, that isn't distribution...
I know that's why they did it, which is why I posted this comment. I'm also aware that people inside Sun have been trying to streamline Java SE further. I think it's pretty clear that Google is working hard to facilitate the creation of non-Free software by mobile phone makers. I guess the company slogan changed to "Do lots of evil". Meet the new Microsoft, happily embracing and extending Java.
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
Google cares little either way about fragmenting Java - what they want to avoid is fragmentation of Android, and I think they will accomplish this, more or less. They just decided that J2ME didn't do it technically for them. As far as the license, I think they wisely realized that Apache would be seen as more business friendly, and it leaves service providers with the illusion that they can still lock everything down.
Illusion? Yup - in practice, this will be extremely difficult. IMO, Google's play is to make a huge fuss about how open the platform is, and get a whole crapload of software written for it that requires fully unlocked phones in order to operate, which will all exist before the first phones even come out. They're even dumping $10 mil into this, and I all but guarantee you that most of those 50 finalists will be using all the cool API features that providers would be happier to lock independent developers out of. By the time phones hit the market, people will be so used to seeing all the sweet things that full Android phones can do that it would be tactical suicide for a phone company to release crippled versions - they would be instantly accused of misleading their customers, with very good reason. I'd be freaking pissed if I was expecting to get a phone that could run all sorts of free map-based software with P2P gaming and all that fun stuff, and when I picked one up none of the software I was promised (implicitly, by their marketing of it as an Android phone) would run.
Think about it - what are the buzzwords associated with Android as far as the press releases go? 1) Open, and 2) Business-friendly. These are largely mutually incompatible, but a lot more people will be pissed if the phone companies strip out 1), so they will have no choice but to succumb to a different business strategy. Google is going to force their hand by making their customers insist on keeping the phone open, just watch - it's rather clever, if you ask me, and I hope it works.
"people will be so used to seeing all the sweet things that full Android phones" Once again, slashdot user != typical user. Normal people want what they see on TV or what their friends have. Not something from videos in the developer section of google's website.
The reason that one forks or fragments a project like this is in order to try to do it right. With so many vendors working on and supporting Android, I think they've got a real shot at making a platform where tweaks aren't necessary to get code to work on another Android phone (compare to getting the same software to work in different J2ME phones.)
That's one of the more thoughtful posts on this topic that I've read. It's also optimistic which is nice.
"'Write once, run anywhere'. Hmm, I'm a java programmer and have been for 10 years. I know, as every java developer knows and realises, it actually means 'write once, run on the important places'. Meaning something that works on your desktop PC will also work on the Solaris server you intend to deploy it to."
Well, so what you are saying, is a 'hello world' application will run on all the important places.
How about something a little more complex?
Not all apps are conent with simple objects and methods.
I'm pretty sure a C programmer can write a hello world app that compiles and works on 'all the important places'.
Pfft. Spoken like a true Apple fanboi. And as usual, with absolutely no clue whatsoever as to what you're talking about.
Educate yourself. Try looking up the original Unix philosophy. Wikipedia has an article. But the original philosophy was well described by one of the creators of UNIX in the old Bell Labs Technical journal.
But, being a fanboi, I doubt you'll do it, nor will you believe it, unless Jobs decrees it so.
I hope it works too.
/me begins work on bandwidth-hungry, GPS enabled Android application.
So looking at this from the opposite direction (I downloaded the SDK last night), I think you may have shed some light on Google's rating criteria for the Phase I Challenge. All one has to do is make something that does something the average "G-phone" user would want, but that the cellphone companies wouldn't likely give away without a surcharge or lock-in package. Like you suggest, it's about creating demand for a product that doesn't exist yet, thanks to mobile telco hegemony.
That android overcame fragmentation.
One more thing. I came across this little writeup:
http://ianskerrett.wordpress.com/2007/11/13/what-does-android-mean-for-suns-openjdk/
If you're right about Google forcing the telcos to open up, then perhaps they've deliberately positioned Android for a two-pronged assault: the other target being Sun's kinda-open-but-not-quite-JavaME. After all, they could have done this with a Python variant or something else entirely, so why Java?
Yes, I've had to clean up after someone who relied on Microsoft's locking semantics for their Java application (or rather, their component of a much, much larger application). Knowing the abstractions and not the underlying details does not a useful developer make.
Well, this _IS_ the Internet.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
It's the Unix philosophy. You get many small utilities that work very well together, and you can pipe the input of one into another if you want to do more advanced things.
This is why grep doesn't let you replace, why ls doesn't let you read files, etc.
Of course, not all Unix programs ascribe to the Unix philosophy--which is why EMACS can read your mail.
IMO, Python got the thumbs down for three reasons, 1) there are far more Java developers out there than Python, 2) there is a much larger body of useful Java code for developers to draw on, and 3) adding Python on top of Java is much simpler than the other way around - all that's needed is to get Jython up and running. I'm hoping that support will be added at the OS level at some point before release, it would be a great addition and make certain kinds of development much easier. Java + Python is a pretty good combo, as each one tends to make up for the deficiencies of the other, except when it comes to speed.
So we have to route around Google's efforts to route around Sun's GPL restriction. Sigh. Unfortunately Google didn't just write an incompatible byte-code translator, which we could have dealt with in a simple way, say with a JVM-to-Dalvik translator. They also wrote incompatible class libraries. Really this is just Java in syntagma. Calling it Java is misleading.
-I like my women like I like my tea: green-
Sun had a long time to try and get the handset manufacturers on the wagon and make J2ME a viable platform. Don't blame Google for taking their own stab at it.
I get your point but any Java developer has to at least acknowledge that there might be some differences. For example, we all know that the threading model is different on Solaris and Windows. Also, clock timings used to have different resolutions across platforms too. Your example is far more devious however and probably could not have been predicted so easily.
You are right of course. That is the point I was making I think. I think the 'run anywhere' claim was overblown at the time and shouldn't be taken literally any more. Java developers have long since realised this and those opposed to Java should stop using it as an argument.
We do not inherit the Earth from our parents. We borrow it from our children.
So... Letting people make non-free software is evil, but charging people money to make non-free software is not?
I think you don't realize to which extent fragmentation is a problem... The various JVMs are buggy and have different bugs. That is: they don't fully respect Sun's specs (not even Sun's own J2ME JVM). Then you've got the JSR / APIs problem: which functionality of which phone is supported and which isn't? And then you've got a huge problem: various screen size / screen colors / etc. So it is very hard to have a single codebase generating all the builds.
Yet some companies offer such products and they're pricey (no, I'm not considering the free "J2ME Polish" to be a match for commercial solutions out there). Pricey, but you've got hundreds of builds generated from a single codebase. These companies are making a killing. They even translate Java cellphone apps automagically to C++ Brew ones.
Android is solving some problems, but it's still not adressing this one: how do you deal with X% market share of non-Android phones?
Of course another take on that, witness Google's CEO and Apple's iPhone, is that for many (I didn't say "all", I said "many") applications a Web browser supporting JavaScript is all that is needed. Android phone shall come with a full browser. That alone will please a great many Webapp developers.
One Java to rule them all?
Money is the root of all evil?
No, you're missing the point. Google isn't making phones that happen to run Java. They're making a PLATFORM that developers can target, that happens to use Java. You won't be writing apps for Android that can run on other devices.
Ah, well. Should have known.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
No, twitter. I think you don't really understand what "unified" means. It doesn't mean being able to copy and paste text across applications, Microsoft figured that out 15 years ago. It means KParts working with GNOME applications. It means KIOslaves working with GNOME applications. It means KDE apps being bonobo-aware. It means that hilarious "embedding" technology OpenOffice uses is used by other desktop applications as well. It means having a single unified shell API. It means not having to load another massive set of runtimes for the "other" desktop when I want to use Kate on GNOME or Gedit on KDE. It means having a single binary layer API like COM that acts as glue for everyone.
That's what "unified" would mean. There is no such thing on Linux, at all. There is unity on Windows because it's controlled by a single entity, but at least there is cohesion and consistency. The only way you approach that in Linux is if you write apps that run on plain X or ncurses.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo