Hi David, I think you raise some valid concerns, particularly with the byte buffer pools.
That said, I'm interested in knowing whether your concerns extend to choice of using the JDK9 Flow API for handling asynchronous IO? Cheers, √ (Adding my colleague, James Roper, to the conversation) On Dec 4, 2017 19:42, "David Lloyd" <david.ll...@redhat.com> wrote: > On Mon, Dec 4, 2017 at 10:17 AM, <mark.reinh...@oracle.com> wrote: > > New JEP Candidate: http://openjdk.java.net/jeps/321 > > I have concerns. > > This will be the first public, NIO-based, asynchronous/non-blocking > network protocol API introduced into the JDK proper, _ever_. > > First, I want to note that the API seems to bear no resemblance > whatsoever with the asynchronous NIO.2 API. Now I'm no fan of that > API as it stands for a couple of reasons, but nevertheless it calls > into question either the validity of the HTTP API as it stands, or the > scope of reusability of the NIO.2 API. > > With that items put aside: there are a wide variety of mature, > non-blocking network protocol implementations out there, with > literally thousands of years of experience distributed amongst their > authors, maintainers, supporters, and communities, none of which were > used as a model. There was, as far as I can see, no kind of study of > existing non-blocking approaches in Java, and their strengths and > weaknesses; there was no round table of engineers with experience in > this field, talking about what works and what doesn't work. > > Some new, seemingly general-purpose, concepts are introduced by the > code base, for example: ByteBufferReference, and ByteBufferPool. Are > these strategies that should be promoted to NIO proper? If not, then > are they _really_ right for this particular use case, particularly if, > for some reason, a _second_ non-blocking network protocol API might be > introduced some day, probably duplicating these concepts? > > Making this thing be the first real platform NIO-based asynchronous > network protocol API, yet being completely removed from the previous > NIO.2 asynchronous APIs and any other existing stable, mature API, > should be done very carefully and deliberately, and perhaps most > importantly, incrementally: first, establish a non-blocking byte > stream API that makes sense generally, and bring that into NIO > (NIO.3?); then, perhaps, enhancements to byte buffers to better > support efficient pooling. By the time that point is reached, it is > hopefully rapidly becoming obvious that this is not something that > should be taken lightly. > > I believe that most third-party implementations are taken less lightly > than this seems to have been. I and my team have been developing an > asynchronous/non-blocking NIO library for ten years now, and while I'm > proud of our work and the discoveries we've made, I am realistic about > the fact that it's still pretty far from as good as it could be (not > in the least part due to existing platform limitations), certainly far > from something I'd say "hey let's standardize this as is". I think > that to standardize something of this type that was just written over > the past 18-odd months reflects, to put it kindly, some pretty > incredible confidence that I wish I shared. > > Speaking *solely* in the interests of platform quality and integrity, > I think that before _any_ high-level non-blocking/asynchronous > protocol API is ever introduced into the platform, it would be an > incredible waste to not have some kind of design consultation with > other industry experts. Now I'm not suggesting that a JDK API would > have to be _agreeable_ to every expert, as we all know that is > basically impossible; but at the very minimum, I am very confident > that we can tell you what _doesn't_ work and the pitfalls we've found > along the way, as well as what each of us would consider to be an > ideal API, and that is information that has incredible value. > > Talking about introducing the first-ever non-blocking protocol API > into the platform, at _this_ stage, seems premature and needlessly > risky. I would suggest that maybe it's best for the API to stick to > blocking I/O, at least for now. Or else, take it outside of the > platform, and let it mature in the wild where it can evolve without an > overbearing concern for compatibility for a decade or so (no, I'm not > kidding). As long as this thing lives in the JDK, but isn't > standardized, it's probably not going to be used heavily enough to > really feel out its weak points. And once it's in, its ability to > evolve is severely hampered by compatibility constraints. > > I feel like it is impossible to over-emphasize the difficulty of the > problem of non-blocking I/O when it comes to interactions with user > programs. Though the fruits of such an effort are probably small in > terms of API surface, the complexity is hard: hard enough that it is, > in my mind, a project of a larger scale, maybe JSR scale. And the > benefit is potentially large: large enough that it could change the > landscape of other specifications and network applications. Or at > least, I think so, which is why I've spent so many years of my life in > pursuit of such a thing. > > -- > - DML >
