Expecting Integer.valueOf(String) to accept Literal format ...
While discussing with colleagues, someone said: However, my main gripe is about not supporting in String representation of
an integer what is supported in its literal representation. Thus, Integer x = 1_000_000; is valid, whereas Integer.valueOf("1_000_000") is not. That sucks.
It seems to me that this is a reasonable expectation and has practical benefits (e.g. accepting program arguments that are integers with _'s). Supporting underscores in number literals (beginning JDK 7) was meant for readability of the Java source code. Perhaps doing this correctly incurs unwarranted implementation complexity in the JDK. As library writers however, how would you explain this mismatch? Was this side effect (arguably so) considered at all? Regards, Kedar
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.
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@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.
On 04/09/2016 12:33 PM, Christoph Engelbert wrote:
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?
Yes.
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.
Code which rejects underscores in strings today would not reject underscores if this were changed. This is a change which is visible to applications. Andrew.
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" <me@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@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.
I don't think the risk of breaking existing code in such a common API is worth the slight convenience improvement. If someone is keen on supporting such things, they can front this API by replacing underscores themselves, or more generally have something else accept underscores and canonicalize to what Integer.valueOf expects. On Saturday, April 9, 2016, Charles Oliver Nutter <headius@headius.com> 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" <me@noctarius.com <javascript:;>> 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@redhat.com <javascript:;>> 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.
-- Sent from my phone
What are you breaking though? Text that would not parse before will now parse as a valid integer in an extremely narrow set of cases. It is *exactly* the same as code that would not compile before compiling now, but at a different phase of development. And guess what...you're going to get this report over, and over, and over... - Charlie (mobile) On Apr 9, 2016 22:51, "Vitaly Davidovich" <vitalyd@gmail.com> wrote:
I don't think the risk of breaking existing code in such a common API is worth the slight convenience improvement. If someone is keen on supporting such things, they can front this API by replacing underscores themselves, or more generally have something else accept underscores and canonicalize to what Integer.valueOf expects.
On Saturday, April 9, 2016, Charles Oliver Nutter <headius@headius.com> 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" <me@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@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.
-- Sent from my phone
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@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@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.
Hello, actually Integer.decode is used to parse JLS Integers. And its JavaDoc explicitely state that it does not support underscores. I would have changed that method, not the valueOf. I think there are some legit cases where changing the behavior of valueOf can cause problems. It is (unfortunatelly) often used to verify the format of a number (instead of retrieving its value). And if this verificationsuddenly gets more lenient it might let numbers pass which makes problems in other (possibly non-java) places. Gruss Bernd Am Sat, 9 Apr 2016 21:22:01 +0600 schrieb "Tagir F. Valeev" <amaembo@gmail.com>:
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 CON> it is a valid syntax in javac, it should be a valid syntax in CON> JDK APIs. My first impression was that this was an obvious CON> oversight.
CON> - Charlie (mobile) CON> On Apr 9, 2016 21:04, "Christoph Engelbert" <me@noctarius.com> CON> 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@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.
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" <me@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@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.
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.darcy@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" <me@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@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.
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. 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 On Wed, Apr 13, 2016 at 1:00 PM, kedar mhaswade <kedar.mhaswade@gmail.com> wrote:
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.darcy@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" <me@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@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.
Am Wed, 13 Apr 2016 13:16:45 -0500 schrieb Paul Benedict <pbenedict@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
participants (9)
-
Andrew Haley
-
Bernd Eckenfels
-
Charles Oliver Nutter
-
Christoph Engelbert
-
joe darcy
-
kedar mhaswade
-
Paul Benedict
-
Tagir F. Valeev
-
Vitaly Davidovich