
No Java 7, The End Game - jancona
http://www.jroller.com/scolebourne/entry/no_java_7_the_end
======
mcantelon
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
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.

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

~~~
zmmmmm
I'm not so sure.

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.

~~~
technomancy
> AFAIK all those other languages only run on Dalvik by first being compiled
> to Java byte code format

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.

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

~~~
bad_user
.NET can even act as a direct replacement, because .NET's type-system is a
superset of Java and because of <http://www.ikvm.net/>

(because of it, projects like Eclipse and Apache Derby have been seen running
on top of Mono :))

------
nathanb
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
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
Not seeing anything specific about 'no java 7' - did I miss it in the article?

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

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

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

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...](http://www.androlib.com/android.application.com-nethackff-zzxC.aspx)

GUI for Nethack is nonexistant, but logic isn't trivial.

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

~~~
thesz
>Statically typed code is only type-safe as long as you don't use any meta
programming techniques.

MetaOCaml: <http://en.wikipedia.org/wiki/Objective_Caml#MetaOCaml>
TemplateHaskell:
[http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/temp...](http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/template-
haskell.html) "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...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.3609)

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.

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

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

------
d0m
java 7 is called clojure

