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.g...@oracle.com
