OK. Will do.
On 21/10/2016 19:21, Pavel Rappo wrote:
Just to append to my previous email. BufferedReader wraps any Reader out there.
Not specifically FileReader. While you're talking about the case of effective
reading from a file.
I guess there's one existing possibility to provide exactly what you need (as I
understand it) under this method:
/**
* Opens a file for reading, returning a {@code BufferedReader} to read text
* from the file in an efficient manner...
...
*/
java.nio.file.Files#newBufferedReader(java.nio.file.Path)
It can return _anything_ as long as it is a BufferedReader. We can do it, but it
needs to be investigated not only for your favorite OS but for other OSes as
well. Feel free to prototype this and we can discuss it on the list later.
Thanks,
-Pavel
On 21 Oct 2016, at 18:56, Brunoais <brunoa...@gmail.com> wrote:
Pavel is right.
In reality, I was expecting such BufferedReader to use only a single buffer and
have that Buffer being filled asynchronously, not in a different Thread.
Additionally, I don't have the intention of having a larger buffer than before
unless stated through the API (the constructor).
In my idea, internally, it is supposed to use
java.nio.channels.AsynchronousFileChannel or equivalent.
It does not prevent having two buffers and I do not intent to change
BufferedReader itself. I'd do an BufferedAsyncReader of sorts (any name
suggestion is welcome as I'm an awful namer).
On 21/10/2016 18:38, Roger Riggs wrote:
Hi Pavel,
I think Brunoais asking for a double buffering scheme in which the
implementation of
BufferReader fills (a second buffer) in parallel with the application reading
from the 1st buffer
and managing the swaps and async reads transparently.
It would not change the API but would change the interactions between the
buffered reader
and the underlying stream. It would also increase memory requirements and
processing
by introducing or using a separate thread and the necessary synchronization.
Though I think the formal interface semantics could be maintained, I have doubts
about compatibility and its unintended consequences on existing subclasses,
applications and libraries.
$.02, Roger
On 10/21/16 1:22 PM, Pavel Rappo wrote:
Off the top of my head, I would say it's not possible to change the design of an
_extensible_ type that has been out there for 20 or so years. All these I/O
streams from java.io were designed for simple synchronous use case.
It's not that their design is flawed in some way, it's that they doesn't seem to
suit your needs. Have you considered using
java.nio.channels.AsynchronousFileChannel
in your applications?
-Pavel
On 21 Oct 2016, at 17:08, Brunoais <brunoa...@gmail.com> wrote:
Any feedback on this? I'm really interested in implementing such
BufferedReader/BufferedStreamReader to allow speeding up my applications
without having to think in an asynchronous way or multi-threading while
programming with it.
That's why I'm asking this here.
On 13/10/2016 14:45, Brunoais wrote:
Hi,
I looked at BufferedReader source code for java 9 long with the source code of
the channels/streams used. I noticed that, like in java 7, BufferedReader does
not use an Async API to load data from files, instead, the data loading is all
done synchronously even when the OS allows requesting a file to be read and
getting a warning later when the file is effectively read.
Why Is BufferedReader not async while providing a sync API?
