0

I'm using GWT 2.8.2.

When I run the following code in SuperDev mode, it logs 123.456, which is what I expect.

double d = 123.456789;
JsNumber num = Js.cast(d);
console.log(num.toFixed(3));

When I compile to JavaScript and run, it logs 123 (i.e. it does not show the decimal places).

I have tried running the code on Android Chrome, Windows Chrome and Windows Firefox. They all exhibit the same behavior.

Any idea why there is a difference and is there anything I can do about it?

Update: After a bit more digging, I've found that it's to do with the coercion of the integer parameter.

console.log(num.toFixed(3));  // 123 (wrong)
console.log(num.toFixed(3d)); // 123.456 (correct)

It seems that the JsNumber class in Elemental2 has defined the signature as:

public native String toFixed(Object digits);

I think it should be:

public native String toFixed(int digits);

I'm still not sure why it works during SuperDev mode and not when compiled though.

ᴇʟᴇvᴀтᴇ
  • 12,285
  • 4
  • 43
  • 66

2 Answers2

1

The problem is that "java" automatically wraps the int as an Integer and GWT end up transpiling the boxed Integer as a special object in JS (not a number). But, if you use a double, the boxed double is also transpiled as a native number by GWT and the problem disappears.

I'm not absolutely sure why this works in super-devmode, but it should not. I think that the difference is that SDM maps native toString to the Java toString, and (even weirder) the native toFixed call the toString of the argument. In SDM the boxed-interger#toString returns the string representation of the number which ends up coercing back to int, but in production, the boxed-interger#toString returns "[object Object]", which is handled as NaN.

There is a special annotation @DoNotAutobox to being able to use primitive integers in JS native APIs. This prevents integer auto-wrap, so the int is transpired to a native number (example usage in the Js#coerceToInt method). Elemental2 might add this annotation or change the type to int as you suggest. Please, create an issue in the elemental2 repo to fix this (https://github.com/google/elemental2/issues/new).

Ignacio Baca
  • 1,538
  • 14
  • 18
  • Thanks for the explanation about `boxed-integer#toString`. I thought using Java would save me from being caught out by JavaScript's implicit type coercion. Ah well! – ᴇʟᴇvᴀтᴇ Aug 01 '19 at 09:22
  • Unfortunately, gwt isn't quite magic - in order to still permit you to box an `int` to an `Integer`, and store it as an `Object` (such as in a collection, etc), it has to be tagged with type details, which means it is no longer just a number, but a wrapper object. Just as in regular Java, try to avoid boxed primitives where possible, but sometimes it isn't possible. Hopefully with that filed issue, we'll lose this extra layer of wrapping. – Colin Alworth Aug 01 '19 at 14:09
  • And what about the behavior change between SDM and production, did you know it? is it true that the #toString is only overridden in SDM? – Ignacio Baca Aug 02 '19 at 13:25
1

Nice catch! This appears to be a bug in the jsinterop-generator configuration used when generating Elemental2's sources. Since JS doesn't have a way to say that a number is either an integer or a floating point value, the source material that jsinterop-generator works with can't accurately describe what that argument needs to be.

Usually, the fix is to add this to the integer-entities.txt (https://github.com/google/elemental2/blob/master/java/elemental2/core/integer_entities.txt), so that the generator knows that this parameter can only be an integer. However, when I made this change, the generator didn't act on the new line, and logged this fact. It turns out that it only makes this change when the parameter is a number of some kind, which Object clearly isn't.

The proper fix also then is probably to fix the externs that are used to describe what "JsNumber.toFixed" is supposed to take as an argument. The spec says that this can actually take some non-number value and after converting to a number, doesn't even need to be an integer (see https://www.ecma-international.org/ecma-262/5.1/#sec-15.7.4.5 and https://www.ecma-international.org/ecma-262/5.1/#sec-9.3).

So, instead we need to be sure to pass whatever literal value that the Java developer provides to the function, so that it is parsed correctly within JS - this means that the argument needs to be annotated with @DoNotAutobox. Or, we could clarify this to say that it can either be Object or Number for the argument, and the toFixed(Object) will still be emitted, but now there will be a numeric version too.

Alternatively, you can work around this as you have done, or by providing a string value of the number of digits you want:

console.log(num.toFixed("3"));

Filed as https://github.com/google/elemental2/issues/129

Colin Alworth
  • 17,801
  • 2
  • 26
  • 39