Home
About Diagrams
    Motivation
    Diagram Description
    FAQ
    Sitemap
Java 7
Java 8
Java 9
JavaFX 8
JavaFX 9
 
Guestbook
Contact
Legal

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.



PanelState
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 ()
and
   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 the image 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 stay. Links in the JavaDoc comment are green when they link to other diagrams of this site. 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 an bound of this type,
  • Executables which throw this type if this type is an Exception, and
  • Diagrams on this site where this type also occurs.
The qualified name of the originator 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. The links open a new window with the defining diagram of the originator type. If there is no diagram or the originator type is already on the current page, only the plain text is present. 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 the images to view an animation of the different tab contents.

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 everywhere. The static values and valueof method of Enum types are analogical omitted. Note that 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. In the same regard is inheritance information suppressed, if a subtype inherits types which a supertype is already showing.

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.

BooleanProperty-Hierarchy
The diagram is also available with complete type panels.

Outlook

There are a lot of ideas which are not yet implemented. For example when a type name is clicked, a pop-up with the complete-form of this type should be shown. The search functionality needs to be improved and the code to make these diagrams should be published.

I hope I get the support to continue this work.



About Diagrams
Motivation
Detailed Diagram Description
Frequently Asked Questions