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.
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?
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...
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.
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.
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.
A "JVM" is not a Java language interpreter anyway but a Java byte code interpreter. AFAIK all those other languages only run on Dalvik by first being compiled to Java byte code format, thus it is arguable that they are all "Java" as far as the VM goes.
What Google needs is something that compiles directly to Dalvik's own native format which has no "Java" at all in the pipeline.
Anyone care to explain the downvotes? The poster I replied to claimed that Dalvik is different because people target different languages at it. Not only do people do this for the JVM, I think it was probably the first VM where people did this.
things that will get you downvoted include statements like "wtf, you apparently don't know..."
1) impolite.
2) your comments should concentrate on what you can add to the convo, not what others haven't.
I mean, it also doesn't help that your statement was incorrect (P-system as mentioned), but being rude in what is ideally a civil forum dedicated to a stated purpose is not helpful.
> The poster I replied to claimed that Dalvik is different because people target different languages at it
Reading comprehension, bro. Give it a try.
The Dalvik VM, like the Java Virtual Machine, is quite capable of running languages that aren't Java. There's nothing controversial or incorrect about that statement.
> 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.
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.
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.
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).
> 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.
Well, it's got a new steward, Oracle, that's not exactly engendering trust in certain areas such as hemorrhaging key employees and suing Google's Dalvik using VM patents (and the company does not exactly have a nice reputation). Plus as the grandparent noted, Sun's broken promise is clearly going to stay broken and I'll note that various Oracle positions have completely changed now that they own Java(TM).
On the other hand, one might say that shedding some of these employees is OK or better and finally getting decisive on moving forward on Java 7 is good ... and the two might not be entirely unrelated.
I don't know the inside story and who's to blame, but it's patently obvious that Sun's stewardship of Java was serious failing at the time of the acquisition and for some time before then. Java 7 wasn't converging on getting finished in the foreseeable future and as I understand it the JCP process wasn't being used for it. Note that in a couple of months it will have 4 years since the release of Java SE 6 (prior to 7 the releases 3 through 6 each took 2 years (http://en.wikipedia.org/wiki/Java_version_history)).
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?
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?
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.
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.
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.
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.
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.
They certainly require more effort from developer to be as reliable as programs on statically typed languages. Compare theoretical absence of certain errors (typos, for example) with probable absence of them.
All my friends who happen to write some substantial code in Javascript now search for translators to Javascript from other languages and lints and typecheckers for Javascript programs. Number of those my friends is about four, but they are unanimous.
Statically typed code is only type-safe as long as you don't use any meta programming techniques. But that means you have to write and test much more code. More code means more errors. Also, being forced to test more may cause dynamically typed code to be more reliable at the end of the day. But that's all speculation. I don't think we have any empirical evidence on that and hence I disagree with the general claim that dynamically typed languages are less reliable.
I write mostly statically typed code and I do appreciate what the compiler does for me. Also, I find statically typed code more readable and self-explanatory sometimes. It's ultimately faster as well. It's a tradeoff though, and since JavaScript is already present on mobiles anyway, I don't see the advantage of adding yet another VM.
The MetaOCaml example is certainly interesting but what it does is increase speed, not reliability. In this case, the type (in some general sense) of n is known at compile time, so the compiler can guarantee that whatever is generated at runtime conforms to that type.
But that's not the type of meta programming that depends on runtime discovery of entirely new information, say, an ORM that discovers changes in the database schema. That's the type of meta programming that made Rails so popular and productive (and slow) for some cases. Obviously, it is impossible to provide compile time guarantees about something that is unknown at compile time.
But I tend to agree with you that it is desirable to have correctness proofs at compile time wherever possible.
'They certainly require more effort from developer to be as reliable as programs on statically typed languages. Compare theoretical absence of certain errors (typos, for example) with probable absence of them.'
Just because some JavaScript implementations don't provide compile-time reference checking and type inference, doesn't mean it's not possible, or even particularly hard. See for example the kinds of warnings SBCL provides at compile time (they are not far off from the stuff you'd see from a Java compiler). People have been writing very large, reliable programs in Lisp for 40 years now.
Java's type system is completely broken (what else do you think the implication of having every type be "or null" is?) - in practice this means the difference in number of errors stemming from bad types between Java and programs written in dynamically typed languages is much less than you think. The way forward is languages with a logically sound type system that supports inference and polymorphism (and today this means Haskell or ML and derivatives).
In the hands of a really capable developer, JavaScript can be used to engineer reliable, complex systems. Sadly, most people who write software for a living are not "really capable", so the extra safety net provided by compile-time type checking and good IDE support that comes with Java tends to outweigh the concision and flexibility of a dynamic language like JavaScript.
Also, while V8 is quite heavily optimized for performance on modern PCs, I haven't seen much to support the idea that it is a great fit for memory and CPU-constrained mobile devices. Early versions of Dalvik specifically traded runtime compilation (as implemented in HotSpot and most other modern JIT-ing JVMs) for ahead-of-time in order to minimize the memory footprint of applications. Any VM designed around heavy runtime optimization (like a mobile V8 derivative) would have to be carefully tweaked to not thrash horribly given the memory constraints on most smartphones.
I don't see that optimizing the V8 JIT for that purpose would be more difficult than creating an entirely new VM. Actually I think that V8 is used in Android anyway.
I don't have anything new to add to the age old debate about dynamic vs static typing in general. I'm not firmly in one or the other camp on this one. I just don't see the empirical evidence for the much touted greater reliability of statically typed languages (nor for the equally much touted greater productivity of dynamically typed languages)
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.)
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.
51 comments
[ 4.5 ms ] story [ 119 ms ] threadIt 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.
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...
If they'll release specs for Dalvik, make it a standard somehow, I'm pretty sure Apache will help.
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.
This is already pretty clear; you can run Lua, Scala, Javascript, Scheme, Ruby, and many other languages on Dalvik.
A "JVM" is not a Java language interpreter anyway but a Java byte code interpreter. AFAIK all those other languages only run on Dalvik by first being compiled to Java byte code format, thus it is arguable that they are all "Java" as far as the VM goes.
What Google needs is something that compiles directly to Dalvik's own native format which has no "Java" at all in the pipeline.
You seem to think the JVM bytecode format is specific to the Java Programming Language™; why is this?
Admittedly Sun has muddled things up here by using the word "Java" to mean many separate things.
1) impolite. 2) your comments should concentrate on what you can add to the convo, not what others haven't.
I mean, it also doesn't help that your statement was incorrect (P-system as mentioned), but being rude in what is ideally a civil forum dedicated to a stated purpose is not helpful.
Reading comprehension, bro. Give it a try.
The Dalvik VM, like the Java Virtual Machine, is quite capable of running languages that aren't Java. There's nothing controversial or incorrect about that statement.
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.
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.
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.
Harmony is a full implementation, which means that there's a VM too. Google didn't use it in Android, though.
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.
On the other hand, one might say that shedding some of these employees is OK or better and finally getting decisive on moving forward on Java 7 is good ... and the two might not be entirely unrelated.
I don't know the inside story and who's to blame, but it's patently obvious that Sun's stewardship of Java was serious failing at the time of the acquisition and for some time before then. Java 7 wasn't converging on getting finished in the foreseeable future and as I understand it the JCP process wasn't being used for it. Note that in a couple of months it will have 4 years since the release of Java SE 6 (prior to 7 the releases 3 through 6 each took 2 years (http://en.wikipedia.org/wiki/Java_version_history)).
(because of it, projects like Eclipse and Apache Derby have been seen running on top of Mono :))
Now it's not quite as clear cut, depending on Oracle's actions going forward.
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.
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.
All my friends who happen to write some substantial code in Javascript now search for translators to Javascript from other languages and lints and typecheckers for Javascript programs. Number of those my friends is about four, but they are unanimous.
Also, smallish UI centric code is just one case of Android apps. Nethack, for example, you can't call it small and UI-centric: http://www.androlib.com/android.application.com-nethackff-zz...
GUI for Nethack is nonexistant, but logic isn't trivial.
I write mostly statically typed code and I do appreciate what the compiler does for me. Also, I find statically typed code more readable and self-explanatory sometimes. It's ultimately faster as well. It's a tradeoff though, and since JavaScript is already present on mobiles anyway, I don't see the advantage of adding yet another VM.
MetaOCaml: http://en.wikipedia.org/wiki/Objective_Caml#MetaOCaml TemplateHaskell: http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/temp... "A Verified Staged Interpreter is a Verified Compiler (Multi-stage Programming with Dependent Types)": http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.3...
I think that metaprogramming techniques would only gain from strong types.
I don't agree with most points of your comment, but I do not think I have strong arguments against.
But that's not the type of meta programming that depends on runtime discovery of entirely new information, say, an ORM that discovers changes in the database schema. That's the type of meta programming that made Rails so popular and productive (and slow) for some cases. Obviously, it is impossible to provide compile time guarantees about something that is unknown at compile time.
But I tend to agree with you that it is desirable to have correctness proofs at compile time wherever possible.
Just because some JavaScript implementations don't provide compile-time reference checking and type inference, doesn't mean it's not possible, or even particularly hard. See for example the kinds of warnings SBCL provides at compile time (they are not far off from the stuff you'd see from a Java compiler). People have been writing very large, reliable programs in Lisp for 40 years now.
Java's type system is completely broken (what else do you think the implication of having every type be "or null" is?) - in practice this means the difference in number of errors stemming from bad types between Java and programs written in dynamically typed languages is much less than you think. The way forward is languages with a logically sound type system that supports inference and polymorphism (and today this means Haskell or ML and derivatives).
Also, while V8 is quite heavily optimized for performance on modern PCs, I haven't seen much to support the idea that it is a great fit for memory and CPU-constrained mobile devices. Early versions of Dalvik specifically traded runtime compilation (as implemented in HotSpot and most other modern JIT-ing JVMs) for ahead-of-time in order to minimize the memory footprint of applications. Any VM designed around heavy runtime optimization (like a mobile V8 derivative) would have to be carefully tweaked to not thrash horribly given the memory constraints on most smartphones.
I don't have anything new to add to the age old debate about dynamic vs static typing in general. I'm not firmly in one or the other camp on this one. I just don't see the empirical evidence for the much touted greater reliability of statically typed languages (nor for the equally much touted greater productivity of dynamically typed languages)
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.)