Why can't Java IO implement async reading?

Question

In Java IO, we use Stream and Reader while in NIO we use Channel, Selector.

They both do the same thing, but the structure is totally different.

So why they don't write a new Stream like "AsyncStream" or a Reader like "AsyncReader" to implement what NIO have implemented. If so, we only have one structure and it's beautiful.

So why Java IO cannot implement async reading? What are the difficulties to implement async reading using Java IO ?

Or what is the advantage of writing a new framework instead of using the existing one?

Answer 1

I tried to understand your idea in the comment above, but I'm afraid that there is insufficient detail to understand it as a proposal. Without that, it is impossible to make a judgment on whether it would work or not.

However, there are a couple of points that can be made in response:

• IF Java was a shiny new (and unreleased) language, THEN they could improve on the I/O API design in a few areas.
• In addition, IF someone came up with a well-considered, fleshed out API design that combined sync and async capabilities, THEN that could be considered.

But Java is NOT a shiny new language. It is an old programming language, with billions of lines of source code written in it. The kind of change that you are contemplating on a central API would either create huge binary compatibility problems for Oracle's paying customers, or it would lead to a huge legacy code problem. It simply would not happen.

Setting that aside, if you attempted to merge sync and async capabilities into a single API, you risk creating a situation where:

• custom stream types need to implement a lot of extra functionality, and / or
• the merger leads to unanticipated performance issues.

Now these concerns may not be warranted.

However, we cannot tell without seeing a concrete API design proposal and an implementation to try out for usability and performance. Bear in mind that the original elegant API design for I/O streams and (then) readers / writers actually turned out to have a variety of problems. These did not become apparent until people used the APIs in production code. For example:

• character encoding concerns lead to the introduction of Reader / Writer in Java 1.1.
• performance analyse identified that memory memory-to-memory copying was a problem, leading to the introduction of Buffer and so on.

In summary, it is really hard to design a good I/O API ... and Java is unlikely to change anyway.