1. Interfaces,
2. Classes,
3. Annotations,
4. Enums,
5. Exceptions and
6. Packages.

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:

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.

• Header,
• Constructors,
• Methods,
• Fields including constants,
• Inner types and
• Information about hidden methods and fields.

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

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) 

   public String get / setName ()

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.

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.

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

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

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