General Updates and Major Changes – Nothing new from the Western Front

Despite the semester starting soon/having just started (being a good student, I don’t recall exactly when it starts), I’ve been fooling around with my MBT Workbench still.  I still owe a video demo and an update on the report generation, but between cultivating a healthy hate of JasperReports and not feeling like investing 5-10 hours in recording and editing a demo, I’ve procrastinated by looking at a couple of large technology upgrades happening in the background.

MBT has been based on Spring 5/Spring Boot 2 almost since the get-go, so while Spring 5 is a nice upgrade, it also provides little in terms of challenges or new functionality for the MBT Workbench (the updates are primarily focused around reactive programming for the web, which is nice but large irrelevant for us).

[youtube_advanced url=”https://www.youtube.com/watch?v=xoMgnJDXd3k” width=”300″ height=”240″ responsive=”no” showinfo=”no” loop=”yes” rel=”no” fs=”no” modestbranding=”yes” https=”yes”] The other big update happening recently, is the upgrade to Java 9.  That one is going to be a bitch and a half.  Java 9 is primarily focused around cleaning up some old crud and adding a new module systems.  The new module system makes it possible to hide implementation details and split programs up into modules with well-defined interfaces.  This works a bit like how OSGi has compartmentalized class-loaders and allows only exposing some packages in each module or how JBoss AS 7 introduced isolated modules instead of a single namespace.  Anybody who has worked with migrating non-OSGi code to OSGi or upgrading JBoss 5 applications to JBoss 7 knows this is a literal nightmare.

The module systems means that all dependent modules have to be upgraded to support the Java 9 module system.  Some are already, som will be soon and some might never be.  Spring 5 supports Java 9 out of the box, so that’s a great relief.  Unfortunately, I make use of CXF’s dynamic client functionality, which relies on internal classes.  I run into similar issues with Groovy, where I do a bit more inspection of the Groovy ASTs thanI also use slf4j, which interferes with other logging frameworks (Java, of course, has close to a bajillion logging frameworks, so each library uses their own; slf4j makes it possible to emulate all those other logging frameworks and send logging information to a single logging implementation), and this is not close to compatible with Java 9’s module system (for example, it breaks the rule that only one module can supply classes in a given package).  AspectJ (used for @Configurable) is not updated for Java 9 yet (there’s a beta which I’m using now), and Eclipse claims to have early support but that’s not really working.

I decided to also bump my JUnit installation to JUnit 5, which has been entirely rewritten and got a new API slapped on top.  This is mostly ok, but means you have to add a lot of dependencies to your Maven configuration yourself, and Mockito is not really integrated yet (though, you can just put this class in your classpath and things mostly just work).  Also, testing is for losers so who cares?

Biggest problem (for me) is that my Observable Collections library depends on the Java Observable/Observer class/interface for its notification infrastructure, which has been deprecated in Java 9. In their place, they suggest using the PropertyChangeListener, which doesn’t quite fit my needs.  Anyway, I squeezed my code into the framework (check it out in the java9 branch).  It’s not terribly elegant, but works.  Kind-of – as of now, some tests are failing.  I cannot really debug it because Eclipse doesn’t quite understand Java 9.

Being forced to not only update the Observable Collections library to use a not-quite-fitting event structure but also update the main application afterwards, I again set out to find an alternative: having to do a major event infrastructure upgrade anyway, I might as well put the maintenance burden on somebody else.  My Google-fu was a bit better this time around, and I stumbled upon the Glazed Lists library (get it, it’s sugared lists).  The library provides an event structure for lists, along with a view mechanism similar to what I made with the Observable Collections library, but was entirely focused on lists.  My need for other collection types, primarily (sorted) sets and maps can be supported by Glazed Lists’ UniqueList and SortedList views and my own ObservablePair class.  Glazed Lists comes with bridges to Swing (and, impressively, SwingX, Hibernate and a handful other goodies), and seems to be actively maintained again (which is good because until the most recent version, the previous latest version was a good half decade old).

And that’s where I am right now.  I have migrated the tool to Glazed Lists and I am working on new functionality on that branch which I wait for things to get a bit more mature on the Java 9 side.  I have done some percentage of the Java 9 migration on a separate branch (a percentage which feels like 90% but is probably closer to 10%).  I also moved from Maven 3.3.3 to Maven 3.5.0, which has new warnings I had to get rid of.

To tide you over until I get my ass together to do a demo video, here’s a sneak peek of the new reporting functionality, which also serves a great counter-example to the old adage that techies shouldn’t be tasked with design:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.