On 28-06-2020 15:11, Arioch The wrote:
> is there some standard de facto library of infinite precision numbers
> and math in JVM ecosystem?
I describe the options in jdp-2020-08. Java provides
java.math.BigDecimal (which is the standard type for JDBC types NUMERIC
and DECIMAL), and it provides java.math.BigInteger.
However, JDBC doesn't really associate a JDBC type with BigInteger. In
some (but not all) of the mappings defined in appendix B of the JDBC
specification, it is associated with JDBC type BIGINT, but as the
standard type associated with JDBC type BIGINT is a (64-bit) long, using
that as a type would be problematic. In my experience, a lot of the
libraries and tools written in Java work with the assumption that JDBC
type BIGINT means 64-bit long. Using that for a 128-bit integer would
then yield overflow errors when the value is out of range, or
potentially problems if you'd let getObject return a
java.math.BigInteger instead of a java.lang.Long.
Jaybird already supports getting and setting java.math.BigInteger on
NUMERIC and DECIMAL, so if you want to use it, you can. Furthermore a
java.math.BigDecimal is basically a wrapper around a
java.math.BigInteger with a scale.
The advantage of using JDBC type NUMERIC (or DECIMAL) is that through
its mapping with java.math.BigDecimal, most tools will transparently be
able to work with it. There might potentially be some edge-cases when
generating DDL or casts in SQL (ie tools might generate - for example -
NUMERIC(38) or NUMERIC(38,0) instead of INT128). In those same cases,
those tools would likely generate BIGINT when mapped to JDBC type
BIGINT, which would be worse, because at least NUMERIC(38) and INT128
cover the same range of values and the same can't be said for BIGINT.
When using a custom type, or Types.OTHER, it is hard to say what will
happen, but I suspect it would be worse.
Mark
--
Mark Rotteveel