RFR: 8015315: Stream.concat methods

Peter Levart peter.levart at gmail.com
Mon Jul 1 15:50:58 UTC 2013


On 07/01/2013 03:19 PM, Remi Forax wrote:
> On 07/01/2013 01:36 PM, Peter Levart wrote:
>>
>> On 07/01/2013 11:52 AM, Remi Forax wrote:
>>> On 06/29/2013 02:58 AM, Henry Jen wrote:
>>>> Hi,
>>>>
>>>> Please review the webrev that add concat static method to Stream and
>>>> primitive Streams.
>>>>
>>>> http://cr.openjdk.java.net/~henryjen/ccc/8015315.0/webrev/
>>>>
>>>> Cheers,
>>>> Henry
>>>
>>> Hi Henry,
>>> I find the the cast to Spliterator<T> in Streams.concat() dubious,
>>> I can not see how it can be correct, could you explain why this cast 
>>> is Ok.
>>>
>>> cheers,
>>> Rémi
>>>
>>
>> Hi,
>
> Hi,
>
>>
>> I think that if we want to concat say Stream<Integer> with 
>> Stream<Long>, producing Stream<Number>, there would have to be an 
>> unsafe cast somewhere. Since Stream<T> API apears to be covariant 
>> (like for example Iterator<T>), casting Stream<? extends T> to 
>> Stream<T> seems to be safe.
>
> if Stream is covariant, it should be possible to create a Stream<T> 
> from a Spliterator<? extends T>,
> so there is no need of such unsafe cast.

Sorry, I meant so say:

Spliterator<T> API apears to be covariant (like for example 
Iterator<T>), so casting Spliterator<? extends T> toSpliterator <T> 
seems to be safe.

Regarding creating Stream<T> from a Spliterator<? extends T> it wouldn't 
help here, since we can't create Spliterator<? extends T> from two 
spliterators: Spliterator<? extends T> and Spliterator<? extends T> 
without unsafe cast in the first place...

So maybe we should bury the unsafe cast in the ConcatSpliterator's 
constructor then...

Regards, Peter

>
>>
>> Regards, Peter
>>
>
> cheers,
> Rémi
>




More information about the core-libs-dev mailing list