Todd Huss

I tell ya, one of the things I love about Ruby, Python, Perl, etc… is that when you make a change to a the code or presentation layer, all you do is hit refresh in your browser.

With java and servlet containers it's a bit more difficult but can be almost as elegant if you know how to setup your dev environment properly. I'm often surprised by how many Java developers rebuild and redeploy the whole webapp for every change they make to say the domain model, a controller, or even simple JSP pages. Imagine changing a JSP, then sitting around for 15 seconds to a minute while it redeploys to make the change and then do that 100 times. It's a little too reminiscent of walking a stack of punchcards down the hall and quite frankly it's crazy, because as many know, there's a better way.

Here's how I like to address this issue is as follows.

1. Make sure you can build an exploded war and that when you rebuild, only updated classes, JSP files, etc… are copied into the exploded war. As a Maven user I do this with maven war:webapp, you can also do it with Ant or even better, through your IDE.
2. Make sure your servlet container knows to automatically check for and reload classes when they are updated in the exploded war. If you're a Tomcat user like me set the reloadable attribute in your Context to true. Never set reloadable to true in production!
3. Fire up Tomcat and mount the exploded WAR directory in Tomcat thought the manager application.

Now, make a change to class or JSP and run whatever command updates that class or JSP into the exploded WAR (e.g. ant, maven, or best of all setup your IDE to do it when you hit save). Hit refresh, Tomcat will detect the new class or JSP file and you'll see your results immediately.

Bottom line, even in Java you can update a class or view and see the results immediately by hitting refresh in your browser. It's just a bit more of a PITA to get setup initially!

I had almost written off XMLUnit because I assumed it required subclassing XMLTestCase and I already have my own JUnit TestCase sublass that I like to use. However, to my delight I discovered they have refactored out an XMLAssert class full of static assert methods so that you can call them anywhere.

If you've never heard of XMLUnit it's a nice library that lets you compare XML documents for equality or subsets thereof using XPath. Very nice for creating unit tests to verify that the XML your classes are returning is what you expect without worrying about linebreaks, whitespace, and other pesky formatting details if you were trying to do it with String.equals or String.indexOf.

We're a small enough company that we can make the move to J2SE 5.0 whenever we want but we're holding off right now for 3 main reasons:

1. I'm not interested in being an early adopter unless the gain will give us some major competitive or efficiency advantage. While I'm looking forward to autoboxing, generics, annotations, enumerations and such I don't think they'll really give us major gains in either of those areas.
2. While IDE support for J2SE 5.0 is improving I don't know anyone that's tried it that hasn't run into some issues. Same goes for library support.
3. It's still relatively new to the 247 production world and since we fall into that category I want to be very confident in the stability of the JVM.

So when's the right time to make the switch for me?

1. When friends start asking me “why are you still running 1.4?”.
2. When I hear friends talking about their companies upgrading production servers to 5.
3. When the libraries and app-servers we use start requiring 5.

In summary, I think the right time to move is after the early adopters have gone through most of the pain and moving to J2SE 5 starts to become mainstream. All of that said the time is right to start playing with 5, setting up your continuous integration server to build and run unit tests with both 1.4 and 5, and so on.

One thing I find annoying at times is adding in null checks in a method body to throw an IllegalArgumentException for method arguments that shouldn't ever be null.

Most of the time as programmers we skip it and rely on the fact that a null pointer will get thrown somewhere further down in the method body. That's not ideal though, especially in a non-transactional system where you can't rollback easily (e.g. writing data to a file or network). I also find myself looking at API's sometimes wondering if a certain field is optional and then going to the javadoc only to find no mention of what happens if I pass in a null for a seemingly optional field.

Ensuring that a method argument is non-null is so cookie cutter that I feel like it should be part of Java. We can declare objects as final so they can only be assigned once, why not be able to declare them as required or notnull so that they can never be assigned null? For example I would like to write a method that looks like this:

public Foo doSomething (final required Bar bar) {
	// Passing in null would throw an IllegalArgumentException
	// or a brand new RequiredArgumentException

rather than what we currently have to do if we want to guarantee that a non-primitive is not null:

public Foo doSomething (final Bar bar) {
	if (bar == null) {
		throw new IllegalArgumentException("bar is required");
	}
	// Now that we've established bar is not null we can start doing
	// non-transactional stuff like writing to a file or network

I also find the former more readable than the latter since even without good javadoc I know it's expecting a non-null value based on the method signature.

Two weeks ago I wrote about code coverage from within Eclipse using djUnit. Since discovering djUnit I've become a huge fan of code coverage in the IDE to improve the TDD process. Since we're going to be using Idea at my current company I looked around and discovered that Clover (commercial software) has both Idea and Eclipse plugins which is what we'll be using. Another really nice coverage tool that is open-source is Emma and as it turns out Emma has an Idea plugin.

The Java developer I hired to lead the Java side of our port from Perl to Java came from a background of using Idea rather than Eclipse. He liked it so much that we're going to be using Idea as our standard IDE, and what the hell, if Atlassian, Martin Fowler, and other respected folks are using it, it can't be that bad. Anyhow, this will be my first time using something other than Eclipse to develop Java and I'm looking forward to the change. So far the experience has been quite positive so I thought I'd report briefly on my initial impressions.

Eclipse's biggest strength aside from being a great IDE is plugins, plugins, and more plugins. Idea's greatest strength is more out of the box funtionality (e.g. J2EE app server support, XML editor, etc…) and more robust refactoring functionality. To address the out of the box functionality issue with Eclipse I used to install a bunch of plugins but eventually saw the light (the number of hours I was wasting) and ended up purchasing MyEclipse which does a good job of filling the gap and is amazingly inexpensive!

With Idea I feel that the 3rd party integration is ever so slightly more polished than in Eclipse. For example I like the CVS and JUnit sub windows more in Idea. There's a little more detail and the visual layout is slightly more intuitive. The refactoring functionality seems to offer more options in Idea and they offer a slightly more powerful window management paradigm (or at least one that took me less time to learn than Eclipse's). Lastly Idea has some really nice code analyzing features to look for common programming issues (e.g. too many constructors possibly indicating a need for refactoring into sub-classes).

I couldn't find anything in Idea that was of major importance to me that you can't also do in Eclipse with plugins installed (or by using MyEclipse). In other words, there were no glaring features missing from one or the other that make me say X is by far a better product. I also haven't found one to be vastly more productive than the other (although time may tell a different story).

To summarize my initial findings I don't think you can go wrong using either IDE, they're both extremely powerful. On the Eclipse front I would definitely recommend going the MyEclipse route, for $30 a year per person you'll save money over the time you'd spend keeping a plethora of plugins up-to-date. Overall I think Idea is an ever so slightly more polished IDE than Eclipse. Is it worth $500 per person? Too early for me to say. It took me about 5 hours of using it before I started to get over that initial feeling of “this is worse but only because I'm not used to it yet” to evolve to “I can do everything I did in Eclipse and there are some things that I like better”.

Have you used both Idea and Eclipse? If so what were your experiences?