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

 



Forgot your password?
typodupeerror
×
Programming Java IT Technology

Ruby and Java Running in JavaScript 220

John Resig is reporting on his blog that a recent trip to Tokyo opened up some very interesting JavaScript projects to him that haven't met with widespread popularity outside of Japan yet. "One project, in particular, really caught my eye. It's called Orto and is an implementation of the Java Virtual Machine (JVM) in JavaScript. This means that you can take an existing Java application, compile it to bytecode, run it through Orto (which produces the JavaScript, and embed it in a web page. While it doesn't provide the full capabilities of most Java code it does provide enough to make for some interesting demos." In a separate post he also detailed how the HotRuby project is allowing a Ruby VM to run in a browser using JavaScript or even indirectly using ActionScript in Flash.
This discussion has been archived. No new comments can be posted.

Ruby and Java Running in JavaScript

Comments Filter:
  • Awesome! (Score:4, Funny)

    by eln ( 21727 ) on Monday April 28, 2008 @02:15PM (#23228366)
    Finally, a way to combine the feature-rich capabilities of Javascript with the speed of Java!
    • Re: (Score:3, Interesting)

      by nmb3000 ( 741169 )
      Finally, a way to combine the feature-rich capabilities of Javascript with the speed of Java!

      Cynicism was my initial response as well, but reading TFA shows a pretty cool demo [accelart.jp]. The fact that they are able to convert Java's user input events, GUI, and multithreading to Javascript is pretty cool. Probably has no practical use, but still cool.

      If nothing else it means that the next time (in about 3 minutes if today is a normal day) somebody gets Java and Javascript confused, I can say they really ARE "basical
      • Re:Awesome! (Score:5, Funny)

        by omeomi ( 675045 ) on Monday April 28, 2008 @03:29PM (#23229248) Homepage
        If nothing else it means that the next time (in about 3 minutes if today is a normal day) somebody gets Java and Javascript confused, I can say they really ARE "basically the same thing" now!

        Fantastic. Somebody's found a way to make the morons of the world slightly more correct without them even knowing it.
      • In actuality, I can think of several applet-type projects that suffer significant problems in Java, which I'd like to try to "cross-compile" to Javascript... One that we've been trying to get to work for a long time works just fine in every browser we have tested it on. Unless, of course, you try to run it from a page loaded by HTTPS! If it is, the success of it running depends entirely upon the browser used, AND whether or not it was previously run from the same page, loaded via a non-TLS connection.

        Attem

      • by HeroreV ( 869368 )

        I can say they really ARE "basically the same thing" now!

        That's like saying Python and C are basically the same thing, since the CPython interpreter is written in C. Writing an interpreter for language A in language B doesn't mean languages A and B are basically the same thing.

        Plus this isn't even the Java programming language we're talking about, it's Java bytecode, which could have been produced from something other than the Java programming language (like Groovy or Scala).


    • Finally, a way to combine the feature-rich capabilities of Javascript with the speed of Java!

      You joke, but I'm sure it's the other way around. The myth that Java is slow persists to this day, though it hasn't been true for many years.

      The ugly thing about this hack is going to be the slowness of javascript execution, especially when doing this bizzare translation. I'm all for replacing javascript with a less sucky language. But this doesn't seem like the solution.
    • Feature-rich? You mean it has things like introspection, closures, functions as first-class objects, and objects by aggregation as well as inheritance? Seriously, JavaScript is chock full of neat features.

      It's the two primary runtime environments' gross annoying differences, and weaknesses with little syntaxy things like variable declaration and adding strings - or did you mean integers? and how parseInt('08') blows up etc... things like THAT make it a pain.

      • By features, he probably meant the Java's library which is pretty huge. The language itself has very few features and it was a design goal. I prefer Python for having the best of both worlds.
  • by techno-vampire ( 666512 ) on Monday April 28, 2008 @02:16PM (#23228378) Homepage
    What this is, basically, is emulating the Java in Javascript, an interpreted language. I can't help but feel that anything written in this is going to be very slow, and I can't, personally, see why anybody would bother. Of course, I'd be very happy to be proven wrong!
    • Re: (Score:3, Interesting)

      by gstoddart ( 321705 )

      What this is, basically, is emulating the Java in Javascript, an interpreted language. I can't help but feel that anything written in this is going to be very slow, and I can't, personally, see why anybody would bother

      I'm with you, I read the summary and almost choked on my coffee.

      This is like writing a Cray emulator for your TI 99/4a -- I don't know what it buys you.

      Of course, I'd be very happy to be proven wrong!

      I'm sure some clever person will put out a demo showing something completely amazing, and I'd

      • This is like writing a Cray emulator for your TI 99/4a -- I don't know what it buys you.


        Hey, I used to have a TI 99/4A. Great little machine, back then!

        • Hey, I used to have a TI 99/4A. Great little machine, back then!

          I'm not disparaging the TI 99/4a, I have very fond memories of that machine.

          But, let's face it, that's just as odd a scenario as running Java on a javascript interpreter. :-P

          It's like ... making a scale model of a dump truck from a Yugo. Sure, it kinda mostly looks like a dump truck. But, it can't do any of the things you'd actually want a dump truck for. :-P

          Cheers

    • by Dekortage ( 697532 ) on Monday April 28, 2008 @02:24PM (#23228466) Homepage

      The article suggests that the speed was not bad. (The sample Tetris [accelart.jp] clone loaded very quickly for me.) And the article's commenters note that this runs on an iPhone. In other words, Orto could be a route to port Java apps to be iPhone aps.

      • by hanshotfirst ( 851936 ) on Monday April 28, 2008 @02:29PM (#23228544)
        Anticipated application stack:

        iPhone -> Orto -> Javascript -> Java -> C64 Emulator -> VIC-20 Emulator -> Zork I

        Exciting New ways to be eaten by a grue!
      • Re: (Score:3, Informative)

        by eln ( 21727 )
        The game loaded faster than most Java apps do for me, but once it loaded the controls were laggy and the video was pretty choppy. Most of the time for me, the JVM takes a while to load but at least the app runs fairly smoothly once it does. I'd rather have that then a shorter load time on a laggy application.
      • by evanbd ( 210358 ) on Monday April 28, 2008 @02:52PM (#23228772)

        Tetris performed better on my Gameboy (an 8-bit, 4.2MHz x80 CPU with 8KB RAM) than this clone does on my 32-bit 1.4GHz Athlon. And it had sound. Tetris shouldn't load "quickly" it should load instantly.

        This is a very clever hack, and I admire the work -- but it is in no way practical for anything. I find the idea of using it for "real work" apalling -- and I code in Java by choice!

        • by Atario ( 673917 )

          Tetris performed better on my Gameboy (an 8-bit, 4.2MHz x80 CPU with 8KB RAM) than this clone does on my 32-bit 1.4GHz Athlon. And it had sound. Tetris shouldn't load "quickly" it should load instantly.

          I think your complaint here is with Java, not Javascript or Orto. I guarantee it would take longer for this Tetris to load up were it directly in Java if you didn't already have the Java runtime loaded up in memory -- and maybe even if you did.

          So, I'd grade Orto as "damn impressive".

          • by evanbd ( 210358 )

            Even after it loaded, it was sluggish with poor response to the controls. In native Java there'd be a load time, but if done well it would be quite snappy after that.

            Don't get me wrong, I'm quite impressed. But I'm impressed in the "damn that's neat" sense, not in the sense that I'd ever contemplate using it for anything.

      • by hey! ( 33014 )
        Well, I always tell young programmers that the things that matter most are at the top and at the bottom of the stack of the abstractions you are using. The in between part is always negotiable and subject to clever alterations.

        Tetris is not apt to use a great deal of java's vast libraries, so if you're smart about loading just the parts you need, when you need them, why shouldn't Java on Javascript Tetris be fairly close to plain old Javascript Tetris, with a modest constant time hit. What I'd like to see
      • by omeomi ( 675045 )
        The article suggests that the speed was not bad. (The sample Tetris [accelart.jp] clone loaded very quickly for me.) And the article's commenters note that this runs on an iPhone. In other words, Orto could be a route to port Java apps to be iPhone aps.

        I think the article was likely talking about web-based iPhone games, which presently is the only Apple-sanctioned way of playing a game on your iPhone. Unfortunately, the web-based games are pretty limited compared to what can be played on, say, a Jailbroke
      • (The sample Tetris clone loaded very quickly for me.)

        Okay, but that's a pretty trivial example indeed -- Tetris was developed in the mid-'80s on a Soviet PDP-11 clone. Tetris has been implemented as simple state machines that run on wristwatches and keychains.

        While novel, I don't think JVM-implemented-in-Javascript is going to be a practical path for anything very complex. This isn't going to enable me to run Eclipse as a web app.
    • ``What this is, basically, is emulating the Java in Javascript, an interpreted language. I can't help but feel that anything written in this is going to be very slow, and I can't, personally, see why anybody would bother. Of course, I'd be very happy to be proven wrong!''

      Probably, it will be slow.

      But, in general, just because something is interpreted doesn't mean it has to be slow. There are various ways to implement an interpreter, and interpreters can have either very fast start-up time or very fast execu
      • in general, just because something is interpreted doesn't mean it has to be slow.

        However, except in rare and unusual cases (e.g., using an interpreter that does realtime execution analysis and modifies code on the fly), interpreted code will always be at least a little bit slower than compiled code.

    • The Ruby-in-Javascript ended up being faster than Ruby 1.8 (the stable version) -- although it did use Ruby 1.9 on the server to compile it to bytecode.
  • But... (Score:5, Interesting)

    by Oxy the moron ( 770724 ) on Monday April 28, 2008 @02:17PM (#23228386)

    Does it run Linux? ;)

    In all seriousness, though... I'm struggling to see how this is truly beneficial. Aren't most pages already hopelessly clogged with mounds of JavaScript? Is it that difficult to expect a user to have a Java interpreter already installed when they visit the page such that having your Java "emulated" in JavsScript is the better solution?

    Just seems like a solution needing a problem to me.

    • Re: (Score:2, Insightful)

      I'm struggling to see how this is truly beneficial.


      If you can run it under JavaScript, you can run it on an iPhone.
    • Previously, so-called RIA applications were limited to those with Flash and JavaScript expertise. These advances may open this field up further to Java and Ruby developers who don't know JavaScript. This puts less cognitive burden on the individual developer which, on the whole tends to be a good thing.
      • by jrumney ( 197329 )
        Java developers can already develop so called RIA applications using an old technology called applets. Some of the first RIA applications used it, because ten years ago there was no such thing as cross browser Javascript and Flash was only useful for making vector animation cartoons.
    • Re: (Score:2, Insightful)

      Don't you see? Javascript is available on every hardware platform! You don't need to have a separate Java binary package from Sun to run Java programs. You can use the portable javascript implementation in your browser! It makes sense.
  • by kripkenstein ( 913150 ) on Monday April 28, 2008 @02:19PM (#23228416) Homepage
    Also worth mentioning that PyPy allows you to run Python as Javascript [codespeak.net], inside a browser. Like all of these things, it isn't 100% mature, but pretty cool nonetheless.
  • Google Web Toolkit (Score:5, Interesting)

    by mysqlrocks ( 783488 ) on Monday April 28, 2008 @02:20PM (#23228424) Homepage Journal
    While not exactly the same thing, the Google Web Toolkit [google.com] (GWT) lets you write your code in Java and then run it in the browser. The difference is that the GWT translates the Java into JavaScript instead of giving you a full JVM. I'm not sure what practical advantage having a full JVM gives you.
  • Strange (Score:5, Interesting)

    by graveyhead ( 210996 ) <fletch AT fletchtronics DOT net> on Monday April 28, 2008 @02:22PM (#23228444)
    Seems odd to use languages that weren't really designed to be embedded in a browser. One of the nice things about Javascript in the past couple of years has been the great DOM support. Add a library like JQuery [jquery.com] and you have full cross platform goodness and a sane way to write code. Getting Java or Ruby code to interact with the DOM seems like it would be a huge pain compared with JQuery.

    Why does everyone hate Javascript so? If you're going of cut-n-paste examples from the web yes it looks like an ugly language. Check out how the OO stuff works, or some JQuery code, and you'll be pleasantly surprised.
    • Re:Strange (Score:4, Informative)

      by CastrTroy ( 595695 ) on Monday April 28, 2008 @02:31PM (#23228570)
      I think that everybody just has memories from the Netscape 4 days, where every line had to be coded differently depending on which browser you were using. Things have matured a lot lately, and you can almost get by without writing any browser specific hacks. However, the history of Javascript has lead many people to dispise it.
      • by emkman ( 467368 )

        Things have matured a lot lately, and you can almost get by without writing any browser specific hacks.

        Umm kinda. Tons of browser specific Javascript (and CSS!!!) hacks are still needed to write an app that plays nice across all platforms. The only difference is that developers of libraries such as JQuery, Prototype, and ExtJS have done an excellent job of encapsulating all the hacks into a library with a consistent API for you to use. They give you normalized event handling, keycode input, DOM element lookup etc. However if you tried to fly solo and develop without one of these libraries, Javascript would

      • The hacks still continue depending upon what you want to do. If you're trying to seriously manipulate your interface using JavaScript you're still going to find yourself having to write browser hacks. Even with IE7 I've still run into plenty of things that don't work correctly in it versus FireFox.

        This doesn't make me hate JavaScript though... it just makes me hate browsers that don't work. If I tell you to update the contents of an object you should update it without me having to move the focus to that o

    • Re: (Score:2, Insightful)

      by lcampagn ( 842601 )
      > Why does everyone hate Javascript so?

      Javascript is inherently multithreaded and embedded in a highly asynchronous environment, het has no threading API whatsoever. To me, this is mind-boggling. Every AJAX project I've been involved in has had to build in ugly workarounds or just drop features to prevent race conditions.
      • by xero314 ( 722674 )

        Javascript is inherently multithreaded and embedded in a highly asynchronous environment, het has no threading API whatsoever.
        This is because there is no reason to create custom threads. Multi-threaded functionality can be handled in a safe way through event handling. Implementing a semaphore is pretty simple if you need such a thing, but creating true asynchronous applications is actually a better approach.
        • by rhizome ( 115711 )
          Multi-threaded functionality can be handled in a safe way through event handling. Implementing a semaphore is pretty simple if you need such a thing, but creating true asynchronous applications is actually a better approach.

          Pointers to async JS would be nice, since my RSS reader pegs my CPU for minutes at a time while fetching updates to my 100+ feeds. When this happens every 20min you can see where this might become frustrating.
    • by jrumney ( 197329 )

      Getting Java or Ruby code to interact with the DOM seems like it would be a huge pain compared with JQuery.

      Not really, the netscape.javascript.* package for interacting with Javascript and the DOM has been a standard part of Java (even the notoriously incompatible MS JVM) since the early days. Perhaps it isn't as well known as it could be due to being outside the java.* namespace.

  • by Hoplite3 ( 671379 ) on Monday April 28, 2008 @02:28PM (#23228528)
    This just reminds me of the "octoparrot" from The Simpsons. "Braawk! Polly shouldn't be!"
  • by Daishiman ( 698845 ) on Monday April 28, 2008 @02:28PM (#23228536)
    'Orto' means 'ass' in Spanish.
  • No Perl? (Score:4, Informative)

    by SCHecklerX ( 229973 ) <greg@gksnetworks.com> on Monday April 28, 2008 @02:29PM (#23228538) Homepage
    Client side perl would kick ass. Then I could match my front end with the back.
    • Perl is so Web 1.0, though! Remember back in the day when all the Slashdot posters loved to talk about their awesome Perl skills? Kids these days use AJAX and such... back in my day we wrote web applications in COBOL and we were glad to have it!.
    • http://en.wikipedia.org/wiki/PerlScript [wikipedia.org]

      Neat, in a way. I recall playing a very VERY small bit with this ~5ish years ago, I believe. Not sure how useful it is, but it still warms my perl-loving heart.
    • That's a nice idea, but I think that client-side PHP is the wave of the future. getPHPScript('today')!

      No, wait. I think it was get_php_script('today'). Or was it get_today('script', _PHP_)...?
  • by trybywrench ( 584843 ) on Monday April 28, 2008 @02:31PM (#23228576)
    writing a java VM in javascript? *head asplodes*

    that's pretty cool but man, talk about a daunting tedious task. I'd rather bail 600 acres with a weed wacker and twisty-ties.
  • by serviscope_minor ( 664417 ) on Monday April 28, 2008 @02:37PM (#23228622) Journal
    Ok, so maybe we can run python in pypy in ironpython in java in javascript.

    Now all we need to get is a C compiler to output python code. If someone can then write an x86 VM in python we could then run Linux in Firefox!
    • by pjt33 ( 739471 )
      Prolog in Javascript [ioctl.org] is available too. I first ran across an earlier version of this in a compressed form as an entry to the 5k competition: show off what you can do with 5k for your entire website.
  • * Urk * (Score:3, Funny)

    by Tarlus ( 1000874 ) on Monday April 28, 2008 @02:47PM (#23228732)
    Anybody else twitch at the sight of that headline?
    • by Z34107 ( 925136 )

      I know I twitched a little when I read the "Java in Javascript" part. A really neat hack, tho.

      Thing is Internet Explorer has supported lots of languages - even those not meant for a web browser! - for writing full-featured client-server code. They're called viruses.

  • by Decameron81 ( 628548 ) on Monday April 28, 2008 @02:55PM (#23228814)
    As a side note: "orto" in argentina means ass. I don't think I'd want to run anything through it.
  • So how Orto different from Google's Web Toolkit? Does it accomplish it's goal without AJAX?
    • by jrumney ( 197329 )

      GWT is an API. You write your server side java code to use the GWT library to do its display instead of one of the alternatives like AWT, SWT or Swing. GWT then takes care of sending the right Javascript to the client to do the display. The client never gets sent any Java.

      This is a byte code interpreter written in Javascript. You send it compiled Java, and it interprets it using Javascript. Presumably it has limited support for one of the aforementioned graphics APIs, probably AWT, and probably only enoug

  • Why the hell would you use a JVM in Javascript when there are Java plugins for every major browser anyway? The only good use I could think of is if you want Java to run on some user hostile DRMd machine that doesn't let you do Java but lets you do javascript.
  • While Ruby and Java are nice and all, I give you Brainfuck and Ook! [virtuelvis.com].
  • by bigsexyjoe ( 581721 ) on Monday April 28, 2008 @03:27PM (#23229220)
    Clearly the top application of this project is me playing that Tetris game and telling my boss that it's research for my job.
  • by Kryptikmo ( 1256514 ) on Monday April 28, 2008 @03:30PM (#23229258)
    They don't know if it works properly yet - they're still waiting for it to finish running "Hello World"....
  • That means it's as cumbersome to program in as Java and even slower than JavaScript. What more could you ask for?
  • Month 1: Developer A writes a relatively complicated Java program. Developer A compiles it to bytecode, runs it through Orto and deploys resulting Javascript to company's webserver. Developer A writes no documentation.

    Months 2-6: Developer A continues to write no documentation concerning his work in Month 1.

    Month 7: Developer A quits, resigns, is fired, or otherwise disappears.

    Month 8: Developer B -- Developer A's replacement -- is asked to fix several bugs in the company's web pages. Developer B opens u
  • The JavaScript Ruby interpreter is faster than the "real" one
    • It is faster than Ruby 1.8.

      However, it is running with the aid of Ruby 1.9 on the server, so I suspect that actual Ruby 1.9 is faster.
  • I'd like to point out that there are already two implementations of java on javascript aside from the one in the article:

    1. Google Web Toolkit compiles java to javascript.
    2. XML11 project actually implements the JVM in javascript. That's right, their script *interprets* and *executes* java bytecode. They let you do things like run existing AWT applications unmodified, by emulating AWT in HTML. Of course, this was pretty slow the last time I looked.

The fancy is indeed no other than a mode of memory emancipated from the order of space and time. -- Samuel Taylor Coleridge

Working...