Expecting Integer.valueOf(String) to accept Literal format ...

[Tagir F. Valeev]

Strictly speaking there are many more ways to specify integer constant
in Java. Like

int x = 045;
int x = 0x34;
int x = 0b11101;

So why should we support "4_5_6" only, but not "0x456"? Note that
"045" is already parsed by Integer.valueOf, but as decimal number, not
as octal. Thus I don't think that being valid syntax in Java language
should be considered as a reason here.

Also note that there are more integer parsing methods like
Scanner.nextInt() and so on. I feel that they should provide
consistent behavior with Integer.valueOf(). However changes in Scanner
might break even more existing code.

With best regards,
Tagir Valeev.

CON> I feel like this is an obvious API gap that should be fixed. If it is a
CON> valid syntax in javac, it should be a valid syntax in JDK APIs. My first
CON> impression was that this was an obvious oversight.

CON> - Charlie (mobile)
CON> On Apr 9, 2016 21:04, "Christoph Engelbert" <me at noctarius.com> wrote:

>> Hey Andrew,
>>
>> Not sure it would risk breaking compatibility. It’s fairly easy to support
>> it by just replacing underscore before parsing. Do you think of code that
>> is expected to not parse underscore arguments? I think it’s a fair request
>> to support underscore based integer representations, even though I never
>> needed it yet, anyhow it makes sense to me to give users the possibility to
>> have the same integer representation in, let’s say, properties files.
>>
>> Chris
>>
>> > On 09 Apr 2016, at 11:06, Andrew Haley <aph at redhat.com> wrote:
>> >
>> > On 08/04/16 23:36, kedar mhaswade wrote:
>> >> As library writers however, how would you explain this mismatch?
>> >
>> > Changing valueOf(String) runs the risk of breaking existing Java code,
>> > and Java takes compatibility very seriously.  Whether it's worth the
>> > risk is a matter of judgement.
>> >
>> > Andrew.
>> >
>>
>>