Finding Deprecated Methods

Is there really no way to find if a method is deprecated using 1.4? It looks like you can determine it via annotations in 1.5, but this code I'm using was compiled using 1.4 so that's not an option. Maybe I'll just write a doclet...

Radio Button Select Lists

I recently changed some pages from radio buttons to select lists for space reasons. The choice between which to use can be tricky sometimes. This guy has a nice solution. I may have to write a tag lib for that one.

Tool Managed Development

One of the various complaints about JSF is that it's tool centric. Many would prefer a framework that didn't "need" tools to work with. Regardless of the merits of that particular complaint, I've been thinking about the larger question of "is using tools a bad thing?" Many people prefer to work with systems that are simple enough to work with without needing to rely on tools. Others praise the "productivity" gains garnered by the use of tools. Certainly the complexity complaint is valid one but, on the flip side, "so what?"

Perhaps it's possible that the industry is beyond the days of simple applications that developers can contain entirely inside their heads. The demands on software are increasingly complex and the problems we're solving are also fairly complex. So perhaps relying on tools is a way to better manage that complexity, drive down development time/costs, and reduce defects along the way. Case in point, work with any EJB application and you have tons of XML documents to keep in sync. The same is true of a "simpler" struts/tiles apps. And it's not just configuration files. There are supporting classes to keep in sync as well. Sometimes a tool is the better choice for managing these dependencies.

On the other hand, perhaps we've painted ourselves into a corner here. Most webapps are not complex applications, per se. A lot of configuration files and the like are there because the frameworks are not smart/sophisticated enough to figure some of this stuff out. Some of it's there because someone thought it'd be a great idea to specify page flow via XML. (Honestly, I've never had someone ask me to change the flow of pages once an app was built that didn't need some code rework. YMMV.) With frameworks like ruby on rails, we can see that is possible to build frameworks and applications that don't need 4 XML files for every Java and HTML file in the system.

To be honest, I'm no sure how I feel just yet. I enjoy using IDEA. It's helped me out quite a bit. But I could go back to gvim if I had to. Are we just making things harder than they have to be? Or is all this complexity really required?

I knew it!

Everyone has blogged about this but I didn't really pay attention. Finally I looked at the moon and learned something we've always suspected. The moon is made of cheese! Zoom in close for the proof.

Test Framework Article Uploaded

I've uploaded the PDF version of my testing article as well as a paginated HTML version for those who are interested. See the links on the home page.

Rails vs. J2EE

The world is aflame these days as rails and java advocates take potshots at each other's tool of choice. I've glanced at ruby on rails a couple of times over the last few months but not given it a serious look. At this month's Denver JUG meeting David Geary presented an intro to ruby on rails. It was good to see an in depth demonstration of what rails is and what it can do. I have to be honest and say that Active Record might have some limitations but I'd have to play with some more complex relationships than what David showed. It could very well handle things like sorted many-to-ones, or priorited lists. I just haven't seen the code to handle it.

To be honest, though, my main concern is one of maintainability. When David showed the first .rhtml file I flinched. It looked a lot like the JSPs everyone was writing when they first came out: lots of code intermingled with HTML. Now, this was the scaffolding code which David freely admitted was crap and that hardly anyone would really use it (then what's the point of rails again?...) Mike Clark told me you could use templates and the like to achieve taglib like scenarios. David also made use of "partials" as well. So all that to say, that while rails is certainly intriguing, I'd have to see a bit more code before I could really say if it's worth learning. David and Mike and certainly big fans and I'm open to learning it. But I'd really like to see some anecdotes of maintaining that project to took less than 1/10 the time it'd take to do in java. Speed of development is all find and good but if it's impossible to maintain then it's not really worth it. Just look at all the dinks that PHP gets for that very reason.

Either way, I'll probably be writing a test app soon just to see what it's like first hand. Anecdotes are great but nothing beats experience...

KDE 3.4 on Gentoo

I recently upgraded to KDE 3.4. I had been waiting for the gentoo folks to unmask it (or rather, promote it from ~x86) but I got tired of waiting. I found a nice script called "gimme" here . This script will add a package to /etc/portage/package.keywords effectively marking that package as ~x86 (or whatever your arch is) so you can emerge "experimental" packages.

The sad thing about this script is that it does only the one package. I had been running the monolithic KDE ebuilds for 3.2 and wanted to switch to the separate ebuilds. There were about 202 dependencies that I'd then have to call gimme for. So like any good UNIX/Linux type, I scripted it. I extended the gimme script to recursively resolve dependencies until they have all been resolved. Here is the script for what it's worth. It's been functional for everything I've used it for but I can't guarantee it won't be flaky in certain circumstances. I hope you find it helpful.

Finally

Well, since things were already falling apart at the seams after my aborted upgrade, I decided to finish the job. As it turns out, it would seem the init scripts my hosting provider uses weren't quite killing tomcat. killall -9 took care of the zombie processes and the upgrade went mostly smooth after that. So at least I'm up and running now. I think I'll see to dinner with my wife and daughter. Enough for one day. (I hope.)

Aborted roller upgrade

Well, I tried to upgrade to the new roller today. Initially i was getting an error about a JDBC driver of '' which of course nothing could work with. Once I resolved that (mainly by handwaving and gnashing of teeth) I finally got roller to start up with my old data. However, the admin pages all went schizo. I'd click a link on the admin pages and then header would show up in the upper right like it should. And then just below and to the right of that, another copy of the header. And then just below and to the right of that, another copy of the header. And then just below and to the right of that, another copy of the header. ...

So I restored the database from back up and rolled back to 1.0. And that's a shame because the one brief peek I got at the new admin stuff looked kinda nice. I'll have to test some and see just what the problem is. Maybe another day. On top of it all my RSS feed appears broken. Maybe I should quit for the day while i'm still (barely) ahead.

Concrete inheritence is not "evil"

I have several friends who are constantly harping on concrete inheritence saying it's "evil" and breaks encapsulation. Though I have never heard an adequate explanation of how it breaks encapsulation, one argument I've heard is that it's impossible to unit test a class that extends another. "How do you isolate a class from its parent?" Well, you don't. That's the nature of inheritence. (For simplicity, I'm just going to say "inheritence" to mean concrete inheritence...) A subclass leverages the code of it's parent. "But you can't get 100% code coverage in your tests with inheritence!" Um, yes, you can. When I write tests and start working toward that magical 100% (3 cheers for emma!), I focus on the code that I write. Now, sometimes I own that parent class and sometimes I don't.

If I happen to own that parent class, it has its own set of tests aiming for 100% coverage. But when testing a certain class, I have no problem only worrying about this particular class. I leave testing the parent class to its owner (sometimes that's also me). Because inheritence has been abused in some circumstances, some would discard it altogether citing such problems as the fragile base class which is that when the base class changes, it can introduce instability down the line. In my experience, the proposed solution, composition and delegation, suffers the same problem.

But, anyway, back to the original question of testing classes. The question came up today of how to test the private methods on a class. What I've done in some cases is to make those methods protected so I can get at them directly (my test classes tend to live in the same package but different source tree). This works well but has the disadvantage of actually breaking encapsulation by overexposing some methods. I don't have too much of a problem with this but some might. Another option (that I haven't tested yet) is to try to use a dynamic proxy in your tests that wrap the target class and expose those methods more publicly. This doesn't require changing the actual production code but does let your tests dig as deep as they want.

What is probably the best option (and one I've really started thinking about lately), is to expand your test data set. Given a broad enough spectrum of data, you should be able to get at every single line in the class. If you can't, then perhaps that code isn't really needed. I love code coverage tools because they really let you see what you are and are not testing (at least in terms of lines of code). The problem with overreliance on those tools, is that none of them (at least that I've used) provide any metrics on the quality of your tests. There's no easy way to tell that you're testing a sufficient range of possible inputs to adequately test your code. There are some tools out there that can generate test data and that's not a bad first step. But ultimately, it comes down to your developers and how well the know and can test their code. And that's going to be true no matter what you do whether you use inheritence or not.