11–20 of 32 posts
I think its a silly thing really, running a JVM on top of a JITer inside a browser. I can see it having some uses in specific cases but I can't imagine it being used for anything heavy duty.
Talk about abstraction! Java -> bytecode -> JVM -> CoffeeScript -> JavaScript -> interpreter/JIT -> machine code -> CPU -> hardware. Turtles all the way down...
I don't think the CoffeeScript step exists in the pipeline. CoffeeScript is the language the JVM is written in, but I don't expect it outputs CoffeeScript itself.
I'm one of the authors. Doppio's not the first JVM in Javascript, but I believe we have the most extensive support for the JRE among the lot. In particular, we can run Rhino and the Java 4 compiler. Feel free to ask me any questions! Check out the demo here: http://int3.github.com/doppio/
Can you run Doppio in Rhino on the JVM?
Funny enough, Someone had told me about a grad student having to recreate the JVM in JavaScript at our school. Low and behold, the credits at the bottom of the page are for a few grad students at my school. I think its a silly thing really, running a JVM on top of a JITer inside a browser. I can see it having some uses in specific cases but I can't imagine it being used for anything heavy duty.
The plan is to implement a bytecode -> JS compiler next, a la JSIL / Emscripten. Thus far most of the work has gone into porting the runtime environment first.
P.S. I'm a sophomore, the other two are grad students :)
Funny enough, Someone had told me about a grad student having to recreate the JVM in JavaScript at our school. Low and behold, the credits at the bottom of the page are for a few grad students at my school. I think its a silly thing really, running a JVM on top of a JITer inside a browser. I can see it having some uses in specific cases but I can't imagine it being used for anything heavy duty.
> While we do not emulate threads, we still wanted to handle blocking operations, particularly for standard input. Since the browser DOM is largely asynchronous, blocking operations have to be emulated via async callbacks. We solved this by implementing a 'yield' construct: upon encountering a blocking function, we throw a YieldException to pause the VM. This exception would also contain the asynchronous function that we are waiting on, which eventually calls the VM and resumes the program.
Absolutely brilliant work guys
Funny enough, Someone had told me about a grad student having to recreate the JVM in JavaScript at our school. Low and behold, the credits at the bottom of the page are for a few grad students at my school. I think its a silly thing really, running a JVM on top of a JITer inside a browser. I can see it having some uses in specific cases but I can't imagine it being used for anything heavy duty.
Oh, and if this thing catches on, we won't be seeing another FlashBlock again :)
function scrollToBottom() {
jQuery.fn.jquery > "1.6" ?
inner.prop({scrollTop: inner.prop("scrollHeight")}) :
inner.attr({scrollTop: inner.attr("scrollHeight")})
}Android in the browser.