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'"

Comments

Java? Fragmented?

[Anonymous Coward]

What, java has "recently" fragmented? What about all the incompatible versions of the JDK/JRE that people must install to use the latest Java Crapplet(TM)?

What about java's promise of 'write-once, run anywhere'..more like, write-once, maintain 5 different versions of the JRE, each at 100Mb+.

Seems fitting that with most cellphones these days, being nothing more than over-priced toys, that just happen to be able to occasionally make and receive calls, that they use a fragmented, broken toy programming language.

I'll stick to a basic phone, and follow the *NIX philosophy, "just does one thing, and do it well", thank you very much.

Re:Java? Fragmented?

[jdeisenberg]

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

Re:Java? Fragmented?

[gEvil (beta)]

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.

Re:Java? Fragmented?

[crush]

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.

Re:Java? Fragmented?

[omeomi]

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.

Re:Java? Fragmented?

[crush]

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.

Re:Java? Fragmented?

[rubycodez]

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.

Re:Java? Fragmented?

[Comatose51]

I'm not sure if I should mod you flamebait, insightful, or funny. Well I guess it doesn't really matter now...

Re:Java? Fragmented?

[EmperorKagato]

Mod parent down.

The first comment to any article about Java on slashdot is by someone who always trolls Java as Anonymous Coward.

What about java's promise of 'write-once, run anywhere'..more like, write-once, maintain 5 different versions of the JRE, each at 100Mb+.

That's up to the SUN Java Runtime Environment developers not the public that codes in Java

Seems fitting that with most cellphones these days, being nothing more than over-priced toys, that just happen to be able to occasionally make and receive calls, that they use a fragmented, broken toy programming language.

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.

Re:Java? Fragmented?

[dintech]

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

Re:Java? Fragmented?

[crush]

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.

Re:Java? Fragmented?

[EmperorKagato]

There are Java profiles that work across most cellphones. Most of the new phones implement the profiles with ease.

Re:Java? Fragmented?

[forgotten_my_nick]

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.

Re:Java? Fragmented?

[ComputerPhreak]

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.

Re:Java? Fragmented?

[omeomi]

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.

Re:Java? Fragmented?

[omeomi]

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.

Re:Java? Fragmented?

[crush]

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.

Re:Java? Fragmented?

[crush]

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.

Re:Java? Fragmented?

[ianare]

I'll stick to a basic phone, and follow the *NIX philosophy, "just does one thing, and do it well", thank you very much. You have perfectly described Apple philosophy, not *NIX. *NIX is more like "do as many things as you want to do". The fact that Apple uses *nix to a large extent, and has put it on a phone, while at the same time some of these same tools help run huge render farms, workstations on different architectures, datacenters, embedded devices, routers, etc.. ad nauseam -- just goes to show the versatility of *NIX.

Re:Java? Fragmented?

[Anonymous Coward]

It's a good thing no one gives a shit what you think then...

Re:Java? Fragmented?

[muyuubyou]

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.

Re:Java? Fragmented?

[Anonymous Coward]

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.

Re:Java? Fragmented?

[crush]

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.

Re:Java? Fragmented?

[Goaway]

right when sun is doing the right thing by releasing a GPL'ed Java Except that is the exact reason they did what they did. Sun's license requires all surrounding code to also be GPL'd on mobile platforms (but have a special exception for this for the desktop version). This is basically so that phone providers, who neither want nor can release this code have to pay them for commercial licenses.

Re:Java? Fragmented?

[bjourne]

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. Seek and you shall find. At least both Sony Ericsson and Nokia have public discussion boards where you can get in touch with handset developers, bug reporting and free test suites. You can also, if you represent a reputable ISV, borrow phones to test with and (if you sign a bunch of NDA:s) even get unreleased phones to experiment with.

Re:Java? Fragmented?

[Anonymous Coward]

That's up to the SUN Java Runtime Environment developers not the public that codes in Java So if your Java code doesn't work on an already widely platform you need it to, what do you do? Do you spend time figuring out and developing a work-around for someone else's bugs so it does work, or do you just whine?

Re:Java? Fragmented?

[ClassMyAss]

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.

Re:Java? Fragmented?

[supermansuper]

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

Re:Java? Fragmented?

[Sancho]

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. Java (and even J2ME) is a strange little beast. It's not quite a platform, but it tries to be one. Google is trying to create a true platform based upon Java. It's probably true that code written for their platform will have issues (or not run at all) on non-Android platforms, but that's something that would happen anyway, even if Google had chosen J2ME and tried to improve it. With everyone else fragmenting Java, coupled with versioning problems, software written for Android probably still wouldn't work by default on other J2ME phones.

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

Re:Java? Fragmented?

[crush]

That's one of the more thoughtful posts on this topic that I've read. It's also optimistic which is nice.

Re:Java? Fragmented?

[Anonymous Coward]

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

Re:Java? Fragmented?

[Anonymous Coward]

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.

Re:Java? Fragmented?

[pragma_x]

I hope it works too.

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. /me begins work on bandwidth-hungry, GPS enabled Android application.

Re:Java? Fragmented?

[pragma_x]

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?

Re:Java? Fragmented?

[cduffy]

Meaning something that works on your desktop PC will also work on the Solaris server you intend to deploy it to.

Only until your code depends on filesystem locking semantics which differ between your development and target platforms.

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.

Re:Java? Fragmented?

[nschubach]

do you just whine?

Well, this _IS_ the Internet.

Re:Java? Fragmented?

[Sancho]

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.

Re:Java? Fragmented?

[ClassMyAss]

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.

Re:Java? Fragmented?

[aminorex]

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.

Re:Java? Fragmented?

[Anonymous Coward]

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.

Re:Java? Fragmented?

[dintech]

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.

Re:Java? Fragmented?

[dintech]

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.

Re:Java? Fragmented?

[rmerry72]

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.

True, but this is the fault of the developer not the language. No useful language can protect against bad / lazy developers. Java can't abstract absolutely everything about the O/S away (nor should it try) so if a developer needs to write code steps outside these bounds then you must write it in a portable way, even if that means using JNI or writing less efficient code.

Re:Java? Fragmented?

[etnu]

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.

Google versus Apache

[webword]

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.

Re:Google versus Apache

[kevin_conaway]

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.

How exactly? I don't see it that way

Google releases all their open source under the Apache license. I'm sure they have various reasons for choosing the Apache license, but I'd wager a major one is that it is very business friendly. They most likely understand what a pain it can be to include OSS products that are licensed under a different licensing scheme in a commercial product.

Re:Google versus Apache

[Kadin2048]

In a strange kind of way, this is Google versus Apache.

I really don't think it is. This is Google taking the Apache license and then fixing a major perceived weakness in it, at least within the context of their application (creating a single, uniform, mobile platform). And even then, they're not really restricting the software; they're just getting the people who are part of their trade group to agree not to stab each other in the back.

It's not Google "versus" anything or anyone, except perhaps maybe the closed-source phone manufacturers. Certainly not Apache.

Re:Google versus Apache

[Kazrael]

Apache. While Google does have the mantra "Do No Evil", you must remember, they are a corporation. Their goal is to make money. While they are good now, down the road, you can't be sure. The heart of the system is always corporate gain. The heart of Apache is public gain.

Re:Google versus Apache

[crush]

Well, if the licensing of the SDK is anything to go by it seems more like it's a case of Google vs. Free Software.

Re:Google versus Apache

[Kadin2048]

Well, if the licensing of the SDK is anything to go by it seems more like it's a case of Google vs. Free Software. Well, we always knew that there were going to be parts of the software stack that aren't going to be Free software. The FCC won't allow the parts that control the radio, for example, to be user-modifiable. So there have to be some big locked-down chunks, just because it's a cellphone.

If Google actually said that the "full stack" would be OSS, then shame on them. But it seems like they're going to be way more open than anyone else, and possibly as open as they can be while still getting FCC approval for the device.

At any rate, I find the whole project interesting but I'm not getting personally invested in it yet. I'll see what the license is like on the real thing before praising or condemning it.

Re:Google versus Apache

[Anonymous Coward]

"The FCC won't allow the parts that control the radio, for example, to be user-modifiable. "

That's a red herring. All cellphone chips are locked down in *hardware*. The software can control certain parts (that's why, for example, we have the ETSI specs). And any user CAN modify those parts.

Just because the hardware is locked is no reason whatsoever why parts of the software should be.

Re:Google versus Apache

[Danny Rathjens]

But it seems like they're going to be way more open than anyone else, and possibly as open as they can be while still getting FCC approval for the device. How can you possibly say that when http://openmoko.org/ exists?
And I don't think openmoko had any problems with FCC approval and are truly open. "free software" is not all that relevant the type of "locked-down chunks" you are talking about - like 911 location service - since they are "locked down" in the hardware chips (by simply not having certain things controllable via serial interface) and not by any software.

Re:Google versus Apache

[angryLNX]

I would argue that it's Google versus closed-source phone manufacturers, their service allies, their software allies (i.e, Microsoft), and, most notably, Sun Microsystems and the Java Community Process.

Note the conspicuous absence of any Sun software (or support for it) in the SDK release.

See:
http://ohadev.com/blog/dalvik-vm-icicles-abound-no-sun-in-sight/

Re:Google versus Apache

[Torne]

And I don't think openmoko had any problems with FCC approval and are truly open. "free software" is not all that relevant the type of "locked-down chunks" you are talking about - like 911 location service - since they are "locked down" in the hardware chips (by simply not having certain things controllable via serial interface) and not by any software.

There's no such thing as "locked down in hardware" for telephony stacks - the stack is firmware as well and thus subject to being reflashed and modified. OpenMoko and similar devices have a separate baseband processor which runs its own firmware, which you talk to over a serial interface - the application processor runs free software, the baseband processor doesn't.

But.. handset manufacturers in general are moving towards a single-processor model - a separate baseband processor costs money. Either they run an RTOS which has the entire application stack as a task (so, your OS is effectively being context switched in and out, whether it's Linux or whatever) and the telephony stack as a separate task - which is also going to be nonfree - or they run Symbian, which has a hard realtime microkernel and can support a telephony stack running on that alongside Symbian tasks - which is nonfree. :)

So, while openmoko and similar might choose to make hardware designs that allow it to be 'truly open' - assuming you choose to call it that - other handset manufacturers probably won't, your free software will be stuck running on a closed RTOS to support the telephony stack.

Re:Google versus Apache

[PhotoGuy]

Exactly. I prefer this approach. Fork it if you want to do your own independant thing, but if you want to belong to our trade group, then agree to the non-fragmentation agreement. Everybody should be happy.

I prefer the Apache and BSD style licensing myself, it's really what freedom is all about to me (including the freedom to have your own private fork if you wish). The Apache license hasn't exactly led to the Apache web server itself going to hell in a handbasket due to fragmentation. People are free to fork, but the mainstream is tasty enough that it's what most people use.

Que?

[$1uck]

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?

Re:Que?

[$1uck]

blah... this was supposed to be in response to someone else and not the main article... I am out of it this morning sorry.

Re:Que?

[rumith]

I'm not sure how exactly it is Google vs Apache, too, but the Apache License is not the only way ASF is involved in this story: Google's custom Java VM, named Dalvik, is heavily based upon Apache Harmony.

Pretty cool start

[Zebra_X]

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

Re:Pretty cool start

[FinestLittleSpace]

You have a valid point, however Google /have/ been running Android on mobile handsets. You can see videos of them in action on the main site.

Re:Pretty cool start

[$1uck]

"almost as easy" Are you saying that J2me is easier than this? or... are you comparing to a different embedded sdk?

Re:Pretty cool start

[Zebra_X]

Almost as easy as developing for windows mobile...

Re:Pretty cool start

[Anonymous Coward]

IIRC, a quick look at the emulator documentation showed an option to "emulate" the slowness in the hardware!

Re:Pretty cool start

[enjo13]

I seriously doubt that they haven't put this on hardware yet. The entire system is a fairly standard set of components...you could flash it onto a number of different reference boards. I would be shocked if they didn't do just that.

Re:Pretty cool start

[Anonymous Coward]

One of the things about emulators is that they run really fast, much faster than the actual hardware runs... That's why I run Virtual PC, inside Virtual PC.
It creates a paradox that bends time, allowing me to observe things like windows redrawing, and birds in mid-flight.

Re:Pretty cool start

[babbling]

There is no "speed that real hardware runs at," since each phone running Android software will be different, just like every PC is different. Think of Android as a PC in your pocket that has mobile phone capabilities.

I haven't looked at the SDK, but from what I have heard you can configure the emulator a bit to reflect the capabilities of different types of phones.

Revisionism?

[AKAImBatman]

One of the current problems with mobile Java development is that Java has fragmented ... Java virtual machines have fragmented

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

Re:Revisionism?

[Anonymous Coward]

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 This is just plain wrong. Once you start looking at graphics, audio, keyboard input, bluetooth, gps, network, photo or video capture or anything beyond very basic apps, you reach the murky world of JSRs, which are bits of java that may or may not be included in a particular j2me installation. If they are included, many of them have lots left up to the implementation to decide, for example MMAPI leaves it up to the implementation whether to support MIDI sound, whether to support playing audio directly from code rather than from a file, whether to support recording, what file formats to support etc. You can't even reliably play audio files across platforms, let alone do interesting things like get at the camera, get video frames etc.

Nokia phones for example, most will let you grab a single frame from the camera, some won't, but you can't grab multiple video frames without a 1/4 second delay per frame, whereas motorola phones, many will not let you at the camera at all, but those that will, will let you record multiple frames properly, except for a few which will only let you take single frames.

Re:Revisionism?

[Anonymous Coward]

It sounds like what you're talking about has nothing to do with Java, and everything to do with variation in phone capabilities or hardware standards.

Re:Revisionism?

[bjourne]

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

This is just plain wrong. Once you start looking at graphics, audio, keyboard input, bluetooth, gps, network, photo or video capture or anything beyond very basic apps, you reach the murky world of JSRs, which are bits of java that may or may not be included in a particular j2me installation. If they are included, many of them have lots left up to the implementation to decide, for example MMAPI leaves it up to the implementation whether to support MIDI sound, whether to support playing audio directly from code rather than from a file, whether to support recording, what file formats to support etc. You can't even reliably play audio files across platforms, let alone do interesting things like get at the camera, get video frames etc. No it is not wrong. Not all phones has camera snapshotting or audio recording capability which is why you need API:s that leaves it up to the manufacturer what to support. The only other alternative is that each manufacturer writes their own API for whatever features their phones support. All manufacturers had such API:s but are now trying to phase them out because it is easier to stick to standards than to invent your own. Which is exactly what Google is doing, which is exactly why they will fail to attract developers.

It is the same thing with other widely deployed specifications, POSIX, the C library, etc.

Nokia phones for example, most will let you grab a single frame from the camera, some won't, but you can't grab multiple video frames without a 1/4 second delay per frame, whereas motorola phones, many will not let you at the camera at all, Alright, that sucks. But what is your alternative? Try writing a PC program to record frames from a USB camera, easier than MMAPI?

Re:Revisionism?

[sacrilicious]

Whoa, he-llo? [Claiming that jvms have fragmented is] 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.

Each time I've developed for a particular phone, I've had to visit the website of the manufacturer and download one or more jars that specify what subset of j2me is supported on the phone. Does this not qualify as having different APIs for different phones?

Issues between phones almost always come down to working around JVM implementation bugs.

Don't jvm implementation bugs indicate that there's different -- and potentially incompatible -- code in the jvms?

Re:Revisionism?

[ClassMyAss]

FWIW, Android also leaves it up to the handset manufacturers to decide whether or not a particular piece of functionality is available. However, it provides a simple and standardized mechanism to determine whether or not it is, and use it if it is there.

And besides this, even just having a single VM with a single set of bugs will seriously simplify things - right now entire companies exist for the purpose of making J2ME code run on enough phones to take the thing to market (I know - my brother works at one), and the process is anything but simple.

Re:Revisionism?

[jrumney]

This is just plain wrong. Once you start looking at graphics, audio, keyboard input, bluetooth, gps, network, photo or video capture or anything beyond very basic apps, you reach the murky world of JSRs, which are bits of java that may or may not be included in a particular j2me installation. If they are included, many of them have lots left up to the implementation to decide, for example MMAPI leaves it up to the implementation whether to support MIDI sound, whether to support playing audio directly from code rather than from a file, whether to support recording, what file formats to support etc. You can't even reliably play audio files across platforms, let alone do interesting things like get at the camera, get video frames etc.

You obviously missed the section on optional APIs in the Android docs. And do you think they have everything covered that will come up in the next 10 years? This platform will get into the same state as J2ME very quickly.

Re:Revisionism?

[jrumney]

However, it provides a simple and standardized mechanism to determine whether or not it is, and use it if it is there.

try {
...
}
catch (NoClassDefFoundError e) {
...
}

Works on any Java VM.

Re:Revisionism?

[jrumney]

There are about 4 J2ME vendors that cover 90% of the phone market. The main problem comes from developers who assume that every phone has the snazzy new API they want to use, then find that people with older phones want to use their app too.

Re:Revisionism?

[ClassMyAss]

Right, but there are problems with try/catch for fragmented services.

Suppose four different phones implement the same functionality in different ways. Now you've got to have four different try/catch segments, and best case scenario, you're going to trip three of those every time you call the thing. Not only is this slow as all hell (catching an exception is one of the slowest ops in Java), it is an abuse of the exception mechanism. Exceptions are supposed to be used for exceptional situations, not for normal control flow.

Any decent programmer can work around this - just do all the try/catches once at init, and store the results, then use a switch to decide what to do when stuff happens more often. But it's not very clean - I'd much rather be able to write Latitude myLat = myGPS.hasLatitude()?myGPS.getLatitude():null; or something like that (I don't remember off the top of my head how it's actually done in Android), rather than checking how each phone does it and create a whole mess of code to deal with it.

Re:Revisionism?

[Anonymous Coward]

Supporting various hardware standards is one thing. Supporting it via an API that attempts to hide the differences is another.

For example, pretty much every MIDP device in existence has a framebuffer and its pixel format is one of about five possibilities.

So..
Does Java let you access it directly? Nope.
Does Java let you access it via some emulation layer? Nope.
Does Java let you create offscreen bitmaps in native format? Nope.
Does Java let you create offscreen bitmaps in format of your choice? Nope.
Does Java let you create offscreen bitmaps in some standard format? Depends, do you have MIDP2?
Is this format likely to be the native format of the device? Hell no.
Hey, how do you do this stuff in MIDP1 anyway? You don't want to know.

etc. Let's not get into sounds or saving data..

Oh, FORK!!!

[tomhudson]

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.

Re:Oh, FORK!!!

[ajs]

Sounds to me like they don't want anyone forking it. Read it again. The members can't fork the development. Non-members can. They're just trying to prevent the situation where, 5 years down the line, NTT says "thanks for all the hard work Google, but now that we've achieved brand loyalty, we're going to stop working on our competitor's OS." The idea is to make the cell phone OS a commodity and let cell phone makers focus on higher level features that will work on any phone.

Re:Oh, FORK!!!

[tomhudson]

Riiight - but who are these potential non-members? Its not like you can have half you development team be members, and the other half non-members.

And its not like there's a huge field when it comes to cell phone manufacturers. There's not thousands of different manufacturers, so google starts out with a de facto quasi-monopoly.

So even if a fork came along that was better, the companies can't use it.

No wonder Microsoft is afraid google will be the next Microsoft - they're using Microsofts' playbook.

Re:Oh, FORK!!!

[Anonymous Coward]

Maybe if you checked who actually is in Open Handset Alliance, and compared it to the world market share of sold mobile phones. 40% of all phones and 25% of smartphones is hardly a monopoly.

Re:Oh, FORK!!!

[Anonymous Coward]

So even if a fork came along that was better, the companies can't use it.

My understanding of this is that if a fork came along that was better and they wanted to use it, they would all have to agree that it becomes the main branch.

Re:Oh, FORK!!!

[yasth]

Ummm the members are the potential non members. No business would sign a death pact. There is bound to be some termination clause. So given a few months lead any member of the alliance can fork the code.

Re:Oh, FORK!!!

[jrumney]

Nokia would be the main non-member Google has to worry about. They are already using Linux on their Internet tablet devices, and are already porting WebKit to GTK so they can use it in place of Opera (which they currently use on those devices), so forking their own version of this platform might be quite attractive to them. Any smaller companies probably have more to gain by using the platform as-is, so they benefit from the upgrades and applications developed by/for their bigger competitors.

Re:Oh, FORK!!!

[AlexBirch]

Apple would be a potential non-member. Research In Motion or Palm seem to be good competitors as well.

The doesn't seem to have a quasi-monopoly on smartphone manufacturers, not even a semblance of a monopoly.

Re:Oh, FORK!!!

[tomhudson]

40% of all smartphones AT LAUNCH is well on the way ...

Re:Oh, FORK!!!

[ajs]

Riiight - but who are these potential non-members? You? Me? The folks at OpenMoko? Just ideas....

Linus is right

[Anonymous Coward]

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.

Re:Linus is right

[Dunbal]

So why do people keep adopting it.

      For the same reason people keep voting for the same old corrupt politicians?

Re:Linus is right

[Kadin2048]

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. What are you getting on about?

Look, I know I'm going after a sacred cow around here, but if Linus had decided to do something else with his time instead of Linux, it wouldn't have been nearly as big a deal as you're making it out to be. He was the right person, at the right time, satisfying a very specific need, namely for a freely-licensed OS kernel. In the worst-case scenario, the whole thing would have been set back a year or two, waiting on the BSD kernel. More likely, I think somebody else from the MINIX community might have done it (who knows, maybe Andrew Tanenbaum might have done it himself, had he not gotten in a pissing match with Torvalds). We'll never really know, but the key point is that Linux was evolutionary; it was what was needed at the time, it was there first, and it gained traction as a result. (And at least early on, it wasn't all that great from a software engineering perspective; it was the license that distinguished it from technologically superior alternatives, not the other way around.)

But the fact that the demand for a free kernel existed at all is due to a whole lot of other people, and I'm not sure why you'd give Linus' opinion more weight than you'd give to the people who created the license that made Linux successful.

Re:Linus is right

[Seen]

Regardless of why Linux is popular, the fact remains that it is (arguably) the best known open source project.

Even assuming that the GPL is the reason Linux occupies in its current position in the computing landscape, the points you make (which I agree with BTW) about being in the right place at the right time and somebody else stepping up, don't change a thing. Linux is here and it is important and by extension Linus is here and he is important.

Ultimately, disregarding what Linus says isn't the best way to push adoption of the new license.

Re:Linus is right

[Anonymous Coward]

get some kneepads!

Re:Linus is right

[slack_prad]

GP is a troll. The same message gets posted every now and then.

With Andriod, you are free...

[WindBourne]

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?

Re:With Andriod, you are free...

[ceroklis]

And if I develop for Windows Mobile, PalmOs or Symbian I can write in C/C++, compile once, and have the guarantee that the code will run everywhere, because every device is based on the same architecture/ABI (f.i. ARMv4). This is what make these platforms superior.

The only reason to offer Java *exclusively* is if you run on a limited device (i.e. no MMU). In this case a VM is necessary to isolate untrusted third party applications. But in the case of modern ARM chips (with MMU), which can run a POSIX system, the OS can achieve process isolation even if they are written in machine code. Java is thus unnecessary on modern phones.

Now I realize a good jazelle based VM may render Java almost as fast as C++, but there is another reason beside performance to support C++, easy porting of existing code.

Therefore the absence of well defined C/C++ ABI is a deficiency.

Re:With Andriod, you are free...

[smilindog2000]

Until Android has a native C/C++ application development framework, I'm staying away from it... this is really a bummer.

Could it be??!

[porkThreeWays]

Could it be that when smart management couples with some of the best engineers in the world you come up with a great idea? I really think Google has shown everything doesn't have to be closed and secret and can still make some really badass products along the way.

GPL solves these problems

[dmoen]

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.

Re:GPL solves these problems

[domatic]

What? The GPL does NOT prohibit forking. There are dynamics associated with it that tend to discourage forking but it certainly is not prohibited.

Re:GPL solves these problems

[Anonymous Coward]

WHOOSH!

Re:GPL solves these problems

[Anonymous Coward]

You missed the sarcasm - "if Gnome and KDE would both switch to using the GPL licence, then the projects would just magically merge into one" was a key tip off for me, and "Oh, wait... (consults Google). Never mind." seals the deal.

The fact that the GPL doesn't prohibit forking was exactly his point.

Re:GPL solves these problems

[Anonymous Coward]

If Android had just used the GPL (which prohibits forking),

if Emacs had used the GPL,

You keep using that word. I do not think it means what you think it means.

Google is EVIL!!! (for your convenience)

[R2.0]

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"

Re:Google is EVIL!!! (for your convenience)

[mwvdlee]

<cue tumbleweed rolling by>

Android? Non-fragmentation?

[SlipperHat]

Say it isn't so! It's all these guys can do!

If portable Java fragmented

[Burz]

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

Gist of the Apache license: Anyone?

[bogaboga]

Can a kind Slashdotter educate an ignorant soul about the gist of the Apache license? I sincerely would like to know.

Re:Gist of the Apache license: Anyone?

[Anonymous Coward]

BSD
with patent clauses
and a few other restrictions that the BSDers won't go for.

Apache license not interoperable with GPL2 or BSD licensed code, though if the BSD code is included in the Apache license only, then only Theo will throw a hissy fit.

Yep - Article Is Nothing More Than A GPL Troll

[Anonymous Coward]

It is good to see more and more companies like Google dumping the viral GPL and embracing open and free code licenses.

The kooky GPL is quickly becoming a relic like Perl - both use to be Slashdot favorites but now days are looked upon a discarded relics.

Perhaps they want to avoid symbians mistake?

[SmallFurryCreature]

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.

Re:Perhaps they want to avoid symbians mistake?

[Sancho]

Perhaps Google wants to avoid this. Wants apps that push the hardware requirements so that the Android phones will HAVE to be powerhouses, Gosh, I really hope not. Battery technology just isn't there for powerhouse phones :\

Hype again for nothing?

[Iloinen Lohikrme]

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.

Re:Hype again for nothing?

[ElBeano]

I'm guessing you are posting from another country. Japan, perhaps? The point isn't the hardware. The point isn't even the software. The point is creating a different paradigm for phones and service in a country with an oligarchic mess, one that is open and free of extraordinarily ridiculous limitations. In this environment, it really only takes one hardware manufacturer with enough courage to step out of line to shake things up.

Re:Hype again for nothing?

[m2943]

How serious Motorola is about Android when they have just made an serious investment into an Symbian company?

Motorola is already shipping lots of Linux phones (far more than Symbian), but they have almost no developer community. Android might be the answer to their problems.

Motorola just bought half of UIQ from Sony-Ericsson

I think UIQ is a short-term fix for them. I also don't think UIQ is going to make it in the long term. For Symbian, Series 60 is going to be the de facto standard.

Re:Hype again for nothing?

[AmericanInKiev]

Right (ATTN MODDERS see parent)

Apple got Time's invention of the year nod-- not for the device but for the breaking of an anti-consumer technopoly.

This isn't about Google /choosing/ linux, its about the calvery finally showing up to address the crippling backwardness of a corrupted FCC/MEN/Telecom bloc. The Linux, apache, GPL, fork driven is hopelessly beside the point. This is a political seachange,far more than a technical one.

AIK

Re:Hype again for nothing?

[babbling]

The difference between Android and other, similar projects is that Android has huge backing from Google and 33 other companies. That means that it is guaranteed to be the most widespread operating system for mobile phones.

That Google has released the SDK early and is running a "competition" for applications that ends before the first phone will even be released guarantees that there will be cool and interesting software available for these devices as soon as they are released.

One open platform on almost every phone within the next few years is a huge advancement.

Free FUD. Re:GPL solves these problems

[Erris]

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.

Forking is not necessarily bad

[Geof]

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, like speciation, is an essential source of variation and ultimately of radical innovation. Too much forking would undermine the open source process in the obvious ways that people worry about all the time - scattered efforts, duplication of work, incompatibilities, and so on. But to _little_ forking (in other words, too much successful coordination) be as dysfunctional in a different way.

Forking helps distribute influence and the freedom to make choices about development (pp. 180-181):

by creating the right to fork code, the open source process transfers a very important source of power from the leader to the followers. The privileges that come with leadership then depend on the continuous renewal of a contingent grant from the community.

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

The more open a project is and the larger the existing community of developers working on it, the harder it is to attract potential followers to a fork.

One interesting difference between the Linux and BSD worlds is that the Linux kernel (and associated OS core utilities) have never forked, but BSD's has, at least three times. What makes this interesting is that the social structure of the BSD groups is centralized in a way intended to define clear lines of authority and to prevent forking, while the decentralized and amorphous Linux community takes no such measures. It appears that the projects that open up development the most actually have the least tendency to fork!

Java is simple to decompile

[gilesjuk]

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.

Re:Java is simple to decompile

[Anonymous Coward]

They compile to Dalvik bytecode not to .class, retard. I'm sure it strips debugging strings because they would be useless once on the phone.

Re:Java is simple to decompile

[AKAImBatman]

it would be incredibly easy to decompile the bytecode back to Java source.

#1 Who cares? Only young'uns with little experience with how the industry works actually care about someone "stealing" their (incredibly boilerplate, easy to duplicate, hard to integrate into my own project) source code. Did you know that it's easy to "decompile" your HTML, Javascript, Actionscript, PERL, Python, Ruby, Shell scripts, and even Assembler too?

Oh noes! Do not want!

#2 The "Java" that runs on the phone isn't Java at all. Java is used as a development language, and is actually compiled down to Google's Dalvik VM instead. Thus while it will still be decompilable (there's no such thing as code that can't be decompiled) it might be made more difficult by the non-standard bytecode.

I suppose you can limit it yourself.

[SanityInAnarchy]

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

Re:I suppose you can limit it yourself.

[SimonBelmont]

Or, you know, you can just clock your emulator so it runs at the actual hardware speed. I always did hate that instantaneous game over I get on NES emulators...

What the fuck?

[SanityInAnarchy]

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.

Prize money

[u01iz]

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

Re:Prize money

[uhmmmm]

There are two stages to the competition with the prize money split evenly between them. Details for the second stage will be released later.

either/or?

[m2943]

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.

Wait a sec...

[LingNoi]

'All of the partners have signed a non-fragmentation agreement saying they won't modify [the code] in non-compatible ways

To me that reads as they could close off the code and fork it into a proprietary monster as long as everything is still 100% compatible with the Google framework (user apps run correctly, etc).

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)

Re:Free FUD. Re:GPL solves these problems

[Joe Jay Bee]

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?

Developers, Developers, Developers

[un1xl0ser]

"We've built some interesting applications for Android, but the best applications are not here yet, and that's because they're going to be written by developers," It seems that most of Skyne^WGoogle's code has been written by robots so far. WATCH OUT!

Toolkit Fragmentation != Device Fragmentation

[efornara]

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?

Re:Free FUD. Re:GPL solves these problems

[Anonymous Coward]

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.

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?

J2ME

[edxwelch]

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.

So wht if it's a web service?

[Anonymous Coward]

Do I have to stop it forking? After all, that isn't distribution...

Re:Java? Fragmented? -- Google? Non-evil?

[crush]

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.

Re:Free FUD. Re:GPL solves these problems

[Macthorpe]

where you can't be sure the clipboard is going to work across applications Just want to add my non-AC voice to this - why don't you cite your examples of where the clipboard doesn't work between applications and we'll see if we can verify them.

Obligatory T-1000 reference

[Anonymous Coward]

That android overcame fragmentation.

Re:Java? Fragmented? -- Google? Non-evil?

[Goaway]

So... Letting people make non-free software is evil, but charging people money to make non-free software is not?

fragmentation of the JVMs

[Anonymous Coward]

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.

so...

[wellingj]

One Java to rule them all?

IHBT.

[Kadin2048]

Ah, well. Should have known.

Re:Free FUD. Re:GPL solves these problems

[dedazo]

The "Linux Desktop" is far more unified than non free equivalents from M$ and others

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.