top | item 1782045

No Java 7, The End Game

107 points| jancona | 15 years ago |jroller.com | reply

50 comments

order
[+] mcantelon|15 years ago|reply
Seeing as Google has its own Java-like VM, what would stop Google from creating its own spec and Apache, and the rest of the Java community, following this spec? Can Oracle's patent arsenal stop the Java community from forking?
[+] zmmmmm|15 years ago|reply
Yes. I can't help thinking that if I was Google, I would be working on an alternative language that compiles directly to Dalvik bytecode as fast as I could. Heck, I'd probably just be grabbing something like Go and throwing 10 pHDs at it.

This would help them in many many ways. Firstly it would demonstrate to the courts that Dalvik is not specifically a Java VM. This clears them of several legal challenges (still leaving some).

Secondly and more importantly, it would up the stakes with Oracle tremendously. Having Google actually abandon Java on Android due to legal concerns would be a huge blow to Java. Especially if Google did so in a way that enabled existing Java applications to be ported easily (by adopting the Apache Harmony libraries, utilizing their existing dexer to enable people to run their existing Java code while picking up Google's replacement language for new code). They'd have to work around any patent violations in the VM which might have some performance impact but I'd still assume it is possible.

It would basically change the game to a lose-lose proposition for Oracle - win the court case, get some money, but lose Java. Lose the court case, effectively still lose control of Java.

[+] davisp|15 years ago|reply
Let me preference this as I'm not a Java guy, but I've been reading a bit since Oracle filed suit because of the ASF angle.

From what I understand, the Apache Harmony project was doing a clean room implementation of the Java standard library. There was a clause somewhere (I haven't researched the exact text of this) that said something along the lines of "You must pass the TCK (Java's language test suite sort of like rubyspec http://rubyspec.org/) to be a 'compatible implmentation'," or some such.

Apache Harmony people started writing code and when it got time to say, "Ok, can we have the TCK to validate this?" Sun said, "Yes, as long as you promise no one will run your shit on mobile phones."

If you know the ASF, this sort of thing is wildly against their core mission: to make unencumbered software. So they gave Sun-Now-Oracle the finger.

Now, we need to cover a few bases here. Apache Harmony is not a VM, its an implementation of the standard library. The patent issues Oracle sued over were related to the Dalvik VM. The important point here is that the Dalvik VM is not Java. Its an interpreter for byte code. The byte code that runs on Dalvik will not run on any other VM. People think that Android Java is Java, but its not. Android Java is Java that's been compiled to JVM bytecode and then been translated to Dalvik bytecode (again, IIUC).

The basic point is that 'The Java Language' is not a JVM. It is not a standard library. But there's some weird ass 'Certified Java' thing that can't be obtained unless you give up rights, even though Java is open source.

My reading of this IBM/Oracle tryst is that IBM decided that it could get a "TCK certified" Java implementation by backing OpenJava.

Which is a long way of saying, no, Google/Apache probably can't just create a new Java spec. The JCP et al will prevent such things. Perhaps they could fork and make a RangerRick language that was source level compatible, but something tells me these people employ too many lawyers for that to go over well.

[+] jsankey|15 years ago|reply
Google's Dalvik VM is specifically designed for mobiles. Presumably a lot of the engineering trade-offs made in light of that would make Dalvik relatively weak on servers. So I'm not sure Dalvik would be a great starting point for Google to fork Java.

Having said that, Google are heavily reliant on the Java platform, so they must have at least considered how they can protect the platform if necessary. Could they fork OpenJDK? Or at least support a fork? They certainly have the resources to do it, and Oracle's early moves don't bode well for a cooperative solution, so I wouldn't be surprised. Perhaps they will use the current litigation as a test re: the possible patent issues, although by the time that is resolved it may be too late to make a move...

[+] cletus|15 years ago|reply
Oracle's patents and trademarks.
[+] tungwaiyip|15 years ago|reply
Microsoft did that years ago. And that was widely decried as a move to fragment and subvert the Java community. What's the difference for Google to do this?
[+] invisible|15 years ago|reply
To me (and IANAL), this sounds like a stern response to Google's claims that Sun/Oracle are supporting such projects (not a very good response, mind you). It is a shame that it has to play out this way, but it seems Oracle thinks this is in its best interests somehow. Maybe destroying Java is somehow beneficial to them (I have no idea how besides getting rid of the responsibility)? Does Java-as-a-product have a positive cash flow?
[+] wheels|15 years ago|reply
Oracle relies heavily on Java for their enterprise products (including the custom business logic that their consultants write for customers). Oracle has a deep vested interest in Java, however, so do their competitors. They may just be trying to put it on a shorter leash.
[+] nathanb|15 years ago|reply
Java has been on life support for a while now. The majority of the "innovation" over the last few major(!) releases has been playing catchup with other languages, other virtual machines, and other bytecodes. If C# hadn't played the Firefox to Java's IE, I'm not convinced that many of Java's linguistic advances would have ever seen the light of day.

Perhaps the single greatest contribution of Java has been limiting the impact of poorly-written Visual Basic applications on the business software landscape, though the alternative it provides is poorly-written Java applications, which in addition to being slow, unmaintainable spaghetti code look visually distinct enough from each platform's native widget set to be jarring.

I have little experience with mobile development so perhaps this is a monumentally bad idea, but a set of well-defined APIs, a clean windowing and widget layer with its own APIs, and native bindings for a handful of the more popular languages (Python, Ruby, C++) plus perhaps one or two more specialized languages the platform developers want to support (Clojure/Scheme/CL, Go) would provide enough flexibility to let developers do what they want.

(Although come to think about it this seems to be the approach that Maemo used, and that platform never saw the uptake I thought it deserved. So I'm probably relying on wishful thinking rather than actual reality.)

[+] rbranson|15 years ago|reply
I agree with you, the greatest part about Java and it's ecosystem is that it somewhat minimizes the impact terrible developers can have. That's why it's such a superstar in the corporate world where you rarely get to pick and choose.
[+] mgkimsal|15 years ago|reply
Not seeing anything specific about 'no java 7' - did I miss it in the article?
[+] wmf|15 years ago|reply
It's explained in a previous entry: http://www.jroller.com/scolebourne/entry/no_more_java_7 TLDR: He theorized that Sun was planning to avoid claims of standards hypocrisy by never submitting the Java 7 spec for standardization in the first place.

It didn't quite play out that way, but it will be interesting to see what kind of non-reform reform Oracle has planned for the JCP.

[+] fauigerzigerk|15 years ago|reply
It seems Google has a problem on their hands. If I undstand it correctly, Android relies on the Harmony implementation of the Java standard library. So Google will now have to carry those libraries forward on their own.

What I don't quite get is why Google isn't just using V8 to power Android apps. Also, why isn't Android apps development more like writing Chrome extensions?

The main attraction of Java on Android is that so many people know Java. However, a lot of poeple know JavaScript as well, particularly those involved in client side programming. So replacing Java with JavaScript on Android seems like a no-brainer to me. (The threading model might be an issue)

Replacing Java with Go would be more interesting to me personally, but it's a stretch as very few people speak that language yet.

[+] thesz|15 years ago|reply
I think Java in the sweet spot between program reliability and developer availability. A developer can prevent most variants of uninteresting errors using Java, yet there are many developers.

Android apps works "in the distance" - developer cannot load REPL and fix it while client is on the phone with technical support. So you need pretty solid language, one that helps fixing bugs before they hit customer. Or, at least, a pretense on that.

More solid languages, like Haskell, Coq and Agda2, just do not have enough developers.

Go is good, at least as good as Java, but it also doesn't have big enough community.

[+] signa11|15 years ago|reply
and ... steve-jobs is laughing all the way to the bank
[+] d0m|15 years ago|reply
java 7 is called clojure