JavaScript JVM runs Java

[Derek]

Rather then running new languages on a JVM, how about new languages to
run your JVM?

"
Until recently implementing a JVM in JavaScript would have been
difficult because of efficiency problems but there have been huge
speed increases in JavaScript engines. So much so that a lone coder,
Artur Ventura, has implemented a large part of the standard JVM using
JavaScript and you can check the code out on Github.

The motivation for this effort is put very well in Artur's blog. He
argues that rather than build JavaScript into web browsers they should
have a virtual machine so that any language can be used. As well as
this advantage, he also points out that with a JVM type approach you
get automatic sandboxing and simply sending the JVM to the server
provides browser independent persistence.

It really does make much more sense to have a JVM build into the
browser but failing that why not simply emulate the JVM in JavaScript
which is built into every browser. This is just another aspect of the
steady conversion of features provided by plugins to JavaScript
implementations - codecs, pdf, zipping and so on.

After 6 months of work the result is BicaVM which, it is claimed, runs
60% of byte code. It hasn't been optimized as yet, but it does run on
the iPad/iPhone and it supports a JNI interface to the DOM.
"

Blog Post: http://www.surf-the-edge.com/2011/11/15/bicavm-jvm-in-javascript-why/
Source: https://github.com/nurv/BicaVM

Via http://www.i-programmer.info/news/167-javascript/3360-javascript-jvm-runs-java.html
Via: http://developers.slashdot.org/story/11/11/21/0454254/javascript-jvm-runs-java

[Fabrizio Giudici]

On Wed, 23 Nov 2011 08:14:25 +0100, Derek <derek....@gmail.com> wrote:

> It really does make much more sense to have a JVM build into the
> browser but failing that why not simply emulate the JVM in JavaScript
> which is built into every browser. This is just another aspect of the
> steady conversion of features provided by plugins to JavaScript
> implementations - codecs, pdf, zipping and so on.

Well, definitely it makes some sense. I'm not worried by the speed,
because I understand it can be interesting; the real problem is how much
traction the project will have and so how many things it will support. For
instance, just manipulating the DOM in Java doesn't make a lot of sense.
It would make sense to run JavaFX, for instance, but this - in addition to
the bytecode translation - would require mapping graphics to HTML 5,
etc... which is a project per se. BTW, if I don't recall bad, once upon a
time a JavaFX to JavaScript translation was in the plans of Sun... but I
lost track of it.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Jan Goyvaerts]

Isn't this also called the Java Plugin ? :-P Just kidding of course...

But this is a deja-vu situation from a decade ago of running applets - because then you have exactly the same advantages: Sandboxing, browser-independent, etc... 

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Fabrizio Giudici]

On Wed, 23 Nov 2011 09:02:53 +0100, Jan Goyvaerts <java.a...@gmail.com>
wrote:

> Isn't this also called the Java Plugin ? :-P Just kidding of course...
>
> But this is a deja-vu situation from a decade ago of running applets -
> because then you have exactly the same advantages: Sandboxing,
> browser-independent, etc...

I seem to have seen drawing pixels to a canvas too, but in spite of that
it's "new" thing in HTML 5 :o)

Unfortunately, we're seeing reinventing wheels all the way...

[Carl Jokl]

I hope it is a positive thing that someone else feels the same about having a VM in the browser that can be targeted instead of relying only on JavaScript. I think I have mentioned the idea in the forums before though.

Despite it being fairly sound technology wise I have a feeling it will get blocked by individuals with their own political agendas for not wanting it.

I also think the current push to get rid of all plugin technology is probably going to get traction. The problem is that I think the plugin technology will get abandoned to appease the current mentality of the leaders in Web development. However I think that the replacement will be a much more inconsistent across browsers than the plugin based solutions were and probably be lacking in key functionality that the plugin solutions could do but we will be pushed to accept this for the 'greater good'.

Many browsers tout that they support HTML 5 but how can they really if the standard isn't due to be finished for years? All I seem to hear about for HTML 5 is the canvas and the video tag (which ultimately reached no agreement as regards a cross platform codec making it considerably less useful).

Are any improvements actually coming in JavaScript? In particular, to have anything like equivalent functionality to plugin technology will JavaScript in the future support:

- Some core primitive types and full binary operations on those types for bit twiddling (I know there is some support for bit twiddling but not to the same extent as Java for example)

- Byte Arrays / manipulation of binary data

- Ability to open / work with / get info about Files

- Threading support

I know some individual browsers have proprietary extensions to support these features but that is pretty useless for most who want cross browser support.

In the past I have looked at non plugin solutions for certain types of problems such as a file uploader that shows how much of a file has been uploaded. JavaScript was a non starter because as far as I could find it had no way of interacting with files.

Having standard cross browser ways of doing things seems great in theory. After about 15 years or so of promises that all the browsers will standardise and do things consistently and repeated failure to agree on so many things I am a bit cynical as to thinking this will ever change.

I may be getting off topic now...

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

[Fabrizio Giudici]

On Wed, 23 Nov 2011 11:27:01 +0100, Carl Jokl <carl...@gmail.com> wrote:

> Having standard cross browser ways of doing things seems great in theory.
> After about 15 years or so of promises that all the browsers will
> standardise and do things consistently and repeated failure to agree on
> so
> many things I am a bit cynical as to thinking this will ever change.

+1 (mainly to the quoted sentences, but in general to the whole post).

[Carl Jokl]

Being concise isn't always my strong point but to say in fewer words:
Implementing Java on JavaScript is all good an well but the JavaScript
platform has to also be able to support fundamental features that the
Java (and other) platforms support otherwise you are just writing Java
that gets turned into JavaScript but still lack the support for
fundamental platform features needed to accomplish certain types of
tasks.

I have long since wished that the browsers would use some kind of VM,
frankly I would not care if it was a JVM, CLR LLVM or something else.
I would be happy with whatever I could get.

I see the problem being that no-one would agree on the VM. The backers
of the most popular browsers tend to have very incompatible political
agendas.

[Cédric Beust ♔]

On Wed, Nov 23, 2011 at 2:27 AM, Carl Jokl <carl...@gmail.com> wrote:

Having standard cross browser ways of doing things seems great in theory. After about 15 years or so of promises that all the browsers will standardise and do things consistently and repeated failure to agree on so many things I am a bit cynical as to thinking this will ever change.

I would argue that Flash achieved this goal, albeit not for much longer.

A universal VM in browsers sounds as good now as it did fifteen years ago, and while I don't think this particular project (Java VM written in Javascript) will go very far for performance reasons, I'm curious to see where DART and NaCL will go.

Writing Javascript on Chrome is a delight (debugger, breakpoints, variable inspections, etc...) but I'm looking forward to a post-Javascript world.

-- 

Cédric

[Carl Jokl]

That is kind of my point though. Flash did what JavaScript still cannot do. The problem is that the plugin free purists now want rid of flash but JavaScript still hasn't reached a point where it can do what Flash can do. Being able to draw to a canvas only fixing one of many things ECMA standard JavaScript platform (exposed platform in browser more than language). If the purists don't want a plugin, a replacement needs to be an integral part of a browser and not a separate plugin. Building Java on JavaScript doesn't help much because the limits are still based the functionality permitted by JavaScript in the browser.

2011/11/23 Cédric Beust ♔ <ced...@beust.com>

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[KOD]

Slightly off topic - There is a slow and completely impractical way to run Java non-graphical applications on a pre-1.5 JVM within a browser.  That is via JavaScript PC Emulation.  Some time ago I ported JPC to JavaScript - JsPcEmulator via GWT.  It can boot the Sanos, which is just enough of an OS to run Java.  My more recent port of Dosbox- JsDosbox might also run java if combined with Japheth's HX DOS extender with Win32 PE file format support (again with the same limitations).