JDK-4969995 : [Fmt-Nu] NumberFormat.setMaximumFractionDigits set to Integer.MAX_VALUE causes mem. leak
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 5.0
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-12-17
  • Updated: 2010-08-16
  • Resolved: 2010-08-16
Related Reports
Relates :  
Relates :  
Description
I am attaching a test case written by Santiago Pericas-Geertsen. This affects the xsltc tests causing OutOfMemory problems. According to Norbert this may be a regression caused by 4018937
//
// Written by ###@###.###
//

import java.text.DecimalFormat;
import java.text.NumberFormat;
import java.util.Locale;

public final class Test {

    public static void main(String[] args) throws Exception {
        NumberFormat f = NumberFormat.getInstance(Locale.getDefault());
        /* 
         * In earlier JDK's it was OK to use MAX_VALUE to avoid truncation.
         * In Tiger, this causes toPattern() to loop and run out of memory.
         * (c.f. line 2194 of java.text.DecimalFormat.java) I haven't 
         * checked the Javadoc for Tiger, but it this has changed it will
         * not be backward compatible with earlier JDK's.
         */
        f.setMaximumFractionDigits(Integer.MAX_VALUE);
        String p =  ((DecimalFormat) f).toPattern();
    }
}

Comments
EVALUATION It doesn't seem to be distant to specify such a large number as the number of decimal places.
16-08-2010

EVALUATION This is not a regression but is nevertheless a result of the fix for 4018937. Prior to that fix, it was reasonable to set a limit on the maximum number of fraction digits in a format. The limit of 340 digits was enough to handle all the precision possible in Java's aritmetic types. However, 4018937 added formatting support for BigDecimal and BigInteger which are arbitrary precision types. Thus it is no longer reasonable to cap the number of fractional digits to something less than what the user asks for. Looked at another way, this is simply a case of users needing to be careful what they ask for. ###@###.### 2004-01-05
05-01-2004