Java interop for primitive types

[tonygermano]

When I was creating PR #1501 I noticed a couple things that I thought were worthy of bringing up for discussion.

char

Java char gets converted to a js number, but when isJavaPrimitiveWrap is false in the Context's WrapFactory, java.lang.Character gets converted to a js string instead. This seems inconsistent, but it's been this way forever.

long

Java long gets converted to a number, and likewise when isJavaPrimitiveWrap is false, java.lang.Long also gets converted to a number (see below for some quirks regarding this.) This causes a java widening conversion to occur, and an unavoidable loss of precision when the value is outside of the range of [Number.MIN_SAFE_INTEGER - Number.MAX_SAFE_INTEGER]. This can make it challenging to impossible to work with classes like java.util.UUID.

Now that we have BigInt support, which obviously did not exist when this class was first written, I wonder if we should give the option to convert long to bigint so that Rhino can support true 64-bit integer interop with java. I think it would make sense to do this as a WrapFactory flag like isJavaPrimitiveWrap. Likewise, I think bigint values should be automatically truncated (by calling BigInteger::longValue) when passed to java methods requesting a long.

Here are the current quirks I mentioned:

js> var max = java.lang.Long.MAX_VALUE
js> typeof max
number
js> max.toString()  // loss of precision
9223372036854776000
js> BigInt(max).toString() // this is actually the correct value. `max` must internally still be a Long
9223372036854775807
js> BigInt(max+0).toString() // no idea where this came from
9223372036854775808
js> Number(BigInt(max)).toString()
9223372036854776000
js> BigInt(Number(BigInt(max))).toString()
9223372036854775808

[p-bakker]

Also see #996

[tonygermano]

Regarding long and custom wrap factories:

A lot of people write javascript code in software where Rhino is embedded and do not have the ability to choose an alternate wrap factory. I think for these people it makes sense to have defaults that do the "right thing." Additionally, it may be desirable for a script to alter how long is mapped during execution. Sometimes it may be easier to work with it as a number, and at other times bigint may be required to prevent loss of precision.

I did a quick test, and I think the WrapFactory only dictates how java.lang.Long is mapped, and not the primitive long, but I did not do a lot of exploring yet to see what additional changes would be needed.