RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value

[Brian Burkhalter]

On May 29, 2013, at 11:40 AM, Mike Duigou wrote:

> In other cases similar to this an InternalError is thrown. It seems that for a property like this which can have a dramatic effect on performance silently ignoring bad input may not be the right choice.
> 
> java  -Djava.lang.Integer.IntegerCache.high=foobar
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at java.lang.Integer.valueOf(Integer.java:640)
> 	at sun.launcher.LauncherHelper.initHelpMessage(LauncherHelper.java:330)
> Caused by: java.lang.NumberFormatException: For input string: "foobar"
> 	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> 	at java.lang.Integer.parseInt(Integer.java:492)
> 	at java.lang.Integer.parseInt(Integer.java:527)
> 	at java.lang.Integer$IntegerCache.<clinit>(Integer.java:607)
> 	... 2 more
> 
> Doesn't seem to be that bad to me, but throwing internal error with an appropriate "system property java.lang.Integer.IntegerCache.high must be non-negative integer" message

Problem is that the String in the NumberFormatException in this case does not contain the reason, only the offending String. The parseInt() would need to be changed accordingly to make this intelligible.

I have no strong preference but it does not seem to me that failing to start the VM is a great plan.

Brian

> would seem to be superior than silently doing the wrong thing when:
> 
> java  -Djava.lang.Integer.IntegerCache.high=1024-Xmx2g
> 
> or the less obviously wrong:
> 
> java  -Djava.lang.Integer.IntegerCache.high=1024\
> -Xmx2g
> 
> is encountered.
> 
> Mike
> 
> On May 29 2013, at 11:00 , Brian Burkhalter wrote:
> 
>> http://cr.openjdk.java.net/~bpb/8015395/
>> 
>> Fix is to ignore bad value passed for java.lang.Integer.IntegerCache.high property and devolve to the default.
>> 
>> Thanks,
>> 
>> Brian
>