It clearly says that Orto is free for non-commercial use, but otherwise you need to contact them for permission. For all practical purposes, though, I think it's safe to consider it effectively public domain at this point.
I've made a rough translation of the license. As mentioned it's in Japanese. It's also kind of confusing. I'll send a pull request when I'm back at my desktop. (EDIT: Though of course, redistribution seems to break the condition at line #6).
1 Orto SDK is Free Software.
2 Copyright Kobayashi Yuu
3
4 Use and publication of applications produced by using Orto SDK
5 are free for both commercial and non-commercial purposes.
6 For other uses of Orto SDK, or for redistribution of the Orto SDK,
7 please contact support@orto.jp beforehand.
8
9 Due to lack of contract with Sun Microsystems,
10 Orto is Java-style but it is not Java. Orto is an independent language.
11 Java is a registered trademark of Sun Microsystems
12
13 The author is not responsible for any damages which may occur through use of Orto SDK
14 Furthermore, reverse engineering of Ordo SDK is prohibited.
No, sorry. I guess it really was a redundant response. Anyway, I used this reference for the first time. I said it because I think a JVM written in JS is remarkable - This is something I would not have expected anyone to do. Not at all. Yet, technically, it was predicted by said law.
I wonder if JVM bytecode would be a viable alternative intermediate language for compilation-to-javascript, as compared to the LLVM IR that projects like Emscripten use.
> I wonder if JVM bytecode would be a viable alternative intermediate language for compilation-to-javascript
That would be very cool! In fact I've been thinking about compiling JVM bytecode to JS using Emscripten. Either by compiling JVM bytecode to LLVM IR, or directly to Emscripten's IR (which is a close parallel to LLVM's).
If any JVM hackers want to work on that with me, that would be awesome (I can do all the LLVM/Emscripten parts).
I'm not sure I expect a "real" JVM to end up back in the browser, but everyone these days does seem to be trying to compile everything else to JS by hook or by crook, so anything that serves as a halfway plausible IR for that is interesting. The LLVM IR, for example, is used more or less because it was the least-bad option, not because it's great for the job (the Emscripten list has a lot of discussion of how not-really-platform-independent it is).
It's technically impressive, but I cannot see any real world application. A native Java runtime is heavily, heavily optimized for performance. Why would you run Java code through an interpreted/JITed JavaScript environment?
However - I can appreciate the technical challenge :)
This is backwards. It should be JavaScript syntax driving the JVM. Because Scala and Groovy are way to small for anyone to care, but the JVM is an awesome way for people to write play-anywhere applications. Java is one of those languages that could have been dynamically typed from the beginning, but they chose to force us to be static to be academic (or something...). People can do a lot more in JavaScript than in Java FASTER. Make a version of JavaScript that drives the JVM and you win. Perhaps you can even use one of the current ECMA Standards. They probably already have some 'make window' syntax defined somewhere.
If this project already exists please let me know. I have tons of uses for it. Thanks.
Oracle announced Nashorn recently that is not yet open sourced, but should be released for Java 8 and compile to bytecode (w/ the help of invokedynamic)
http://ejohn.org/blog/running-java-in-javascript/
Edit: Seems to be missing from the web. I'm pushing my local copy to github:
https://github.com/robterrell/orto