On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixed missing BufferedInputStream
I think we should
On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixed missing BufferedInputStream
Please keep this PR open; I will
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixed missing BufferedInputStream
Please keep this PR open; I will
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixed missing BufferedInputStream
Please keep this PR open; I will
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixed missing BufferedInputStream
Please keep open
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixed missing BufferedInputStream
Good catches, I will lo
> Implementation of JDK-8279283
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
fixed missing BufferedInputStream
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6935/files
- new: https://git.openjdk.java.
> Implementation of JDK-8279283
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
removed unused code
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6935/files
- new: https://git.openjdk.java.net/jdk/pull/6
On Mon, 27 Dec 2021 09:30:25 GMT, Markus KARG wrote:
> Have you surveyed the existing tests to see if transferTo is invoked on a
> BIS? New tests may be needed.
I have provided a test for BIS.transferTo in
https://github.com/openjdk/jdk/pull/6935/c
> Implementation of JDK-8279283
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
test for BufferedInputStream.transferTo
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6935/files
- new: ht
On Mon, 27 Dec 2021 08:50:26 GMT, Alan Bateman wrote:
> BIS is not specified to be thread safe but the existing read/write operations
> are. If transferTo is overridden then this is an area that will require close
> attention.
In analogy to the other read/write operations I now have synchroniz
> Implementation of JDK-8279283
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
synchronized BufferedInputStream::transferTo
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6935/files
- new: ht
Implementation of JDK-8279283
-
Commit messages:
- BufferedInputStream::transferTo
Changes: https://git.openjdk.java.net/jdk/pull/6935/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8279283
Stats: 15 lin
On Thu, 12 Aug 2021 01:04:29 GMT, Brian Burkhalter wrote:
>> Markus KARG has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Draft: Eliminated duplicate code using lambda expressions
>> - Draft: Use blockin
On Mon, 6 Dec 2021 07:07:03 GMT, Markus KARG wrote:
>> Markus KARG has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Draft: Eliminated duplicate code using lambda expressions
>> - Draft: Use blockin
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Thu, 12 Aug 2021 01:10:15 GMT, Brian Burkhalter wrote:
>> Markus KARG has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Draft: Eliminated duplicate code using lambda expressions
>> - Draft: Use blockin
On Sun, 15 Aug 2021 13:37:23 GMT, Markus KARG
wrote:
> I think the best course of action is to reduce the scope of this PR to the
> file channel cases. There is no reason why future PRs can't build on this and
> add implementations for other channel types.
I have split up t
On Fri, 13 Aug 2021 12:54:55 GMT, Alan Bateman wrote:
> > Does it make **any** real sense to answer your recent questions, provide
> > the proofs, tests and benchmark results (I actually would love to _if_ it
> > makes sense) _or_ will the outcome be that I _must_ drop everything besides
> > f
On Thu, 12 Aug 2021 08:40:34 GMT, Alan Bateman wrote:
>> Markus KARG has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Draft: Eliminated duplicate code using lambda expressions
>> - Draft: Use blockin
On Wed, 11 Aug 2021 11:27:53 GMT, Alan Bateman wrote:
> I've looked through the latest revision. Is there any way that we could drop
> most of the changes to ChannelInputStream and focus on one or two specific
> cases? I'm asking because there are several issues, inconsistencies, and it
> is t
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Sun, 1 Aug 2021 08:24:13 GMT, Markus KARG
wrote:
>>> The modified code found in
>>> [4b501b2](https://github.com/openjdk/jdk/commit/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20)
>>> should be safe from infinite loops, as it checks the actual file length in
>&
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG has
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
On Sat, 31 Jul 2021 17:33:50 GMT, Alan Bateman wrote:
>>> Also can you can check that IllegalBlockingModeException is thrown for the
>>> case ch is a SelectableChannel configured non-blocking and the destination
>>> is a FileChannel?
>>
>> Done in
>> https://github.com/openjdk/jdk/pull/4263/c
On Sun, 1 Aug 2021 07:46:36 GMT, Markus KARG
wrote:
>>> I need to look at it closely but I suspect this introduces a potential
>>> overflow. Also if output stream is backed by a SocketChannel configured
>>> non-blocking then FC::transferTo may return 0 so I assum
On Sat, 31 Jul 2021 21:20:28 GMT, Markus KARG
wrote:
> I suspect the eventually patch will need have to make use of the blockingLock
> to prevent the underlying channels from being changed to non-blocking during
> the transfer.
The blocking lock now is used since
https://github.co
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
On Sat, 31 Jul 2021 17:33:50 GMT, Alan Bateman wrote:
> I need to look at it closely but I suspect this introduces a potential
> overflow. Also if output stream is backed by a SocketChannel configured
> non-blocking then FC::transferTo may return 0 so I assume there is a
> potential infinite l
On Sat, 31 Jul 2021 14:39:02 GMT, Markus KARG
wrote:
>>> Just on naming, the existing channel implementations use "dst" for the
>>> destination and "wbc" (not "oc") for writable byte channels. Just
>>> mentioning it so that the new
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
On Sat, 31 Jul 2021 13:12:54 GMT, Markus KARG
wrote:
>> Is this loop correct for the case that the channel gets truncated? In that
>> case transferTo will return 0 as no bytes will be transferred and I'm
>> concerned this code will go into an infinite loop.
>>
&
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG has
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
On Fri, 30 Jul 2021 12:09:30 GMT, Alan Bateman wrote:
> Just on naming, the existing channel implementations use "dst" for the
> destination and "wbc" (not "oc") for writable byte channels. Just mentioning
> it so that the new code can be kept consistent where possible.
I have renamed `dest` t
On Thu, 29 Jul 2021 16:42:35 GMT, Brian Burkhalter wrote:
>> The JavaDocs in `InputStream::transferTo` *cleary* tell the caller that
>> there is **no** guarantee of *any* specific behavior in that particular
>> case:
>>>The behavior for the case where the input and/or output stream is
>>>asyn
On Mon, 26 Jul 2021 23:59:05 GMT, Brian Burkhalter 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.
>
> src/jav
On Tue, 27 Jul 2021 00:57:02 GMT, Brian Burkhalter 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.
>
> src/jav
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG has
On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Wed, 14 Jul 2021 18:35:15 GMT, Brian Burkhalter wrote:
> Have you looked into other tests which have implemented Providers?
I have not found any test code containing the word `new FileChannel() {...}` or
`extends FileChannel`, so I apparently there exists no mock of `FileChannel`.
Unfortuna
On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
On Thu, 1 Jul 2021 21:59:33 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final re
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
y to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of
> `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual
> review?
Markus KARG ha
On Sun, 30 May 2021 17:30:56 GMT, Markus KARG
wrote:
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
&
On Thu, 17 Jun 2021 20:08:08 GMT, Michael Bien
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final review.
>>
>> As proposed
On Tue, 8 Jun 2021 19:26:14 GMT, Brian Burkhalter wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final review.
>>
>> As propos
On Tue, 8 Jun 2021 20:34:15 GMT, Brian Burkhalter wrote:
>> I'd like to abstain from changes in ChannelOutputStream, as I did not write
>> that code at all. It is simply moved from being an inner class. Please let's
>> concentrate on the code I actually wrote in this PR. Thanks.
>
> That's fine
On Thu, 3 Jun 2021 17:29:14 GMT, Markus KARG
wrote:
>> src/java.base/share/classes/java/nio/channels/Channels.java line 145:
>>
>>> 143: * @since 18
>>> 144: */
>>> 145: public static class ChannelOutputStream extends OutputStream {
>&g
On Sat, 5 Jun 2021 07:25:44 GMT, Markus KARG
wrote:
>> You mean as a source comment or just here in this discussion thread?
>>
>> In fact it might be better to not add it to a package with is part of the
>> API, but to move it to the `sun` package, which i
On Wed, 2 Jun 2021 09:03:03 GMT, Alan Bateman wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final review.
>>
>> As proposed i
On Tue, 8 Jun 2021 11:49:55 GMT, Alan Bateman wrote:
>> @AlanBateman I'm done with the changes you requested and kindly like to ask
>> where to go from here.
>
>> @AlanBateman I'm done with the changes you requested and kindly like to ask
>> where to go from here.
>
> Moving ChannelOutputStrea
This PR-*draft* is **work in progress** and an invitation to discuss a possible
solution for issue
[JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
yet* intended for a final review.
As proposed in JDK-8265891, this PR provides an implementation for
`Channels.newInput
On Sun, 30 May 2021 17:30:56 GMT, Markus KARG
wrote:
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
&
ust really want to know how to move
on with this issue.
Thanks
Markus KARG
Head Crashing Informatics
http://www.headcrashing.eu
http://www.java.net/blogs/mkarg
67 matches
Mail list logo
