Почему Java IO не реализует чтение async?

В Java IO мы используем Stream и Reader, а в NIO мы используем Channel, Selector.

Они оба делают одно и то же, но структура совершенно другая.

Итак, почему они не пишут новый Stream, такой как "AsyncStream" или Reader, как "AsyncReader", чтобы реализовать то, что NIO реализовало. Если это так, у нас есть только одна структура, и она прекрасна.

Итак, почему Java IO не может реализовать чтение async? Каковы трудности для реализации асинхронного чтения с использованием Java IO?

Или в чем преимущество написания новой структуры вместо использования существующей?

Ответ 1

Я попытался понять вашу идею в комментарии выше, но я боюсь, что недостаточно деталей, чтобы понять это как предложение. Без этого невозможно судить о том, будет ли это работать или нет.

Однако есть несколько моментов, которые могут быть сделаны в ответ:

Если Java был блестящим новым (и неизданным) языком, ТОГДА они могли бы улучшить дизайн API ввода-вывода в нескольких областях.
Кроме того, если кто-то придумал хорошо продуманный, разработанный API-интерфейс, который объединил возможности синхронизации и асинхронности, ТОГДА, которые можно было бы рассмотреть.

Но Java не является блестящим новым языком. Это старый язык программирования, в котором записаны миллиарды строк исходного кода. Такие изменения, которые вы рассматриваете в центральном API, либо создавали бы огромные проблемы с бинарной совместимостью для клиентов Oracle, либо это привело бы к огромной проблеме устаревшего кода. Это просто не произойдет.

Если вы попытаетесь объединить возможности синхронизации и асинхронности в один API, вы рискуете создать ситуацию, когда:

пользовательские типы потоков должны реализовывать множество дополнительных функций и/или
слияние приводит к непредвиденным проблемам с производительностью.

Теперь эти проблемы могут быть неоправданными.

Однако мы не можем сказать, не видя конкретного предложения по дизайну API и реализации, чтобы опробовать удобство и производительность. Имейте в виду, что оригинальная элегантная конструкция API для потоков ввода-вывода и (тогда) читателей/писателей фактически оказывала множество проблем. Это не стало очевидным, пока люди не использовали API в производственном коде. Например:

проблемы с кодировкой символов приводят к введению Reader/Writer в Java 1.1.
Анализ производительности показал, что копирование памяти в память было проблемой, что привело к введению Buffer и т.д.

В целом, очень сложно создать хороший API ввода-вывода... и Java вряд ли изменится.