This reminds me of the situation in the late 90s when Swing was added to the JDK (version 1.2 in 1998), Internet Explorer became the dominant browser that only supported Java 1.1 and suddenly users had to install a rather large browser plugin to run applets. I think it is safe to say that this killed Java in the browser and almost killed Java as a language before it had a strong comeback on the server side. A particular problem was the large size of the plugin (remember that the internet was slow back then and many people were still on dial up). But given the dependencies between the toolkits, even if you were using only AWT you had to download (the much larger) swing as well!

9637 if (Component.isInstanceOf(this, 
            "javax.swing.JComponent")) {
9638  if (((javax.swing.JComponent) this).
                             isOpaque()) {
9639   states.add(AccessibleState.OPAQUE);
9640  }
9641 }

Reference to javax.swing.JComponent in java.awt.Component (click here to explore the dependency graph)

A common point made here is that there might be another reason, not known to the outsider, for having this dependency here. Or, in other terms, that a behaviour-preserving refactoring that breaks this dependency is just not possible. But this is definitely not the case here: in the alternative Apache Harmony implementation of the JDK, this dependency is missing.

Detecting Dependency-Related Problems

There are a number of tools that can extract, display and analyse the dependency graph. There are two approaches to detect critical dependencies: metrics and patterns.

Metrics associate artifacts and their relationships with numerical values expressing quality. The classical example is distance from the main sequence (D) - a metric for packages. It states that abstract packages should have relatively many incoming dependencies (high responsibility), while concrete (implementation) packages should have relatively few incoming dependencies but will depend on other packages (high instability and low responsibility). The classic tool to detect the D metric is JDepend. JDepend computes several package dependency metrics, and can be easily embedded into IDEs and build scripts. It also supports the detection of circular dependencies between packages.