JDK 8 code review request for initial unsigned integer
Roger Riggs
Roger.Riggs at oracle.com
Thu Jan 19 16:17:03 UTC 2012
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
>
More information about the core-libs-dev
mailing list