Fujaba:
Wow. I wasn’t expecting this. 10 seconds after install was complete, I’d already imported all my classes - even from multiple different source directories, NOT packaged correctly, etc. (see below, though).
I get the feeling Fujaba may be returning to its roots (I used it for my uni dissertation years - and many versions - ago, and it worked much better then than it has for the past few years).
Moments later, I had a PDF, a PNG, and a JPEG version. The PDF was BUTT-UGLY (looks like it took an anti-aliased version and then monchromed it), but the image versions were lovely (fully anti-aliased).
Now, onto the problems. I was actually very grateful that Fujaba completely ignored the package statements in my source - I was actually loading classes directly out of our NFS-mounted SCM, and they are not located in “com/company/project/package/etc” but in 1- or 2- deep folders (the SCM autmoatically exports them in a hierarchy when you tell it to build the current version). For anyone who wanted the UML class-diagram “package” feature, prepare to be disappointed. I’m not sure where I sit on this - having done hundreds of UML diagrams, I find the package notation mostly useless for java projects except when you’re using it to represent the package, not to hold all the contents (e.g. you are showing how multiple packages interact, and don’t want to show all the classes). Paradigm took the opposite approach, and automatically created a package element, and WOULD NOT ALLOW ME to drag classes out of the package element (which made layout and editing a PITA). It’s worth remembering that UML (unlike many/most programming languages) is designed to be 99.9% optional - you are specifically advised to only use the language features you need to make your diagram work it’s best. So, it’s arguable that both tools are “correct” so long as both allow you to use them the other way around as well.
There was also a momentary “Huh?” when I reverse-engineered the UML: nothing on-screen changed. THis is because the root node of the object tree defaults to closed - double-clicking opened up the children and allowed me to find my newly generated UML. I don’t know how long this would confuse the average programmer; I suspect that people not used to MSVC etc might want to just ignore the tree-pane and hence have problems here :(.
EDIT: Followup…
As the best of those I tried, I went on to do the rest of the editing with Fujaba. A lot of the bugs that were there last year are still there, so that editing UML diagrams is a real chore until you’ve learnt what works and what doesn’t. Fortunately, it has a very easy to find “edit source directly” that lets you edit the source and the changes are auto-synchronized back into the diagram. This gives you a “plan B” in 90% of cases where an editing feature doesn’t work properly (like a particular one of the interfaces not appearing in the list of interfaces I could extend from/implement).
However, there are a few cases where the diagram decides “no, you’re wrong” and overwrites the modified source (accompanied by a bug in the diagram’s class-member privacy-editing ).
Basically, it looks like Fujaba 4.1 has about 50% of the 4.0 bugs fixed, making it about 80% as reliable as 1.x (which I used to use) but it’s considerably easier to use, faster, and has good auto-layout (which it didn’t have at all before). But it’s far from perfect. I suspect that the “ideal” is to use F4.1 to do your reverse engineering, and something like paradigm for editing until one or the other fixes their major bugs!
This is a pity, because Paradigm looks like it’s gorgeous WHEN it works, and Fujaba has some cool features like being able to use JEdit as it’s editor, and being designed for use by newbie programmers - so it’s very simple (AIUI it’s actually a teaching aid, and has won several awards for ease-of-use / involvement in “teaching students to program” courses).