Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question

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

share|improve this answer
    
+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 17 hours ago
    
@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 17 hours ago
    
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 16 hours ago
    
@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 14 hours ago

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:

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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