Well put David, I couldn’t agree more .... I would even go this far and say this is not something I would include in the platform itself at all.
Bye Norman > Am 04.12.2017 um 19:41 schrieb David Lloyd <david.ll...@redhat.com>: > >> 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
