Right way to convert of BigDecimal to String

Question

Why I should use valueOf()? why cant I use the implicit conversion?

Code Snippet is shown below:

BigDecimal xmlvalue = new BigDecimal(12.3434379328948927894789237);
String str1 = String.valueOf(xmlvalue); //Option 1
String str2 = "" + xmlvalue; //Option 2

Answer 1

You can use BigDecimal#toString to convert a BigDecimal to string

Answer 2

you can use the toString() method

xmlvalue.toString();

Answer 3

One could argue that it is more readable to use valueOf(x) than "" + x. Internally, both will fall back to toString but they can also deal with null values (where null.toString() will throw a NullPointerException).

In theory, the performance of valueOf(x) should be better than "" + x, as the latter uses a StringBuilder internally, which can lead to some overhead.

When you know that your BigDecimal is non-null (as in your example), you should just use toString.

By the way, be careful with the BigDecimal(double) constructor. The safer approach is to use new BigDecimal("12.3434379328948927894789237") in your example. The reason why BigDecimal(double) is unpredicable is explained in its Javadoc comment.

Answer 4

For two reasons:

1. Using String.valueOf better conveys your intent: you obviously try to get the String representation of a BigDecimal value; abusing String concatenation requires a little more mental effort to understand what you are trying to do
2. It may be faster: Using concatenation will internally create a StringBuilder, which concatenates two Strings and then calls toString() onto itself (though the compiler may be clever enough to get rid of these unnecessary operations)

Answer 5

Why would you ever manually use "" + string for a conversion to String? I know that a lot of developers use that, but to me it seems just like taking an advantage of Java's developer friendliness and the fact that it does a lot of stuff(terminus technicus "conversions") automatically. In other words it's a lazy way around and I don't like raping Java when String.valueOf() is implemented exactly for this purpose.

Technical answer:

When a + "" is used with an integer a. It behaves as such:

String.valueOf(a) + new String("");

This creates two String objects, while String.valueOf(a) uses just one.

Answer 6

Using BigDecimal doesn't bring back the precision lost in double If you need more than 15 digits of accuracy you need to use String and BigDecimal.

BigDecimal xmlvalue = new BigDecimal("12.3434379328948927894789237");
String str1 = xmlvalue.toString(); // Simplest Option 

If you have a double you may as well just do

// creating BigDecimal here doesn't help unless you do rounding.
String str1 = String.valueOf(d); 

Answer 7

I think better way is to use class - java.text.DecimalFormat because in practical scenarios , there is no relation between actual value represented by these number classes like BigDecimal & their String representations, though you haven't listed your reason for wanting a String value for an altogether different type of data.

In my opinion, String representation is all about formatting & this DecimalFormat class gives you better control over that e.g. I needed to write few BigDecimal values to a text file and different values needed to be in different format.

A portion of Java Doc,

DecimalFormat is a concrete subclass of NumberFormat that formats decimal numbers. It has a variety of features designed to make it possible to parse and format numbers in any locale, including support for Western, Arabic, and Indic digits. It also supports different kinds of numbers, including integers (123), fixed-point numbers (123.4), scientific notation (1.23E4), percentages (12%), and currency amounts ($123). All of these can be localized.

Answer 8

The String#valueOf use Double#toString method in this case.

I think is better use BigDecimal#toString method. For example if you want to converted back this data, it better use this toString method.

If that string representation is converted back to a BigDecimal using the BigDecimal(String) constructor, then the original value will be recovered.