Am Wed, 13 Apr 2016 13:16:45 -0500 schrieb Paul Benedict <pbened...@apache.org>:
> I think the argument for changing Integer.valueOf(String) hinges on > the belief that the method is meant to parse JLS integer syntax. If > it is, the Javadocs don't speak to that responsibility. If it's an > omission from the docs, I would never have guessed. I agree it is not. It points to parseInt() which itself exactly describes its grammar: # Parses the string argument as a signed decimal integer. # The characters in the string must all be decimal digits, # except that the first character may be an ASCII minus sign # '-' ('\u002D') to indicate a negative value or an ASCII plus # sign '+' ('\u002B') to indicate a positive value. This quite concrete. The decode() method mentioning the JLS (and supporting the integer literal prefixes) is a more ikely candidate for that. But that method explicitely dislclaims its heritage: # DecimalNumeral, HexDigits, and OctalDigits are as defined in section # 3.10.1 of The Java™ Language Specification, except that underscores # are not accepted between digits. So while I symphatise with having a full features JLS integer parser the spec would require a change to accept it. Maybe a new method... (it could eve take a JLS version argument :) > > Regarding how it parses today, I wouldn't be surprised if there are > validation libraries out there using Integer.valueOf(String) for > user-input validation. Good or bad decision, I expect them to exist. > They probably have relied on it not being JLS compliant. So changing > the behavior would break the assumption and their code. > > Cheers, > Paul