8067801: Enforce null check for underlying I/O streams

Lance Andersen lance.andersen at oracle.com
Wed Jul 17 20:02:08 UTC 2019

Hi Brian,
> On Jul 17, 2019, at 3:46 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> Hi Lance,
>> On Jul 17, 2019, at 12:35 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>> I might consider adding the NPE message to the individual classes as it is easy to miss in the java.io <http://java.io/> <http://java.io/ <http://java.io/>> package but that is just a suggestion.  Especially with the new search feature of javadoc, I usually go straight to the method so would never see the info in the package comments.
>> It might be better but I don’t know where else in java.io <http://java.io/> an NPE is thrown without being documented on the ctor/method itself. If there are other places then a general inspection might be in order.
> I looked through some of the other classes and there are not-locally-documented NPEs in a number of constructors including all the Readers and Writers. I think for now I’d rather leave it as is.

Understand, go with what makes sense,  BTW, I was not suggesting adding it to the individual constructor javadoc, but to the Class overview javadoc at the top of the class.

Totally get leaving it as is. :-)
>> Note that the practice of using the package-level doc occurs also in java.nio:
>> "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown."
>>> Did you give any thought of using TestNG/assertThrows?  Not a big deal, I just a personal preference :-)
>> I don’t see how that would work in this case as we do *not* expect an exception.
> Sorry: I had it backwards - d’oh!


Blame me as I could have been clearer in my comment, apologizes for that :-)

> You are correct, that would work. I’ll look into revising it.
> What I was actually wondering about with respect to the tests is whether one can have the same bug ID in two different tests.

Yes that should be OK as @bug is just an informational tag: https://openjdk.java.net/jtreg/tag-spec.html

> Also I was not sure whether there might be a location where the two merged into a single test would be appropriate.

I think what you have is fine, a unique test in each subdirectory as it is organized by class.  What you might consider is having a generic NPE Test class, which validates the error for Constructors and methods as described in the package javadoc.  Maybe this is a TBD, but if you decide that is a good idea, consider renaming the test now to maybe NPETests.java

Either way you are good to go.

> Thanks,
> Brian

 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>

More information about the core-libs-dev mailing list