RFR: 4247235: (spec str) StringBuffer.insert(int, char[]) specification is inconsistent

[Jim Gish]

I've created a new bug: https://jbs.oracle.com/bugs/browse/JDK-8005118 - 
I'll address the consistency issues there, and treat the NPE specs 
separately.

Jim

On 12/17/2012 11:29 AM, Jim Gish wrote:
>
> On 12/15/2012 08:58 AM, Alan Bateman wrote:
>> On 14/12/2012 22:49, Jim Gish wrote:
>>> Please review 
>>> http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ 
>>> <http://cr.openjdk.java.net/%7Ejgish/Bug4247235-Add-Blanket-Null-Stmt/>
>>>
>>> This minor spec change (which will require CCC approval), adds 
>>> blanket null-handling statements to both StringBuffer and 
>>> StringBuilder, equivalent to the one already in String.
>> It looks like most (all?) of the methods defined by StringBuffer and 
>> StringBuilder that can throw NPE already specify it. Are you planning 
>> on removing the @throws from the methods?
> I left it as is to raise this very point.  In a previous proposed 
> change, adding a method somewhere that was explicit about throwing 
> NPE, someone brought up the issue that we should rely on a blanket 
> statement and not clutter the javadoc with @throws NPE.
>
> Should we, in fact, be removing these method-specific @throws specs?
>>
>> I see that String uses <tt>null</tt>, the proposed update to 
>> StringBuilder uses <code>null</code>, and the proposed update to 
>> StringBuffer uses {@code null}. We should try to be consistent.
> I aimed for self-consistency here -- keeping what was already in 
> place.  This was intentional to raise the point of whether everything 
> should be brought up to date.
>
> Thanks,
>    Jim
>
>>
>> -Alan.
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com