Java 9 BigInteger constructors with offset/length params missing
niloc132 opened this issue · comments
In Java 9, two new constructors were added to BigInteger:
Speaking of BigInteger, all browsers except IE support BigInt (just sayin')
If you're interested, it's all yours, file a ticket on what we can do to make that make more sense?
Jsinterop-base already has a JsBigInt type - just an interface, no members, but elemental2-core fills in the rest. If you're just looking at using it in specific "treat it like any other Object" cases that might be enough, but making GWT emit bigint literals might be tricky - gwt's js ast is basically es3, so adding a new JsLiteralValue might not be entirely seamless (esp when following the rules about not mixing numbers and bigints). Using bigint for long values that don't fit in an int32 could make sense though, at least at a glance, but mixing operation might be gross (in Java, long * int is a long, in js you can't mix of course).
With regards to performance, is bigint comprehensively better than regular numeric math? Gwt's BigInteger is already just plain integers (so no dealing with long math). At a glance, the emulation might end up producing smaller output, and some operations like remainder()...
With no numbers to back me up, I'd guess there would be bigger wins replacing the int[] digits with a Int32Array than bigint for bit/byte-wise operations (de/serializing values, checking if bits are set), but likely better performance for BigInteger-BigInteger operators for bigint, plus smaller generated code.
Why not simple use the code of BigInteger(byte[]) and extend this to take length and offset (missing constructor) and copy the array in the beginning (or change the code to handle length and offset – whatever is easier) and let the (now missing) BigInteger(byte[]) constructor use the newly created one (with zero as offset and array length)?
@lgemeinhardt exactly, plus add tests, that's what this ticket is for. It should be just as easy as you suggested. I'd avoid the copy if we can help it, and have BigInteger(byte[]) call the new one with 0, arr.length - it shouldn't make a difference in the compiled output if you don't use the new ctor, since the old one will get inlined and putBytesNegativeToIntegers/putBytesPositiveToIntegers already read the length of the array anyway.