Hi Esben,
> Am 17.10.2016 um 09:11 schrieb Esben Andreasen <es...@esbena.dk>: > > A. > Where can I read about such non-ECMA-standard features in Nashorn? > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions I don’t think the string methods from java.lang.String are contained in that page because, as Attila said, it is a side effect of using java.lang.String as JS string representation and transparently exposing Java methods to scripts. > B. > ECMAScript 6 includes `String.prototype.startsWith`, but it is not > supported by Nashorn in ES6-mode: > > ``` > 1 $ jjs -version --language=es6 > 2 nashorn 1.8.0_101 > 3 jjs> typeof String.prototype.startsWith > 4 undefined > ``` > > And it is unclear whether Nashorn intends to support it yet > (https://bugs.openjdk.java.net/browse/JDK-8066046). > So, is it a deliberate omission? We’ll only implement some ES6 features in the initial JDK 9 release, and the String methods are not among them. Hannes > --- > Esben > > On Mon, Oct 17, 2016 at 7:44 AM Attila Szegedi <szege...@gmail.com> wrote: > >> it’s a side effect of the fact that primitive strings values in Nashorn >> are instances of java.lang.String, and the fact that with Nashorn you can >> invoke methods on Java objects, therefore “startsWith” is a Java String >> method. >> >> While Java methods also don’t inherit from Function.prototype (hence, you >> can’t call “call” on them as you have correctly observed), implementations >> of Function.prototype.call and .apply are actually coded so that they do >> work on them with a not terribly obvious, but correct invocation: >> >> var sw = "".startsWith >> Function.prototype.call.call(sw, "abc", "a") >> >> should return true. Note that since the expression fn.call.call is totally >> unbound from the fn that produced it, you can use any “fn”; I usually use >> “Function” for some semblance of clarity: >> >> Function.call.call(sw, "abc", "a") >> >> Finally, .startsWith is only present on primitive String values (as >> they’re java.lang.String), not on JS String objects, that’s why you were >> getting results you didn’t expect from “typeof Object(string).startsWith” >> >> HTH, >> Attila. >> >> >>> On 16 Oct 2016, at 13:42, Esben Andreasen <es...@esbena.dk> wrote: >>> >>> Hi >>> >>> I am not sure if this is a bug or feature of the Nashorn engine. But >>> it looks like some String-prototype methods are missing, yet the >>> methods are somehow present when used in the right way. >>> >>> Minimal example: calling `startsWith` by using `call`: >>> >>> ``` >>> 1 $ jjs -v >>> 2 jjs> String.prototype.startsWith.call('abc', 'ab') >>> 3 <shell>:1 TypeError: Cannot read property "call" from undefined >>> ``` >>> >>> Expected behavior: >>> >>> Not a type error, for multiple reasons: >>> >>> 1. Other JavaScript engines do not throw a type error. >>> 2. The equivalent code `"abc".startsWith("ab")` does not throw a type >> error. >>> >>> >>> Further investigation: >>> >>> ``` >>> 1 $ jjs -v >>> 2 nashorn 1.8.0_101 >>> 3 jjs> "abc".startsWith('ab') >>> 4 true >>> 5 jjs> "abc".startsWith >>> 6 [jdk.internal.dynalink.beans.OverloadedDynamicMethod >>> boolean java.lang.String.startsWith(String,int) >>> boolean java.lang.String.startsWith(String) >>> ] >>> 7 jjs> "abc".startsWith.call("abc", "ab") >>> 8 <shell>:1 TypeError: "abc".startsWith.call is not a function >>> 9 jjs> typeof String.prototype.startsWith >>> 10 undefined >>> 11 jjs> String.prototype.split.call("abc", "b") >>> 12 a,c >>> ``` >>> >>> Interpretation: >>> >>> It looks like `startsWith` is not present on the String-prototype, yet >>> it is present on the String-primitives. Other String-prototype methods >>> (`split`) are however present. >>> >>> Further notes: >>> >>> This also applies to `String.prototype.endsWith`. >>> >>> >>> Related bug/feature: primitive values are not wrapped properly: >>> >>> ``` >>> 1 $ jjs -v >>> 2 jjs> typeof Object("abc").startsWith >>> 3 undefined >>> ``` >>> >>> - >>> >>> Esben >> >>
