On 13 September 2011 18:03, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> - It doesn't actually help many people right now. The complexity in the
> application is (much) higher, so until frameworks do it automagically,
> it's not going to be used.
I think it would be appropriate to have a discussion about what are
our requirements for this API. Is ease of use a higher priority over
scalability and performance?
For example, the async IO features in java 7 are actually pretty easy
to use, but they don't scale all that well. They are based around a
Future pattern like:
Future<Integer> read(Buffer data)
This is simple to use, but suffers from the scalability issue that the
buffer has to be allocated at the time the read is scheduled rather
than when data actually arrives to be read.
My thoughts in this regards to this are:
+ if you want outright performance, then working behind a generic
portable API is always going to be a hindrance.
+ Those who want the last nano second are probably going to go
proprietary anyway.
+ Java 7 appears to have made the call of async usability over
outright scalability, so perhaps we should follow them?
I think there is scope to copy many of the async patterns in NIO.2
(such as futures) without actually needing to expose any specific
NIO.2 APIs. If we were to do that, then at least developers familiar
with NIO.2 will also be able to easily understand similar features in
the servlet API.
Of course - there is the contrary position - that perhaps we should
not bother with exposing async IO anymore. Instead continue to
provide higher level APIs (eg File upload in 3.0 and Websockets in
3.1) that individual containers can implement with async IO behind he
scenes
cheers