Integer.parseInt

[Joe Darcy]

On 4/11/2012 7:45 AM, Rémi Forax wrote:
> On 04/11/2012 04:18 PM, Benedict Elliott Smith wrote:
>> 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 (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't just replace String by CharSequence because the exact 
> signature of the method
> (with the parameter types) is encoded in the bytecode.
> Joe Darcy write a cool blog post on that [1].

That is a kinder description of the blog post than I would expect :-)

FYI, a fuller exploration of that issue in a broader context is written 
up in:

     
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html

>
> The best here is to add new methods that takes a CharSequence, move 
> the code that use
> a String in them and change the method that takes a String to delegate 
> to the one that use
> a CharSequence.
>
> cheers,
> Rémi
> [1] https://blogs.oracle.com/darcy/entry/kinds_of_compatibility
>

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 work sensibly even with mutable CharSequences, and 
the easiest way to ensure that is to call the toString method of a 
CharSequence passed as a parameter.

-Joe