Согласно Javadocs :
"A Spliterator, который не сообщает IMMUTABLE или CONCURRENT, как ожидается, будет иметь документированную политику, касающуюся: когда Spliterator связывается с источником элемента и обнаружения структурных помех источника элемента, обнаруженных после поздняя привязка Spliterator привязывается к источнику элементов в точке первого обхода, первого разбиения или первого запроса для предполагаемого размера, а не во время создания Spliterator. A Spliterator, то есть не позднее связывание привязывает к источнику элементов в точке конструирования или первого вызова любого метода. Изменения, внесенные в источник до привязки, отражаются при прохождении Spliterator. После связывания Spliterator должен на основа наилучшего усилия, бросить ConcurrentModificationException, если обнаружены структурные помехи. ... "
Так что, если вы тщательно проанализируете, с поздним связыванием против без позднего связывания действительно подходит для обнаружения структурных помех.
A Spliterator, обертывающий произвольный итератор, не может гарантировать обнаружение структурных помех. Это зависит от того, как реализовано Iterator. И даже для Iterators, которые обнаруживают (или смягчают) структурные помехи, Spliterator не может дать никаких гарантий относительно того, когда обнаружение начнется; то есть когда происходит «связывание».
Короче говоря, он не может гарантировать истинную позднюю привязку семантику.
Если я обеспечу позднюю привязку iterator(), результирующее Spliterator также должно быть, нет?
Javadocs не гарантирует этого.
На практике: вероятно, так и должно быть, хотя это зависит от реализации Spliterators. Но такое заявление в javadocs может ограничить реализацию будущих версий класса Spliterators и его вложенных классов опасными способами.
Вы можете не согласиться с моим анализом. Однако авторы javadocs четко и сознательно заявили, что эти Spliterators не являются поздними связанными. Если вы считаете, что они не правы, подайте отчет об ошибке против javadocs.