RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

Chris Hegarty chris.hegarty at oracle.com
Wed Jun 3 21:00:20 UTC 2015


Looks good Paul, just a few minor comments. ( looked at all, but *security* and *sql* )

NetworkInterface
  s/Enumertion/Stream
    L127 * will be returned in the Enumeration. However, if the caller has the

  s/an/a
    L131 * @return an Stream object with all or a subset of the InetAddresses
    L 209 * @return an Stream object with all of the subinterfaces

-Chris.

> On 3 Jun 2015, at 21:17, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
> On Jun 3, 2015, at 9:27 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> On 03/06/2015 17:47, Paul Sandoz wrote:
>>> :
>>> Ok, i removed it but added an assert for the array being non-null and containing at least one element. I also refined the documentation of the stream returning method in light of this:
>>> 
>>>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8081678-enumeration-and-stream/webrev/
>>> 
>> The update looks good.
>> 
>> A minor point on getInetAddresses where the javadoc has been changed to "Get an Enumeration ...". I think that would be better as "Returns an Enumeration". Same thing in inetAddresses() where "Return" would read a bit better (IMO anyway).
>> 
> 
> It's frustratingly inconsistent throughout, i tried to make it locally consistent (for example, see the instance methods for sub interfaces). The whole doc needs to be consistently updated.
> 
> 
>> A niggle in inetAddresses is that it's got two /**.
>> 
> 
> Ooops fixed.
> 
> 
>> I was surprised to see PermissionCollection on the list, I don't know how often that is used.
>> 
> 
> grepcode.com shows quite a few usages of PermissionsCollection.elements(). Twas cheap to add.
> 
> 
>> For the tests then @library ../../util/streambootlib doesn't seem right. Is it time to move some infrastructure to make it easier to get at in other parts of the suite?
>> 
> 
> Quite probably, but not with this fix.
> 
> Thanks,
> Paul.



More information about the net-dev mailing list