Home
About Diagrams
    Motivation
    Diagram Description
    FAQ
    Sitemap
Java 7
Java 8
JavaFX
 
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 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.
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 and the exceptions need to match for this to work. Similar aggregations are made for the combination of "add" and "remove" methods and the JavaFX property method 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.

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. The row can be clicked to reveal the hidden elements.

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.




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 exceptions are types with public methods which are supertypes of 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.

JavaDoc comment appearence

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 leave the supertype at the right or bottom and end at the subtype always at the left or top. 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 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. Also 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