somewhat daily mutterings

/Programming/Java A Napkin-sketch Look and Feel

In a stroke of pure genius, Ken Arnold introduces his "napkin look and feel". The purpose behind it is to keep stakeholders reviewing the design from considering it "done". I think this has two dimensions: 1) it makes it seem easier to change, and 2) it doesn't look as though it can be shipped.

If only we were developing a Swing app at my shop, we'd definitely be using this technique. Instead, we build static HTML prototypes that our UI guy always polishes to perfection (even though I've repeatedly mentioned that we should not try to make it look to pretty). Maybe we should attach an "ugly" stylesheet to the prototype, although we could never get the same great hand-drawn effect.

Posted: Fri Sep 30 06:50:34 -0700 2005

/Programming/Java Note to Self: Read this Article

Cameron Purdy on Caching (via The Server Side).

Posted: Mon Feb 14 08:10:52 -0800 2005

/Programming/Java Bug in Hibernate UserType Example

In Gavin King's excellent book Hibernate in Action, there lurks an insidious bug. If you follow his custom UserType implementation example on page 203, you're in for big trouble and lengthy debugging sessions. Here's the example

public Object nullSafeGet(ResultSet resultSet, String[] names, Object owner) 
        throws HibernateException, SQLException {

    if (resultSet.wasNull()) return null;    // <------- BUG!!

    BigDecimal value = resultSet.getBigDecimal(names[0]);
    return DataUtils.toPercentage(value);

The problem with the above code is that the wasNull() call is not preceded by a get*() call. In our particular circumstance, once wasNull() returned true (due to a null value in a given column), it kept returning true for every column that was mapped using the UserType. This, of course, resulted in the subsequent fields of this type being given null values, even if the column did not contain a null value.

Do I need to say that this is a very subtle bug that pops out in odd places, and is extremely difficult to find? I spent hours with log messages and the debugger. The right way to do it is as follows.

public Object nullSafeGet(ResultSet resultSet, String[] names, Object owner) 
        throws HibernateException, SQLException {

    String name = resultSet.getString(names[0]);  // <----- You GOTTA do this!
    if (resultSet.wasNull()) return null;

    BigDecimal value = resultSet.getBigDecimal(names[0]);
    return DataUtils.toPercentage(value);

Posted: Fri Jan 28 10:53:52 -0800 2005

/Programming/Java Fall 2004 RMSS Report

First, a link for those who may be looking for the updated slides to my Strangling Legacy Code session. The presentation went smoothly (from my side, anyway), and I appreciated the attendance and comments. I averaged a 3.9/5.0 in overall rating, which ain't bad for a first time presentation of this content.

As an attendee, I enjoyed all the sessions that I attended:

  • First, Erik Hatcher's Ant 1.6 Hacks was a great (re)introduction to many of the features I'm not using on my project, even though we're using Ant 1.6. I have a renewed interest in upgrading our buildfiles now.
  • Stu Halloway's Design Patterns Revisited was a great two part talk on using reflection and AOP to simplify (or factor out altogether) some common design patterns. I especially appreciated his treatment of Iterator and iteration in general. His generic iteration helper class has me reconsidering my project's use of Commons Collections (although we're quite happy with CC in general). Stu has made a nice niche for himself in this area. I finally got around to buying his book Component Development for the Java Platform at the RMSS bookstore.
  • Another Erik Hatcher session, Tapestry by Example held my interest a bit less than the other stuff. This isn't Erik's fault, it's just that web frameworks don't really hold my interest very well. I did feel that the overview was important for me to see, and that's what I got, and more.
  • Ted Neward's two-part Effective Enterprise Java talk was entertaining and informative. One of the more effective and amusing bits was when he used two audience members to demonstrate the concept of a two-phase commit. What was so effective was that he mapped 2PC onto a common human transaction -- a marriage ceremony (yours truly being one of the "transactional resources" in the demonstration).
    There were times however, where I have to admit that the enterprise development issues Ted brought up were so various and many and intertwined that it got a bit overwhelming. Still, the issues that he brought up must be considered when developing enterprise systems, and Ted is obviously encyclopedic in his knowledge.
  • Next up was back-to-back SOA talks by Justin Gehtland: SOA Explained and SOA with Axis and WS-I. Fabulous job in both cases. SOA Explained did a good job convincing me that I already had a pretty good handle on the 30k-foot level of SOA (especially the part where nothing much has really changed, diagram-wise, since I was a Vitria BusinessWare consultant in '99). SOA with Axis and WS-I was much more about code, and Justin did a great job of demonstrating just how easy it is to create web services with Axis and also of describing and demonstrating the implementation of WS-I standards implementations via Axis' layered request-handling architecture.
  • I also went to this great talk with the provocative title of Strangling Legacy Code. Well mainly I went because I had to present it :-).
  • After my session, I stuck around for Nick Lesiecki's AOP Applied talk, which was very organized and informative. I definitely left with a better understanding of AOP, both conceptually and in practice, but I have to admit I've not quite come to grips with moving it into center stage on my current project. Thanks to Nick also for being very gracious when my talk butted right up against his due to a scheduling SNAFU (and my somewhat lacking time management skills).

I really enjoyed this particular RMSS, and I appreciate Jay giving me the chance to speak. I now have the bug, or at least the beginnings of the bug. I'm considering developing another session on speculation of getting to present it somewhere. As a teaser, I'll say that it has to do with a couple of my favorite things: visualization and code.

Posted: Tue Nov 16 04:39:50 -0800 2004

/Programming/Java SpringGraph is now SpringViz

Due to a naming conflict, I've renamed SpringGraph to SpringViz.

Also, a word of appreciation to Craig Walls who's done me the favor of posting some nice things about SpringViz on his weblog, which is syndicated all over. His reach is much further than mine. Thanks Craig -- I'm glad you've found this little hack useful (SpringViz, that is, not me. I'm a big hack.).

Posted: Wed Sep 15 19:25:31 -0700 2004

/Programming/Java Introducing SpringGraph

I just hacked together a little utility for Spring Framework developers called SpringGraph. It generates a graph of the bean dependencies expressed in a spring configuration file. It's based on a similar hack for Ant builds called antgraph (thanks for the idea Eric).

Here's an example graph:

Example Spring configuration graph from "jpetstore" sample

Go to my SpringGraph page for more info and the download.

Posted: Fri Sep 10 17:16:20 -0700 2004

/Programming/Java Abstracts Submitted to SD West

My boss has been pressuring me (in a good way) to submit abstracts to some technical conferences. In particular, he really hammered on me to submit to SD West. I did so just before the deadline, in true Mike fashion. Here are the abstracts I submitted:

IoC Containers - What's all the Hubbub?

Inversion of Control (IoC) Containers have really captured the development community's attention in the last year or so. What do these so-called lightweight containers have to offer your project? Better designs featuring loose coupling and testability, just for starters. By the end of this session you'll have the understanding you need to put a lightweight container to work in your project.

Spring into Action

"Lightweight" Inversion of Control (IoC) Containers have really captured the development community's attention in the last year or so. One such "lightweight container" is the Spring Framework. What does the Spring Framework have to offer your project? Better designs featuring loose coupling and testability, just for starters. See how Spring has been put to practical use on a real project. By the end of this session you'll have a basic understanding of how to put Spring to work in your project.

Strangling Legacy Code

In the Summer of '04, Martin Fowler published an entry to his "bliki" proposing a pattern called, vividly, "StranglerApplication" ( Fowler describes how a new system can grow "around the edges of the old", eventually overtaking and replacing it. In this session you'll learn pragmatic approaches to putting this pattern into action from a practitioner who's been there, is doing that.

Posted: Tue Aug 17 20:35:20 -0700 2004

/Programming/Java Spring 2004 RMSS Reflections

Let's get straight to the point: this RMSS was basically about three main topics: Spring, Hibernate, and AOP. Aspect-oriented programming, combined with Spring (or other lightweight containers) and Hibernate was essentially declared to be the death of EJB (or at least the death of the "need" for EJB). To be sure, the larger shops will continue to buy into the EJB story sold by the large vendors, but the smaller and more "agile" teams will likely forego the EJB approach.

Speaking of smaller and more agile teams, the Spring/Hibernate focus was fine by me, since it strongly validated my recommendation to my (relatively) new team at that we use Spring in the development of the new version of our product. We incorporated Spring into the "new" section of our codebase about eight weeks ago, and have never looked back. We've also basically assumed we'll use Hibernate at some point, as well so we're pretty well aligned with the brave new world. It was a kick for us to be able to raise our hands in response to the presenters' queries of, "who here is using Spring?" In contrast, when I worked for BEA, I often didn't get to use some cool stuff because it may have called into question the usefulness of BEA's own products. The order was always "BEA on BEA." Now I have no such restrictions, and I'm like a kid in a candy store (but I'm still selective with my sweets).

Unfortunately for the RMSS experience, my cool work toolset had a surprising downside: there just wasn't a lot of new material for me to absorb this time around. I mean, it was all fresh material, but I've been reading (and doing) so much with the new toys that it was hard to find sessions that really intrigued me. Since we use Spring I have no interest in AspectJ (plus, I'm still trying to get over my dislike of source annotations and/or language extensions). I really wanted to get into a Groovy session, but the first one conflicted with Dave Thomas' Pragmatic Mock Objects session, and the second was jam-packed by the time I got to the room. I ended up going to several of Bruce Tate's sessions, although he's not one of my preferred presenters (nothing personal - he seems like a very fine fellow), because he was doing most of the Spring and Hibernate talk, several of Glenn Vanderburg's sessions (always a favorite of mine) because he's just plain a great presenter, and a couple of Daniel Steinberg's sessions (Jini - thumbs down, Max OS X Java Hacks - thumbs up).

Posted: Wed May 26 04:37:57 -0700 2004

/Programming/Java To DTO or not to DTO?

This is a work in progress!

There seems to be a lot of debate lately on whether DTOs (Data Transfer Objects) are a good idea. Seems as though the Hibernaters are now saying "without EJB to muck things up, why do I need DTOs - they were just a hack pattern to get around the problems with EJB". Well, as much as I approve of throwing EJB out of many solutions, I think jettisoning DTOs as well is throwing out the baby with the bathwater.

Here's why: I happen to still think that we should tier systems (logically, at least), and as such, have a services layer that defines the boundary between the front and back-ends of our systems. I think most people still agree with that notion. Why do I like service layers? Generally, because they decouple the business rules end of the system from the presentation end, and through decoupling, promote the separation of concerns. Of course, if you're no longer tiering your systems you can ignore my arguments.

So, what are the concerns of which I speak? The way I see it:

The concerns of the front-end are:

  • presenting data to the user
  • gathering data from the user
  • performing minimal data checks
  • navigation through the system
  • security
The concerns of the back-end are:
  • getting/storing data
  • performing maximal data checks
  • carrying out business rules
  • defining and executing transactions
  • security

The creation of a service layer promotes separation of concerns by creating a "facade" (the service interface) between the front-end and the back-end. It's clear (to me, anyway) that business logic belongs behind the facade, and anything that sneaks though the facade from the service to the front-end represents a possible "leak" that can be costly in the future. Prevent the leak by communicating with the front-end via DTOs. Because DTOs are stupid data holders, they convey very little about the implementation of the service. Having clients communicate with services only via DTOs promotes decoupling by keeping the front-end of the system ignorant of the workings of the back-end.

The other alternatives, as I understand it, are to allow the client to access the domain model, either 1) directly, or 2) via a service interface.

The first approach just feels wrong to me, having argued for a service-based architecture in the first place. In my experience, when domain objects are exposed directly to client code, the two have a tendency to become intermixed, which anyone will admit to be a bad thing. A service-based approach at least draws a line in the sand to make it obvious when rules are being broken.

The second approach still has problems, even though it makes use of a service-based architecture. If the service is implemented in terms of the domain model, then we've just negated, or at best muddied, the reason for having a service in the first place. Our pretty facade has sprung a leak, and one that's very difficult to patch. Our domain objects are now subject to possible misuse by front-end coders, who also, because they are now coupled to the domain model, will resist changes to it. Additionally, the domain model is subject to usage patterns for which the domain implementors didn't plan. These new usage patterns may break important invariants or constraints that service implementations were intended to enforce. Having lost control of the domain model, we also won't be as free to change the way we implement our services, say from a thin service implementation to a thick one. These are all basically the same problems that occur when we give clients direct access to the domain model with no intervening service.


Objects are recast at system boundaries for a reason: decoupling. The front-end of the system, in the majority of cases, needs only to pass us simple data structures, and to receive simple data structures in return. It does not need (nor does it really want, due to the responsibility that comes along for the ride) access to the full domain model.

Posted: Wed May 26 04:33:57 -0700 2004

/Programming/Java Spring Framework Dedication

Spring Framework

In honor of Spring (both the framework, and the season), I've changed my weblog's stylesheet to be a springy-green.

Why honor the Spring Framework in such a way? Because, at my new company, I suggested its use (along with Velocity), even though I'd never used it profesionally. Why would I do that? Because Rod Johnson's book Expert One-on-One J2EE Design and Development (in which Johnson introduces the ideas and code that have become the Spring Framework) is such an excellent book that I became convinced that Spring is best-of-breed. Also, lurking on the mailing list proved to me that Spring is well-supported and has great traction with developers.

The result of choosing Spring is that the team has really become productive writing the new parts of our system, and it's helped us think about the system's architecture in better ways than before. The configuration infrastructure has allowed us to write better-decoupled components that can be wired up declaratively, or wired up programmatically and tested in isolation. There are so many good things about it that it's hard to cover them all.

Watch for the release of Expert One-on-One J2EE Development without EJB from Rod Johnson, which I'm sure will be a great treatise on using Spring to create non-EJB-based solutions.

Posted: Fri Apr 23 17:33:28 -0700 2004

/Programming/Java Why Some Folks Use Modifiers for Member Variable Names

While working in some legacy code yesterday, I had an insight that I can't believe took me so long to figure out. I've always thought it odd that some people insist on differentiating member variable names by some naming convention, such as by prefixing the name with an 'm', as in:

    private String mFoo;

I've never been a big fan of overloading variable names with type or scope information because I think it makes it harder to read the variable names, and by extension, the code. To me, the extra "information" is noise, so it lowers the S/N ratio of the code. The inclusion of scope information seems especially unnecessary(and therefore especially noisy) to me, and yesterday I figured out why: it's because I tend to factor my methods into very small, cohesive units.

I assert that where this convention exists you will also find code with long, uncohesive methods.

Why? Because methods that are very small don't have many local variables compared to long-winded, uncohesive methods. Therefore, there can be very little confusion about where a given variable was declared, and therefore no need to communicate the scope in the variable name. Long methods tend to use more variables from multiple scopes (simply because they're long), so to keep things clear, the programmer uses naming conventions to communicate scope that would otherwise be pretty obvious.

This is another argument for short methods, similar to the refactoring that states that a block of code prefaced by a comment should probably be replaced with a well-named method call.

In other words, program by intention - make your code say what it's doing.

Posted: Fri Feb 13 06:52:07 -0800 2004

/Programming/Java Phear my WebLogic Admin Skillz - I'm Certified!

I found out last week that I've passed the BEA WebLogic 8.1 Administrator certification test, so bow down before my administrative skillz! :-)

It actually is somewhat cool that I finally have one certification to my credit, even though I tend to poo-poo certifications, in general. So call me a hypocrite.

Posted: Wed Dec 24 09:52:15 -0800 2003

/Programming/Java My Favorite Java Site - BileBlog

Actually I don't visit very many Java sites - I already know everything. I only wish I was half as funny as the person who edits BileBlog.

Posted: Mon Oct 20 14:25:05 -0700 2003

/Programming/Java Where do JDK 1.4 Preferences Go on OS X?

In case you were wondering (I was), they go in a 'plist':

Posted: Wed Jun 18 21:28:12 -0700 2003

Thanks for visiting! Send comments to Mike Thomas.