On Mon, 21 Nov 2022 18:22:26 GMT, Jens Lidestrom <d...@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

Reply via email to