Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Java Programming News

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."
This discussion has been archived. No new comments can be posted.

JavaScript JVM Runs Java

Comments Filter:
  • Javaception (Score:5, Funny)

    by embolalia ( 1561119 ) on Monday November 21, 2011 @01:53AM (#38121454)
    So you could write a browser that supports JavaScript in Java, and then run the browser in itself?
    • Re:Javaception (Score:5, Informative)

      by linuxgeek64 ( 1246964 ) on Monday November 21, 2011 @01:54AM (#38121460)
      It doesn't implement that much of the standard JVM.
      • Re: (Score:2, Insightful)

        by DrXym ( 126579 )
        It couldn't either. Stuff like threads would be virtually impossible to do on Javascript, even with web workers. I suppose what it might do in the dim and distant future is allow tools like GWT to deploy jar files straight to web sites without any of the usual nonsense of translating Java source into umpteen variations of JS to cope with browser quirks.
        • Re: (Score:2, Insightful)

          by Anonymous Coward

          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.

          • by sydneyfong ( 410107 ) on Monday November 21, 2011 @05:37AM (#38122188) Homepage Journal

            but it wouldn't be "virtually impossible"

            Exactly. It'd literally be virtually possible if you control the whole virtual machine...

          • by DrXym ( 126579 )
            Well I suppose Java did come from that situation a long time ago - so called "green" threads. So I concede you could probably use some crappy timer / yield type model. The timeslice / yielding would be the issue and all the synchronization / deadlock issues would be fun too.
            • Re: (Score:3, Interesting)

              by Anonymous Coward

              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)

                by DrXym ( 126579 ) on Monday November 21, 2011 @07:52AM (#38122654)
                You'd have to use timers. The JS is running in a browser. If you let code for as long as it likes the browser won't be responsive and eventually will start complaining to the user about the fact. The JS would have to execute a bit of code, find some convenient point to halt, set a timer, drop out back to browser and then execute some more when the timer fired. Even if there was just one thread. When you have more than one thread you'd have to do the same for multiple threads via some kind of scheduler.
      • Re:Javaception (Score:5, Interesting)

        by Zortrium ( 1251080 ) on Monday November 21, 2011 @08:28AM (#38122808) Homepage
        Warning: shameless self-promotion ahead: I've also written my own JVM interpreter in JavaScript [zortrium.net], which supports a substantial amount (perhaps most?) of the standard JVM, including threading, synchronization, reflection, rudimentary I/O, and most of the standard library classes (e.g., HashMap and Random). There's a lot of hackery involved but it's totally doable.

        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?
    • by DigiShaman ( 671371 ) on Monday November 21, 2011 @02:24AM (#38121580) Homepage


    • Re: (Score:3, Informative)

      by cb88 ( 1410145 )
      Sun already did that with HotJava it supported javascript.
    • by afabbro ( 33948 ) on Monday November 21, 2011 @02:37AM (#38121626) Homepage

      10 Write Browser in Java

      20 Write Javascript engine in Browser

      30 GOTO 10

      • by Joce640k ( 829181 ) on Monday November 21, 2011 @04:17AM (#38121920) Homepage

        Ummmm, Java != Javascript.

        I thought that bit of confusion was cleared up by now. I was wrong.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        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.

        • by Rysc ( 136391 ) *

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

    • by game kid ( 805301 ) on Monday November 21, 2011 @04:15AM (#38121918) Homepage

      Now we just have to do all of that in a Minecraft map so the CPU collapses under its own virtual weight!

      • You mean a Mincraft map with Redstone-circuitry building a 32-bit processor + OS + Browser + JavaScript + BicaVM running Minecraft with that map? Uhh...I feel dizzy...
    • Re:Javaception (Score:5, Interesting)

      by alexhs ( 877055 ) on Monday November 21, 2011 @05:38AM (#38122190) Homepage Journal

      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.

    • by StripedCow ( 776465 ) on Monday November 21, 2011 @06:57AM (#38122452)

      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.

    • by Spudley ( 171066 )

      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.

  • ... will be eventually written in JavaScript. ~ Atwood's Law [codinghorror.com] (circa 2007)
  • Not A New Concept (Score:3, Interesting)

    by DERoss ( 1919496 ) on Monday November 21, 2011 @02:13AM (#38121528)

    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)

      by bucky0 ( 229117 ) on Monday November 21, 2011 @02:22AM (#38121568)

      I feel like that sort of bootstrapping is normal. GCC's written in C, afterall.

    • Re:Not A New Concept (Score:4, Informative)

      by afabbro ( 33948 ) on Monday November 21, 2011 @02:36AM (#38121622) Homepage

      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.

    • 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)

      by TheRaven64 ( 641858 ) on Monday November 21, 2011 @06:53AM (#38122432) Journal
      Most compilers work like that. The Java compiler is written in Java (as you discover when it crashes and you get a Java stack trace). Smalltalk was written in Smalltalk and even modern Smalltalk implementations like Pharo are written in Smalltalk. The typical trick is to write a small compiler for a subset of the language in another language and then use it to compile the rest of the compiler. For example, the core of the Squeak VM is written in a subset of Smalltalk that is fairly easy to translate to C. This is then translated to C and compiled with the target system's C compiler. You then have enough of the VM running for it to load the rest. Early Pascal compilers did the same. In the '70s, having the compiler written in the language was considered a test of whether something was a 'real' language (since then we've learned that languages that are good for writing compilers are not necessarily good for other things. Well, some of us have...)
    • Even CoffeeScript is self-hosted.
    • Re:Not A New Concept (Score:5, Interesting)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Monday November 21, 2011 @10:42AM (#38123778) Homepage Journal

      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)

    by Anonymous Coward on Monday November 21, 2011 @02:16AM (#38121544)

    So we heard you like java...

  • Hey Bro... (Score:5, Funny)

    by bennomatic ( 691188 ) on Monday November 21, 2011 @02:16AM (#38121548) Homepage
    ...I heard you like Java in your script so I wrote you a JVM in Javascript so you can run Java while you're scripting.

    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*.
    • by Mitchell314 ( 1576581 ) on Monday November 21, 2011 @02:26AM (#38121590)
      Of course there's a difference. Java is defined as the language that runs on top of javascript. This is simple, it's just a compiled language that runs atop of an . . . interpreted . . . of an interpreted . . . it's a compiled . . . it's a compiled language that runs on an interpreted . . . okay guys, really, what the fuck? I think I just heard the sound of part of the universe and a good chunk of logic spontaneously imploding. I'm going to go cry now, and thanks to these dipshits my tears will probably fall sideways upwards now.
      • by deniable ( 76198 )
        Just run it inside VMWare or Virtual PC and you won't have any problems.
  • by maweki ( 999634 ) on Monday November 21, 2011 @02:28AM (#38121602) Homepage
    For years I've been saying that we need a DOM-Interface for byte code in Browsers and everytime I get downvoted. Nice to see people exploring in these directions now.

    "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."
    • 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.

      • by tepples ( 727027 )
        Flash hasn't been proprietary since the Open Screen Project relicensed the SWF specification to allow making competing players.
    • by devent ( 1627873 ) on Monday November 21, 2011 @04:11AM (#38121906) Homepage

      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.

      • by jimicus ( 737525 )

        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

        • by Lennie ( 16154 )

          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.

        • by devent ( 1627873 )

          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

        • by am 2k ( 217885 )

          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.

      • we could all just agree on a byte code standard like the Java byte code standard.


        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.

    • by martin-boundary ( 547041 ) on Monday November 21, 2011 @04:19AM (#38121926)
      I'd rather have source code than byte code. The web was built on visible code like HTML. Do you think it would have exploded if people couldn't look at the source to figure out how some neat web page was written?
      • by devent ( 1627873 )

        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]

        • There's a huge difference between reading/understanding bytecode and reading/understanding code written in a programming language. Bytecode is designed for efficiency and for compiler convenience, whereas programming languages are designed for human convenience (except brainfuck ;-).

          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

  • by sgt scrub ( 869860 ) <saintium@yaho[ ]om ['o.c' in gap]> on Monday November 21, 2011 @02:40AM (#38121632)

    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.

  • created by Java which was created with Java-script. Have the planets aligned?

  • Problem is speed (Score:2, Interesting)

    by Anonymous Coward

    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.

    • by Lennie ( 16154 )

      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)

    by aglider ( 2435074 ) on Monday November 21, 2011 @03:45AM (#38121826) Homepage


    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.

    • by dkf ( 304284 )


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

      • I think aglider's point is that there exist notable bytecodes other than JVM bytecode, such as Microsoft CIL, UCSD p-code, Infocom Z-code, SCUMM bytecode, LLVM bitcode (which is already handled by Emscripten), and more.
  • by fsckmnky ( 2505008 ) on Monday November 21, 2011 @04:02AM (#38121880)
    ... you understand that a computer language, is a mapping of human readable symbols -> cpu instructions, either direct or indirect. If the mapping results in a set of cpu instructions that implements another language, you get another language.

    It's not rocket science people, its just math. Wait, maybe it is rocket science.
  • by DamnStupidElf ( 649844 ) <Fingolfin@linuxmail.org> on Monday November 21, 2011 @04:27AM (#38121954)
    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.
  • Why now? (Score:5, Interesting)

    by thegarbz ( 1787294 ) on Monday November 21, 2011 @05:26AM (#38122156)

    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)

      by sydneyfong ( 410107 ) on Monday November 21, 2011 @05:43AM (#38122208) Homepage Journal

      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.

      • by Lennie ( 16154 )

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

    • by jimicus ( 737525 )

      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.

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

    • by slim ( 1652 )

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

  • by kikito ( 971480 ) on Monday November 21, 2011 @07:55AM (#38122676) Homepage

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

All Finagle Laws may be bypassed by learning the simple art of doing without thinking.