Siestas… They do a body good

Noticed an interesting CBC article discussing the benefits of siestas on heart health. Supposedly the benefits are even more pronounced in males.

Now it would be next to impossible to have such a thing in my current office situation but at least I’m fortunate enough to be able to spend my lunch hour working out at the gym. Foosball tables aren’t a bad office accessory either.

It’s amazing the impact that stress can have on your ability to work effectively. Therefore I think it’s critical to get out of the office and recharge. If you’re like Intuit and have nap facilities, more power to you. Otherwise, go outside and enjoy the sun.

A JBoss Without Marc Fluery

It’s almost been a year since JavaOne… you know the one with Marc Fluery up on stage in a red beret and the rest of the crew (notably Bill Burke) sporting the same goofy hat at one point or another.

I bet it’s been an interesting ride for Marc and it’s not really a surprise to see him resign. He’s been both controversial and successful at the same time and has every right to walk away from it. Hell, I’d probably do it. I can’t speak from experience but one would imagine RedHat to be an entirely different beast from the geographically dispersed JBoss group. Over the course of last years JavaOne I managed to interact and speak with a number of JBoss employees and developers. The senior JBoss’ers seemed genuinely happy at the time with the prospect of joining RedHat… who knows about the actual project committers.  Rumour has it that they may have gotten a bit of a cold shoulder in terms of compensation for their effort.
From an end-users perspectively, I haven’t really seen much of a difference from a post-RedHat JBoss. The application server and Hibernate still exist. Not to mention that JBossMQ, unfortunately, still exists. Gavin’s going full bore on Seam and I really don’t know what anyone else is doing.  I’m sure there’ll be a bit of a shake-up as even bigger ego’s come into the mix.
It’ll be interesting to see what the JBoss presence is like at this years JavaOne.

A Useful Idea for a Swing EDT Aspect?

I spent most of today debugging some performance problems we’re having in our application. It’s fun stuff, I really enjoy it. Lately it’s been a lot of threading work with Swing which is a fairly interesting area to play in. It’s amazing what kind of perceived performance improvements you can make by simply making appropriate use of background threads and obeying Swings threading rules.

The product in question is a swing-based desktop application that retrieves data from a remote application server, manipulates it and renders it on-screen. Pretty simple, right?

It really should be but being developers we like to make our lives difficult, especially if there’s nothing there to tell or warn us that perhaps our approach needs a second look.

I came across a little nugget this morning that involved a sort routine being called on a collection immediately after an item was added to it. Forget the fact that it was a List instead of a SortedSet (perhaps the biggest gotcha assuming we actually wanted a sorted collection), but to compound the problem (or perhaps make it more noticeable) the custom Comparator being used was expensive. It performed various substrings in order to perform a lexicographically correct sort. The problem was that this addItemToCollection() method was being invoked many hundreds and hundreds of times in succession, to the point where it was taking ~30-35s just to sort and insert items.

What made this difficult to track down was that it was functionality happening solely on the client-side and on the event dispatch thread. We’ve got logging in place so that we (the developers) will be notified when we’re doing something stupid like calling an expensive server call and blocking the EDT. However, we didn’t and still don’t have anything in place that will notify when we’re performing expensive business logic on the EDT and blocking it for a non-trivial length of time.

What I was thinking would be nice, is if you could write an aspect that would execute around various methods in the system (perhaps ones that you knew were potentially troublesome) and would trigger a notification in the event that the time spent executing (on the EDT) within the scope of the method was greater than some predetermined amount of time… say 10ms but even that is perhaps generous.

I’m not sure if the overhead of apply an aspect like this would completely through performance for a loop or if it’s even possible to do. I expect it is possible but I honestly haven’t done enough AOP to be certain. Regardless, I think it would make our lives as developers simpler and less error prone. Alternatively, perhaps there are some static code analysis tools that would be able to catch similar errors?