Create java.util.stream.Stream from Iterator / Enumeration

Paul Sandoz paul.sandoz at oracle.com
Fri Jul 15 15:10:15 UTC 2016


> On 14 Jul 2016, at 17:55, Patrick Reinhart <patrick at reini.net> wrote:
> 
> Hi Paul,
> 
> On 2016-07-13 10:28, Paul Sandoz wrote:
> 
>> I see some comments already by Stuart and Alan, and concur with Alan
>> about working closely with jigsaw-dev.
>> Focusing on the public methods is good and then it will come down to
>> naming them appropriately. Given that sub-classes can override the
>> existing public Enumeration returning methods we most likely need to
>> specify the implementation behaviour of the Stream returning methods
>> i.e. specify in an @implSpec that they call the Enumeration returning
>> methods. Later on it may be possible to sub-types to implement more
>> optimally (but the Enumeration “string” is quite long and intertwined
>> with the internal code base)
> 
> When I understand you correctly here we should concentrate on the public
> methods naming firstly? I initially was not sure, what a proper naming
> for the steams method was. It seem to me reasonable the way Stuart pointed
> them out on his first comment to name them something like this:
> 
> Stream<URL> resources(String name)
> Stream<URL> systemResources(String name)
> 

Yes.


> Has anyone a better naming suggestion? For me those names would fit so
> far. If we look into the stream characteristics I would suggest that it
> has a unknown size and is immutable in both cases. Maybe the entries are
> also distinct, but there I'm not sure.
> 

I would expect the URLs to be distinct, but that might not be consistent with URL.equals i.e. i don’t trust URL handlers :-) therefore i would be wary of including the DISTINCT characteristic.

Paul.

> 
>> The protected findResources method may be trickier, i suggest leaving
>> that one alone for now.
> 
> From the point of a consumer of the public API I have no problems with
> this approach, as I created the enhancement issue on the public methods
> anyway.
> 
> Better to deal with that when we know how to do it better.
> 
> Cheers Patrick



More information about the core-libs-dev mailing list