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" <m...@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 <a...@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. >> > >> >>
