Details
-
Bug
-
Status: Closed
-
Resolution: Fixed
-
2.5
-
None
-
Operating System: All
Platform: All
-
43940
Description
We format a lot of double values to strings for PDF and PostScript output. We
currently use DecimalFormat in a problematic way (DecimalFormat is not
thread-safe). It also doesn't quite cover the requirements I have for the method
in that particular context. Furthermore, this has shown as a minor hotspot in
profiling sessions.
The task is to write an implementation of the following method:
static void formatDouble(double value, int decimals, int precision, StringBuffer
target)
value: the double value
decimals: the number of decimal places behind the decimal point
precision: the maximum precision for small values. If the value is between -1
and +1, the precision needs to be increased up to the number of decimal places
indicated by this parameter. This is used in contexts where transformation
matrices scale the content and a higher precision might be required.
target: the formatted characters are appended to the given StringBuffer. A
StringBuffer is chosen for efficiency so the number of String concatenations can
be reduced if possible. A wrapper method returning a String is easily written
around this method.
The goal of this method is to have a compact representation of a double value
while adressing accuracy requirements in the usage context.
the decimal point is . (".", PERIOD) (this is not dependent on the user's
locale)
A few examples (consider decimals being 4 and precision being 8):
0.0 should be rendered as "0"
0.1 should be rendered as "0.1"
1234.1 should be rendered as "1234.1"
1234.1234567 should be rendered as "1234.1235" (note the trailing 5! Rounding!)
1234.00001 should be rendered as "1234"
0.00001 should be rendered as "0.00001" (here you see the effect of the
"precision" parameter.
0.00000001 should be rendered as "0.00000001".
0.000000001 should be rendered as "0".
Acceptance criteria:
- The method has to prove to be faster than new DecimalFormat("0.######", new
DecimalFormatSymbols(Locale.US)).format(value) on Sun Java 1.4, 1.5 an 6.0. - The method must be thread-safe.
- The method must have a javadoc comment.
- It must be accompanied by a JUnit TestCase testing all aspects of the method.
- It should not depend on any additional library not already in the dependency
list of Apache XML Graphics Commons (its destination in the end).
Any volunteers? The prize: eternal glory and a big "thank you" from me!
Otherwise, this is just a reminder for myself.
Attachments
Attachments
Issue Links
- depends upon
-
FOP-1932 Re-implement DecimalFormatCache to prevent memory leak with Tomcat
- Closed