> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov 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
On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race wrote:
>>> One or two of the sources changes should probably uses Files.copy, e.g.
>>> ZipPath, sjavac/CopyFile.java.
>>
>> Good idea! Replaced in few places. But not in ZipPath: it's actually
>> implementation of underlying call from Files.copy:
On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman wrote:
> I have to say that introducing a ThreadLocal here seems like a step in the
> wrong direction. With a ThreadLocal, if I read this correctly, a
> MessageDigest will be cached with each thread that ever calls this API, and
> it won't be
On Sun, 20 Dec 2020 20:45:55 GMT, Claes Redestad wrote:
>>> I have to say that introducing a ThreadLocal here seems like a step in the
>>> wrong direction. With a ThreadLocal, if I read this correctly, a
>>> MessageDigest will be cached with each thread that ever calls this API, and
>>> it
On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman wrote:
>> I have to say that introducing a ThreadLocal here seems like a step in the
>> wrong direction. With a ThreadLocal, if I read this correctly, a
>> MessageDigest will be cached with each thread that ever calls this API, and
>> it won't be
On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov
wrote:
>> jrtfs is compiled twice, the second is to --release 8 so it can be packaged
>> into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need
>> to be careful with the changes here as it will likely causing build
On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman wrote:
> One or two of the sources changes should probably uses Files.copy, e.g.
> ZipPath, sjavac/CopyFile.java.
Good idea! Replaced in few places. But not in ZipPath: it's actually
implementation of underlying call from Files.copy:
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
use Files.copy in
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
use Files.copy in MLet too
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
revert changes in ASM
use
On Fri, 18 Dec 2020 20:11:26 GMT, Stuart Marks wrote:
> I have to say that introducing a ThreadLocal here seems like a step in the
> wrong direction. With a ThreadLocal, if I read this correctly, a
> MessageDigest will be cached with each thread that ever calls this API, and
> it won't be
On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov
wrote:
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
jrtfs is compiled twice, the second is to --release 8 so it can be packaged
into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to
be
On 20.12.20 18:47, Rob Spoor wrote:
...
That "> 0" is incorrect here; it's allowed to return 0 before EOF
I don't think the method is allowed to return 0 before EOF. To quote
from the method Javadoc.
> This method blocks until input data is available, end of file is
detected, or an
According to the documentation of InputStream.readNBytes:
Reads up to a specified number of bytes from the input stream. This
method blocks until the requested number of bytes have been read, end
of stream is detected, or an exception is thrown. This method does not
close the input
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
revert changes in JrtPath.
8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
-
Commit messages:
- 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
- 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
Changes:
16 matches
Mail list logo
