Thanks Joe, for the bug report! I am a bit unsure about gauging interest in this by looking at the votes on the bug report because I expected this to just work, especially since the API was already there! To me, not having this behavior in the platform is a violation of POLA [1].
I was thinking harder on the compatibility concerns raised on this thread, but the fact that JDK team itself filed this bug removed them! But I guess I will live with the status quo. 1- http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment On Sat, Apr 9, 2016 at 9:44 AM, joe darcy <joe.da...@oracle.com> wrote: > The Project Coin team did file > > JDK-6863378: Project Coin: Consider library support for underscores in > numbers and binary literals > https://bugs.openjdk.java.net/browse/JDK-6863378 > > back before JDK 7 shipped. This change in question wouldn't be > unreasonable, but it didn't seem critical either, hence the bug was filed > and left open to gauge interest, which generally has been slight. > > Cheers, > > -Joe > > > On 4/9/2016 7:44 AM, Charles Oliver Nutter wrote: > >> I feel like this is an obvious API gap that should be fixed. If it is a >> valid syntax in javac, it should be a valid syntax in JDK APIs. My first >> impression was that this was an obvious oversight. >> >> - Charlie (mobile) >> 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. >>>> >>>> >>> >
