Javaコレクション（java.util）のパッケージ構造-Iterableがjava.langにあるのはなぜですか？

以下の図のように、interfaceを除いてIterable、残りのすべての構成要素（interface / class / abstract class）は同じパッケージにありますjava.util

ここに画像の説明を入力してください

パッケージにIterable座っているのはなぜjava.langですか？

注：意図は、Javaプログラミングのパッケージングの側面を理解することです。

— 過剰交換
ソース

なぜこれがjava8とタグ付けされているのか、ここで尋ねられたすべてのAPIはずっと古いのだろうか。IterableはJavaバージョン1.5、1.2のコレクションフレームワークで導入されました

— gnat

回答:

javadocで説明されているように、目的は特定の言語構文Iterableをサポートすることです。

このインターフェイスを実装すると、オブジェクトを「foreach」ステートメントのターゲットにすることができます

そのため、langパッケージに属します。

Javaプログラミング言語の設計の基礎となるクラスを提供します。

図のその他のクラスはJCFに属しているため、utilパッケージにあります。

コレクションフレームワークが含まれています...

— ぶよ
ソース

+1。しかし、Iterator理想的にはjava.lang、にもあるべきだと思いますIterable。もちろん、java.util下位互換性の理由である必要があります（「foreach」構文が適切な言語での役割を与えるずっと前にJDKで導入されていました）。

— ruakh

@ruakhイテレータは便利ですが、おそらく「基本的な」パッケージに進むにはあまりにも具体的すぎると考えられていました（メソッドの選択と命名）。その前身と考えて列挙 LANGパッケージには行かなかったということは賢明だった、当初考えていたとして、最終的には便利なようではない判明、

— GNAT

私のポイントは、それが便利だということではありませんでしたが、適切な言語は今ではそれに依存しているということです。（Iterableon の依存関係は別としてIterator 、java.langパッケージは一般的にjava.util。のクラスに依存しません。）

— ruakh

@ruakhなるほど。それは非常に良い点です、ありがとう。APIの設計者が公開する反復処理可能を望んでいた理由を私は理解することができ、「オブジェクトをその実行する反復」しかし、彼らは、これはエレガントな感じがしないんことを選択した道

— ブヨ

多くの要素がIterableインターフェイスを実装するか、サブインターフェイスとして拡張するためです。

実装クラスは次のとおりです。

java.util
- AbstractCollection
- AbstractList
- AbstractQueue
- AbstractSequentialList
- AbstractSet
- ...
- 同時
  - ArrayBlockingQueue
  - ConcurrentLinkedDeque
  - ...
java.beancontext
- BeanContextServicesSupport
- BeanContextSupport
- ...
java.sql
- BatchUpdateException
- DataTruncation
- ...
javax.management
- AttributeList
javax.print.attribute.standard
- JobStateReasons
- ...
...

これは膨大なリストです。そして、あらゆる種類のパッケージに触れます。

さらに、循環パッケージの依存関係を最小限に抑える必要があります。パッケージAのクラスがパッケージAのクラスに依存するパッケージBのクラスに依存する場合、循環依存関係があります。それらが存在することは必ずしも悪いわけではありませんが、他の循環依存関係につながり、それは悪いことです。それ自体は悪くはありませんが、2つのクラスまたはパッケージ間の結合が強すぎることを示すデザインの匂いです。技術的な負債の蓄積の始まりです。

これに対する解決策は、「はい、Iterableインターフェースは、javaおよびjavax構造全体のさまざまなクラスおよびパッケージに依存しているものです。言語ライブラリの最もベースにあるべきです-java .lang。」

そして、それはあなたがそれを見つける場所です。