RFR: JDK-8297299 SequenceInputStream should not use Vector [v2]

[Markus KARG]

On Sun, 20 Nov 2022 15:21:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman WDYT?
>
>> @AlanBateman WDYT?
> 
> The long standing and undocumented behavior is unfortunate. I don't think the 1-arg constructor is fixable while still allowing for lazy behavior. So I think the only thing we can do is document the existing behavior that a null element in the enumeration will lead to read or close throwing NPE at a later time. For the 2-arg constructor then we need to be cautious. This is very old API and we have to assume the phenomenon that is Hyrum's Law. You may be right that nobody can reasonably depend on the current behavior but I think it would need a survey to inform the discussion. I can't tell if this PR was intended to rehabilitate SequenceInputStream or just a reaction to seeing that it uses Vector. If the latter then you could just change it to:
> 
> var list = new ArrayList<InputStream>();
> list.add(s1);
> list.add(s2);
> e = Collections.enumeration(list);
> peekNextStream();
> 
> and preserve the existing behavior.
> 
> While SequenceInputStream may be legacy I guess it would be interesting to get some idea of usage or usages that use something better in libraries. Maybe there is a case for InputStream to have a concat method for example.

Indeed my intention solely is to get rid of `Vector`, so I am fine with keeping a low profile and being full backwards compatible. I assume SIS is seldomly used, so opening a can of warms is not worth it (I think). I am perfectly happy with your proposal, but for the sake of brevity I'd rather go with a shorter way of doing the pretty same:
```this(Collections.enumeration(Arrays.asList(s1, s2))```
Are we all fine with that? Otherwise I'd switch this PR back to Alan`s proposal.

-------------

PR: https://git.openjdk.org/jdk/pull/11249