On 2016-04-10 06:36, Claes Redestad wrote:
For completeness, maybe we should also check that the value is not
part of a continuation:
// Check that the value is followed by a
// newline and does not have a continuation
Hi Steve,
checking that there's a newline after the true seems OK according to the
grammar[1], so that seems like a good call.
Not sure it really matters, but perhaps setting isMultiRelease to true
once the test passes improves readability:
if (MULTI_RELEASE_ENABLED && versi
This change has been pushed to jdk9/dev. The hotspot gatekeeper
will bring it down into the hotspot forests.
-Chris.
> On 7 Apr 2016, at 18:14, Chris Hegarty wrote:
>
> Enough technical debt has been paid down that we can now create the new
> JDK-specific module as proposed by JEP 260 [1], name
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
The issue with "program order" is it may confuse people, particularly ones
that don't know what a compiler fence is, into thinking it implies CPU
fences as well (they may not know those either, perhaps). You'd need to
define program order anyway for them. IMHO, I'd rather see compiler fence
used
On 04/09/2016 09:03 AM, Vitaly Davidovich wrote:
Just to confirm - opaque is also a compiler fence right? C++ relaxed doesn't
require compiler fence, but it sounds like opaque does. Would be good to
clarify this, unless "program order" is the way you want to do that.
"Program order" normally
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
Just to confirm - opaque is also a compiler fence right? C++ relaxed
doesn't require compiler fence, but it sounds like opaque does. Would be
good to clarify this, unless "program order" is the way you want to do that.
On Saturday, April 9, 2016, Doug Lea wrote:
> On 04/08/2016 02:39 PM, Hans B
On 04/08/2016 02:39 PM, Hans Boehm wrote:
My prior impression was that Opaque was intended to be similar to a C++
memory_order_relaxed access to a variable that is declared as both atomic
and volatile, with the unordered interpretation of C++ "volatile".
Yes. This is awkward to spell out in de
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.
16 matches
Mail list logo
