No Java 7, The End Game

http://www.jroller.com/scolebourne/entry/no_java_7_the_end

by jancona • 16 years ago

107 50 16 years ago

mgkimsal• 16 years ago

Not seeing anything specific about 'no java 7' - did I miss it in the article?

wmf3• 16 years ago

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.

mcantelon• 16 years ago

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?

cletus• 16 years ago

Oracle's patents and trademarks.

rbanffy• 16 years ago

And their army of lawyers.

jsankey• 16 years ago

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

wmf3• 16 years ago

Given that Dalvik is designed to run multiple Java processes with low memory overhead and fast startup, it might actually be pretty great for PaaS like, say, App Engine. That's just speculation, though.

bad_user3• 16 years ago

I don't think there's anything in Dalvik's bytecode that's specific to servers, and so they could have 2 versions of the VM: one for mobile phones, and one for the desktop/server.

If they'll release specs for Dalvik, make it a standard somehow, I'm pretty sure Apache will help.

zmmmmm2• 16 years ago

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.

technomancy3• 16 years ago

> Firstly it would demonstrate to the courts that Dalvik is not specifically a Java VM.

This is already pretty clear; you can run Lua, Scala, Javascript, Scheme, Ruby, and many other languages on Dalvik.

mhw• 16 years ago

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

Swapping the language out is probably the smaller part of the problem. The dependency that every application has on the Java-based runtime libraries are the bigger problem.

> Heck, I'd probably just be grabbing something like Go and throwing 10 pHDs at it.

Go already has a working ARM code generator, so you could potentially skip the Dalvik step completely and ship native code. I think you'd still need to put some effort into building a set of Android libraries for Go though.

anonymous245• 16 years ago

Why do you think Google picked Java in the first place (and not a "really" open language like C++, Javascript, or Python)? To appeal to as many developers as possible on Day 1.

Further, Google as a company seems to have drunk the Java Kool-Aid (e.g., Closure compiler is written in Java, GWT uses Java as source language, and I hear Java is one of the three "blessed" languages (others being C++ and Python)). Personally, I think C++ would have been a better choice for the first project, and Python for the second one.

It's highly unlikely they're going to stop using Java on Android.

davisp• 16 years ago

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.

wmf3• 16 years ago

You're mostly right on, but IBM's proprietary J9 JVM has been TCK certified for years. Given that there are two open-source JVMs and one is clearly winning and the other is clearly losing (forever), IBM decided to switch to the winning team (even though open-source Java is kind of a "hobby" for IBM).

davidw• 16 years ago

> Apache Harmony is not a VM, its an implementation of the standard library.

Harmony is a full implementation, which means that there's a VM too. Google didn't use it in Android, though.

bad_user3• 16 years ago

> Apache Harmony is not a VM, its an implementation of the standard library.

It's both, and Harmony is an implementation of Java SE.

Also note the following quote from JSR 270:

"""Nothing in the licensing terms will prevent open source projects from creating and distributing their own compatible open source implementations of Java SE 6, using standard open source licenses."""

That's a broken promise, although I don't think it is legally binding because the term "open source license" they could argue it is something that comes with code (since the trademark for "open source" could not be obtained by OSI).

But for me as a Java user, a broken promise is a broken promise.

I never viewed Java as being a dangerous platform, not even when OpenJDK didn't exist. That changed.

tungwaiyip• 16 years ago

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?

d0m• 16 years ago

java 7 is called clojure

invisible• 16 years ago

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• 16 years ago

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.

ShardPhoenix• 16 years ago

Considering the obvious alternative to Java (for the sort of large company that still heavily uses Java) is C# and the Microsoft stack, Oracle ought to be careful not to even wound Java too much, and certainly not kill it.

signa11• 16 years ago

and ... steve-jobs is laughing all the way to the bank

fauigerzigerk6• 16 years ago

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.

thesz3• 16 years ago

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.

fauigerzigerk6• 16 years ago

So your case is resting on the assumption that JavaScript programs are less reliable than Java programs. That's a pretty bold claim to make in general and particularly for the kind of smallish UI centric code we're talking about.

nathanb• 16 years ago

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• 16 years ago

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.

No Java 7, The End Game

Related Stories