+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 <[email protected]>
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.
