12

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.

Improve this question
1
  • 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.2
    – gnat
    Commented Jun 29, 2015 at 20:47

2 Answers 2

Reset to default
22

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...

Improve this answer
4
  • +1. I think, though, that Iterator should ideally also be in java.lang, since Iterable is. Of course, it has to be in java.util for backward-compatibility reasons (it had been introduced in the JDK long before the "foreach" construct gave it a role in the language proper).
    – ruakh
    Commented 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 package
    – gnat
    Commented 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 Iterable on Iterator , the java.lang package does not generally depend on classes in java.util.)
    – ruakh
    Commented 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 elegant
    – gnat
    Commented Jun 20, 2015 at 12:38
6

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:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.