On 09/10/2014 01:55 PM, Claes Redestad wrote:
On 09/05/2014 03:49 PM, Alan Bateman wrote:
On 05/09/2014 14:03, Claes Redestad wrote:
Hi,
I'm requesting reviews and a sponsor for these changes to the recently
added parse methods (8041972), suggested during discussions on net-dev:
bug: https:/
On 09/05/2014 03:49 PM, Alan Bateman wrote:
On 05/09/2014 14:03, Claes Redestad wrote:
Hi,
I'm requesting reviews and a sponsor for these changes to the recently
added parse methods (8041972), suggested during discussions on net-dev:
bug: https://bugs.openjdk.java.net/browse/JDK-8055251
webrev
On 05/09/2014 14:03, Claes Redestad wrote:
Hi,
I'm requesting reviews and a sponsor for these changes to the recently
added parse methods (8041972), suggested during discussions on net-dev:
bug: https://bugs.openjdk.java.net/browse/JDK-8055251
webrev: http://cr.openjdk.java.net/~redestad/805525
Hi,
I'm requesting reviews and a sponsor for these changes to the recently
added parse methods (8041972), suggested during discussions on net-dev:
bug: https://bugs.openjdk.java.net/browse/JDK-8055251
webrev: http://cr.openjdk.java.net/~redestad/8055251/webrev.1/
discussion:http://mail.openjdk.j
+1
to Benedict and Martin
-Ulf
Am 12.04.2012 11:35, schrieb Martin Desruisseaux:
Le 12/04/12 10:57, Benedict Elliott Smith a écrit :
I think in this case it is reasonable to leave it to the user to ensure
that the input remains consistent for the duration of the call. It can be
documented if n
Le 12/04/12 10:57, Benedict Elliott Smith a écrit :
I think in this case it is reasonable to leave it to the user to ensure
that the input remains consistent for the duration of the call. It can be
documented if necessary, but as I say I think all imperative methods come
with that caveat by defin
>
> Remi and I have in the past had differences of opinion on the utility of
> introducing CharSequence versions of such methods.
>
> One benefit to using a string is that the object is immutable; there are
> no time-of-check-versus-time-of-**use conditions to worry about. Robust
> code should arg
e. Is there a reason I can't
fathom,
or was it an oversight? It would be nice to widen the type for this (and
potentially other equivalent methods).
Integer.parseInt (1.0 or 1.1) pre-date CharSequence (1.4),
that's why it use a String an not a CharSequence.
If you don't want
e both declared by CharSequence. Is there a reason I can't fathom,
>> or was it an oversight? It would be nice to widen the type for this (and
>> potentially other equivalent methods).
>>
>
> Integer.parseInt (1.0 or 1.1) pre-date CharSequence (1.4),
> that's why i
was it an oversight? It would be nice to widen the type for this (and
potentially other equivalent methods).
Integer.parseInt (1.0 or 1.1) pre-date CharSequence (1.4),
that's why it use a String an not a CharSequence.
If you don't want to break all already compiled programs,
you can&#
Hi,
Looking at the source code, it doesn't appear as though there is any reason
to require the input be a String - only length() and charAt() are called,
which are both declared by CharSequence. Is there a reason I can't fathom,
or was it an oversight? It would be nice to widen the type for this (
11 matches
Mail list logo
