java

It turns out , as Stefano Mazzocchi so nicely illuminates here, there's more story to be told concerning Google's use of their own, proprietary java VM (Dalvik) and their end-run around the Java Community Process.

There's a licensing angle here, and Google's is playing the game like a Grand Master.

Java, you see, is now licensed under the GPLv2 - this wins open-source friends for Sun. However, it's only the platform itself that's GPL'd; code written in Java does not have to adhere to the same licensing - there's an exception built into the licensing allowing the user code to be exempt from the GPL.

Unless it's Java Mobile Edition. Apparently In this case the basic Java ME licensing requires that all software written on that platform be open sourced as well. There is, however, a commercial version of Java ME that is licensed differently - it's this commercial version that many for-profit software developers go for, because it allows them tighter control over what their IP.

Got all that? If so, you're smarter than me, 'cause it took me a while.

So now Google comes along with Android, and Dalvik, and licenses the whole thing under Apache v2. How? Well, by creating their own proprietary VM for running the Java code, and having the Java code compile into their own bytecode. They use the Java syntax, some Java-friendly dev tools (Eclipse), but the underlying engine is all their own, and they're very careful not to describe the language as "Java".

Slick moves on Google's part.

A different angle here at articlesmodern.com, concerning Android's new Dalvik Java Virtual Machine.

Dalvik, is, you see, completely Google's invention, which as alright, I guess. Problem is, Android and Dalvik are not part of the Java Community Process, the standards group Sun put together to keep track of standards around new Java features. Apparently Google thought it would show Sun how it should be done:

“We wanted the platform to be open in a lot of different ways,” said Mike Cleron, a Google senior staff engineer working on Android. “The idea is that anybody can come along and replace the pieces of the Android experience on a very fine-grained level. The existing APIs didn’t really allow the level of openness we were hoping to achieve in Android.”

This fragmentation has some worried, apparently, and for good reason, as evidenced by my favourite part of the article:

Mauro Lollo, CEO of mobile phone video-streaming company Movidity, saw Google’s work similarly. “In essence, they’ve created another standard. Standards are great, but the challenge is that there are so many of them,” he said.

Well said, Mr Lollo.

Taking a break from the unboxing to have a look around the Android site.

There's a blog Here.

Some highlights on the platform, from here:

* Application framework enabling reuse and replacement of components
* Dalvik virtual machine optimized for mobile devices
* Integrated browser based on the open source WebKit engine
* Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
* SQLite for structured data storage
* Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
* GSM Telephony (hardware dependent)
* Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
* Camera, GPS, compass, and accelerometer (hardware dependent)
* Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

A set of c/c++ libraries. Linux 2.6 for "core system services". Each app runs in its own VM, which I'm sure the security geeks are gonna be sweet on.

Android will ship with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.

Okay, sounds nice, but where's my ogg and flac support, dammit?

Check out the videos here. Tell me that introductory video isn't sweet -- Google Maps with integrated StreetView on a mobile device, with a touch interface? Nice. The UI looks nice and responsive, the browser seems to rival the iPhone's safari implementation...

So far it's looking good.

Tried to run Eclipse and got some sort of error about Java missing. Installed the java6 runtime environment and development kit, tried Eclipse again, and it's up and running.

And, boy, is it pretty:

That's some hot, hot welcome screen action right there.

Okay, follow the instructions on the Android install site:

1. Start Eclipse, then select Help > Software Updates > Find and Install....
2. In the dialog that appears, select Search for new features to install and press Next.
3. Press New Remote Site.
4. In the resulting dialog box, enter a name for the remote site (e.g. Android Plugin) and enter this as its URL: https://dl-ssl.google.com/android/eclipse/. Press OK.
5. You should now see the new site added to the search list (and checked). Press Finish.
6. In the subsequent Search Results dialog box, select the checkbox for Android Plugin > Eclipse Integration > Android Development Tools and press Next.
7. Read the license agreement and then select Accept terms of the license agreement, if appropriate. Press Next.
8. Press Finish.
9. The ADT plugin is not signed; you can accept the installation anyway by pressing Install All.
10. Restart Eclipse.
11. After restart, update your Eclipse preferences to point to the SDK root directory ($SDK_ROOT):
1. Select Window > Preferences... to open the Preferences panel. (Mac OS X: Eclipse > Preferences)
2. Select Android from the left panel.
3. For the SDK Location in the main panel, press Browse... and find the SDK root directory.
4. Press Apply, then OK

Seems to be all well and good. Went off without a hitch, except...

After the "Press Apply..." part of step 11 substep 4, I get the following:

Now that's interesting. Grabbing info about "active usage" and "which tools are most popular" is fine, but if I start getting targeted ads in my IDE I'm gonna be pissed.

Coming up next: okay, it's installed, so now what?

There seems to be some reticence brewing on the developer side over adoption of Android. Zdnet is reporting on the issue.

What it basically comes down to is fragmentation of the market. As MobiTV CTO Kay Johansson says in the piece, “Right now, Android just adds to the headache of developing different versions of our applications for different operating systems.”

On the PC side, the Microsoft and IBM-compatible (remember when they were called that? Now it's known as x86) combo standardized the platform, for better or worse. This means that a developer can write for Windows and be sure that the vast majority of users will be able to run the software without any additional development work.

Of course the Mobile phone market is different. We have Symbian, Palm, Windows Mobile, Java mobile (sucks!), etc. On the mobile LINUX front there are a number of initiatives: LiMo, OpenMOKO, Ubuntu Mobile and Embedded, Qtopia. It's ugly out there. This is undoubtedly the prime impetus for Google's move in forming the alliance and releasing Android: an attempt to standardize. Whether it succeeds of fails in that goal is what make Android either an industry-changing product or just another mobile OS.

David Herron has a thought-provoking post on his blog over at java.net, in which he shines a light on a potential pitfall with the Apache licensing Android will use.

As many analysts have pointed out, the advantage of the Apache license over the GPL is that it will allow developers to adapt Android code without being forced to give the changes back. This is obviously attractive to members of the OHA beholden to the proprietary software model.

But as David points out:

...what good is an "open platform" (as Android calls it) when customers can't be assured their app is going to run on any random instance of that platform? That is.. suppose Google/Android is successful and there's a couple dozen OHA phones out there. If each vendor is free to remove features and mix and match features, that leads directly to incompatibilities. That leads to an Aunt Millie who gets an OHA phone and wants to install OHA software which then doesn't run because there is no compatibility. What good is that?

Of course, by fragmenting the software in this way vendors are also giving up some of what would make Android attractive to the consumer. If a handset vendor, for example, implements some nifty new functionality that, as a side-effect, renders a certain class of third-party apps incompatible then a consumer looking for a widely-compatible platform might look elsewhere, to a different Android implementation.