

Oracle VP: “We have a strategy to run Java inside a Javascript environment” - pepijndevos
http://cemerick.com/2010/12/12/oracle-vp-we-have-a-strategy-to-run-java-inside-a-javascript-environment/

======
raganwald
"We have a strategy to promise that everything and anything provided that
there is no firm specification or explanation and provided that we provide no
date for implementation.

"This gives our customers a sense of security that if anything should happen
to become important in the future, they will have purchased from a vendor that
has a vision for embracing the technology even if there is no roadmap for
actually implementing the technology.

"And although they may not ever end up benefitting from the technology, their
careers are safe because they made a decision that, at the time, was prudent,
namely to standardize on a technology that was thought to be on its way to
becoming ubiquitous from a vendor that articulated a strategy for achieving
ubiquity."

tl;dr: "F.U.D."

~~~
cemerick
Where is that from? That's not in my post, and not in the podcast transcript…

~~~
raganwald
Oh? Gosh, I must have misread it. I admit I was in a hurry, and what he said
sounded _so much_ like what other proprietary enterprise vendors say when
promising vaporware that I got the exact wording confused.

UPDATE: Look, I am _NOT_ making fun of your post in any way. I think it's fair
game to poke a little at his comments given that there has been no other
mention of this, no roadmap, nothing. But I respect your post and the fact
that you pushed a little further and tried to find some corroboration for his
statement.

I'd like to think that _somewhere_ in Oracle-land, there's a white paper from
the Sun days talking about this idea, and maybe they're even trying to make it
fly right now. And good job teasing that out and asking some intelligent
questions about what it may mean.

~~~
cemerick
I'm hardly an Oracle (née Sun in this context) booster; i.e. as a Clojure
partisan, I'm all too aware of the benign neglect that comes with using the
JVM but not Java, and with vaporware (JWebPane, anyone?).

All that said, I'm happy enough to be Charlie Brown and take a run at this
football. Cynicism leads to either resigning myself to using Javascript
forever for client side stuff, something I just couldn't swallow
psychologically.

~~~
aaronblohowiak
Why do you hate JavaScript so much? You can thoroughly ignore all notions of
classes and use it as a lesser scheme.

~~~
cemerick
Javascript is a _bad_ language with poor libraries, and I'm _forced_ to use
it. I've said before: if it weren't for its distribution, it simply wouldn't
be used. If given other choices (emphasis on the plural there), not one
developer would opt for Javascript.

"The good parts" of Javascript get a lot of play, but I don't want to have
cope by using patterns and avoiding the dull, broken bits that go along for
the ride...and I'm surprised that many (most?) other competent developers that
wouldn't put up with such compromises in their "real" languages aren't as
irritated about Javascript as I have been.

~~~
somnium
Some percentage of developers do choose Javascript among multiple choices:
[http://en.wikipedia.org/wiki/JavaScript#Uses_outside_web_pag...](http://en.wikipedia.org/wiki/JavaScript#Uses_outside_web_pages)

~~~
detst
Stockholm syndrome?

------
endtime
Umm...are there any reasons, other than the JVM, to use Java? I'd much rather
write plain old JS (or even better, CoffeeScript) than Java any day.

~~~
Locke1689
I don't know but this trend of making Javascript a compilation target is
making me want to shoot myself (from a compiler-design perspective).
JVM->Javascript seems like they're begging me to head over to Oracle and
scream "Guys! You're going the WRONG WAY!"

~~~
cemerick
Javascript's absolutely ubiquitous distribution characteristics have resulted
in all sorts of irrational behaviour.

If the W3C or the browser makers collectively had put some thought into making
it possible for other languages to be linked into the client in a sane way
(i.e. rather than the existing plugin regime), or defined some proper IL that
app authors could compile to, Javascript wouldn't be on its way to being the
compilation target for the web.

~~~
azakai
You make it sound like they were incompetent, lazy or evil. Or perhaps I
misunderstood you, sorry if so.

But the fact is, they _did_ think a lot about using other languages on the
web, and about proper ILs as well. The fact is, there has been no good way to
do either, _if_ you want a standards-based platform with multiple compatible
implementations.

You can take some existing IL like Java bytecode, but (1) that stuff is
patented, and (2) there is no hope of cross-vendor agreement on what that IL
should be, and all of them have various issues anyhow (for example, Java and
.NET bytecode were designed with static languages in mind).

JavaScript is winning simply because it's there, it works, and everybody
supports it. Yes, it has frustrating limitations, but it's hard to see a
practical alternative. We will simply need to overcome those limitations - and
that is possible.

~~~
cemerick
That was perhaps a little harsh in the phrasing; I wasn't really implying any
of those things. I think I am saying that this appears to have been a blind
spot on the part of the web standardization crowd and the browser makers.
Maybe I'm entirely wrong though, and there were efforts that simply hit hard
problems, as you say.

I'd never heard of any discussions around determining a proper IL, though; if
you can, a link so relevant MLs and such would be most appreciated.

~~~
azakai
Here's Brendan Eich (creator of JS) talking about something even simpler, a
bytecode standard for JS in browsers,

<http://www.aminutewithbrendan.com/pages/20101122>

and here is him talking on HN about JS vs Python, Lua etc. in browsers,

<http://news.ycombinator.com/item?id=1905155>

~~~
cemerick
Many thanks for those. I obviously haven't digested them yet, but I will.

------
zmmmmm
I started out writing about how I thought this was insane and by the end of it
I had changed my mind and - suspending disbelief and assuming they can pull
this off in a reasonable and performant manner - it's actually a pretty clever
idea.

Now that Apple, Google and Microsoft have all put the nail in the coffin of
applets by not supporting them on their mobile devices Java is looking
decidedly shaky as a client side browser technology - especially when you
consider that Flash IS shipping to most devices. However Oracle can actually
one-up Flash here if they can promise to run inside the browser on any
platform. Not too long ago it would have been impossible, but with things like
Canvas, WebWorkers and WebSockets they can probably make a reasonable stab at
implementing at least the functions of a standard Applet with Javascript.

~~~
duskwuff
Java as an applet host has been effectively dead for years. I would be _very_
surprised if Oracle were trying to resurrect that. Seems more likely that
they'd be trying to replace the server JRE with a server-side JS interpreter.

~~~
zmmmmm
_Seems more likely that they'd be trying to replace the server JRE with a
server-side JS interpreter_

Unless you're suggesting they are being willfully misleading I'm not sure how
you could interpret that from what they said:

 _...we think it’s something that we need to do for the community so we can
make Java available more places from tablet devices like the iPad ..._

I think Java applets are a lot less dead than people realize. There are heaps
of enterprises that have deployed them for internal apps (essentially a
slightly less evil version of ActiveX). I could easily imagine a lot of these
places now have executives wandering around with iPads complaining that the
payroll app doesn't work on their computer any more.

------
bad_user
Creating something like a VM or a compiler that produces reliable and fast-
enough Javascript from bytecode is hard work, and there is no evidence that it
can be done. Microsoft tried something similar with Volta (project
discontinued) and when I tried it the results where awful, although it was
cool that you could compile CLR bytecode to Javascript:
<http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta>

On the other hand creating something less than Java SE would break
compatibility and it would not be covered by the patents grant, not to mention
difficulties in calling the thing "Java".

Oh wait ...

------
jfb
It's turtles all the way down.

~~~
dstein
Oh the amazing things I could write in JavaScript, inside Rhino, inside Java,
inside JavaScript.

~~~
jfb
This was _exactly_ my thought. Jesus wept.

------
rbanffy
There is a certain amount of cluelessness that, when concentrated inside a
given company, risks starting a runaway chain reaction that ends up destroying
the company and the ecosystem around it.

------
mrleinad
SUP DAWG, WE HEARD YOU LIKE JAVA, SO WE PUT JAVA IN YO JAVA SO YOU CAN EXECUTE
JAVA WHILE YOU EXECUTE JAVA

~~~
hugh3
I'm glad someone else already posted this so I didn't have to sacrifice my own
karma by doing it myself.

~~~
mrleinad
Damn...

------
wmf
For Oracle's sake, let's hope Google doesn't have patents on GWT.

~~~
bad_user
Like a patent on compilers that converts from language A to language B?

No, Oracle has that already.

------
ShabbyDoo
GWT achieves reasonable speed by only supporting a subset of Java which is
already basically compatible with the JavaScript runtime. So, you don't get
things like threads, weak references, etc. To support such things (if it's
even possible) would require writing (at least pieces of) a JVM in JavaScript.
Want weak references? You now can not use JS GC -- you have to synthesize Java
objects and write your own GC impl. Good luck getting that to perform.

------
jcw
No no no no no no no.

