4 ms·

An ES5-compliant JavaScript interpreter, written in Java

37 points by neeleshs 3y ago

Alifatisk 3y ago
Cool, I wonder how more JS interpreters would affect the ecosystem.
peter-m80 3y ago
JavaJavaScript
- deleted 3y ago
  [deleted]
pipeline_peak 3y ago
https://en.m.wikipedia.org/wiki/Rhino_(JavaScript_engine) https://en.m.wikipedia.org/wiki/Rhino_(JavaScript_engine) Written in Java and compiles to JVM
- MrBuddyCasino 3y ago
  Nowadays one would probably use the GraalVM based implementation instead of Rhino: https://www.graalvm.org/latest/reference-manual/js/ https://www.graalvm.org/latest/reference-manual/js/
  - mdaniel 3y ago
    I would guess that depends on the licensing context in which it will be running, since Rhino is MPLv2 <https://github.com/mozilla/rhino/blob/Rhino1_7_14_Release/LICENSE.txt https://github.com/mozilla/rhino/blob/Rhino1_7_14_Release/LI...> and OP's repo is MIT whereas Graal is UPLv1 <https://github.com/oracle/graaljs/blob/graal-23.1.2/LICENSE https://github.com/oracle/graaljs/blob/graal-23.1.2/LICENSE>. GitHub's license gizmo claims it is OSI/FSF approved, but Oracle gonna Oracle and they for sure have more lawyers than you do
mdaniel 3y ago
Well, I know what my first PR would be to this repo: it's missing the ScriptEngine plumbing <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptEngineFactory.html https://docs.oracle.com/en/java/javase/11/docs/api/java.scri...>, which I think is a prerequisite for use in any sane JVM setup One will also want to watch out for the "yes, but" in their parser around reserved words: https://github.com/TopchetoEU/jscript/blob/v0.9.6-beta/src/java/me/topchetoeu/jscript/compilation/parsing/Parsing.java#L78-L86 https://github.com/TopchetoEU/jscript/blob/v0.9.6-beta/src/j... I'm not an ES[0-9] ninja enough to know what the practical implication is of those decisions, but nor do I think hiding them in some comments down in the Parser is the correct way to advise folks of that choice
- arghwhat 3y ago
  > I'm not an ES[0-9] ninja enough to know what the practical implication is of those decisions Well, it makes it non-compliant and makes it unable to run some (horrible, yet compliant) ES5 scripts. "undefined", "arguments", "globalThis", "window" and "self" are just variables which can be aliased and overwritten, so considering them keywords is broken. Disallowing "const" and "let", which only became reserved in ES6, isn't a big deal as any modern interpreter uses them, but does also limit valid ES5 scripts from running. (And yes, it's very weird that "undefined" is just a property on the global object that has not been assigned a value. Feels like someone trying to be "smart" instead of just giving it a keyword...)
deleted 3y ago
[deleted]
bdw5204 3y ago
> THE GOAL OF THIS ENGINE IS NOT PERFORMANCE. My crude experiments show that this engine is 50x-100x slower than V8 This should be obvious given that it's written in Java. A C++ implementation like V8 is always going to be much more performant. I think it'd be fascinating to see if a JavaScript engine written in Rust or Zig could compete on performance with V8. But Java, as I believe even its biggest advocates would acknowledge, is not a good language choice for performance sensitive programs.

37 points by neeleshs 3y ago

Alifatisk 3y ago

Cool, I wonder how more JS interpreters would affect the ecosystem.

peter-m80 3y ago

JavaJavaScript

deleted 3y ago
[deleted]

pipeline_peak 3y ago

https://en.m.wikipedia.org/wiki/Rhino_(JavaScript_engine) https://en.m.wikipedia.org/wiki/Rhino_(JavaScript_engine) Written in Java and compiles to JVM

MrBuddyCasino 3y ago
Nowadays one would probably use the GraalVM based implementation instead of Rhino: https://www.graalvm.org/latest/reference-manual/js/ https://www.graalvm.org/latest/reference-manual/js/
- mdaniel 3y ago
  I would guess that depends on the licensing context in which it will be running, since Rhino is MPLv2 <https://github.com/mozilla/rhino/blob/Rhino1_7_14_Release/LICENSE.txt https://github.com/mozilla/rhino/blob/Rhino1_7_14_Release/LI...> and OP's repo is MIT whereas Graal is UPLv1 <https://github.com/oracle/graaljs/blob/graal-23.1.2/LICENSE https://github.com/oracle/graaljs/blob/graal-23.1.2/LICENSE>. GitHub's license gizmo claims it is OSI/FSF approved, but Oracle gonna Oracle and they for sure have more lawyers than you do

mdaniel 3y ago

Well, I know what my first PR would be to this repo: it's missing the ScriptEngine plumbing <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptEngineFactory.html https://docs.oracle.com/en/java/javase/11/docs/api/java.scri...>, which I think is a prerequisite for use in any sane JVM setup One will also want to watch out for the "yes, but" in their parser around reserved words: https://github.com/TopchetoEU/jscript/blob/v0.9.6-beta/src/java/me/topchetoeu/jscript/compilation/parsing/Parsing.java#L78-L86 https://github.com/TopchetoEU/jscript/blob/v0.9.6-beta/src/j... I'm not an ES[0-9] ninja enough to know what the practical implication is of those decisions, but nor do I think hiding them in some comments down in the Parser is the correct way to advise folks of that choice

arghwhat 3y ago
> I'm not an ES[0-9] ninja enough to know what the practical implication is of those decisions Well, it makes it non-compliant and makes it unable to run some (horrible, yet compliant) ES5 scripts. "undefined", "arguments", "globalThis", "window" and "self" are just variables which can be aliased and overwritten, so considering them keywords is broken. Disallowing "const" and "let", which only became reserved in ES6, isn't a big deal as any modern interpreter uses them, but does also limit valid ES5 scripts from running. (And yes, it's very weird that "undefined" is just a property on the global object that has not been assigned a value. Feels like someone trying to be "smart" instead of just giving it a keyword...)

deleted 3y ago

[deleted]

bdw5204 3y ago

> THE GOAL OF THIS ENGINE IS NOT PERFORMANCE. My crude experiments show that this engine is 50x-100x slower than V8 This should be obvious given that it's written in Java. A C++ implementation like V8 is always going to be much more performant. I think it'd be fascinating to see if a JavaScript engine written in Rust or Zig could compete on performance with V8. But Java, as I believe even its biggest advocates would acknowledge, is not a good language choice for performance sensitive programs.