Slashdot Mirror
Ruby and Java Running in JavaScript
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.
Finally, a way to combine the feature-rich capabilities of Javascript with the speed of Java!
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!
Good, inexpensive web hosting
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.
Proudly supporting the Libertarian Party.
Still with the "Java is slow" comments. Jeez.
Also worth mentioning that PyPy allows you to run Python as Javascript, inside a browser. Like all of these things, it isn't 100% mature, but pretty cool nonetheless.
While not exactly the same thing, the Google Web Toolkit (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.
Bradley Holt
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 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.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
It's especially amusing when it comes from people who predominately use Python or Ruby.
This just reminds me of the "octoparrot" from The Simpsons. "Braawk! Polly shouldn't be!"
Use the Firehose to mod down Second Life stories!
Congratulations! Sounds like a very secure platform. Maybe there's time to include it in IE8.
'Orto' means 'ass' in Spanish.
Client side perl would kick ass. Then I could match my front end with the back.
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.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
One word - Slllllllllllllllloooooooooooooooooooooow!!!
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!
SJW n. One who posts facts.
The primary reason its okay for python to be slow, but not for java, is that python isn't a crippled version of C++ that runs at 1/10 the speed, whereas java is.
That, and the fact that you can rewrite the performance-critical portions of python code in C if you need to.
> Because neither one is slow enough on its own?
Yes, but this way you get the speed of Java, and the strongly typed, fun to develop world of Javascript.
http://www.haskell.org/haskellwiki/Haskell_in_web_browser
Matt
Anybody else twitch at the sight of that headline?
/* No Comment */
Java is still slow.
All what is needed now is an implementation of Javascript in Java (and possibly have it be compiled).
As a side note: "orto" in argentina means ass. I don't think I'd want to run anything through it.
diegoT
So how Orto different from Google's Web Toolkit? Does it accomplish it's goal without AJAX?
Finally the name JavaScript makes sense
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
or GWT?
Because you can - or because you should?
Python and Ruby have nice foreign function interfaces/or making C extensions for them is easy. Java makes it a pain (on purpose, Sun doesn't want anything that isn't portable across the JVMs) to write JNI stuff. So, when Python is too slow for a task, you write the part in C and be done with it. Try the same with Java and you will want to gouge your eyes. Fuck JNI.
That and the fact that Python and Ruby are a lot more high level languages than Java. Java is just a crippled C++ with garbage collection and running on top of a virtual machine. It's nothing exciting.
Now all we have to do is compile that Javascript into bytecode with Rhino, and it will tear a hole in the fabric of space and time.
Saying that Java is a crippled version of C++ that runs at 1/10 the speed is idiotic and only displays your ignorance. You're just parroting what you've heard from other ignorant retards. Java has a ton of significant problems but people like you continuously bring up points that are either wrong or completely irrelevant. Based on your posts I doubt you understand much about Java or the JVM.
By the way, you can obviously rewrite critical portions of Java code in C as well... Being able to call out to C is not an excuse for the current Python and Ruby implementations being complete trash. There are lots of languages that provide a similar level of abstraction that have far better performance and a threading model that isn't a complete joke.
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!.
http://virtuelvis.com/
Brainfuck has been available for JavaScript for years!
Clearly the top application of this project is me playing that Tetris game and telling my boss that it's research for my job.
Democracy Now! - your daily, uncensored, corporate-free
They don't know if it works properly yet - they're still waiting for it to finish running "Hello World"....
There are people who love Java and those who hate it. You missed a chance to trash it, so you are not of a former variety :)
DLR in Silverlight 1.1 and 2.0beta already has Ruby/Python/compiled Javascript and C# on the browser. F# for functional programming is coming soon.
Under their VM, it's 1000x faster than interp JS.
I know this will go under the "lalalalalalalalalalala I cant hear you lalallaallalal" camp, but someone needs to say it's already been done.
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.
The most interesting part in the last link is that the following process:
..is somehow 5x faster in their example than running the same ruby script on Ruby1.8 as a shell script on the commandline. Their example is incredibly simple, but I am still surprised that it wasn't 5x slower.
- Ruby code in tag sent to the server via XMLHttpRequest
- Code recieved by a Ruby1.9 Cgi program.
- Cgi script compiles the code with YARV to opcodes and sends it back formatted as JSON.
- Browser takes the Ruby opcodes and translates it to javascript with HotRuby and runs it.
In any case I can't wait to be able to have all my application code written in Ruby.
http://en.wikipedia.org/wiki/PerlScript
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 means it's as cumbersome to program in as Java and even slower than JavaScript. What more could you ask for?
That and the fact that Python and Ruby are a lot more high level languages than Java. Java is just a crippled C++ with garbage collection and running on top of a virtual machine. It's nothing exciting.
Pardon my ignorance (I've never played with either Java OR virtual machines...) but has anybody ever created some sort of platform where each C++ app runs in its own VM? Wouldn't that give you nearly full c++ performance, while also giving nearly Java's security and memory protection?
Too bad it's compiled to JavaScript rather than interpreted. That would have enabled secure execution of foreign code... and be the worst performance achievement in history.
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 up the Javascript and freaks out while looking at auto-generated Javascript. Developer B slowly but surely makes his way through the Javascript and makes required non-trivial changes, updates and modifications.
Month 9: Developer B flees the scene.
Month 10: Developer C -- Developer B's replacement -- is asked to fix several more bugs in the company's web page. Developer C opens up the original Java program. Developer C opens up the company's deployed web pages with embedded Javascript. Developer C spends several hours looking from one to the other and then back again. Developer C submits the resulting mess to thedailywtf.com and then runs screaming from the building.
To all potential Developer C's out there: Start running!
"Flag on the moon. How did it get there?"
... these.
OMeta: http://www.cs.ucla.edu/~awarth/ometa/
The more recent OMeta 2.0: http://jarrett.cs.ucla.edu/ometa-js/
And, of course, COLA - http://piumarta.com/software/cola/
Self-sustainment, anyone? ;-)
One more link: http://www.swa.hpi.uni-potsdam.de/s3/
I haven't kept up with Java--has its speed really improved, or is it just that hardware has caught up enough to make delays primarily the result of waiting for user input?
When I first started messing around with Java (fairly shortly after it was released), it really was much, much slower than compiled code of just about any language. I wasn't a big Perl user at the time, so I really couldn't compare, and the joy of Python wasn't even a twinkle in my eye.
Java is slow when done inefficiently, like any other programming language. In Java code that is implemented correctly, speed will be one your lesser worries. In fact, under certain conditions, Java can rival, and even surpass, native code for speed. The implemented correctly is a much bigger one.
brandelf -t FreeBSD
Hey, I used to have a TI 99/4A. Great little machine, back then!
College-Pages.com - Online Colleges, Degrees, and Programs
What ? You mean a Turing complete language can be compiled to another one and still run on a Turing machine ? Oh noes, my world view collapses!
The JavaScript Ruby interpreter is faster than the "real" one
Game... blouses.
Yes, in the early days, the byte code interpreter was just that - an interpreter, and the garbage collection was naive and blocked all threads when it kicked in, leading to the notorious GC pauses at random times (great for all those Java games that sprung up in the early days).
After Java 1.2 was released, Sun released a drop in replacement "Server VM" which had "hotspot" compilation, where programs were profiled at runtime and parts of the code that were frequently called were compiled to native code. In Java 1.3, this became the default VM on Unix platforms, and incremental garbage collection was introduced as an option. Both the hotspot compiler and the garbage collector have continued to be improved, to the point where there is no longer a distinction between server and client VMs and at some point generational garbage collection was introduced to speed up collection of short-lived objects. The focus now in 1.6 seems to be on improving startup time by loading only parts of the standard class library that are needed, instead of loading the whole lot at startup, and improving download time by downloading parts of the JVM on demand (the latter feature is currently in beta).
After reading that page, I see that it's a wordplay. Orto is taken from Greek which means "recto" (straight) or "correcto" (right, as opposed to wrong). "Recto" also means "rectum".
The best way to predict the future is to invent it
Yes, it's much faster now. Now JVMs perform on-the-fly optimisations much like the ones C compilers do at compile time, but since they're done at runtime, they can very specifically target the runtime context like your CPU model. Even though a specific optimisation set in a static compiler can do the same or even better, at runtime you get more information and more flexibility like being able to turn off synchronization when there's no chance of contention anyway.
Version 6 of Sun's JVM now regularly outperforms even finely optimised C/C++ code for many tasks, and cuts through layers of abstraction and encapsulation so you don't have to clutter your code to speed it up. There are still many problems left for Java's performance, but they're going away, meanwhile C/C++ still have huge problems in language design and ease of development that are *not* going away.
As an aside, the fact that Java has constantly-on features like garbage collection, bounds checks, null pointer checks, type safety checks, JNI call checks, etc. and STILL performs comparably with C/C++ code lacking these features, is a strong sign that the JVM itself optimizes code *very* well. If you turn all of these things off it goes even faster, but as a developer I like to have as much confidence in my code's correctness as possible, and doing formal proofs isn't fun.
Sam ty sig.
The Perl 6 people were targeting javascript with KindaPerl6.
has existed for ages...they are called Applets. Every browser supports them.
Thanks to you and jrumney for the explanations.
It seems like Java really has a bad case of "first impression syndrome." At the time, the only thing that it really seemed to have going for it was wide compatibility--and even that was not always true (I've had to deal with incompatibility issues between JVM versions in some applications that we support.) It sounds like Java is pretty nice now, so I may have to give it another look.
I understood that Java was an OOL, but failed on the whole JS understanding.
/. moderators give you some 'informative +' love.
/.*... based on that, I feel compelled to add you to my 'Friend's' list here, so be forewarned if your pref's advise you on the change/message. (have not checked your user page,etc.)
Thanks to your reply, I now know enough to differentiate the two: In other words: Java !=JS. I sort of get it and heartily thank you for the informative reply.
I sincerely hope the
I did not really get the diff, but see now I have more learning and research to do, as I do want to 'get it'.
I guess the whole 'Java' vs. 'Javascript' is confusing to n00bs (or 'us morons') since they both contain the (unrelated) root word:java.
Again thanks for a respectful and informative reply that can forward the conversation constructively...*can be a rare thing here on
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
Exactly. JIT'ed code performs quite well.
For anyone trying to make a Java program run faster, the first thing I always do is look at the profiler output (java -Xprof Foo) and see how much time is spent in the GC. If it's more than a couple %, you've got too many new's and too much garbage collection going on -- and 5% time in the GC represents far more than a 5% performance hit, thanks to thread switching overhead and thrashing the CPU caches. Basically, never ever have a new in an inner loop -- you wouldn't put a malloc there in C, so don't put a new there in Java.
If you've taken care of that, and it still runs slow... Look to what API calls you're making. Are you adding single characters to Strings a lot (they're final; there's a hidden new and lots of copying in that operation)? Making lots of system calls that produce context switches? Basically, attack it like you would a C program, and you'll get good results. Why people manage to optimize C code well and not Java is beyond me, given that they use similar tools to do so...
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.
Comment removed based on user account deletion
Orto means "Anus" in spanish.
Okay, we do multi-threaded number cruching and that involves wait()ing, but is that high amount of waiting normal? Could it be an indicator of using too many worker threads (which would make sense as I tested with a small data set and thread-happy settings)?
Oh, and we spendi upwards of 10% of all ticks with the GC, which is probably bad, as your post points out. Is there any way to determine where the GC spends the most time cleaning up without digging through the code? I'd love to make the app faster (as it needs to crunch absurdly large amounts of text), but a full-scale code evaluation would be too much effort and I have other things to do.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
I don't know of an easy way to figure out what the GC is cleaning up. -Xloggc and such may help, or may not. I would say that much waiting is a bad thing -- you should likely be doing less of it, though how to accomplish that I can't say without seeing the code.
You say you're doing text crunching; I'd look for string ops as possible culprits for the GC activity. Remember, for Strings, a = b + c involves a hidden new -- and therefore a GC operation if a has been initialized before (all string objects are constants). If you're doing any sort of modification of strings, ie not just reading numbers but breaking strings up into lines and such, you probably want to consider using a CharBuffer, or possibly a char[] array, depending on what you're doing.
The dirty hack method of reducing GC time (only sometimes works) is to give the JVM too much memory at invocation (-XmxBIGNUM -XmsBIGNUM), and then call System.gc() occasionally and hope to do your garbage collecting in large chunks.
Oh, almost forgot, and it's a big one -- assuming you're using Sun's JVM, are you running server or client mode (-server or -client)? It can make a big difference on some apps, and it's worth trying both ways. My guess is your app does better under the server JVM, and it defaults to client...
Anyway, good luck. Java performance tuning isn't too hard; just watch out for hidden operations. There are much better tools available, but just running -Xprof is a pretty decent start.
I bet it performs about as well as C++ programs running under a Visual Basic interpreter.
More than half the comments so far are "why would you do this? it'd be slow!" or "I don't see the benefit of this" or "I would not recommend this enterprise architecture".
Gaaaa!
People, you're supposed to be nerds. Sometimes nerds do things just for the fun of it. Because they can. Look at the comments from a mere 8 years ago about the HTTPD server written in PostScript (and in shell, and in assembly). What's happened in the meantime? Did you all go get MBAs? Did you all start kissing girls or something?
Advice: on VPS providers
This looks more like the kind of stuff that some programmer created just to amaze other programmers.
If it's gonna end up being a js app it makes more sense to me to code it in js from start to finish, i don't see the point in coding it in java first.
But anyway, amazing stuff!
Really sorry about harshing your mellow, man.
Thanks for the extra time to reply. It just gets frustrating sometimes to be slapped with something you have not been informed about without any chance for ref's other than a Google search...which can yield many hairy results to wade through.
I guess it's a matter of experience and perception.
BTW, I consider myself a *nix n00b, but I am trying to soak it all up like a dry sponge....but there is a lot out there, and only so many hours in the day!
Now I am going to take my frustrations out by playing Fallout2 and fscking up some stuff! (via WINE on Kubuntu 8.04--just finished Fallout1...again! then opened another beer!)
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
The problem with giving the JVM too much memory is that we will later spawn off a number of worker threads, each of which will potentially use several gigabytes of memory (the most labor-intensive things we do are cooccurrence analysis and clustering and those are memory hogs). If what I've ben told is correct, giving the JVM lots of memory means that any threads it later spawns get less, which would be undesirable.
The -server tip worked well, however. On my minimal data set I cut processing time from 12 to 8 seconds with only 4% of all ticks spent with the GC. It now spends 11% of the ticks on compilation, but that number will likely decrease to nothing when tested with a real data set.
Thanks for the tips. I'll bring your post up at the next project meeting.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Now you are being unfair. Java code runs often runs at almost half the speed of C++, and have a few features (such as better enums, reflection, simpler parse) which C++ doesn't.
If you use the server VM, the java VM can actually inline code. Amazing!
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
Microsoft Live Labs is working on a similar project to translate CIL (.NET bytecode) to JavaScript as part of their Volta project. It's part of a larger effort to allow you to write both the client-side and the server-side code in the same project and then have a post-processor split the resulting assemblies and generate all of the boilerplate RPC code to make the client-side bits run on the client and the server-side bits run on the server.
Parent makes a good point...
A true nerd would build a robot to kiss a girl...
Related to this, here is a nice overview of the current state of various Ruby implementations (including a brief discussion of the javascript one) by Charles Nutter one of the lead developers of JRuby: http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html
Jilles
Ok, I just ran a few quick benchmarks of Sun's Java 6 vs. g++ from GCC 4.3 and I see 1.2 to 2.5 times slower performance for Java. Where are you getting your ideas about performance from?
See the language benchmark shootout for all your implementation comparisons! ;-)
Comparable can be better than or lesser than, as long as it's close enough to bother comparing. I think you're just trying to pick holes in my brief report of what many many Java developers have already benchmarked for their own purposes, including myself.
What code did you compare? I said "regularly outperforms even finely optimised C/C++ code for many tasks", not *all* tasks. The plain fact is that runtime optimization can beat static optimization, and Java does it occasionally. It's safe to say that in Java 7 it will be even better, with more cases meeting or exceeding C/C++.
And keep in mind, while C/C++ *can* be optimized manually with tedium like moving code to headers (so it can be inlined), declaring constants (so they, and their resulting code, can be inlined too), etc., at runtime in the JVM this kind of work is automatic. You generally don't have to sacrifice your cleanliness and abstraction to make Java optimize well, except in currently lacking cases like boxed primitives (which will remain boxed and therefore slow - yes, I benchmarked that too).
Sam ty sig.
I'm a little befuddled by lack of sleep, but the talk of ass and matching front ends with back made me think you were suggesting that Perl would be involuntarily sodomizing someone. In my defense, we are talking about Perl here -- its not like the comment would be terribly out of bounds.
Help poke pirates in the eyepatch, arr.