I have been debugging some code recently using eclipse and I came across something that I can't explain and wanted to get an answer. The following is a JUnit test that is successful. When I attempted to debug it I get an odd result in the debug screen for csp at the end. I would expect the intCompact to be: 231246....... , but it is -9223372036854775808. Yet the test is successful.

What am I missing?

import static org.junit.Assert.assertEquals;import java.math.BigDecimal;import org.junit.Test;public class BigDecimalTest { @Test public void Test1() { BigDecimal opp = new BigDecimal("1.5"); BigDecimal liq = new BigDecimal("1.5"); BigDecimal div = new BigDecimal("0.08"); assertEquals("",2.25d,opp.multiply(liq).doubleValue(),0d); assertEquals("",1.5d,opp.doubleValue(),0d); assertEquals("",.12d,opp.multiply(div).doubleValue(),0d); //Date startDate = new Date("5/9/2013"); //Date endDate = new Date("11/15/2013"); //BigDecimal years = startDate.getYearsBetweenBigDecimal(endDate); //assertEquals("",5.20547945205479E-01,years.doubleValue(),1E-14); BigDecimal years = new BigDecimal(5.20547945205479E-01); BigDecimal dsp = opp.multiply(years).multiply(div); assertEquals("",6.24657534246575E-02,dsp.doubleValue(),1E-14); BigDecimal csp = opp.multiply(liq); csp = csp.add(dsp); assertEquals("",2.31246575342466E+00,csp.doubleValue(),1E-14); }}

Is your goal here to understand how BigDecimal is implemented?

intCompact is an internal part of the representation which BigDecimal can decide to use when it believes the value can be safely represented as an integer (long actually).

However, if the value being represented by BigDecimal is outside that range (or it believes it may be - such as doing a multiplication) then intCompact may no longer be in use - so checking the value can show you garbage essentially.

At that point, BigDecimal relies on intValue instead, which is itself a BigInteger and intCompact is ignored.

Does that make sense?

If you want to learn more about exactly how BigDecimal is processing these calculations, you can set a breakpoint inside the BigDecimal source code and step through it to see how the multiply and add operations are being implemented in this case.

Which indicates that the values I am working with did hit the INFLATED threshold. Okay in this example it does quickly go out to 56 decimal points, which would easily put it over the threshold. From the source code I see that it would put it into a BigInteger. Taking a look at the Debug I can see the intCompact is "Set" to inflated which means it is coming from intVal (BigInteger). Then BigInteger is using an array of type int. Which is supposingly in Big Endian. Yet how would 158225327 translate into 231246...

From a more practical standpoint, the toString() method in BigInteger is in some sense the gold standard for how the internal representation is turned back into a number that you can look at. If you want to spend the time to work through this it will explain (implicitly) how the underlying representation works:

public String toString(int radix) { if (signum == 0) return "0"; if (radix < Character.MIN_RADIX || radix > Character.MAX_RADIX) radix = 10; // Compute upper bound on number of digit groups and allocate space int maxNumDigitGroups = (4*mag.length + 6)/7; String digitGroup[] = new String[maxNumDigitGroups]; // Translate number to string, a digit group at a time BigInteger tmp = this.abs(); int numGroups = 0; while (tmp.signum != 0) { BigInteger d = longRadix[radix]; MutableBigInteger q = new MutableBigInteger(), a = new MutableBigInteger(tmp.mag), b = new MutableBigInteger(d.mag); MutableBigInteger r = a.divide(b, q); BigInteger q2 = q.toBigInteger(tmp.signum * d.signum); BigInteger r2 = r.toBigInteger(tmp.signum * d.signum); digitGroup[numGroups++] = Long.toString(r2.longValue(), radix); tmp = q2; } // Put sign (if any) and first digit group into result buffer StringBuilder buf = new StringBuilder(numGroups*digitsPerLong[radix]+1); if (signum<0) buf.append('-'); buf.append(digitGroup[numGroups-1]); // Append remaining digit groups padded with leading zeros for (int i=numGroups-2; i>=0; i--) { // Prepend (any) leading zeros for this digit group int numLeadingZeros = digitsPerLong[radix]-digitGroup[i].length(); if (numLeadingZeros != 0) buf.append(zeros[numLeadingZeros]); buf.append(digitGroup[i]); } return buf.toString(); }

For beginner Java programmers or at least those new to the Eclipse IDE, the following tutorial will show some (four) ways in which you can import your Java projects to your Eclipse workbench.
Introduction
While learning Java can be done with…

Introduction
This article is the first of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article explains our test automation goals. Then rationale is given for the tools we use to a…

Viewers learn how to read error messages and identify possible mistakes that could cause hours of frustration. Coding is as much about debugging your code as it is about writing it.
Define Error Message:
Line Numbers:
Type of Error:
Break Down…

Viewers will learn one way to get user input in Java.
Introduce the Scanner object:
Declare the variable that stores the user input:
An example prompting the user for input:
Methods you need to invoke in order to properly get user input: