Use BigInt in JS backend for JVM long datatype

[mirkosertic]

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt

[ogrammer]

I'd prefer if this was an option, because for some projects 53-bit longs are enough.

[mirkosertic]

Related to #154.

[blackbirdone]

Hello :) I saw this problem while testing the ranges of values aswell.

System.out.println(Long.MAX_VALUE); result on console 9223372036854776028 System.out.println("9,223,372,036,854,775,807 " + Long.MAX_VALUE); result on console 9,223,372,036,854,775,807 9223372036854775807

Fun fact the max range is 9223372036854776000 The call on jiPrintStream.VOIDprintlnLONG.call(jlSystem.init().out,9223372036854775807); includes the right amount but die JavaScriptVM can only handle float 64 as max parameter without an object. So the max value for that is 9223372036854776000.

After that the system out function decodes int to chars and there is something broken? so the 9223372036854776000 becomes 9223372036854776028 even more wrong :D

I included it to may test project with compiled classes to showcase the problem https://github.com/blackbirdone/bytecoder-test/tree/master/example Just use the longTest.html. Just as an reminder that const values can be broken on the javascript site without a really hard relation to a long object

[mirkosertic]

@blackbirdone thank your for the testcase. Issue #251 will reduce the described effect, but for full long support we either need BigInt support or an emulation like long.js. I'd prefer a native solution (BigInt), but it seems it is not supported by WebKit at all https://caniuse.com/#search=bigint

[mirkosertic]

The new Bytecoder release uses BigInt for JS and Wasm backends. I'll consider this issue as closed.