Path: csiph.com!aioe.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk>
Newsgroups: comp.lang.java.programmer
Subject: Re: [OT] Re: missing import java.lang.Comparable
Date: Fri, 22 Jul 2016 23:31:14 -0400
Organization: Aioe.org NNTP Server
Lines: 113
Message-ID: <nmuoe1$826$1@gioia.aioe.org>
References: <ra50obpr4u0h974pt9gkmhr8vp70dc01bh@4ax.com> <nlpi9j$upm$1@jstuckle.eternal-september.org> <6cbiob184r55h86pg11p45gkkmg4c877tu@4ax.com> <nmbe3e$3er$1@jstuckle.eternal-september.org> <e5qiob5msltgi6fethiagdvu7q810nvf79@4ax.com> <nmbr2m$iej$1@jstuckle.eternal-september.org> <uqdqobpt834eh1u6orr1t2mlbm7u3464ad@4ax.com> <nmje14$5oe$1@jstuckle.eternal-september.org> <oepqob15nrleoq3fil5s4incq53h1v9lp5@4ax.com> <nmjrvv$sfn$1@jstuckle.eternal-september.org> <vmosobl7sc7vd8vpn9rcfokg3arl168vbc@4ax.com> <nmm321$v6i$1@jstuckle.eternal-september.org> <nmmg1c$14pf$3@gioia.aioe.org> <nmmkds$ku7$1@jstuckle.eternal-september.org> <nmmlo2$19us$1@gioia.aioe.org> <nmms8c$7gd$1@jstuckle.eternal-september.org>
NNTP-Posting-Host: 7SK6yTFfqwlIPNBLl3l7Qg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.java.programmer:35100

On 7/19/2016 11:47 PM, Jerry Stuckle wrote:
> On 7/19/2016 9:56 PM, Arne Vajhøj wrote:
>> On 7/19/2016 9:33 PM, Jerry Stuckle wrote:
>>> On 7/19/2016 8:18 PM, Arne Vajhøj wrote:
>>>> On 7/19/2016 4:37 PM, Jerry Stuckle wrote:
>>>>> And you still haven't described how Java (not javascript) handles
>>>>> decimal numbers with at least 18 digits of accuracy.
>>>>
>>>> It has been mentioned a couple of times in this thread.
>>>>
>>>> BigDecimal.
>>>
>>> Except there are two problems with it.  It is very slow, compared to a
>>> native BCD implementation.
>>
>> Calendar says 2016 not 1986. Not really a problem.
>>
>
> Yes, it is a problem for big data. But you wouldn't understand what it's
> like to process a few tens of gigabytes, would you?

It is a few decades since "few tens of gigabytes" was "big data".

:-)

Processing 20, 30, 40 GB of BigDecimals is not a problem on moderne
hardware.

If you are doing just add, subtract etc. then it should take just a few
seconds.

>
>>>                       And it doesn't support the DECIMAL type in
>>> databases.
>>
>> Not correct. It does.
>>
>
> On which database?

Probably all.

Two reasons:
1) It is the standard per the JDBC specification.
2) There are no other suitable data types to map it to.

Re 1)

The JDBC specification has "TABLE B-1 JDBC Types Mapped to Java Types" with:

NUMERIC      java.math.BigDecimal
DECIMAL      java.math.BigDecimal

The fact that it is recommended standard and there are no good
alternatives does not preclude some JDBC drivers from doing
something weird.

The Google search term is:

<database name> JDBC type mapping

Oracle leads to:

https://docs.oracle.com/cd/E11882_01/java.112/e16548/datacc.htm#g1028145

NUMBER java.sql.Types.NUMERIC java.math.BigDecimal oracle.sql.NUMBER
NUMBER java.sql.Types.DECIMAL java.math.BigDecimal oracle.sql.NUMBER

(Oracle only has NUMBER)

DB2 leads to:

https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/java/src/tpc/imjcc_rjvjdata.html

java.math.BigDecimal 	DECIMAL(p,s)

DECIMAL(p,s) or NUMERIC(p,s) 	java.math.BigDecimal

SQLServer leads to:

https://msdn.microsoft.com/en-us/library/ms378878(v=sql.110).aspx

decimal	DECIMAL	java.math.BigDecimal

numeric	NUMERIC	java.math.BigDecimal

MySQL leads to:

https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-type-conversions.html

DECIMAL[(M[,D])] 	DECIMAL 	java.math.BigDecimal

(NUMERIC is an alias for DECIMAL in MySQL)

That was 4 common databases.

If you have a specific database that you want to check then study the
docs for the JDBC driver.

I would be very surprised if there is one where DECIMAL is not mapped
to BigDecimal, but one never knows.

Arne