Summa

I came across this issue a couple years ago. It was surprisingly not-so-obvious to the developer, a good developer, who was sorting out a very elusive bug in a large Java application.

The symptom was that a Map of objects sometimes returned null when queried. The developer ran the code in a debugger and could see that the object was put into the Map. Yet, when the map was asked to retrieve the object, it was not found (even though it could be seen by inspection in the debugger).

Other objects were successfully stored and retrieved from the same Map.

Continue Reading Add comment

A few weeks ago I ran into a Java problem that took me an embarrassingly long time to solve — I won’t even tell you how long it took me to notice the source of the bug. It’s a relatively common mistake for starting developers — and clearly it even happens once in a while to experienced guys who aren’t paying attention. I figured I would detail my problem in the hopes that someone else out there might run across this post and save themselves half an hour or more of combing through their code.

Continue Reading 4 comments

I know plenty of developers who, at a tactical level, have had success with static source code analysis tools, using them to help find and root out bad code smells. When PMD tells us there’s an empty catch block at line 207, for instance, we know exactly what to do.

At an aggregate level, however, code metrics are seldom so helpful or straight-forward. When seeing that a source tree has 160,000 lines of code or an average cyclomatic complexity of 4.12, our first thought is usually “interesting!”…followed shortly by “well, now what?”.

The problem is, in my experience, we often look at our code metrics in isolation, without good comparison points, leaving us to wonder whether the numbers we see are big or small, typical or abnormal, good or bad. In the end, it’s not clear what to do, if anything.

Continue Reading Add comment

Say you need to hide internal application errors to your users in a friendly way and also notify the support staff of this exceptional condition. In this post you’ll find a way to do that in a JSF web app. The JSF flavor I’m using is Apache MyFaces 1.1 JSF implementation with the Tomahawk component which provides some extra functionality on top of JSF.

Continue Reading Add comment

As is often the beginning of most anything we do, this story starts with necessity! Unfortunately for me, the necessity was caused by my own screw-up: I had to restore my wife’s computer from a backup and instead of giving files their original modified timestamp, I accidentally chose to set the timestamp to the current time! Well, now she lets me know how difficult it is to arrange our digital pictures into their appropriate months when the files are misdated!

Continue Reading Add comment

Think it’s a weird kind of question? Not for people who have worked (or are working) on applications that are moving from one framework to another. I happened to work on one such project where a transition from Struts to Spring MVC was being done over a few releases. Not unexpectedly, this approach of supporting two frameworks at the same time gave the development team its own share of interesting challenges. And one such issue was how to use a new technology i.e. Spring themes in both frameworks, of course we could choose not to use it in enhancements to legacy Struts based application flows but then that would have meant doing the enhancements twice.

Continue Reading Add comment

AJAX development requires deeper knowledge in JavaScript and there is a slightly different set of features in different browsers. There are also technologies created out there called JavaScript libraries – such as Ext JS and Yahoo User Interface – and JavaScript toolkits – such as Google Web Toolkit (GWT) and DOJO – that can help you ease the burden. Basically, the libraries’ role is to speed up development for the client side and take care of the browser compatibility holdups. Further, the toolkits offer even more infrastructure providing support for the development and deployment phases.

Continue Reading Add comment

What could be simpler than property files? In an enterprise application, it turns out, many things! In this post I’ll take a look at a few subtle complexities to managing properties in an enterprise Java Spring application, and hopefully demonstrate how a little fore-thought in design can yield big savings in terms of time, confusion, bugs, and gray hair down the road.

Continue Reading 2 comments

JAXB (Java Architecture for XML Binding) is a very powerful and comprehensive XML binding framework for Java which can significantly reduce XML programming and testing time by abstracting cumbersome details specific to XML schemas. This post goes through a simple sample for generating a Java class from an XML schema and using JAXB for marshalling and unmarshalling.

Continue Reading 5 comments

You get in to work, grab a cup of coffee, and start your day with a nice, simple, easy-to-read method that stores a value object in the database. By lunch, it has ballooned to 8 lines of code, most of which handle exceptional cases, and make sure that maintenance developers can handle them in testing and production. In this post, I will describe four approaches that I have seen for minimizing this problem and describe some pros and cons for each. The four approaches are, in no particular order:

* Aspect-Oriented Programming (AOP): define an advice class that gets executed whenever any method throws an exception. Log the exception in the advice.

* The catch-all method (i.e. highest interface/tier logging): Log no exceptions at lower levels and allow all runtime exceptions to bubble up. At the highest tier (such as a web UI, main executable, Web Service, etc.), catch all exceptions and log them.

* Self-logging exceptions: Define a base exception class that logs itself in the constructor (takes a message and possibly a Class as parameters). All exceptions in the application must extend from this base class (3rd party or library exceptions must be caught and re-thrown), but no application code should ever log an exception.

* Developer logging: As above, each developer logs exceptions as they see fit.

Continue Reading 4 comments