RFR: 8221397 Support implementation-defined Map Modes

[Andrew Dinn]

Hi Alan,

Thanks for the feedback.

On 04/04/2019 20:47, Alan Bateman wrote:
> On 03/04/2019 10:10, Andrew Dinn wrote:
>> :
>> I still have two undecided points you might advise on:
>>
>> Does the javadoc for FileChannel.map and/or FileChannelImpl.map need
>> updating to record the possibility that UOE might be thrown?
> I don't think I understand your question about FileChannel.map as you've
> already got @throws UOE in the patch.

Yes, indeed :-)

> FileChannelImpl.map is JDK internal/implementation so nothing to do
> there (beyond the implementation change that you already have).

Ok, thanks.

> I looked through webrev.01. The package description has a catch-all for
> NPE so you need to specify that in each method. In the constructor it
> would be better to check for length 0 before assigning name (and of
> course name.length will throw NPE so you get that check for free). The
> test looks okay although I would probably catch the specific exceptions
> rather than catching Exception and catching them later but it amounts to
> the same checking.
Sorry, I am afraid I don't understand what you mean by "The package
description has a catch-all for NPE so you need to specify that in each
method."

What is the "package description"?

Which methods of which class does the term "each method" range over?

I have removed the call to Objects.requireNonNull from the MapMode
constructor and let the call to length generate the NPE. The assignment
of field name now follows the length check.

I'll await answers to the above questions before presenting another webrev.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander