As per the below diagram, except for interface Iterable, all the remaining constructs (interface / class / abstract class) sit in same package java.util
enter image description here
Why does Iterable sit in java.langpackage?
Note: The intention is to understand the packaging aspect of java programming.
-
wonder why this is tagged java8, all APIs asked about here are much older. Iterable was introduced in Java version 1.5, collections framework in 1.2gnat– gnat2015年06月29日 20:47:54 +00:00Commented Jun 29, 2015 at 20:47
2 Answers 2
As explained in its javadoc, the purpose of Iterable is to support particular language syntax:
Implementing this interface allows an object to be the target of the "foreach" statement
As such, it belongs to the lang package, which
Provides classes that are fundamental to the design of the Java programming language.
Other classes at the diagram belong to JCF and hence, are in the util package which
Contains the collections framework...
-
+1. I think, though, that
Iteratorshould ideally also be injava.lang, sinceIterableis. Of course, it has to be injava.utilfor backward-compatibility reasons (it had been introduced in the JDK long before the "foreach" construct gave it a role in the language proper).ruakh– ruakh2015年06月20日 09:34:05 +00:00Commented Jun 20, 2015 at 9:34 -
@ruakh Iterator is convenient, but was probably considered too specific (method selection and naming) to go to "fundamental" package. Think of its predecessor Enumeration, which eventually turned out not as convenient as originally thought, it was prudent that it didn't go to lang packagegnat– gnat2015年06月20日 09:48:36 +00:00Commented Jun 20, 2015 at 9:48
-
My point was not that it's convenient, but that the language proper now depends on it. (Note that, aside from the dependency of
IterableonIterator, thejava.langpackage does not generally depend on classes injava.util.)ruakh– ruakh2015年06月20日 10:31:49 +00:00Commented Jun 20, 2015 at 10:31 -
@ruakh I see. That's a very good point, thanks. I can understand why API designers wanted Iterable to expose "an object that performs iteration" but the way they have chosen to do this doesn't feel elegantgnat– gnat2015年06月20日 12:38:27 +00:00Commented Jun 20, 2015 at 12:38
Because a lot of things implement the interface Iterable or extend it as a sub interface.
The implementing classes are:
- java.util
- AbstractCollection
- AbstractList
- AbstractQueue
- AbstractSequentialList
- AbstractSet
- ...
- concurrent
- ArrayBlockingQueue
- ConcurrentLinkedDeque
- ...
- java.beancontext
- BeanContextServicesSupport
- BeanContextSupport
- ...
- java.sql
- BatchUpdateException
- DataTruncation
- ...
- javax.management
- AttributeList
- javax.print.attribute.standard
- JobStateReasons
- ...
- ...
This is a huge list. And it touches on all sorts of packages out there.
Furthermore, you want to minimize circular package dependencies. If a class in package A depends on a class in package B which depends on a class in package A, you've got a circular dependency. They're not always bad that they exist - but they lead to other circular dependencies and that can be a bad thing. Its not bad by itself, but it is a design smell that indicates that the coupling between two classes or packages is too tight. It is the start of technical debt accumulating.
The solution to this is to say "yes, the Iterable interface is something that is depended on in a wide variety of classes and packages throughout the entirety of the java and javax structure. It should be in the most base of the language libraries - java.lang."
And that is where you will find it.
Related reading: