AW: Coercion of Java Enums works differently than in Rhino
Krause, Michael
michael.krause at grawe.at
Tue Feb 3 16:15:30 UTC 2015
Hi, thank you for the concise explanation!
I understand that it is a difficult choice. I would vote for the TypeError, because I feel that all this implicit stuff can break easily. As it indeed did in my case.
Also, since many shops have Java 8 in production right now, going for the TypeError will break existing scripts in an observable manner. Which is much
better compared to silently changing behaviour, which will happen when you choose to invoke toString().
if this qualifies as a bug, could you please create one?
Thank you!
> ________________________________________
>Von: Attila Szegedi [attila.szegedi at oracle.com]
>Gesendet: Dienstag, 3. Februar 2015 15:15
>An: Krause, Michael
>Cc: nashorn-dev at openjdk.java.net
>Betreff: Re: Coercion of Java Enums works differently than in Rhino
>I'm throwing all this out here because we'd like to hear what the community thinks about which'd be the preferred way to go.
>
>Attila.
>
>On Feb 3, 2015, at 1:26 PM, Krause, Michael <michael.krause at grawe.at> wrote:
>
>> Hi,
>>
>> It seems that in Nashorn Java enums are no longer coerced into their string value:
>>
>> java.math.RoundingMode.UP == "UP"
>>
>> evaluates to true in Java 7 but to false in Java 8 when executed in the respective JavaScript engine.
>>
>>
>> Does anybody know if this is actually a bug or just something in the specification?
>>
>> Thanks!
More information about the nashorn-dev
mailing list