Which regular expression will Nashorn use?

[Hannes Wallnoefer]

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