JDK 8 code review request for initial unsigned integer

[Roger Riggs]

The scope of CR 4504839  doesn't cover broader changes to APIs, so
the suggestion to upgrade String to CharSequence should be a separate CR
to be examined and reviewed separately.


The new (and some old) NumberFormatExceptions contain English text
preformatted with arguments.  From an I18n localization view, that's 
hard to localize.
A fixed string, though less informative could be localized more easily.


On 01/19/2012 10:49 AM, Ulf Zibis wrote:
> Am 18.01.2012 22:20, schrieb Roger Riggs:
>> On 01/18/2012 03:09 PM, Joe Darcy wrote:
>>>
>>>> 1. In the new parsing methods, could the String arguments be 
>>>> changed to the more general
>>>> java.lang.CharSequence? For many parsing applications, it could be 
>>>> more convenient
>>>> to pass a CharSequence than to create a new String.
>>>
>>>
>>> I don't think that would be very helpful in this case.  If the 
>>> methods were changed to take a CharSequence, the first action I'd 
>>> write in the method would be to call toString on the argument; this 
>>> is necessary to guard against the class of 
>>> time-of-check-versus-time-of-use problems because the CharSequence 
>>> objects can be mutable.
>>
>> Though the existing methods do operate on immutable inputs,  there is no
>> expectation of synchronization provided by the parsing methods of 
>> Integer, etc.
>>
>> Making the change would not break any existing code because it 
>> continues to pass
>> immutable inputs.
>>
>> New code that calls the methods using CharSequences, in full 
>> knowledge of the
>> mutability of CharSequences, would manage or avoid the concurrency 
>> issues,
>> most likely by keeping the computation to a single thread or 
>> otherwise synchronizing
>> changes to the object that implement CharSequence.
>>
>> Since Integer makes no assurances about being multi-thread safe it 
>> can operate
>> under those assumptions and does not need to make copies of the 
>> arguments.
>> In any case, the copy operation itself could run afoul of concurrency 
>> faults, and it
>> doesn't matter where the copy occurs, inside or outside of the 
>> Integer methods.
>>
>> Please consider the necessity of  extra steps by the developer (to 
>> produce strings)
>> and the potential savings in the load on the heap by not creating 
>> copies of strings.
>>
>> Roger
>
> +1
>
> -Ulf
>