JDK-8148068 long is no longer a number
Florian Bruckner (3kraft)
florian.bruckner at 3kraft.com
Tue Apr 26 11:07:18 UTC 2016
it is this one:
It looks quite straight forward to me. If the input is a number, try parsing as milliseconds epoch,
if it is a string, try ISO 8601.
We allow both types to be passed into the script and let moment.js decide how to handle it. With
8u92, when an epoch long is passed, moment constructs itself with the current time.
So it is not that moment.js breaks - it is just different behavior that is triggered since 8u92
because the long we pass into the script is no longer a number.
On 26.04.16 12:13, Hannes Wallnoefer wrote:
> Hi Florian,
> Sorry about that. When we made that change we were aware of the fact that it could break existing
> code. However, the behaviour we had (treating longs as JS numbers) also caused some very real bugs
> when numbers grew larger than 53 bits. After some back and forth we decided to solve this issue
> the way we did.
> Can you please point me to the function in moment.js that breaks? It would be interesting to see
> what that code does and whether there is something we can do about it.
> Am 2016-04-26 um 11:53 schrieb Florian Bruckner (3kraft):
>> you need to stop introducing changes like these into jdk8u. It has been the third or fourth time
>> a change in Nashorn in jdk8u has broken our application.
>> What broke this time was that we are passing a java epoch as long to nashorn and use this to
>> construct a date from it (with moment.js) and do some calculations around this date. Because long
>> is no longer a number, moment.js does no longer construct a (correct) date.
>> Thanks for listening and sorry about the ranting.
Mobile: +43 699 102 53 901 | Phone: +43 1 9204549 113 | Fax: +43 1 9204549 3113 | 3kraft.com
3kraft IT GmbH & Co KG | Wasagasse 26/2 | 1090 Wien | Österreich | FN 333787 p (HG Wien)
Komplementär: 3kraft IT GmbH | Wasagasse 26/2 | 1090 Wien | Österreich | FN 333558 b (HG Wien)
More information about the nashorn-dev