On 9 March 2012 19:14, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> Your proposal is functionally complete more or less so it does not look
> unacceptable to me, although I strongly prefer the one from Rajiv. I
> thought, from the feedback that was posted until now, that everyone was
> fine with Rajiv's drafts, but apparently it is not the case anymore. So
> let's see more feedback.
Glad I finally explained myself well enough.
Having put that out there, for me as a developer, I probably actually
agree with you. I'm very used to async IO that does read/write
available call backs and I believe it is probably the more flexible of
the two approached. I'm just very concerned that it is a lot harder
to use and that I might not be the typical developer that this is
intended for. NIO had this style of async and have moved away from it
to the NIO.2 style, and the JDK developers will have had far more
exposure to the average IO developer than we have.
On 10 March 2012 06:43, Rajiv Mordani <rajiv.mordani_at_oracle.com> wrote:
> Agreed. Let me follow up with Alan Bateman from the JDK team who did the
> NIO2 APIs and get back to the EG as well.
excellent idea and will help us to decide between usability vs flexibility.
Some more minor feed back below:
On 10 March 2012 06:33, Rajiv Mordani <rajiv.mordani_at_oracle.com> wrote:
> Why would you want to tie this to startAsync? Is it really required to have
> an AsyncContext to do async IO?
True - that's a bad idea. I was just thinking of one use-case and
there are others.
So ignore the asynccontext part and just consider the style of the signature.
> But it comes at a cost of having all the ByteBuffers till the write has
> completed.
It certainly is the nature of the NIO.2 style to have a lot more
ByteBuffers, many of them temporary and discarded. I think that is
the cost of the ease of use, but also with good design you can
minimise the buffer usage. I've also found that this style can mean
that the allocation of buffers is done closer to the code that knows
how much buffering is needed or desirable, so you can often avoid
having large partially used buffers or infrastructure mindlessly
buffering, so there are some wins as well.
On 10 March 2012 06:43, Rajiv Mordani <rajiv.mordani_at_oracle.com> wrote:
> The other issue with the API that you are suggesting is that the app now has
> to encode everything into a ByteBuffer for writes and decode everything from the ByteBuffer for reads and cannot
> use the Reader and Writer for doing async IO.
I understand the desire to use readers/writers for async IO, but I do
not believe that any code that is written now against the
reader/writer APIs can be safely used against async versions of those.
This is because that code is written assuming blocking semantics.
For example, you will often see Readers wrapped as BufferedReaders, so
that the readLine() API can be used. This would fail horribly if the
underlying reader was async. It may be a feature not a bug that
async IO mechanism cannot be fed to existing IO code.
cheers