Which regular expression will Nashorn use?

Christopher Brown christopherbrown06 at gmail.com
Tue Apr 9 06:29:27 PDT 2013


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).

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?

Thanks,
Christopher


On 7 April 2013 14:38, Hannes Wallnoefer <hannes.wallnoefer at oracle.com>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
>>
>
>


More information about the nashorn-dev mailing list