Class Diagrammer 2.1.0 Released

Wrapping up the Java port of my Tektosyne library (for computational geometry and graph algorithms), I recreated a number of UML diagrams for documentation, using my recently ported Class Diagrammer. That was its biggest project to date, and sure enough a large number of fixes and enhancements resulted. Class Diagrammer 2.1.0 is now available for download, with the following changes.

UML Element Display

I added all remaining class stereotypes and member properties that I could find in the Java Language Specification. Note that Java unfortunately defaults class visibility to package rather than public scope, and lacks a keyword for package scope to boot. Since documentation diagrams typically consist of public classes, I continue to show these without any stereotype and instead stole the C# keyword internal as a new stereotype for classes with package visibility. (I couldn’t use package because that’s how I annotate actual package elements!)

  • Added class stereotypes «internal» (i.e. non-public), «private», «protected», «static», and «strictfp».
  • Added field properties {synthetic}, {transient}, and {volatile}.
  • Added method properties {final}, {native}, {strictfp}, and {synchronized}.

A number of fixes affect layout positioning. Methods with variable arguments now appear with their Java notation (T…) which seems nicer than appending a {varargs} annotation.

  • Changed last parameter of varargs methods from T[] to T….
  • Consistently sorted otherwise identical methods by covariant return type.
  • Fixed class names being left-aligned rather than centered.
  • Fixed «package» stereotype being right-aligned rather than centered.
  • Fixed nested classes of generic classes appearing before their containing class.
  • Fixed relation lines protruding inside element boxes at right and bottom borders.

Several redundant display items are now automatically suppressed, mostly on enumeration boxes which became much more compact. You may wish to adjust the layout of existing diagrams accordingly.

  • Suppressed display of redundant «final» stereotype on «enumeration» classes.
  • Suppressed display of redundant return type and {final} annotation on enumeration constants.
  • Suppressed display of auto-generated enumeration methods valueOf and values.
  • Suppressed display of redundant {synthetic} annotation on {bridge} methods, which are always synthetic.

If you’re surprised by the last item, bridge methods are automatically generated by the Java compiler to accommodate type-erasing generics. They are normally invisible to the programmer but Class Diagrammer shows them by default – see the diagram in the next section. I’m considering a future update to selectively suppress field and method display by annotation, in case you don’t wish to see them.

Improved Bitmap Output

Previously, all file output used the default Java Graphics2D layout resolution of 72 DPI. This is unproblematic for vector graphics (SVG/HTML, PDF) where the layout resolution only affects positioning, and all rendering occurs at whatever resolution the display device is capable of. However, it was really quite low for bitmap graphics (BMP/PNG, JPEG) and resulted in ugly pixelation when using these formats.

This is now fixed by internally upscaling all bitmap graphics by a factor of four. The resulting output resolution of 288 DPI is close to the standard printer resolution of 300 DPI and should be sufficient for most purposes. Now that Class Diagrammer’s bitmap output is no longer something to be ashamed of, I added an inline sample diagram to the home page and made a smaller one for this blog post, based on the upcoming Tektosyne release:

Class Diagrammer 2.1.0

One inevitable drawback of higher bitmap quality are larger file sizes. PNG files are now slightly larger than PDF files which I think should be acceptable. JPEG files are monstrously large, though. Class Diagrammer output seems to disagree with JPEG’s lossy compression. I tried adjusting the compression ratio both within the application and with an external paint program, and failed to achieve significantly smaller file sizes without greatly degraded image quality. Perhaps you’ll have better luck manually creating JPEG files from PNG output – or just use PNG files.

There was one interesting implementation issue, too. I had to disable font kerning for the upscaled output resolution, or Graphics2D would misalign kerned character pairs. It seems that the current Java implementation does not take scaling transformations into account when positioning kern pairs. This does not greatly affect text quality, however.

Various Fixes & Changes

Two fixes affect project files. Embarrassingly, these saved neither the application title and version in the header, nor any custom colors except those defined in global project options. Now they do!

As you can see in the previous section, I changed the default right color to a much lighter blue for improved readability. Also, the layout resolution is 1/72″ which is the default for Java Graphics2D, but the documentation still claimed 1/96″ which had been true for .NET WPF. This has been corrected.

Finally, there were several improvements to the GUI application.

  • Added shortcut key Ctrl+W for File: Close (close current project).
  • Changed default button on all Change… dialogs from Cancel to OK, so pressing Enter accepts rather than rejects all changes.
  • Diagrams View: Preselect item after removed item in Change Elements dialog lists, if possible, rather than always selecting item before removed item.

Updated PDF Diagrams

I’ve recreated all diagrams published for my various projects with the new Class Diagrammer release. This includes the following (all files are in PDF format):

4 thoughts on “Class Diagrammer 2.1.0 Released

  1. Pingback: Java desktop links of the week, December 19 « Jonathan Giles

    1. Christoph Nahr Post author

      Not at all, see documentation. You must define all relations manually. That was intentional on my part. I had used reverse-engineering diagrammers with automatic relations before, and found that the effort to remove all the unwanted irrelevant ones was greater than just defining the few I actually wanted in the diagram.


Leave a Reply