Search Engine Friendly URLs in Java

At work I’ve been looking into doing search engine friendly URL’s in Java. For those not in the know, a search engine friendly URL is of the form as opposed to the more typical approach of

In my research so far there seem to be several approaches commonly used to solve this problem.

1. The most common seems to be URL rewriting using Apache’s mod_rewrite. In Java there’s also a servlet filter called the UrlRewriteFilter. I think if you’re going to do this for Java backed pages then using a servlet filter is definitely advantageous over using Apache to handle it so that it works in a plain old tomcat dev environment also.

2. Wildcard servlet mapping is another possibility (without using a servlet filter). By mapping something like /* to your dispatcher servlet, you could use the path info in the MVC controller to pull out the parameters. I’m not crazy about this approach because it requires your MVC controllers to be smart and therefor use a non-standard approach to get request parameters.

3. The last option I’ve heard about is just writing your own servlet filter. For example if you know that your search engine friendly urls will always be of the format /foo/param1/value1/param2/value2/etc… then you could simply write a custom servlet filter that disected the uri and filled in the request parameters. You could probably just do this with a regex using option 1 as well.

So far I’m liking options 1 and 3 the most because they take a nice AOP style interception approach that allows you to code MVC controllers expecting regular request parameters. Anyhow, if you’ve heard of how other folks have solved this problem or have suggestions or ideas, I’d be curious to hear about it!

Posted in Java, Search Engine Optimization | 1 Comment

Two additional Ruby features I wish were in Java

I’ve been tinkering with Ruby a little, mainly so I know what I’m missing since a lot of people really seem to dig it. Ruby has a lot of nice features that I like including mixins, closures, Rails scaffolding, active record ORM, etc…

The things I don’t like about Ruby are that it’s weakly typed which I’ve written about before and has a very terse syntax that makes it hard to understand at times if you don’t “know” Ruby. For example when I first started looking at Ruby code these constructs left me wondering: variable, :variable, *variable, @variable, |variable|, and @@variable.

While playing with Ruby over the weekend I found two more language features that Ruby has that I really wish we had in Java:

1. Immutability: you can freeze objects so that any attempt to change an immutable object will result in TypeError exception reporting “can’t modify frozen TYPE”. I would love to have this in Java.

2. Native getter/setter support: declaring a list of variables as attr_reader or attr_writer allows getter/setter functionality of a variable without writing/maintaining any redundant getter/setter code, yet if necessary, you can override the default getter/setter behaviour without affecting the API. In Java it drives me crazy that we waste time and clutter our classes unnecessarily with hundreds of lines of getter/setter methods that all do the same thing. Java really needs a construct for default getter/setter behaviour on selected variables that can be overriden when necessary.

The only other feature that neither Ruby nor Java have that I’ve written about before is language support to guarantee that a method variable cannot be passed as null such as public boolean doSomething(notnull Object foo)

What features do you wish you had in Java that you’ve seen in other languages?

Posted in Java, Ruby | Comments Off on Two additional Ruby features I wish were in Java

Firefox web development extensions

My three Firefox plugins of choice that save me a lot of time troubleshooting and working out web development issues are:

1. Web Developer Extension: this one is a must have!
2. User Agent Switcher: I use this one occasionally to switch my UA into a crawler such as the GoogleBot since there are some cases where I modify pages to behave in a more search engine friendly manner if the user agent is a known crawler.
3. Live HTTP headers: This is my favorite tool for diagnosing pages getting cached that shouldn’t be cached and other general HTTP header work. The web developer toolbar also does this, but I like this one more since it’s real-time.

I asked my old coworker Dave at Urbanasoft what he was using these days and he pointed me to the following which look good as well:

1. View Formatted Source: for debugging missing closing tags, understanding which CSS settings are being applied to a certain tag, etc…
2. ColorZilla: a color picker, eyedropper, and page zooming tool.

Update: just discovered the SearchKeys plugin that Jeremy Zawodny mentions over on his blog, very nice! He’s also a big GreaseMonkey fan which I haven’t tried yet.

What are your favorite Firefox web developer extensions?

Posted in Software Engineering, Technical, Web | Comments Off on Firefox web development extensions

Only crazy people redeploy a webapp after editing a class or JSP

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!

Posted in Java | Comments Off on Only crazy people redeploy a webapp after editing a class or JSP

You can use XMLUnit without subclassing

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.

Posted in Java | Comments Off on You can use XMLUnit without subclassing

Use and overuse of interfaces

Cedric’s blog entries on Extensibility the interface way, More on interfaces, and Numbered Interfaces got me thinking more about how often to use interfaces, prefixing them with I, adding an Impl to the end, etc… so for my own benefit I wanted to break it down a bit:

1. Interfaces starting with I: I could take it or leave it. In practice I don’t care if I’m programming against a class or an interface, I generally use an IoC container these days so I’m rarely newing a class anyhow. It is convenient knowing something is an interface from the name though.

2. Using interfaces for almost everything: I think we’ve swung too much in the other direction now and I see a lot of arbitrary interfaces with an Impl class that nobody will ever want to switch the implementation of. Interfaces are great and they should be used liberally but it adds unnecessary bloat to have an interface for everything. As long as you’re using a factory or dependency injection you can always refactor it into an interface/implementation later with most IDE’s in a snap.

3. Naming implementation classes InterfaceImpl: If you can’t conceive of a name that would differentiate this implementation from another, maybe it’s not time for an interface yet! I much prefer implementation names that tell you what differentiates it such as MemoryLruSessionCache, DiskFifoSessionCache, etc…

4. One thing I haven’t fully resolved is whether the implementation of say the SessionCache interface should be named SessionCacheSomeimpl or SomeimplSessionCache. I definitely favor the former because in practice in an alphabetical listing then the interface and the implementations are next to each other. On the other hand it doesn’t work with I-prefixed interfaces. It would also mean the List interface should have an implementation such as ListArray and that feels strange to me, probably just because I’m not used to it.

5. Versioning interfaces with SomeInterface1, SomeInterface2, etc…: Haven’t formed an opinion on this yet.

Posted in Software Engineering | Comments Off on Use and overuse of interfaces

It's still too soon to upgrade to J2SE 5.0

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.

Posted in Java | Comments Off on It's still too soon to upgrade to J2SE 5.0

Tired of checking for null arguments in the method body

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.

Posted in Java | Comments Off on Tired of checking for null arguments in the method body

Code coverage from within the IDE followup

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.

Posted in Java | Comments Off on Code coverage from within the IDE followup

Eclipse versus IntelliJ Idea

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?

Posted in Java | Comments Off on Eclipse versus IntelliJ Idea