On Sun, 27 Nov 2022 17:49:25 GMT, Markus KARG wrote:
>>> 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.
>>
>>
On Mon, 21 Nov 2022 18:22:26 GMT, Jens Lidestrom 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
>>
On Mon, 21 Nov 2022 17:43:23 GMT, Markus KARG wrote:
>> There is no need to use a temporary Vector within the constructor of
>> SynchronizedInputStream, as more efficient (non-synchronized) alternative
>> code (like List.of) will do the same in possibly less time. While the
>> optimization is
On Mon, 21 Nov 2022 17:43:58 GMT, Markus KARG wrote:
> 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:
On Mon, 21 Nov 2022 07:42:35 GMT, Alan Bateman wrote:
>> N.B.: Regarding usage numbers, I will do a quick poll on Twitter.
>
>> 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
On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote:
>> Markus KARG has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains one
>> new
On Mon, 21 Nov 2022 07:48:01 GMT, Markus KARG wrote:
> While we are at it, would you be willing to change the member variables `e`
> to `private final` and the `in` to `private`? From what I can see, I don't
> see any other class accessing these package private fields.
Fixed in 8d29831 :-)
On Mon, 21 Nov 2022 17:39:24 GMT, Markus KARG wrote:
>> There is no need to use a temporary Vector within the constructor of
>> SynchronizedInputStream, as more efficient (non-synchronized) alternative
>> code (like List.of) will do the same in possibly less time. While the
>> optimization is
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not dramatic, it still makes sense to replace Vector
On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote:
> While we are at it, would you be willing to change the member variables `e`
> to `private final` and the `in` to `private`? From what I can see, I don't
> see any other class accessing these package private fields.
Good catch, will do
On Sun, 20 Nov 2022 16:58:56 GMT, Markus KARG wrote:
>> 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
>>
On Sun, 20 Nov 2022 17:41:28 GMT, Markus KARG wrote:
>> There is no need to use a temporary Vector within the constructor of
>> SynchronizedInputStream, as more efficient (non-synchronized) alternative
>> code (like List.of) will do the same in possibly less time. While the
>> optimization is
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not dramatic, it still makes sense to replace Vector
On Sun, 20 Nov 2022 16:49:16 GMT, Markus KARG wrote:
>>> @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
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not dramatic, it still makes sense to replace Vector
On Sun, 20 Nov 2022 13:06:40 GMT, Markus KARG wrote:
> @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
On Sun, 20 Nov 2022 12:06:55 GMT, Markus KARG wrote:
>> The updated code now changes the behaviour in the other direction:
>>
>> In the original code, if `s2` was null a NPE was thrown in `peekNextStream`
>> when `s1` was exhausted.
>>
>> In the current code, `s2` is silently ignored if it is
On Sun, 20 Nov 2022 09:47:35 GMT, Jens Lidestrom wrote:
>> src/java.base/share/classes/java/io/SequenceInputStream.java line 82:
>>
>>> 80: * @param s2 the second input stream to read.
>>> 81: */
>>> 82: public SequenceInputStream(InputStream s1, InputStream s2) {
>>
>> BTW,
On Sun, 20 Nov 2022 09:14:32 GMT, Markus KARG wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> allowing s2 to be null
>
> src/java.base/share/classes/java/io/SequenceInputStream.java line 82:
>
>> 80: * @param
On Sun, 20 Nov 2022 09:07:21 GMT, Markus KARG wrote:
>> There is no need to use a temporary Vector within the constructor of
>> SynchronizedInputStream, as more efficient (non-synchronized) alternative
>> code (like List.of) will do the same in possibly less time. While the
>> optimization is
On Sun, 20 Nov 2022 02:16:02 GMT, Jaikiran Pai wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> allowing s2 to be null
>
> src/java.base/share/classes/java/io/SequenceInputStream.java line 83:
>
>> 81: */
>>
On Sun, 20 Nov 2022 07:56:59 GMT, Alan Bateman wrote:
> Jai is correct, this constructor appears to have tolerated null in the second
> parameter since JDK 1.0 so we need to proceed with care.
I have fixe this in
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not dramatic, it still makes sense to replace Vector
On Sat, 19 Nov 2022 21:36:56 GMT, Markus KARG wrote:
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not
On Sat, 19 Nov 2022 21:36:56 GMT, Markus KARG wrote:
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not
There is no need to use a temporary Vector within the constructor of
SynchronizedInputStream, as more efficient (non-synchronized) alternative code
(like List.of) will do the same in possibly less time. While the optimization
is not dramatic, it still makes sense to replace Vector unless
26 matches
Mail list logo
