Am Wed, 13 Apr 2016 13:16:45 -0500
schrieb Paul Benedict :
> 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 wo
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 b
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 h
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 e
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 (unfortunate
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 th
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 repo
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
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" wrote:
> Hey Andrew,
>
> Not sure it
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 suppo
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 t
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.
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
13 matches
Mail list logo
