No Java 7, The End Game
jroller.com
jroller.com
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.
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.)
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.
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)