About Diagrams
    Diagram Description
Java 7
Java 8
Java 10
JavaFX 8
JavaFX 10

Panel Types

TypeContainer There are 6 types of panels for
  1. Interfaces,
  2. Classes,
  3. Annotations,
  4. Enums,
  5. Exceptions and
  6. Packages.
They are easily distinguished from each other by color.

LongName The header of a type contains an icon, which distinguishes the package, the package name and the simple type name. If a corresponding package panel is present, the package name is normally omitted. Inner types always contain the name of the container type.

There are 5 main ways a type can be represented:
  1. Complete display of all members,
  2. Only method names,
  3. Summary,
  4. Header-only and
  5. Text-only.

The first case is the normal way to describe a type. For every type there should be at least one diagram with a complete display of all members of the type. The other forms have a link in the JavaDoc comment to the diagram with the complete display.

The header-only form is often used in hierarchy diagrams. The text-only form is typically used in situations were the type is only referenced from a subtype. The referenced type is then immediately placed above the subtype and the inheritance lines are missing. For example the Externalizable interface could show that it extends the Serializable interface in the following way:

reference from subtype
The text-only form may contain an icon and package name when necessary.

Sometimes interfaces are marker interfaces and don't contain members. Their complete-form would therefore be indistinguishable from their header-only form. A user would not be able to know that there is no additional information available when only the header is visible. To help in this situation interfaces with members are visualized differently than empty interfaces. The header of an empty interface has only a border but no background color.
Interface with member and without member
Classes almost always have at least an accessible constructor. However, when this is not the case or when the source code is not available, the class is visualized in the same way.

The distinction between interfaces with members and empty interfaces is also made for the text-only form. The text-only form of an interfaces with members is underlined to show that there is more information available.

Interface with member and without member
This distinction is NOT made for classes, because in the majority of cases classes are not empty. Underlining would therefore add little value and only contribute a perceptional cost.

Type Panel Content

Class panel content The complete panel is divided in 6 sections.
  • Header,
  • Constructors,
  • Methods,
  • Fields including constants,
  • Inner types and
  • Information about hidden methods and fields.
The method section is further divided in
  • Static methods,
  • Accessor methods (getter and setter methods combined in one row),
  • Collector methods (add and remove methods combined in one row),
  • JavaFX property methods (getter, setter and property methods combined in one row),
  • Event methods,
  • Object Methods (methods overriding java.lang.Object) and
  • Other public, protected, package or private methods.

The classification is carried out using the name of the method. Within a category, the methods are listed alphabetically.

Effective information aggregation is achieved by combining getter with setter methods in a row. The two methods

   public String getName ()
   public void setName (String name) 
are summarized into the row
   public String get / setName ()
Note that the reified return type and the first or last argument of the setter, the other arguments, the access level and the thrown exceptions need to match for this to be realized. Similar aggregations are made for the combination of "add" and "remove" methods and the JavaFX property methods with their corresponding getter and setter methods.

Members are shown in the way they appear in Java code, which means that the type precedes the member name. This is contrary to normal UML but avoids the mental effort to switch between the diagram and the code representation.

Method names are in red except when they are overriding or deprecated. Overriding method names are black, deprecated elements are gray and striked through. The name of abstract types and methods are italic, the name of static member are bold. Primitive types are green, reference types are blue, constant fields are bold and green. The presence of exceptions is visualized with a red thunderbolt symbol. A blue thunderbolt symbol is used when the exceptions are all unchecked. All other elements like brackets and the name of arguments are black. Long argument list are always completely shown and continued on the next row if needed.

Deprecated Member and methods which override methods in a supertype are normally hidden to reduce clutter. In this case a row with information about the missing elements is displayed. Clicking this row displays a list of hidden elements. The JavaDoc comment of a hidden element is revealed by a consecutive click.

Hidden Elements
Click to view an animation of progressive disclosure in action.

Modifiers are visualized according to the following table:

private modifier private accessible Element,
package modifier package accessible Element,
protected modifier protected accessible Element,
final modifier final Element,
(bold) static element,
(italic) abstract element,
deprecated deprecated element,
new element marker new introduced Element,
removed element marker removed Element,
deprecation added marker newly deprecated and
deprecation removed marker deprecation removed.

The access modifiers are visualized with an icon at the start of a row. Please note that public access is the standard case for diagrams and is visualized without an icon. This reduces visual complexity and enhances contrast.

A red exclamation mark shows that a element is new in this version of the library. Analogous information is shown if an element was removed or the deprecation status changed.

Library users are only interested in public or protected accessible elements. Therefore all elements with package or private access are removed from the diagrams on this site. The only exceptions are types wich contain public or protected members and are supertypes of other public types.

JavaDoc Comments

The diagrams are interactive. That means that the JavaDoc comment will be shown in a pop-up, when the mouse hovers over a type header or a member. Clicking makes the pop-up permanent. Links in the comment will open the associated diagram if possible. The links have a green color in this case. External links are blue.

Pop-up windows for type headers are special. They do not only contain the JavaDoc comment but also list all appearences where the type is used. The links are organized in the following categories:

  • Methods that return this type,
  • Constructors that require an argument of this type,
  • Methods that require an argument of this type,
  • Fields which have this type,
  • Type parameters which have a bound of this type,
  • Executables which throw this type if this type is an Exception, and
  • All diagrams on this site where this type is present.
The qualified name of the using type and the name of the first member of the type usage is listed. If there is more than one match, the multiplicity will be shown with a counter. Links open the defining diagram of the using type, except when the using type is already on the current page. Diagram links in the last tab are color coded. Bold links are for the default diagram for this type. Diagrams with gray links only contain a header-only type panel.

JavaDoc comment appearence

JavaDoc comment appearence

Click to view an animation of the different tab contents.

The place where a type is used has a somewhat opposite capability. When the type name is clicked, a pop-up with the complete panel of the used type pops up. The pop-up panel is fully interactive and allows browsing of all doc comments.

Type Reveal
Click to view an animation.

Suppressing Superfluous Information

Some informations have been purposeful left out. For example java types must always extend java.lang.Object. Someone fluent in Java would not gain any useful information if the diagrams would map this fact. Information of this inheritance relationship is therefore suppressed. Inheritance information is also suppressed when a subtype explicitly extends a type which is already extended by a supertype. In the same regard are the static values and valueof methods of Enum types typically omitted. Note that the overriding of the equals, hashCode, clone, and toString methods in java.lang.Object are normally shown, because there presence in subtypes typically change the semantics of these methods.

Inheritance Relationship

Inheritance relationships are represented by positioning and lines that connect the supertype with the subtype. The supertype is always to the left or above the subtype. Accordingly, the lines always begin at the at the right or bottom of the supertype and end at the left or top of the subtype. The super class - subclass relationship is visualized with thick dark-blue orthogonal lines. The inheritance relationships, where interfaces are involved, are visualized with thin light-blue straight lines.

The importance of good layout is demonstrated with one of the most confusing inheritance relationships one can find in the JDK. The following diagram maps the BooleanProperty types in the javafx.beans packages. By keeping the inheritance lines as short as possible it is clear which subtype inherits from which supertype. Please note that the inheritance of ReadOnlyJavaBeanProperty from ReadOnlyJavaBeanBooleanProperty is shown with a text-only panel above the type instead of a direct inheritance line. This shortcut avoids a line through half of the diagram.

The diagram is also available with complete type panels.


There are a lot more ideas which are not yet implemented. I hope I get the support to continue this work.

About Diagrams
Detailed Diagram Description
Frequently Asked Questions