JavaScript JVM Runs Java

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

Comments

Javaception

[embolalia]

So you could write a browser that supports JavaScript in Java, and then run the browser in itself?

Re:Javaception

[linuxgeek64]

It doesn't implement that much of the standard JVM.

Re:Javaception

[Anonymous Coward]

I hope it supports applets at least. Since applets are rarely supported by the browser itself.

Re:Javaception

[DigiShaman]

Ouroboros?

Re:Javaception

[cb88]

Sun already did that with HotJava it supported javascript.

Re:Javaception

[afabbro]

10 Write Browser in Java

20 Write Javascript engine in Browser

30 GOTO 10

Re:Javaception

[KarolisP]

I have a feeling it would take a bit more lines than that :D

Re:Javaception

[game kid]

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

Re:Javaception

[Joce640k]

Ummmm, Java != Javascript.

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

Re:Javaception

[Anonymous Coward]

The article is about a JVM that is written i Javascript. Think before posting please.

Re:Javaception

[TheInternetGuy]

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:Javaception

[DrXym]

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:Javaception

[Robert Zenz]

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

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

Re:Javaception

[sydneyfong]

but it wouldn't be "virtually impossible"

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

Re:Javaception

[alexhs]

So you could [...] run the browser in itself?

Old news. Try chrome://browser/content/browser.xul in Firefox (doesn't seem to work as a clickable link, though).
See here for more options.

Re:Javaception

[deniable]

Geeks: making Marketing's screw-ups reality since the beginning of time.

Re:Javaception

[StripedCow]

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.

I'm betting that somewhere, somebody is already writing a browser in NaCl.

Re:Javaception

[DrXym]

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:Javaception

[Lennie]

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/

Re:Javaception

[somersault]

Bonus points if you can do networking using multiplayer characters in mine carts.

Re:Javaception

[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 would have a method execute_instructions(number_of_instructions_to_execute) which would be called). Since, from the JVM's point of view, everything would run strictly synchronous, synchronization would not be an issue. Note that you'd not even use a timer.

Re:Javaception

[Anonymous Coward]

First post!111!!

Re:Javaception

[DrXym]

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

[Anonymous Coward]

A more interesting loop would be this:

Write Editor with Lisp interpreter in C. (check)
Write Browser with JavaScript interpreter in Lisp. (partial check -- I don't think w3 supports JavaScript)
Write JVM in JavaScript. (check)
Write x86 emulator in Java. (check)

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:Javaception

[Zortrium]

Warning: shameless self-promotion ahead: I've also written my own JVM interpreter in JavaScript, 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?

Re:Javaception

[jonbryce]

I think the idea is that the browser could run itself inside a window.

Re:Javaception

[EdgeCreeper]

Or this?

Re:Javaception

[larry bagina]

Sun used to have a browser written in Java. It was supposed to be really awesome but when I tried it (in 2000 or so), it was ugly and outdated.

Re:Javaception

[Anonymous Coward]

The JS is running in a browser.

You don't need a browser to run javascript. No clue where you got that idea from.

Actually, any application that has scripting requirements can embed javascript, for example (but not limited to) games, gameservers, and a certain NoSQL database. You could go as far as running javascript stand-alone, offering only some basic IO functionality.

Re:Javaception

[nschubach]

For instance...

See: http://nodejs.org/

JavaScript outside the browser.

Re:Javaception

[Anonymous Coward]

Reminds me of the claim by the marketing department of one company that their virtual machine executed code 1.5 times faster than native compiled code on the same platform. So in theory, having a chain of virtual machines running instances of that virtual machine would execute code with exponential performance limited only by the number of virtual machines in use.

Re:Javaception

[DrXym]

I never said you needed a browser to run JS, but that is where it is typically run.

Re:Javaception

[Rysc]

That isn't shameless self promotion, that's topically awesome.

Re:Javaception

[Rysc]

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

[Darinbob]

Threads aren't hard. You don't need OS support for threads, and if you're at the byte code already then it's trivial. Essentially the Javascript is just emulating a computer.

Really, there's nothing new or special about this trick it's been done for decades in other languages. All it shows is that Javascript isn't as primitive a language as some may have thought.

Re:Javaception

[Darinbob]

Ah, you may be missing the key point there. The Java inside a JVM written in Javascript is not intended to actually be a practical thing to do in a browser. The performance may be too slow even single threaded or be highly dependent upon the performance of the Javascript engine. This is just a cool hack and not a breakthrough to help out some IT team. The JVM has to be written in some language, so why not Javascript?

Re:Javaception

[Spudley]

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.

Re:Javaception

[recharged95]

So, what takes 10secs to startup in JavaScript will take 10mins in the Java version under the Javascript engine.

Re:Javaception

[DrXym]

In browsers you would have to. Browsers are event based - GUI events and timers cause JS to be executed. The browser executes JS associated with an event and synchronously waits for it to complete before it can do anything else (e.g. update the DOM / layout). If the JS never returns the browser becomes unresponsive and eventually complains to the user about the JS and asks if it should be stopped. So if you were running a JVM in that environment you would most likely have to find some break point during JVM execution to halt execution, save state, set a timer and return to the browser. When the timer fired you would wake up again, restore state and continue for another timeslice.

I realise JS doesn't have to run in a browser, but I would argue that the most useful place for a JVM over JS would be in a browser. It doesn't make sense to me to want to run a JVM over JS on a server or in a standalone JS script because in either place it would be likely be easier to install and invoke a proper JVM which wouldn't suffer from any limitation or slowdown associated with running over JS.

Anything which can be written in JavaScript ...

[Musically_ut]

... will be eventually written in JavaScript. ~ Atwood's Law (circa 2007)

Not A New Concept

[DERoss]

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

[bucky0]

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

Re:Not A New Concept

[afabbro]

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:Not A New Concept

[Joce640k]

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

[TheRaven64]

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

Re:Not A New Concept

[lucian1900]

Even CoffeeScript is self-hosted.

Re:Not A New Concept

[wed128]

No it wasn't; if it were, how was it compiled?

likely C++ features grew in C compilers (like cancer), sort of like how C99 features were implemented in GCC.

Re:Not A New Concept

[Just Some Guy]

The JOVIAL J4 compiler was itself written in JOVIAL J4.

Want something really mind-blowing? PyPy 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 than the native C Python. I've used it and I still can't quite believe it.

Re:Not A New Concept

[Anonymous Coward]

Not completely true. PyPy is written in RPython, which is a restricted subset of Python that is easily translatable to C code. Then this C code is compiled into a VM with a kickass JIT compiler.

The PyPy project is actually designed to make writing virtual machines with a good JIT easy to do in its restricted subset of Python. The PyPy interpreter is a proof of concept of writing the python virtual machine inside of the PyPy environment.

Re:Not A New Concept

[wed128]

http://en.wikipedia.org/wiki/Bootstrapping_(compilers)#The_chicken_and_egg_problem

Re:Not A New Concept

[wondershit]

There is a JVM targeted for research named Maxine that is written in—you guessed it—Java. It needs to be bootstrapped by another JVM in order to compile itself with its JIT compiler and after that it runs by itself. I recently attended a talk by one of its developers and it looks very interesting.

Re:Not A New Concept

[Darinbob]

This is traditional. Many (maybe most) compilers are eventually written in themselves. This is particularly true of older compiler where the new language is more expressive than the older ones, so certainly you'd prefer writing Pascal in Pascal than Pascal in Fortran.

This has changed in the modern era for some reasons; it's nice to have a common backend with different front ends for different languages, such as with GCC, and porting the backend optimizers for each language is cumbersome and makes maintenance a pain (find a bug in the C backend then you'd have to see if the same bug was in the C++, Pascal, Fortran, Java, Euler, Eiffel, or whatever backends).

Of course the first compiler has to be written in a different language. This is what trips up students because they hear "Ada is written in Ada" and start getting dizzy. But if they learn instead "Ada is written in Pascal first and then later written in Ada, and then later written in Ada again, and then later in Ada again, and so forth". The first C compiler was not written in C.

Interesting too are things like Forth cross compilers written in Forth (often called meta compilers or meta Forths). There even the assembler code is written using Forth syntax, and the Forth code will hop back and forth between different domains: target run time, target compile time, host run time, host compile time.

Re:Not A New Concept

[Darinbob]

The first C++ was CFront. Which was written in C and produced C output instead of assembler or object code. But there are people out there who seem to feel that CFront wasn't really a compiler and just a simple translator (untrue), so I suspect they may think that the first "real" C++ compiler was in C++ but they're just messing up the definitions.

C was not a proper subset of the very first C++ language semantics (mostly with respect to typing rules), so you can't even say that the first C++ was compiled with a subset of C++.

Re:Not A New Concept

[Darinbob]

Writing a compiler is a good test of being able to support relatively complex data structures, complex algorithms, and requires a fair amount of coding organization. A language that fails some of these will make writing a compiler in itself a bit painful. It's reasonable proof that a language is general purpose.

Practically though, the reason many wrote a compiler in itself is that they preferred the new language to the old language. I'd much rather write a newer compiler in C++ than in C (or at least a subset of C++) just because it makes a lot of things easier. C is typically used for the pragmatic reason that it's the C compilers are the most commonly available. When GCC was new just about every machine it was ported to had a C compiler already, and just about every new architecture coming out has a C compiler from a vendor soon enough. The intent of GCC was was that end users could download the sources to their machine and compile it there.

Re:Not A New Concept

[larry bagina]

In October of 1979 I had a preprocessor, called Cpre, that added Simulalike classes to C run- ning and in March of 1980 this preprocessor had been refined to the point where it supported one real project and several experiments.

...

Cfront was originally written in C with Classes (what else?) and soon transcribed into C84 so that the very first working C++ compiler was done in C++. Even the first version of Cfront used classes heavily, but no virtual functions because they were not available at the start of the project.

yo dawg

[Anonymous Coward]

So we heard you like java...

Hey Bro...

[bennomatic]

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

Re:Hey Bro...

[Mitchell314]

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.

Re:Hey Bro...

[Anonymous Coward]

Those who care know there is a difference, those who don't ask for a mug...

Re:Hey Bro...

[PCM2]

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:Hey Bro...

[DrXym]

It is a compiled language. It's compiled into bytecode. Whether it's optimized or not is a function of the compiler implementation. It's true the default compiler doesn't do much optimization,but that doesn't mean it is not possible. The Eclipse compiler and Jikes have some optimization settings and you always run a file through proguard too.

Re:Hey Bro...

[deniable]

They're working on JIT compilers though. Not sure when they'll be ready. It will allow the local machine to optimize the byte-code for local conditions.

Re:Hey Bro...

[deniable]

Just run it inside VMWare or Virtual PC and you won't have any problems.

Re:Hey Bro...

[TheRaven64]

What is this, 1998 appreciation day? They were working on JIT compilers for the first release of Java! Modern JVMs all use JIT compilation extensively. The only ones that don't are ones designed to run on very small embedded systems, which use Jazelle, which is basically a Java bytecode decoder on the front of an ARM chip that executes most bytecodes directly and traps on the difficult ones.

Re:Hey Bro...

[Trails]

...so I get a mug?

Re:Hey Bro...

[JSBiff]

"my tears will probably fall sideways upwards now."

Even worse, they just stay at the surface of your eyes and pool in your eyes so you can't see, which makes you cry more, and then you see even worse. . .

DOM-Interface for byte code

[maweki]

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

Re:DOM-Interface for byte code

[Anonymous Coward]

Even sandboxed in a VM, I'd be inherently wary about executing server-compiled byte-code. Isn't this why we got rid of Flash?

Re:DOM-Interface for byte code

[xororand]

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:DOM-Interface for byte code

[devent]

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:DOM-Interface for byte code

[martin-boundary]

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?

Re:DOM-Interface for byte code

[hpoul]

well, somehow google thinks javascript IS bytecode :) they compile java to javascript (GWT) and (until it's supported in any browser) their own language http://www.dartlang.org/ (dartc) .. so the missing part is not the browser-bytecode.. simply write your compiler to output javascript instead of bytecode ;)

Re:DOM-Interface for byte code

[devent]

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

Re:DOM-Interface for byte code

[Anonymous Coward]

Um, so? (sincere question, not being a prick.)

The web already exploded. We're now well past that DIY point.

Yes, sure some enthusiasts still code their own, but we're way past where knowing some HTML was how you got a site up. Individuals have long moved to templates - blogs, wordpress, facebook, tweets and whatever.

Browser incompatibility successfully killed the original DIY plan. I'm nostalgic and sentimental about it, but it's gone. Coding is a pro game now. So why not byte code?

Re:DOM-Interface for byte code

[jimicus]

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 - there were a few ways to do it and unless you did it a particular way, you wound up with an applet where the widget text was only readable on Windows.

Re:DOM-Interface for byte code

[chrism238]

"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." You're not Andrew Tanenbaum by any chance, are you?

Re:DOM-Interface for byte code

[Bomazi]

It is not 100% working yet but it already exists. There are standard java bindings for the DOM. As an example, rhinohide allows java applets to access the DOM via the standard bindings thanks to a javascript bridge. In this demo, which should work in firefox, a java applet modifies the document it is embedded in via this mechanism.

Re:DOM-Interface for byte code

[the entropy]

Yes, but what is different about what the first poster in this thread was suggesting is for that bytecode to have DOM bindings. Java applets were self-contained applications that ran in a window within the page and touched nothing outside of that(and had to do all the drawing themselves and were completely inconsistent with the rest of the page with regards to look and feel as a result).

What is being suggested here is something that would replace javascript that would interact with and modify the whole page through a DOM interface, completely unlike an applet and much more useful.

Re:DOM-Interface for byte code

[jimicus]

Ah, I hadn't fully registered that.

You're quite right - but then you immediately start to run into sandboxing & security issues.

Re:DOM-Interface for byte code

[the entropy]

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 popular products and services for that matter).

Re:DOM-Interface for byte code

[Lennie]

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.

Re:DOM-Interface for byte code

[Lennie]

I think that is called CoffeeScript.

Re:DOM-Interface for byte code

[TheRaven64]

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?

Re:DOM-Interface for byte code

[gbjbaanb]

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

[tepples]

Flash hasn't been proprietary since the Open Screen Project relicensed the SWF specification to allow making competing players.

Re:DOM-Interface for byte code

[devent]

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,Groovy,Java,Closure,JRuby,Jython,LUA, and JavaScript for the browser. Just take the current JVM, add some DOM-API to it and be done with it.

But, no, they had to add some stupid patents to JVM and some stupid politics about the license. So now we still have JS VMs that are like the JVM was in 1995 and with single language attached to it.

Re:DOM-Interface for byte code

[martin-boundary]

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.

The difference between programming code and bytecode may be subtle in special cases, like the difference between BSD and GPL, but the long term effects are major.

Re:DOM-Interface for byte code

[martin-boundary]

The web already exploded. We're now well past that DIY point.

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 combines several ideas and pretty soon you have a full email app in a browser, etc.

Re:DOM-Interface for byte code

[martin-boundary]

Slowness is not a real issue, it's merely a symptom of inefficient javascript interpreters and inefficient threading in the browser. Fix the browser, and slowness won't be an problem. Neither is code size, btw. The difference between bytecode and source code isn't noticeable on today's fast network links, especially with all the other crap that's loaded in a modern web page.

Re:DOM-Interface for byte code

[lucian1900]

JavaScript is always minified anyway. There's a difference between development packages and distribution packages.

Re:DOM-Interface for byte code

[broken_chaos]

No kidding. I 'disassembled' the YouTube JavaScript once, and I still have nightmares.

Re:DOM-Interface for byte code

[am 2k]

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:DOM-Interface for byte code

[am 2k]

but then you immediately start to run into sandboxing & security issues.

In which way is this different to current JavaScript implementations?

Re:DOM-Interface for byte code

[devent]

Did you even visit http://code.jquery.com/jquery-1.7.min.js ?
I would say that's byte code, with just happens to have some ASCII characters in it, instead of just byte tupels.

In Java almost all important libraries are open source, but very few people would download the source code, they are just happy with the compiled .class (i.e. a jar) files. The same is true for all compiled languages, and for some interpreted, like python.

As long as the license is open, the original code available, and the common practice of using minimized JS will increase, I don't see any problem or difference with byte code.

Re:DOM-Interface for byte code

[Toonol]

There's no reason bytecode would be any less secure than running javascript or any other interpreter. Bytecode is just a language with a simple syntax, optimized for fast interpretation. I'd think the simplicity would make it more secure.

The problem isn't security, it's standardization.

Re:DOM-Interface for byte code

[trenobus]

For years I've been saying that we need a DOM-Interface for byte code in Browsers and everytime I get downvoted

For years you've been right. But now that dream can no longer be denied by the browser venders.

Much of the stuff that doesn't make sense in the way we use computers can be attributed to competition between rival companies (or groups). Often competition can be a good thing, such as the current competition of browser venders to make faster Javascript implementations. But sometimes a much better result can be obtained by people cooperating to make a single standard that is in their long-term mutual interest. I believe Javascript became a standard by stealth. If the marketing departments of the companies involved in its standardization had known what it would become, they would not have allowed it to happen. Had they realized the need for large-scale, client-side programs, they would have continued to push proprietary solutions, as Adobe in fact did.

The thing is, now that the browser venders have been suckered into making Javascript a capable platform in its own right, they can no longer control what developers choose to implement on it. If developers chose to standardize a byte code implementation, and then targeted their favorite languages to it, the browser vendors basically have two choices to gain a competitive advantage. One is to optimize their Javascript for execution of the standardized byte code. The other is to provide a native JIT implementation of the byte code.

Another alternative for developers is to standardize the back end of a source-to-source compilation system. So there would be a front end that compiles your favorite language to a common intermediate form, and a common back end to translate the intermediate form into minified Javascript. This is not as good as the byte code solution, in my opinion, but if it gets developers writing client code in something other than Javascript, it's a step in the right direction.

Re:DOM-Interface for byte code

[martin-boundary]

Did you even visit http://code.jquery.com/jquery-1.7.min.js ? I would say that's byte code, with just happens to have some ASCII characters in it, instead of just byte tupels.

Yes I did. Bytecode is a lot worse than that. Try getting rid of functions, if/else and structured loops of all kinds and replace with gotos and memory or stack locations. The wikipedia page has an example of what you can expect in Java for example. Or start with the page on three address code.

The jquery example you point out is mainly designed to reduce code size and bandwidth costs, but if you want to learn how it does something and that file is all you have, then you can start with a well defined entry point and you can trace what's going on from there. It's painful sure, but an order of magnitude less painful than your typical VM bytecode.

Modern bytecodes are designed to be very regular because that actually helps optimizing compilers do weird transformations and reorderings that straddle several separate source code statements. If you want the gory details, read the dragon book.

Re:DOM-Interface for byte code

[martin-boundary]

forgot to talk about this:

As long as the license is open, the original code available, and the common practice of using minimized JS will increase, I don't see any problem or difference with byte code.

There are other reasons to prefer source code. Maybe you have a security plugin that flags certain code patterns, maybe you want to undo some types of anti-social behaviour like popups/unders and whatever gets invented by the advertisers in the future.

Open source is great, but its true power is limited if your browser doesn't use it. Alternatively, one could also argue that the open nature of HTML was a kind of forced open source that applied to all web content, with spectacular results.

Re:DOM-Interface for byte code

[Richard_at_work]

C# and VB.net may have differences, but they both compile down to the same Intermediate Language.

Re:DOM-Interface for byte code

[SickLittleMonkey]

=> Google Native Client.

Re:DOM-Interface for byte code

[devent]

You could use a decompiler. Here is a list of Java decompilers: http://www.program-transformation.org/Transform/JavaDecompilers
Since we are talking about making a bytecode standard, it should be very easy to build such decompilers, if needed.
In Java bytecode the method and class names are saved, so with a decompiler it's a lot easier to understand the bytecode then with the minimized JQuery code.

Re:DOM-Interface for byte code

[devent]

What have the human-readable source code to do with that argument? For such a plugin it's actually way easier to analyze byte code than the source code. As long as the byte code is a standard, which we are talking about the whole time.

I don't think that the generated HTML code have anything to do with the open nature of the web. It have only to do with one important fact: that HTML is an open standard. We shouldn't care less if (the tag) or 0x02 (the byte) is used, as long as it's an open standard.

Of course lots of HTML is written by humans so a text token is better, then a byte number.

Re:DOM-Interface for byte code

[martin-boundary]

Good luck with decompilers. A decompiler can only help with high level patterns that it can identify, but those patterns are deliberately broken by optimizing compilers as part of the optimization process. Also, different compilers (and languages) produce slightly different patterns so going the other way you'll need to know something about what language/compiler created the bytecode.

Incidentally, disassemblers for executable files have existed for many decades on nearly every OS platform, and debuggers can be used to inspect what's going on at that level. It's a popular pastime in the warez scene. But experience shows that just doesn't achieve its potential. "Proper" programming language source code is just an order of magnitude superior and more versatile.

Re:DOM-Interface for byte code

[martin-boundary]

What have the human-readable source code to do with that argument? For such a plugin it's actually way easier to analyze byte code than the source code. As long as the byte code is a standard, which we are talking about the whole time.

Like I said in the other thread, source code ("programming language code") intended for humans is higher level than source code ("bytecode") intended for compilers and VMs. It's just not comparable, but to truly understand that you have to play around with both types of code for a while. Maybe you have and still disagree, but for now I doubt it.

I don't think that the generated HTML code have anything to do with the open nature of the web. It have only to do with one important fact: that HTML is an open standard. We shouldn't care less if (the tag) or 0x02 (the byte) is used, as long as it's an open standard.

The C language is an open standard. Programs written in C and compiled into executables have existed for 30 years. Yet nobody (except for hackers who crack games) inspects the machine code in compiled executables. HTML code is one "view source" button away from being inspected.

Open alone really has nothing to do with it, it's how "high level" the code is that matters (and ultimately how motivated the person - people with average motivation attempt average tasks, people with high motivation attempt more difficult tasks). The jquery example is somewhere in the middle between fully documented maintainable source code, and bytecode.

Re:This is nonsense.

[afabbro]

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.

Interesting mind set

[sgt scrub]

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

[future assassin]

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

Re:This is nonsense.

[Arancaytar]

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:This is nonsense.

[DeathFromSomewhere]

The C# compiler was written in C++.

For now it is, sure.

Problem is speed

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

Re:Problem is speed

[Lennie]

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 performance gap. Ongoing Mozilla projects are being built to leverage inferred type information. With these projects, primarily IonMonkey, Mozilla’s next generation JIT compiler, we hope to close the performance gap with Java completely."

http://blog.mozilla.com/futurereleases/2011/11/10/type-inference-to-firefox-beta/

Yo dawg.. I heard you like Java, so

[D,Petkow]

{yo,sup} dawg, I heard you like Java, so I put an Java Virtual Machine on top of your your Java, so you can compile Javascript while running the JVM.

Re:Yo dawg.. I heard you like Java, so

[Anonymous Coward]

Yo dawg, I heard you liked recursion, so I ran a JVM inside the Rhino Javascript Engine on the JVM.

Re:Yo dawg.. I heard you like Java, so

[Robert Zenz]

Yo dawg, I heard you got Java and JavaScript swapped!

Re:This is nonsense.

[mcavic]

I'd love to see it done in PHP. Anything to avoid running a Tomcat installation would be useful.

Yo dawg, I heard you like bloat

[wye43]

... so I've put bloat in bloat, so you can wait while you wait.

Really?

[aglider]

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:Really?

[dkf]

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

Re:Really?

[tepples]

There are only two bytecodes used by JVM languages: standard JVM bytecode, used in .class files, and Dalvik bytecode, used in .dex files. All JVM languages compile to JVM bytecode. Oracle is suing Google for using Dalvik in Android instead of standard JVM bytecode.

Re:This is nonsense.

[HJED]

JVM is a run time environment not a compiler (although the environment includes a JIT compiler).
Also I think the point was javascript is seen as a less powerful language

sort of already done?

[Anonymous Coward]

Sun already made a JVM written in Java, so it can run java. see Maxine

Not mind blowing when ...

[fsckmnky]

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

Re:Not mind blowing when ...

[MLease]

Let's go shopping!

Re:First I was like D: ....

[Joce640k]

If it means not having the Java runtime installed on my machine then I see no downsides to it.

This is completely unnecessary.

[DamnStupidElf]

Fabrice Ballard already wrote an x86 emulator in javascript. Just install the standard x86 JVM inside of that and you're good to go.

Re:This is completely unnecessary.

[jenic]

Fabrice Ballard already wrote an x86 emulator 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:This is completely unnecessary.

[Anonymous Coward]

Dammit, Fabrice Bellard keeps making me feel like I am as dumb as a plate of chicken.

Re:This is completely unnecessary.

[Just Some Guy]

No kidding. "Hey, guys! I was bored this weekend so I wrote a zSeries emulator in Haskell. Anyone wanna grab a beer?"

it will be useful for ...

[georgesdev]

... justifying tera-hertz processors!

Re:it will be useful for ...

[jonbryce]

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.

Re:it will be useful for ...

[georgesdev]

make it "thousand core" computers if you prefer. I just meant this architecture was so inefficient that it would need vast amounts of hardware resource.
I'm just tired of people making inefficient use of hardware.

Re:This is nonsense.

[Shoe Puppet]

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.

Re:This is nonsense.

[Anonymous Coward]

To the bourne shell

Why now?

[thegarbz]

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?

[sydneyfong]

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:Why now?

[fsckmnky]

It's only a discovery if you're an over-enthusiastic n00b at this game.

To the rest of us, its same-old-shit-different-day.

Re:Why now?

[jimicus]

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.

Re:Why now?

[Lennie]

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:Why now?

[slim]

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

Re:This is nonsense.

[Adrian Harvey]

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

LOL awesome..

[holyshitagain]

But not surprise, since javaScript can implement a Y combinator (a Y-combinator is a function that operates other functions to enables recursion when it can't refer to itself from within itself.)

Re:First I was like D: ....

[deniable]

Microsoft JScript JVM anyone? I can see 'tweaks' to this JVM happening a lot. Then it's write once, test everywhere you can find, pray. Anything web guys can mess with...

Cute hack

[j1976]

Ok, that's about the most amusing hack since someone wrote a fully working web server in postscript: http://www.pugo.org:8080/

(Still think the postscript web server leads the list of odd hacks)

Redundant acronym is redundant

[Anonymous Coward]

"a Java Virtual Machine JVM written in JavaScript"

A Java Virtual Machine Java Virtual Machine written in JavaScript..... really?

A JVM JVM written in JS?

Right, I need to go and try to rememeber by Personal Identification PIN Number so that I can use the Automated Teller ATM Machine.

Re:This is nonsense.

[deniable]

More like writing a Python interpreter in Perl. It'll work, but you'll feel a little dirty afterwards.

Re:First I was like D: ....

[Lennie]

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:This is nonsense.

[TheRaven64]

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:

• Implementing the same algorithm in JavaScript and another language requires a more complex JavaScript compiler to reach the same speed.
• It lacks access to operating system features via standard APIs (e.g. no threads)
• It doesn't allow unsafe operations that are required for low-level programming.

The fact that you can run a slow JVM written in JavaScript doesn't address any of these.

Re:This guy needs to see a psychiatrist.

[StripedCow]

Or, more likely, he was already institutionalized decades ago and was just looking for a nice project to spend his time on.

From the notes

[kikito]

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

[slim]

Let me introduce you to Jetty.

Halting-complete

[tepples]

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:Halting-complete

[nedlohs]

Exactly. Without threads, how is a JavaScript JVM supposed to implement JVM threads?

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.

And without WebGL (which at least one major browser maker refuses to implement for security reasons), how is Java 3D implemented?

Slowly. And surely it's not a required feature of java - I would hope the java that runs on my non-3D set top box doesn't bother with it for example.

Re:Halting-complete

[tepples]

So in other words, the browser has to be even more of an operating system than it already is.

How to translate into JS?

[tepples]

Say I have an existing application, and it is cleanly separated into logic and presentation. How do I automatically translate the source code of the application's logic part into JavaScript so that I can write a new DOM-based presentation for it?

Other bytecodes

[tepples]

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.

Re:Other bytecodes

[aglider]

You hit the point, tepples. It wasn't easy nowadays, but you did it.

LBA-complete, not Turing-complete

[tepples]

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:LBA-complete, not Turing-complete

[tepples]

Everyone knows what Turing completeness is generally accepted to mean: Machines or languages that could simulate a UTM if they had unbounded memory.

In other words, machines or languages that can simulate a universal linear bounded automaton.

Turing completeness is still a useful distinction in computability since in most proofs the unbounded/bounded memory distinction can be generalized away.

Then why don't the proofs say "LBA completeness" in the first place? And I haven't seen a lot of proofs that have much to say about I/O capabilities that end users expect of a desktop or mobile computing device.

IE?

[james_van]

But does it work in IE or does it need browser detection and a bunch of conditionals before it will play nice? Seriously, JS is tolerable when you write it for a "compatible" browser, but once you throw IE into the mix it turns into the code equivalent of a water boarding session

drive-by exploits?

[xipcloud]

So does this mean instead of giving the nasty java warning pop-up when running an unsigned applet using jvm, I can do driveby using javascript that implements a jvm...? Oh that sounds great....

Just cos it can be done, ...

[ThirdPrize]

doesn't mean that it should be done. I'm just saying.

Re:Just cos it can be done, ...

[PPH]

Too late. The idea is stuck firmly in the Slashdot developers' heads.

Re:This is nonsense.

[Trails]

It's also seen as less powerful because it's more confusing (dynamically types and the wacky cross-browser implementations being the main sources of this in my experience). Some of that is also legacy leftover of javascript as a scripting language being conflated with "that script you use to do rollovers" in the ie-netscape days.

As you say, javascript as a language is plenty powerful, see what can be done in unity and flex for examples.

Re:This is nonsense.

[Oligonicella]

That's a byproduct of Perl. What you write has nothing to do with it.

Re:This is nonsense.

[bill_mcgonigle]

Sad day - your comment is the only one that comes up in a browser find for 'Turing' on my default page view and that's because I have my friends scoring +4...

PyPy

[gr8_phk]

PyPy implements Python in Python. Apparently it's a great way to test new features before undertaking an implementation in the C interpreter.

maybe I'm just not seeing it

[JustNiz]

OK bear with me. I'm old school and do a lot of embedded development. I do pretty much everything in C or C++.
I am not even slightly in tune with the kitchen sink mindset and all technologies you internet-everything developer types use. I've always thought you guys do way too much layering and usually end up making some heavyweight, overcomplex and slow monster with all sorts of dependencies on stuff like web servers and databases to just to do something I could do in a few lines of native C++.

A JVM based on Javascript seems a perfect example of extreme bloat to me. I'm genuinely interested in whats the benefit of this approach that can outweigh its no doubt massive resource usage and relatively sucky performance, even compared to native JVM?

Ken Thompson Hack

[nuckfuts]

This discussion of compilers written in their own language makes me think of the Ken Thompson Hack, wherein the hacked compiler forever propagates malicious content that is not contained in the source code.

"This hack can propagate transparently across languages and language generations. In the case of cross compilers it can leap across whole architectures."

27 years later it's still the most devious backdoor I've ever heard of.

Similar Concepts

[Chester K]

It's worth noting that Microsoft Research had the exact same idea back in 2007 with Volta, which was an implemention of the .NET CLR in Javascript so you could take the same .NET compiled assembly files that you run on your PC and run them without any plugins in a Javascript-capable browser.

They eventually ditched the idea in favor of a different approach with Script#, which is a C# compiler that compiles to Javascript instead of .NET bytecode; similar in concept to Google' GWT Java source to Javascript compiler.

Our brains

[Jeff1946]

Don't we "program" our brains in English using English or whatever is your native language with no initial bootstrap compiler? Yes, I know linguists have studied how much of language ability is hardwired into our brains.

Re:This is nonsense.

[wierd_w]

A better use case is for pointing out the unsatisfiability of apple's developer restrictions, regarding interpreted languages/emulation.

This javascript jvm would allow you to run "anything you want" inside the stock idevice browser, since said browser needs to support javascript for a huge number of reasons.

It wouldn't be as good as a native arch jvm, or even better, native arch software, but the abstraction capability would render *all* modern browsers into a nonconforming state with the developer agreement. Apple would have to either forbid modern browsers, or remove the restriction.

Oracle

[jcfandino]

So, is Oracle gonna sue this time?