How to generate UML Diagrams from Java code in Eclipse

UML diagrams compliment inline documentation ( javadoc ) and allow to better explore / understand a design. Moreover, you can print and bring them to table to discuss a design.

In this post, we will install and use the ObjectAid plugin for Eclipse to produce jUnit lib class diagrams. Then, we will be able to generate UML diagrams by simply dragging and dropping classes into the editor. We can further manipulate the diagram by selecting which references, operations or attributes to display. 

• Open Eclipse and go to Help > Install New Software

• Click on add to add a new repository

• Enter name ObjectAid UML Explorer

• Enter Location http://www.objectaid.net/update

Next, select the ObjectAid Class Diagram plugin - it is free - and click Next. The Sequence Diagram one requires a paid license.

Click Finish to confirm your choices and start the instalation process.

• Click Ok on the security warning
• Select Restart Now after the installation completes to restart Eclipse.

To create a new UML diagram we start the ObjectAid wizard with File > New > Other... and start typing in the textbox Class Diagram to filter the desired wizard. Click Next, and enter a directory and name for the diagram.

Drop java source or compiled class files into the visual UML editor to start populating the diagram. Right click on a generated class to bring up a context menu and adjust visibility, operations attributes, etc as you like.
Below, we see the Assert class from the jUnit library with all operations and fileds hidden.

From the context menu, we can add implementations and associations for a selected class. In the following screen, we add the interface Test implemented by the TestCase class.

This is how part of the jUnit UML class diagram look after adding some more classes.

To auto layout the diagram right click anywhere within the editor and select Layout Diagram. From the same menu, you can export the diagram to an image ( gif png jpeg ) by clicking the Save As Image... menu item

Have fun with the plugin, leave a comment if you like :)

Do not use Java 7 yet

The 7th release of Java today seems that introduced some nasty bugs caused by hotspot compiler optimizations miscompiling some loops. Code containing loops will propably be affected by this bug.


If you use Java 7 use this switch when starting the JVM:
-XX:-UseLoopPredicate

Uwe Schindler an Apache Lucene PMC Member tweeted a warning earlier today as the bug affected Apache Lucene and Solr project causing wrong compilation of some loops.

The warning mail and the full story from LucidImagination:

From: Uwe Schindler

Date: Thu, 28 Jul 2011 23:13:36 +0200

Subject: [WARNING] Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7

Hello Apache Lucene & Apache Solr users,

Hello users of other Java-based Apache projects,

Oracle released Java 7 today. Unfortunately it contains hotspot compiler

optimizations, which miscompile some loops. This can affect code of several

Apache projects. Sometimes JVMs only crash, but in several cases, results

calculated can be incorrect, leading to bugs in applications (see Hotspot

bugs 7070134 [1], 7044738 [2], 7068051 [3]).

Apache Lucene Core and Apache Solr are two Apache projects, which are

affected by these bugs, namely all versions released until today. Solr users

with the default configuration will have Java crashing with SIGSEGV as soon

as they start to index documents, as one affected part is the well-known

Porter stemmer (see LUCENE-3335 [4]). Other loops in Lucene may be

miscompiled, too, leading to index corruption (especially on Lucene trunk

with pulsing codec; other loops may be affected, too - LUCENE-3346 [5]).

These problems were detected only 5 days before the official Java 7 release,

so Oracle had no time to fix those bugs, affecting also many more

applications. In response to our questions, they proposed to include the

fixes into service release u2 (eventually into service release u1, see [6]).

This means you cannot use Apache Lucene/Solr with Java 7 releases before

Update 2! If you do, please don't open bug reports, it is not the

committers' fault! At least disable loop optimizations using the

-XX:-UseLoopPredicate JVM option to not risk index corruptions.

Please note: Also Java 6 users are affected, if they use one of those JVM

options, which are not enabled by default: -XX:+OptimizeStringConcat or

-XX:+AggressiveOpts

It is strongly recommended not to use any hotspot optimization switches in

any Java version without extensive testing!

In case you upgrade to Java 7, remember that you may have to reindex, as the

unicode version shipped with Java 7 changed and tokenization behaves

differently (e.g. lowercasing). For more information, read

JRE_VERSION_MIGRATION.txt in your distribution package!

On behalf of the Lucene project,

Uwe

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134

[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044738

[3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068051

[4] https://issues.apache.org/jira/browse/LUCENE-3335

[5] https://issues.apache.org/jira/browse/LUCENE-3346

[6] http://s.apache.org/StQ

Better play safe and expect an update form Oracle i guess...

Code Fitness - Visualize your java classes and identify complexity

Before refactoring a class, package or library  weak spots have to be identified. There are many code analysis tools providing insight, hints and alerts as to where someone should focus.

But before reading these metrics i'd prefer to have a quick look, an overview of the structure and the complexity underneath especially in a new project. Something visual would be ideal.

So jSizer comes to the rescue. It is a small swing-based app which reads a jar file and produces a graph depicting
packages' - classes' node hierarchy while effective coloring and shaping  helps to differentiate each node based on some vital metrics.

Some examples:

To interpret the graphs :

• The Width of a class-node represents the number of fields.
• The Height of a node represents the number of methods.
• The Color represents LOC - lines of code.

So, quoting jSizer's author Robert Olofsson:

What you want to do is to look at the graph, find the big dark boxes and possibly refactor them.