OK. I think I’ve figured out how this works now and gone through the code.
+1 /M > On 19 Feb 2015, at 18:48, Attila Szegedi <[email protected]> wrote: > > 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.
