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
