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
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:
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/
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:
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 arguably
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
+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
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
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 to break all already compiled programs
. 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 to break all already
10 matches
Mail list logo