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

[Markus KARG]

On Mon, 21 Nov 2022 18:22:26 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> I think the public visibility of my Twitter account is not wide enough to get *really robust* answers, unfortunately. So far, 92% answered that they not even used SIS in their whole life. So the users of two-args constructor must be really neglectable. Nevertheless, they are definitively not zero, so all we could do is marking it deprecated some day.
>> 
>> Anyways, thanks for the review. At least we get rid of `Vector` here. Would be happy if you mark the PR as reviewed. :-)
>
>> I think the public visibility of my Twitter account is not wide enough to get really robust answers, unfortunately.
> 
> One alternative is to search GitHub. It's amazing how fast they can search such a huge code corpus.
> 
> Example: https://github.com/search?l=&q=%22new+SequenceInputStream%22+-filename%3ASequenceInputStreamTest.java&type=code
> 
> One problem with GitHub search is that often you get a lot of duplicate matches. In the example above I have filtered out `SequenceInputStreamTest.java` which showed up a lot.

Twitter survey results after one week: 5.4% of all voters have actually used SIS before! This number is big enough to consider SIS as "not irrelevant". OTOH this number is so small that any further poll whether this 5.4% actually used the one-arg or two-arg constructor would not provide stable results. Looking at the results of @jensli's GitHub search tells us that apparently *all* of those findings are using 2-args. So we actually need to be careful, not to break (up to) 5.4% of all existing applications.

So what could be our plan to improve the live of that 5.4%? Some thoughts:
1. We could safely add a `public InputStream concat(InputStream)` *default method* to `InputStream` as a factory for *anonymous* sequences. This allows any IS implementation to provide an optimized variant if needed/wanted, falling back to the existing SIS *by default* as a starting point (until we come up with a better fallback implementation).
2. Having done that, we could deprecate-for-removal SIS with the clear note that from now on `concat` should be used instead. This triggers people to overhaul their existing code little by little, while we gain time to work on a replacement for SIS.
3. We then could provide a **non-public** `ConcatenatedInputStream` which holds **exactly two** IS (`first` and `last` MUST be given), and make that one the default implementation of `concat`, gaining a modern, easy-to-maintain, fully tested, high-performance, sequence of streams.
4. Some fine day we do remove SIS, effectively getting rid of the discussed quirky behavior.

@AlanBateman How does that sound? Shall I go on with a PR for step 1.?

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

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