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