To view parent comment, click here.
To read all comments associated with this story, please click here.
Except that Java *itself* is fragmented, and is not interoperable with itself. Afterall, the APIs available to a J2ME developer are not the same APIs available to a J2SE developer, which are not the same APIs available to a J2EE developer. And that is all Oracle's (originally Sun's) doing!
The problem with Oracle's entire case against Google/Android is that they keep changing their demands/arguments. They don't actually have a case, which is why they keep changing their demands/arguments.
Reading through the Groklaw coverage of the case, it's amazing it even made it to court, let alone made it through the complete trial. There was never any possibility of Oracle winning. Their lawyers and arguments were specious at best, and downright wrong most of the time.
I think Oracle is not right on that. If people write an Android application they write an Android application using the Android API's which are not available in Oracle JVM nor outside of Android. As such such applications are 100% Android and 0% Oracle Java.
The language is irrelevant. It could have been C++, Javascript or C#. It's irrelevant cause both languages are *NOT* compatible cause of the different API's and packages. You just cannot run an Android application with Oracle Java.
cdude,
"As such such applications are 100% Android and 0% Oracle Java."
"The language is irrelevant. It could have been C++, Javascript or C#. It's irrelevant cause both languages are *NOT* compatible cause of the different API's and packages."
The thing is, android does use the Java language plus it's APIs, even though they reimplemented everything in the back end. Oracle's case was about how android derives from Java's APIs, which is true, but the court ruled that it doesn't matter.
Edit: You raised the issue that google's Java implementation bytecode isn't compatible with Java's official bytecode. That may be true (although the existence of a bytecode translator makes it somewhat less true), but I don't think it's relevant. Consider a C++ program that uses the STL APIs, this program can be compiled for Linux (PPC/ARM/x86/x86-64), windows, SunOS, etc. Now would you admit that these all share the same API even though they're not binary compatible?
This was the right ruling, in my opinion. If we're not permitted to re-implement APIs, then 3rd party software implementations could be prohibited from being compatible with defacto proprietary standards (Mono, Wine, ReactOS, Samba, etc). The ruling in this case was very narrow, but it did set the right precedent.
Edited 2012-06-02 01:25 UTC




Member since:
2011-01-28
I think Oracle are absolutely right in claiming that android's API fork has caused java platform fragmentation. However I think this fragmentation argument shows just how desperate Oracle are here. API's are not copyrightable, and yet a clone of the APIs are in violation of copyright law because they fragment the market? Seriously?
I'd like to try that one myself: Your honour, the defended have not violated our copyrights per say, but their clone has fragmented our market you see? Here we have some charts to prove it too. Here we have a laptop running defrag to demonstrate just how bad fragmentation is...