There are several differences between HashMap and Hashtable in Java:
Hashtable is synchronized, whereas HashMap is not. This makes HashMap better for non-threaded applications, as unsynchronized Objects typically perform better than synchronized ones.
Hashtable does not allow null keys or values. HashMap allows one null key and any number of null values.
One of HashMap's subclasses is LinkedHashMap, so in the event that you'd want predictable iteration order (which is insertion order by default), you could easily swap out the HashMap for a LinkedHashMap. This wouldn't be as easy if you were using Hashtable.
Since synchronization is not an issue for you, I'd recommend HashMap. If synchronization becomes an issue, you may also look at ConcurrentHashMap.
Use setRoundingMode, set the RoundingMode explicitly to handle your issue with the half-even round, then use the format pattern for your required output.
Example:
DecimalFormat df = new DecimalFormat("#.####");
df.setRoundingMode(RoundingMode.CEILING);
for (Number n : Arrays.asList(12, 123.12345, 0.23, 0.1, 2341234.212431324)) {
Double d = n.doubleValue();
System.out.println(df.format(d));
}
gives the output:
12
123.1235
0.23
0.1
2341234.2125
EDIT: The original answer does not address the accuracy of the double values. That is fine if you don't care much whether it rounds up or down. But if you want accurate rounding, then you need to take the expected accuracy of the values into account. Floating point values have a binary representation internally. That means that a value like 2.7735 does not actually have that exact value internally. It can be slightly larger or slightly smaller. If the internal value is slightly smaller, then it will not round up to 2.7740. To remedy that situation, you need to be aware of the accuracy of the values that you are working with, and add or subtract that value before rounding. For example, when you know that your values are accurate up to 6 digits, then to round half-way values up, add that accuracy to the value:
Double d = n.doubleValue() + 1e-6;
To round down, subtract the accuracy.
Best Answer
Different people use these terms in somewhat different ways, but here's my take:
1) "Business" and "domain" are roughly synonyms. "Domain" is a bit more general in that it doesn't make the assumption that you're writing a business application. So if we were writing a scientific app or a game, we might prefer to refer to the relevant part of the code as "domain" code rather than "business" code. So in the remainder of this explanation I'll use "domain" since it's more general.
2) "Domain logic" comprehends both "domain objects" and "domain services". For various reasons (technical and otherwise) many architectures employ a design where the domain logic is divided into objects for storing data ("domain objects") and objects that manipulate those ("domain services"). Martin Fowler and others have pointed out that that's not very OO since a big part of the OO concept is to put functionality together with data, and that's right, but it is what it is. Domain objects are the data and domain services are the do-stuff-with-the-data part.
3) In domain-driven design, the idea is to get back to true OO design, and so the various service methods make their way back to the domain objects so that you have objects in the OO sense rather than what are sometimes called "anemic" objects. In a DDD the domain objects themselves are more robust and so they form the domain logic. In reality there may still be some domain services too, but this is typically smaller in a DDD than in a more traditional domain objects vs. services model.