Java – Why does Java define BigInteger / BigDecimal values of 10

javamath

Question perhaps slightly left of field – but I'm curious as to the logic behind why Java's BigInteger/BigDecimal classes feel the need to define a constant of TEN?

Example taken from java.math.BigInteger:

/**
 * The BigInteger constant zero.
 *
 * @since   1.2
 */
public static final BigInteger ZERO = new BigInteger(new int[0], 0);

/**
 * The BigInteger constant one.
 *
 * @since   1.2
 */
public static final BigInteger ONE = valueOf(1);

/**
 * The BigInteger constant two.  (Not exported.)
 */
private static final BigInteger TWO = valueOf(2);

/**
 * The BigInteger constant ten.
 *
 * @since   1.5
 */
public static final BigInteger TEN = valueOf(10);

Now I'm assuming it might be something to do with use in scaling functions or the like, but it did make me curious – especially since TEN seems to first appear in 1.5 whereas ONE and ZERO existed much earlier (I can also see why 1 and 0 would be more immediately useful than 10, too)

Anyone know?

Best Answer

BigInteger and BigDecimal are immutable objects. Once instantiated, if you want to do something with it, you create a new object. This isn't a problem per say, and actually avoids many other problems (especially when threading), and numbers tend to be things that are constants - you don't change them.

It is very common for code that is working with BigDecimal and BigInteger to need to use the values 0, 1, 2, and 10. If these were not defined as constants in the class, programmers would often find themselves instantiating those objects again and again. This can be a problem because it means you are creating objects unnecessarily where there are perfectly acceptable and commonly used objects.

^{I once worked on a code base where miles and kilometers were frequently used. Prior to a clean up, we had over a dozen different places where there was a static BigDecimal MILES_IN_ONE_KM = new BigDecimal("0.621371") in one way, shape, form or another - fortunalty there were only those and they were statics rather than being created every time we converted from one distance unit to another...}

This is a rather special case of the Object Pool Pattern. Other examples of it can be found in the Integer cache (primary used in boxing / unboxing), and the Color class where things such as 'RED' and 'BLUE' are defined.

By allocating these commonly used objects in the class, it provides a rather low cost to have a few extra objects floating around rather than creating and destroying scores every time you want to multiply a number by 10 or add 1.

Articles in Variable Names

They add little to no value in most cases, but make the code longer to read.

Usually, I'd rarely have a the need for the distinction between a "a" or "the" in the flow of a function, so it doesn't make sense to use articles.

It's a formal programming language and I am fine with it not reading exactly like a natural language. In fact, it's probably better this way, not everything's necessarily so great about natural languages.

There are a few cases where readability can benefit from using articles though, for instance if you want to implement a checker for a "is a" relationship with a method signature like boolean isA(Object o, Class<?> cl) ^{(I'm not advocating this to be a good idea)}.

Hard-Coded Strings

It depends on whether you plan to reuse them or not, and whether that reuse is driven by semantics (and not just the fact that the String has the same content in different places) and spread across multiples classes or sub-systems.

To that extent, I usually use these rules:

If you have the same string multiple times and it has the same meaning acros multiple classes, then extract to constants in an interface.
If you have the same string multiple times within a single class and it has the same meaning within that class, then extract to constants within the class.
If you have only a few number of repetitions of as tring, or they just happen to be identical but aren't guaranteed to always be in the future, then I'd leave them inlined.
If any of the above would render maintenance difficult, screw rules 1 to 3 and do whatever works best for you.

Of course, make sure that the constant's name makes the code as semantically valid as the string it holds. That also applies for other things that aren't strings (like Predicates, for instance).

Java – Storing object-graphs with class-evolution in Java with transformation (long time archiving)

I use the Externalizable interface to solve this problem. It doesn't really meet your Appendable requirement, but it might get you started.

Externalizable lets you write each object out yourself. What I do is include a version number for each class. Then, when I change the class, I adjust the readExternal method so it can can read the new format as well as the old ones and change the writeExternal method to write the new format with the new version number. The code to read old formats may need to change to fill new fields (and not fill in removed fields). Then I'm ready to go.

There's usually some sort of object hierarchy in the graph, so if a level 2 class is seriously modified, the new write/read for that class can output/input something completely different from the old one, with completely new lower-level classes.

Some care is needed because sometimes there isn't a hierarchy. You have to remember that, after reading, you can't set a field by pulling data from objects in fields because they may not really be there yet. (Sometimes I add a setUp method to all my classes that gets called after the top-level objectRead so the objects in the graph can get themselves organized after the whole graph has been read.

And it sometimes helps to write out objects manually using a method that just writes out plain bytes. (But on the read you have to know precisely what you are reading, where readExternal will read a complete object of any class.)

Code looks something like:

// version 3 -- November 16, 2013
// version 2 -- March 22, 2013
// version 1 -- April 1, 2012
public void writeExternal( ObjectOutput out )  throws IOException  {
    out.writeShort( 3 )
    out.writeLong( longData );
    out.writeObject( something );
    ....
}

public void readExternal( ObjectInput in )  throws IOException,
             ClassNotFoundException  {
    short version = in.readShort();
    if (version > 3)  {
        // Admit program is too old to read file.
    }
    else if (version == 3)  {
        longData = in.readLong();
        something = readobject();
    }
    else if (version == 2)  {
        longData = 5;
        something = readobject();
    }
    else
       ...
}

Best Answer

Related Solutions

Java – articles in variable names and hard-coding strings

Articles in Variable Names

Hard-Coded Strings

Java – Storing object-graphs with class-evolution in Java with transformation (long time archiving)

Related Topic