Domain: betaversion.org
Stories and comments across the archive that link to betaversion.org.
Comments · 16
-
Not the whole story
It's unfortunate that Schwartz's blog is gone, and that ZDNet didn't drill down a little more carefully to check dates on things. I was working with Sun on the java.net site at the time, through a contract with O'Reilly. As I recall, the story is actually somewhat worse. The rumor mill reported that Android would be using Java, and Schwartz went off half-cocked and praised Google for the "Java/Linux platform". Writing for java.net, I said "But I didn't end up putting this on the front page, because I just couldn't source the Java angle well enough (no offense, Jonathan, but you did say ZFS would be on Leopard...)." (that's the current editor's headshot on the page, not me, BTW).
Not too much later, Google laid out the details of Android, including the Dalvik VM, which meant that Google was only using Java the language (which it didn't have to license) and not Java the VM (which it would have had to). What I heard through the back channel was that Sun was pissed, believing it had been stabbed in the back. This made for a very awkward scene at Sun's mobile-focused "ME Developer Days" a few months later in January 2008: the Sun people had clearly been told to not talk about Android or acknowledge it in any way, which led of a few awkward moments of dancing around the elephant in the room. The first night of the conference, the Java Posse stopped by for dinner, and upon seeing Dick Wall (who at that time worked at Google), the first thing I said to him was "man, are they pissed at you guys."
Relevant dates and links:
- November 5, 2007 - Google announces Android, doesn't mention Java
- November 5, 2007 - Later that day, Schwartz posts blog praising Android as "Java/Linux platform"
- November 12, 2007 - First release of Android source, Dalvik revealed. This blog, written that day, has a pretty good explanation of the fast one Google pulled on Sun. "How did Google manage to get Sun to license off a platform that could very well kill their own? Turns out, they didn’t: their move was even smarter than Sun’s."
Anyways, assuming my recollection of events and this timeline is accurate, Schwartz's blog should not be taken as an indication that Sun knew about and approved what Google was doing with Android. What it does prove is what a lot of people knew then but wouldn't say: Schwartz was a clueless loud-mouthed buffoon who happily fiddled away on his blog as SUNW burned.
-
Re:moreover it seems to me that google has to lose
You might want to read this fairly old summary of what Dalvik is.
Note this bit:
it just doesn’t compile the java code into java bytecode but (ops, Sun didn’t see this one coming) into Dalvik bytecode.
So, Android uses the syntax of the Java platform (the Java “language”, if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android’s implementation of the Java SE class library is, indeed, Apache Harmony’s!)
The trick is that Google doesn’t claim that Android is a Java platform, although it can run some programs written with the Java language and against some derived version of the Java class library.
-
Re:Why not build upon J2ME then?
This pretty much explains the reasons behind Google's decision to go with Dalvik (well, except the specifics of the failed negotiations over J2ME licensing).
In short J2ME as licensed by Sun/Oracle under the GPL has deliberately had the 'classpath exception' removed. Developers targeting a GPL J2ME are forced to release their code as GPL due to the linking with all of the GPL'd libraries. According to their plan this would make paid J2ME licensing under non-GPL license a the only option for mobile vendors. Sun specifically did this for J2ME and not J2EE or J2SE as this is where they saw the most licensing money.
All this talk of complete implementation getting a patent license is moot it seems. Google decided that the paid licensing from Sun was prohibitive for one reason or another and that forcing the GPL on Android app developers was unacceptable. So when they took the decision to clean-room a VM from scratch any efforts to make the implementation complete would not have been rewarded with a patent grant.
-
Re:Not as clear cut.
"Google went to the effort of developing a clean-room bytecode interpreter so they did not just game the rules as you imply. "
And why did they do that?
Oh yes to get around licensing. I don't care if they made more technical effort to do it, they are still gaming the rules.
The intent of Java has always been to keep it to a standard, and the license is all about not subsetting/supersetting.
Google gamed the rules, told Sun to screw off and will now face Oracle in court.
Instead of abiding by the spirit and intent of the license, Google instead chose to ignore it entirely by exploiting a loophole. After that IMO all bets are off. If Oracle nails them because they didn't carry out their exploit cleanly, just deserts for attempting the exploit.
If Google respected the license they wouldn't be in court.
I understand where you are coming from, but I disagree and hence my point, this isn't as clear cut as SCO vs IBM. I think there will be plenty of people that once they read about how Google attempted to just use a technicality to avoid licensing will see the other side.
BTW when the story first broke, my first reaction was "Those damn Oracle bastards", but after I read some back-story, my opinion changed to Google attempting and exploit here to get out of licensing.
http://news.cnet.com/8301-13580_3-9817048-39.html
http://www.betaversion.org/~stefano/linotype/news/110/ -
Re:documenting it on http://en.swpat.org
and also because Java is licensed under the GPL.
"Java" isn't licensed under the GPL. A single Java implementation, derived from Sun's proprietary source code, is licensed under the GPL. Furthermore, the patent grant applies only if you meet specific compatibility conditions, which no implementation other than Sun's meets.
Google implemented the Java language, not its libraries, and did it by themselves. Android (and Dalvik) are licensed under a mix of Apache and GPL, but that doesn't matter; the license under which a third party implementation is released is not relevant for the patent grant.
Google rolled their own implementation and libraries for good reason: the full Java platform would have been far too obese for Android, and embedded versions of Java aren't free at all.
There is effectively only one Java implementation, the one controlled by Sun/Oracle. Sun killed most of the others early on with legal threats, and the few remaining ones seem to fail to meet the conditions of Sun's public patent grant.
Anybody who writes Java software is pretty much stuck with running it on Sun/Oracle's proprietary implementation or its nominally GPL derivative. You're joined at the hip with Oracle, in the bending over kind of sense.
Almost but not quite , check out this interesting read: http://www.betaversion.org/~stefano/linotype/news/110/
So, Android uses the syntax of the Java platform (the Java “language”, if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android’s implementation of the Java SE class library is, indeed, Apache Harmony’s!)The trick is that Google doesn’t claim that Android is a Java platform, although it can run some programs written with the Java language and against some derived version of the Java class library. Sun could prevent this if they had a patent on the standard class library, but they don’t and, even if they did, I strongly doubt it would be enforceable since Android doesn’t claim to be compatible (and in fact, could very well claim that their subset/superset is an innovation on the existing patent and challenge Sun’s position).
-
Re:They're not using Java
Android has its own VM called Dalvik. You use Java tools to compile to JVM bytecode and then there's a translater to Dalvik bytecode.
Maybe Oracle believe Dalvik implements their patented techniques.
Most are saying that they are going after google's jme which is quite interesting since google built (Dalvik) themselves to get around these licensing issues, although if they did use ip from Sun for Dalvik then maybe they have a case, although only the code will tell. Here are also some interesting reads on the matter besides those in the summary:
-
Re:And Google doesn't get Sued?
My understanding is that Google didn't do it this way just to be different, but rather it was the licensing terms for Java ME that caused the problem. Evidently ME is licensed differently from SE or EE, and Google couldn't use it. Discussed here: http://www.betaversion.org/~stefano/linotype/news/110/
-
Re:Pot. Kettle. Black.
And that's bad for everyone.
Unless you want things to be free.
PS. if you don't get what I'm saying please refer here
-
Re:doesn't sound too secure yet
Two reasons they didn't use a JVM for Android:
1) They started the Android project before Java was open-sourced.
2) Sun has slightly different licenses for desktop and mobile use. The desktop license is GPL with a classpath exception (letting you write non-GPL java apps to run on the virtual machine), the mobile license is straight GPL. Google didn't want to force developers to only produce GPL apps for Android, so they could not use this.
See Stefano's blog -
Re:Slashvertisement
erm.. remember that the low-level Android API is entirely written in C++. And the whole thing runs on Linux.
So your "cross platform" problems are immediately concerned with the APIs Android and Linux gives you, so your C++ apps will be as cross platform as Java. (ie its not the same as running a desktop app on Linux, Windows and Mac - here you're running solely on the Android platform).
Symbian is irrelevant, its the huge amounts of code those Symbian developers have that they want to reuse that matters. If they now have to write the same stuff all over again for Android, they're less likely to do so. Why would any of them bother to port to Android if they already have a huge market for Noika phones? If they could port easily (or semi-easily) then I'm sure they would - the market for Android suddenly increases dramatically. To rewrite in Java means they won't until they see a large market already, and that won't happen if they're not developing for it.
Don't forget that a Java implementation (on mobile) is not as cross platform as you'd think, and mobile phone development is never "it just runs" simply because of the different resources available like screen sizes.
See the link here where he describes one mobile java developer who had to make 100 versions of his java app to make it run on lots of phone models.
I think Android on Linux is a good idea, a common platform and a common API means all the hard porting work is done by the manufacturer. Putting Java on just doesn't make sense when you've got that niceness; and you have a large developer base waiting to port their apps and suddenly finding they can't.
PS. the java used on Android isn't really JavaME, due to Sun licensing. I suppose its a possibility that Google could develop a c++ compiler that turns c++ code into dalvik bytecode, or perhaps (more likely) a C# or VB.NET one. Wouldn't that be fun?.....
-
Re:Android not as openThe native API is Java-based, Android applications run under the JVM, and you can't expect to run anything but Java applications on Android. It's not a "Linux phone", it's a "Java phone" that happens to use Linux in its implementation.
Partly correct, except it won't use the JVM. It will use a different virtual machine called Dalvik, so that they can get around Sun's ridiculous JME licensing, MIDP profiles, and everything else that sucks about running midlets on phones today (such as the overzealous security restrictions that keep me from easily running a program I wrote on my own phone.)
-
Re:Does Sun make any money from Java on phones?I'm not sure what you have to pay, but it is something.
Here's a better article about the same thing. I was wondering if this story was going to get picked up anywhere.
I don't think JavaME will be given away any time soon. It's going to be really interesting to see what Sun does here.
-ec
-
Re:I think I can answer that one...
There will be support for other lanugages. Google created their own open source VM called Dalvik:
"So, Android uses the syntax of the Java platform (the Java "language", if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android's implementation of the Java SE class library is, indeed, Apache Harmony's!)" http://www.betaversion.org/~stefano/linotype/news/110/
I expect to see a c# compiler (http://tirania.org/blog/archive/2007/Nov-13-1.html) and others in due course. -
Re:So... Java... standard APIs... WebKit...
Maybe, if they release the source to their Java based but non-standard Dalvik VM under an open license.
Is the Apache license good enough?
http://www.betaversion.org/~stefano/linotype/news/110/ -
Piggy Bank: Greasemonkey for web data
Piggy Bank promises to turn Firefox into a semantic web browser by providing a means to mine data from web sites and then use that data on other web sites. It's like Greasemonkey for data on the web.
-
Re:Java
And this on the day when Piggy Bank beta was announced. And it uses Java. http://www.betaversion.org/~stefano/linotype/news
/ 89/