I just finished working on the first UI prototype for ConsultComm 4. I'm going to try releasing the pre-alphas as a Java WebStart app - available at http://prdownloads.sourceforge.net/consultcomm/ConsultComm.jnlp .
The JTable/JTree mosh-up is courtesy of SwingX. The code has switched from being very state-driven to being more procedurally driven from events generated by embedded components and JavaBeans. Hopefully this procedurally driven approach will mean less bugs, since actions will only take place at one part of the code. An update to one Bean's property will automatically announce itself to all the other Objects that use said Bean, which means you don't have to force each and every component to maintain the Bean's state.
It's hard to explain. But if you look at the code you'll see a ton of event handlers and action listeners, each of which call a single method. Even small changes make ripples across the codebase, so even distant code can hear when a part of the system has been altered.
I'm not making any sense. To any point, even though the demo is fairly simple there was a lot of work that went into it. And hopefully this work will mean accelerated development afterwards.