Review request for JDK-8072426

[Hannes Wallnoefer]

+1

Am 2015-03-08 um 14:29 schrieb Attila Szegedi:
> Thanks for the reviews. In order to backport this to 8u-dev, I had to make some changes. Namely, since we introduced a default method into the JSObject interface, we could not compile this under jdk8u-dev, as for JDK 8 Nashorn is compiled with "-source 7" as the part of the build process is running Nasgen, which is done with the boot JDK, which is a JDK 7 for 8u[*].
>
> For this reason, the 8u backport doesn't add a new getDefaultValue() method to the JSObject interface, as that – without the default methods' ability – wouldn't be a binary compatible class change. Instead, AbstractJSObject gains a getDefaultValue(hint) method with the same behavior as well as a static helper getDefaultValue(jsobj, hint) that delegates to AbstractJSObject.getDefaultValue() for AbstractJSObject, and runs the generic algorithm for any other JSObject. (As a separate task, we'll need to forward-port this static helper into JDK 9 codebase so it stays compatible with 8; I'll soon file a JIRA for that.)
>
> With these in mind, please review the backport changeset at <http://cr.openjdk.java.net/~attila/8072426/webrev.8u>
>
> Thanks,
>    Attila.
>
> --
> [*] This raises an interesting further issue, namely that this somewhat peculiar dependency disallows use of any Java 8 syntactic construct in Nashorn code destined for 8. Long term, it'd be great if we could either get 8u to use the previous 8 release as its boot JDK, or if we could rewrite Nasgen so that it reads Nashorn .class files, but doesn't load them into the JVM.
>
> On Feb 20, 2015, at 9:48 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>
>> +1
>>
>> Nice work!
>>
>> Am 2015-02-19 um 18:48 schrieb Attila Szegedi:
>>> Please review JDK-8072426 at <http://cr.openjdk.java.net/~attila/8072426/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8072426>
>>>
>>> This is what basically became an epic yak shaving exercise after we determined that POJOs aren't subjected to ToPrimitive (earlier known as java.math.RoundingMode.UP != "UP" problem). While we originally advocated for throwing TypeError for POJOs [[DefaultValue]] that would've prevented their implicit toString() in string concatenation too. Instead, I opted to fix this once and forever but it turned out that the biggest issue with it is the fact that JSObject was also not handled correctly for ToPrimitive; fixing that turned out to be the most challenging part, introducing a new JSObject.getDefaultValue() method and deprecating JSObject.toNumber() (which isn't used anymore at all).
>>>
>>> As an unexpected boon, JSObjectLinker no longer needs to do any conversions, so its GuardingTypeConverterFactory functionality has been entirely removed. NashornPrimitiveLinker will now automatically take care of converting JSObject instances to various primitive types, as per specification behavior.
>>>
>>> Finally, the ScriptRuntime changes to the equals() and equalDifferentType() are purely refactoring of some common type testing subexpressions and conversions, as well as short-circuiting of some comparisons. They aren't strictly necessary for this issue, but just for clear understanding of what's happening it seemed like a good idea to make them more concise (ScriptRuntime.EQ and .NE, of which the two affected methods are sub-parts are also not invoked terribly often, and I'll soon make them be invoked even less frequently.)
>>>
>>> Thanks,
>>>    Attila.