Hi Christopher, sorry for the late reply.
Am 2013-04-09 15:29, schrieb Christopher Brown:
Hi,
Does this mean that the scanner will detect (and reject) usage of regular
expression constructs (such as "lookbehind") that are not supported in
JavaScript, even if there is such support in the JDK engine? (This would
be preferable for consistency, as I could always directly use the JDK
version in Nashorn if I really need it).
Yes, the scanner limits the syntax to what should be supported according
to the ECMA spec. Recently we've added some features that are not in the
spec but are supported by all major JavaScript engines, but these are
mostly corner cases that you shouldn't encounter too often.
In other news we switched to Joni as default engine today in our Nashorn
repo, so you should see that change in a JDK8 preview release sometime
in the future.
Also, I guess (seems obvious) that if the JDK is not derived from OpenJDK /
an Oracle JDK, there's no way of using Nashorn, and I would have to require
Rhino for such cases. Is that correct?
I can't really say what other implementers will do, but all the code is
open source and can certainly be included in other JDK implementations
if license requirements are met.
Hannes
Thanks,
Christopher
On 7 April 2013 14:38, Hannes Wallnoefer <[email protected]>wrote:
Hi Christopher,
Our current approach is to translate regular expressions from JavaScript
to Java syntax (this is done in
jdk.nashorn.internal.runtime.**regexp.RegExpScanner)
and then use the JDK's java.util.regex package. This seems to work
reasonably well both for the ECMA 262 test suite and most real world regexp
code.
However, java.util.regex performance is not quite on par with browser
regexp engines, so we've also ported the Joni engine from the JRuby
project. Joni is about two times faster than java.util.regex, depending a
lot on type of regular expressions you throw at it. You can enable Joni as
regular expression engine in Nashorn by setting the "nashorn.regexp.impl"
system property to "joni" (use "jdk" for the default java.util.regex
engine).
jjs -Dnashorn.regexp.impl=joni
I've also started working on Java bytecode generation for regular
expressions using ASM. This would give as another nice performance boost
but is still work in progress.
The bottom line is that you can expect regular expressions in Nashorn to
be currently as fast as in Java (as we're using the same implementation)
and to probably become faster in the future.
Hannes
Am 2013-04-07 07:15, schrieb Christopher Brown:
Hello,
As there important differences in the ECMAScript Regular Expression
specification and the Java implementation (in "java.util.regex"), I was
wondering if Nashorn will also include a "JavaScript-flavor" regular
expression engine or if it will just take a shortcut and delegate to the
Java JDK engine. Which option is planned?
My use case involves updating part of our application to implement a
significant part of business rules in JavaScript, so that these rules can
run on the server AND on the client (without multiple implementations),
and
part of these rules will be expressed using regular expressions. I'm
assuming (that seems to be the goal of Nashorn) that the JavaScript
implementation -- and presumably all parts of JavaScript, including the
regex engine -- will not be significantly slower than an implementation
written in the Java language. Is that correct?
Thanks,
Christopher
