JavaScript JVM Runs Java 234
mikejuk writes "The world of software is made slightly crazy because of the huge flexibility within any computer language. Once you have absorbed the idea of a compiler written in the language it compiles, what else is there left to gawp at? But... a Java Virtual Machine JVM written in JavaScript seems like another level of insanity. 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. Notice this isn't a Java to JavaScript translator but a real JVM that runs byte code. This means it could run any language that compiles to byte code." Bonus: on Ventura's website is a set of visual notes from a talk he gave titled "My Language Is Better Than Yours."
Javaception (Score:5, Funny)
Re:Javaception (Score:5, Informative)
Re: (Score:2, Insightful)
Re: (Score:2, Insightful)
Not true! Since you're performing the execution of the byte code yourself you could implement the time slicing yourself. It wouldn't be easy sure - but it wouldn't be "virtually impossible". It'd all run within a single thread in the browser but emulating multiple threads in your JVM.
Re:Javaception (Score:5, Funny)
but it wouldn't be "virtually impossible"
Exactly. It'd literally be virtually possible if you control the whole virtual machine...
Re: (Score:3)
Re: (Score:3, Interesting)
If you don't care about the quality of your multithreading (and don't care if the whole thing just runs on one core of your multicore system), then writing threads into your JVM shouldn't be hard (assuming the hard part of writing the JVM has already been done, of course): Just have an interpreter for each thread (holding all thread-specific data), and then just cycle through all threads, letting each non-blocked one execute a fixed number of instructions before turning to the next (the interpreter class wo
Re:Javaception (Score:4, Interesting)
Re: (Score:3)
For instance...
See: http://nodejs.org/ [nodejs.org]
JavaScript outside the browser.
Re:Javaception (Score:5, Interesting)
Also, mine runs on Rhino, which is itself written in Java, so it's C (JVM) running Java (Rhino) running JavaScript (JSava, my interpreter) running Java (the user program). How's that for meta-execution?
Comment removed (Score:5, Funny)
Re: (Score:3, Informative)
Re:Javaception (Score:5, Funny)
10 Write Browser in Java
20 Write Javascript engine in Browser
30 GOTO 10
Re:Javaception (Score:5, Funny)
Ummmm, Java != Javascript.
I thought that bit of confusion was cleared up by now. I was wrong.
Re: (Score:2)
Re: (Score:2)
I think the idea is that the browser could run itself inside a window.
Re:Javaception (Score:5, Funny)
Think before posting please.
Seriously, if we are going to put that kind of requirement on posters, I will probably have to cancel my slash dot account
Re: (Score:2, Interesting)
A more interesting loop would be this:
Write Editor with Lisp interpreter in C. (check [gnu.org])
Write Browser with JavaScript interpreter in Lisp. (partial check [gnu.org] -- I don't think w3 supports JavaScript)
Write JVM in JavaScript. (check [slashdot.org])
Write x86 emulator in Java. (check [slashdot.org])
Now run the editor on your x86 system, run the browser in that editor, run the JVM in that browser, run the x86 emulator in that JVM, repeat.
Re: (Score:3)
How long before CPU benchmarks are measured in how deeply you can nest this and still achieve some fixed number of results per second with a computationally intensive task?
"Doom3 is running at 30FPS... inside 8 levels of emulation."
Re:Javaception (Score:5, Funny)
Now we just have to do all of that in a Minecraft map so the CPU collapses under its own virtual weight!
Re: (Score:2)
Re: (Score:2)
Bonus points if you can do networking using multiplayer characters in mine carts.
Re:Javaception (Score:5, Interesting)
So you could [...] run the browser in itself?
Old news. Try chrome://browser/content/browser.xul [chrome] in Firefox (doesn't seem to work as a clickable link, though).
See here [mozillazine.org] for more options.
Re:Javaception (Score:5, Funny)
This is modded "funny", but actually this would be very useful. Because you could send the browser along with your HTML and be done at once with all browser-compatibility problems. Plus you could make browsers supporting other languages (e.g., Python, Haskell, you name it).
Of course javascript would not be the appropriate target-language for this (I guess, due to efficiency issues), but the idea in itself is very interesting. A better target-language would be closer to the machine (no closures, and no garbage collection); the NaCl project might actually be a better candidate. [google.com]
I'm betting that somewhere, somebody is already writing a browser in NaCl.
Re: (Score:2)
I think a large performance gap will be fixed when JavaScript engines support type inference. JavaScript is dynamically typed, which is slower. But if the engine can figure out what type a variable is, it can optimize for that and be just as fast as typed lnaguage JIT VM:
http://blog.mozilla.com/futurereleases/2011/11/10/type-inference-to-firefox-beta/ [mozilla.com]
Re: (Score:3)
So you could write a browser that supports JavaScript in Java, and then run the browser in itself?
And if you run it in a modern browser, it would still run faster than javascript in IE8.
Anything which can be written in JavaScript ... (Score:5, Funny)
Not A New Concept (Score:3, Interesting)
Forty years ago, a major software system for operating unmanned space satellites for the U.S. Air Force was written in a language called JOVIAL J4. The JOVIAL J4 compiler was itself written in JOVIAL J4.
Originally intended for a lifetime of 10-15 years, the system was actually in use for 20 years.
Re:Not A New Concept (Score:5, Interesting)
I feel like that sort of bootstrapping is normal. GCC's written in C, afterall.
Re:Not A New Concept (Score:4, Informative)
Forty years ago, a major software system for operating unmanned space satellites for the U.S. Air Force was written in a language called JOVIAL J4. The JOVIAL J4 compiler was itself written in JOVIAL J4.
Hardly unusual. GCC is written in C.
This is not quite the same thing.
Re: (Score:2)
Nothing unusual about that...most C compilers are written in C and the first C++ compiler was written in ... C++.
Re:Not A New Concept (Score:5, Informative)
Re: (Score:2)
Re:Not A New Concept (Score:5, Interesting)
The JOVIAL J4 compiler was itself written in JOVIAL J4.
Want something really mind-blowing? PyPy [blogspot.com] is a Python interpreter written in Python. It includes a tracing JIT compiler to optimize hotspots as it runs to get about 5 times faster [pypy.org] than the native C Python. I've used it and I still can't quite believe it.
yo dawg (Score:4, Funny)
So we heard you like java...
Hey Bro... (Score:5, Funny)
Joking aside, this is not going to help the amount of confusion people have with regards to Java not being the same as Javascript *at all*.
Re:Hey Bro... (Score:5, Funny)
Re: (Score:2)
Re: (Score:3)
Hey, 1996 calling. Does our interpretation of how Java works still fit? Because if you're not using it anymore, we'd like it back.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
DOM-Interface for byte code (Score:5, Interesting)
"we do need DOM-Bindings for Bytecode now more than ever. It would be so great to write code in a language of my choice and compile it to Browser-Bytecode with DOM-Bindings. This would make it possible to deliver more proprietary code without making browser-plugins or something similar."
"What we really need are DOM-Bindings for Bytecode. So you can use every language you want that is capable of compiling to bytecode and send it to a browser. This would make it easier for the developer and bytecode is easier and faster for the browser to execute."
Re: (Score:2)
more proprietary code
How is this progress? Why would we want to go backwards?
If anything, we need less proprietary code on the web.
We should have learned from the consequences of lock-in by now. See: Flash, Java applets, ActiveX.
Re: (Score:2)
Re:DOM-Interface for byte code (Score:5, Insightful)
Yes, would make sense, wouldn't it? Instead that every browser have to interpret the slow JS language (yes, JS language is slow to interpret, because of the design choices. Just watch some of Doug Crockford videos), we could all just agree on a byte code standard like the Java byte code standard.
Then you could develop web applications in your choice of language and not just in JS. On the server you upload just the byte code, like the compiled Java source code (.class).
For example, you could develop in Ruby, Python or Java, and compile the code to the byte code for browsers. Then you deploy the byte code on the server.
But the web-developers are so stubborn with their JS language, I don't know why.
Re: (Score:3)
Of course we had that with Java applets a few years ago - they didn't really take off.
A number of reasons for this exist: first is there were a couple of implementations of the JVM and they weren't all compatible with each other. Second is that the same version of the same JVM (Sun's at the time) exhibited subtly different behaviour on different platforms - meaning it was fantastically easy to wind up with something that only worked well on one or two platforms. ISTR font handling in the UI was a big killer
Re: (Score:2)
Writing Java VM in JavaScript, is like downloading de JRE to the browser to run some applets. Is that a good thing ? Or a bad thing ?
It would mean it is a lot more compatible, but it would also be slower than just use JavaScript.
How to translate into JS? (Score:2)
Re: (Score:2)
We not talking about applets. We talk about a byte code that every browser have to implement, like the ECMAScript today. But the byte code could be generated by any language, not just JS.
It's the same as with Google's GWT, with takes Java source code and compiles it to JS code, so a browser can run it. Now, why can't GWT compile Java to a byte code that can directly be run in the browser?
If Sun/Oracle could would had more wisdom, we would just have a JVM in every browser. That way you could program in Scala
Re: (Score:2)
My main reason for not liking the Java plugin to this date is that applets take ages to start up. My MacBook Air literally takes less time to boot than an applet takes time to start up after opening its webpage. Back when they were rather popular, Mac OS 9 would block the whole computer while the VM was loaded up, which would take about a minute or more.
If the VM would be part of the browser, that problem would be gone.
Re: (Score:2)
Ah, I hadn't fully registered that.
You're quite right - but then you immediately start to run into sandboxing & security issues.
Re: (Score:2)
but then you immediately start to run into sandboxing & security issues.
In which way is this different to current JavaScript implementations?
Re: (Score:2)
we could all just agree on a byte code standard like the Java byte code standard.
hahahahahahahhahahaaaaa.
agree on something like this, oh boy, that's a good one. I mean, the old Java standards were incompatible. Even Microsoft's .NET has differences between C# and VB.NET (ie - those 2 languages have different features that the other doesn't have).
I think the web devs are stubborn with JS because its there, it works and they can get on with work in stead of arguing the toss over which language is better - the lucky buggers only have 1.
Re:DOM-Interface for byte code (Score:5, Interesting)
Re: (Score:3)
What have that do to with your argument? Libraries like JQuery will still be open source.
I would rather think that Web exploded because it's build on open technologies and open source software.
And if the Byte Code is a standard, it's as simple as a editor or disassembler to use to see the code.
Also, I don't think you can read that code: http://code.jquery.com/jquery-1.7.min.js [jquery.com]
Re: (Score:2)
The average code written in a programming language is always going to be better than the average bytecode generated by a compiler, and if it's an optimizing compiler the bytecode will be even harder for a human to understand.
Re: (Score:3, Interesting)
How is what we have now with things like minified js any different than bytecode? Have a look at the source for gmail, or the minified version of jquery. You need analysis software to have any hope of making any sense of it and it's exactly the same then as a bytecode decompiler.
jQuery is open source, which means you can get the non-minified version and read that to know how it works, but I would dare anyone to make sense of the 100s of KBs of obfuscated js that is the gmail interface(or quite a few other p
Re: (Score:2)
No kidding. I 'disassembled' the YouTube JavaScript once, and I still have nightmares.
Re: (Score:2)
Nonsense. The web exploded a long time ago, but innovative new ideas keep appearing. Remember when Google first unveiled the autocompletion in the search bar? Everyone got excited and went through the javascript source to figure out how they did it, and then it wasn't just copied, but improved and made its way into all sorts of websites.
Innovation doesn't all happen at once, it's a small idea here, a small idea there, and then someone combine
Re: (Score:2)
Re: (Score:2)
I think that is called CoffeeScript.
Re: (Score:3)
Even sandboxed in a VM, I'd be inherently wary about executing server-compiled byte-code
Why is this any different from executing server-supplied source code?
Interesting mind set (Score:4, Insightful)
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.
I think it would have been easier to build a VM into a browser but I doubt it would have gotten this much attention. Still. It is a cool project.
Java Applets (Score:2)
created by Java which was created with Java-script. Have the planets aligned?
Problem is speed (Score:2, Interesting)
I doubt that Javascript accelerators are good at optimizing this, but it's not fundamentally impossible to run it close to JVM speeds. JS is a language that in nutshell is self modifying code, so it can act as a translational layer which in the end enables running Java in a Javascript engine (interpreter,VM or whatever). It could be compared to Dart which also runs another type of language in JS.
Re: (Score:2)
I think it will be (a lot better) when they've added this important part:
"Type Inference brings JS improvements to Firefox Beta"
"Javascript is a dynamically typed language, and without knowing the types of values a JIT compiler needs to generate code that accounts for all the possible types of the involved values. This significantly slows down execution of the program in comparison with a statically typed language like Java. With TI integration into JaegerMonkey, we are closing a significant part of this pe
Really? (Score:5, Informative)
This
This means it could run any language that compiles to byte code.
shoud read as
This means it could run any language that compiles to Java byte code.
Re: (Score:3)
This
This means it could run any language that compiles to byte code.
shoud read as
This means it could run any language that compiles to Java byte code.
Technically, it's running anything that compiles to JVM bytecode. There are a number of languages that do that, one of which happens to be Java. (Yes, JVM stands for Java Virtual Machine and it would indeed be odd if Java didn't compile to it, but Java isn't JVM bytecode, just as C isn't native machine code.)
Other bytecodes (Score:3)
Comment removed (Score:3, Insightful)
Re: (Score:2)
Let's go shopping!
This is completely unnecessary. (Score:5, Funny)
Re:This is completely unnecessary. (Score:5, Funny)
Fabrice Ballard already wrote an x86 emulator [bellard.org] in javascript. Just install the standard x86 JVM inside of that and you're good to go.
Yes, that's why this is completely unnecessary.
Re: (Score:3, Informative)
Why now? (Score:5, Interesting)
Legit question from a programming novice: Why are all these discoveries coming up now? Hasn't JavaScript been around for 10+ years now? Is there something that has changed recently that makes people pursue these strange coding goals?
Re:Why now? (Score:5, Informative)
Javascript speeds have increased greatly due to the reheated competition by browser vendors (it wasn't too long ago that the only thing really existed was IE6). Thus in the past 10 years, nobody in their right mind would expect a x86 emulator, a JVM etc. to be implementable in Javascript at tolerable speed.
In fact, few expect these "discoveries" to happen so soon and so quickly, but since somebody proved it possible to do crazy things on Javascript, everyone with too much time on their hands are jumping on board and having fun with these projects.
Re: (Score:2)
Specifically some primatives/types have been added to work efficiently with binary data when WebGL was added to the browsers (specifically a new type of array).
Re: (Score:2)
It's not a discovery by any stretch. (And JavaScript has been around a bit more than 10 years, I wrote a fairly basic game in an unholy mishmash of JavaScript and HTML circa 1998-1999).
Provided JavaScript is Turing-complete (and there are very few useful languages that aren't), basic computing theory teaches us that it's possible to write more-or-less anything you want in it.
Note the keyword here is possible. Desirable and practical are totally different matters altogether.
LBA-complete, not Turing-complete (Score:3)
Provided JavaScript is Turing-complete (and there are very few useful languages that aren't)
No language is Turing-complete because no machine has unbounded memory. A linear bounded automaton (LBA-complete) is a better model of computers that exist in the physical world.
Note the keyword here is possible. Desirable and practical are totally different matters altogether.
Especially because even once you've ignored speed, neither Turing completeness nor LBA completeness makes any guarantee about I/O capability.
Re: (Score:2)
It's not a "discovery".
You can emulate any turing-complete system in any other turing-complete system. It's just a matter of having the tools and performance to achieve it without going mad.
And we don't know he didn't go mad... or start mad...
From the notes (Score:3)
"Computers languages are how we tell computers what to do"
That's so in the past.
Nowadays, computer languages nowadays are (minus some exceptions) all about telling people what computers do.
Re:This is nonsense. (Score:5, Insightful)
Javascript != Java. "Javascript" is just a naming rip-off. So what's the big deal?
It's like writing a C compiler in Bourne shell. The point is less about the name than about the complexity and absurdity.
Re:This is nonsense. (Score:4, Funny)
It's like writing a C compiler in Bourne shell. The point is less about the name than about the complexity and absurdity.
Isn't it more like writing a C compiler in C-shell - at least name-wise :-)
Re:This is nonsense. (Score:5, Funny)
Re:This is nonsense. (Score:5, Funny)
Re: (Score:3)
Names have nothing to do with it. They could have just as well written their JVM in Python, Perl or PHP - except that none of those languages have undergone ten years of browser vendors fighting head to head to shave off another few microseconds on benchmarks, so their interpreters would be too slow to run an effective virtual machine.
Re: (Score:2)
Let me introduce you to Jetty.
Re: (Score:3)
Also I think the point was javascript is seen as a less powerful language
Re: (Score:2)
Also I think the point was javascript is seen as a less powerful language
It's Turing-complete. You can implement any language in it. That's not what people mean when they say it's less powerful, they mean some combination of:
The fact that you can run a slow JVM written in JavaScript
Halting-complete (Score:2)
That's not what people mean when they say it's less powerful, they mean some combination of: Implementing the same algorithm in JavaScript and another language requires a more complex JavaScript compiler to reach the same speed.
That or reaching the same speed turns out to be halting-complete due to the complexities of trying to squeeze static typed performance out of a dynamic typed language.
It lacks access to operating system features via standard APIs (e.g. no threads)
Exactly. Without threads, how is a JavaScript JVM supposed to implement JVM threads? And without WebGL (which at least one major browser maker refuses to implement for security reasons), how is Java 3D implemented?
Re: (Score:2)
The way it's always been done. We've had multiple processes and multiple threads on single core CPUs for decades. You just give each thread a time slice and then move on to the next one. Completely trivial.
Slowly. And surely it's not a required feature of java - I would hope the java that runs on m
Re: (Score:3)
I can see a use case: Once we have a mostly complete JVM interpreter with satisfactory performance written in Javascript, we can use any language that supports the JVM instead of Javascript.
Yo dawg, I heard you like bloat (Score:4, Funny)
Re: (Score:2)
If it means not having the Java runtime installed on my machine then I see no downsides to it.
Re: (Score:2)
Re: (Score:3)
Actually, if the engine to run javascript is loaded from the website where your java app is downloaded from there is a much higher chance it will work.
It is what a lot of java programs already do, deliver their have their own JRE in a directory.
Re: (Score:2)
Re: (Score:2)
Or, more likely, he was already institutionalized decades ago and was just looking for a nice project to spend his time on.
Re: (Score:2)
Unless there are future developments in getting things to move faster than the speed of light (0.3mm/ps), Or we can miniaturise a computer to considerably less than 1mm^3, I don't think we are going to see tera-herz processors any time soon.