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 >
