As an example consider the following code:

private static final int SPECIAL_CASE_1 = 1;
private static final int SPECIAL_CASE_2 = 2;
…
int someThing;
String param1;
String param2;
…
switch( someThing ) {
  case SPECIAL_CASE_1: {
    doSpecialCase1( param1 );
    break;
  }
  case SPECIAL_CASE_2: {
    doSpecialCase2( param2 );
  }
  default: doSomethingElse();
}

There are some issues with the above code. case statements are easily screwed up (is SPECIAL_CASE_2 supposed to also call doSomethingElse() or is that a bug? Also, adding new cases can lead to quite a lot of classes to update. For the times where a full-blown class hierarchy is overkill, an enum makes quite a lot of sense. Often, the methods doSpecialCase1, doSpecialCase2, doSomethingElse can be refactored into methods of the enumeration.

Here’s how we can accomplish this.

public enum SpecialCaseHandler {
  SPECIAL_CASE_1,
  SPECIAL_CASE_2,
  DEFAULT_CASE
}

This simple enum can be used to replace the type of the control variable someThing. Now the switch statement looks like this:

SpecialCaseHandler someThing;
String param1;
String param2;
…
switch( someThing ) {
  case SPECIAL_CASE_1: {
    doSpecialCase1( param1 );
    break;
  }
  case SPECIAL_CASE_2: {
    doSpecialCase2( param2 );
  }
  default: doSomethingElse();
}

On the surface, this doesn’t get us a whole lot. What would really be nice is if we could remove the switch statement altogether. To accomplish this will take a bit more magic.

We’ll begin our magic by defining an inner interface inside the enum itself. Since the above switch statement uses two separate String parameters, the interface will have to account for both parameters. In addition, our enum will need a field declared of that particular interface. It looks like this:

public enum SpecialCaseHandler {
  …
  private MyRunnable myRunnable;
  …
  private interface MyRunnable {
    public void execute( String param1, String param2 );
  }
}

Next, we’ll rework the enum members to use a non-default constructor that takes an instance of MyRunnable.

public enum SpecialCaseHandler {
  SPECIAL_CASE_1( new MyRunnable() {
    public void execute( String param1, String param2 ) {
      // body of doSpecialCase1() goes here.
    }
  } ),
  SPECIAL_CASE_2( new MyRunnable() {
    public void execute( String param1, String param2 ) {
      // body of doSpecialCase2() goes here.
    }
  } ),
  DEFAULT_CASE( new MyRunnable() {
    public void execute( String param1, String param2 ) {
      // body of doSomethingElse() goes here.
    }
  } );
  …
}

Now the original switch statement can be remove altogether, leaving this beautiful little call:

someThing.execute( param1, param2 );

But wait, you say, what if my caller class has some dependencies that prevent the methods doSpecialCase1, doSpecialCase2, and doSomethingElse from being refactored out of the caller class? The answer is simple, add additional input parameters to the MyRunnable execute method to take the dependencies as input.

That is, if doSomethingElse happens to use a database connection whereas doSpecialCase1 uses a file handle, you’ll have to come up with some way to pass that off to the method call. I’ll leave that as an exercise to the reader.

I’m pretty pleased with the result: I’ve removed the switch block from my code and can pretty easily add in new cases to the enum. I think using enums really is a nice alternative to more rigorous inheritance in a lot of cases. Anytime a specific identifier is called for but not necessarily a super-reusable class, consider using an enum instead.

I’ve been working on a project lately that is a pretty simple management application that uses JPA in the data layer. One of the goals of this project is to provide a nightly process for parsing input files. I could have tackled this in a variety of ways. My first hope was to create an executable JAR file, but I quickly found that I couldn’t get very far due to a limitation/feature of JARs: one cannot modify the classpath via the command line interface. My project uses some platform-specific files, so I could not easily include them in the final package. My second attempt ended up working well: create a JAR file within my WAR and execute a class inside that particular JAR.

This project has quite a lot of dependencies: Spring MVC, Hibernate, JPA, Javamail, SQL Server, etc. If I were to create a command-line call to the java executable it would quickly fill up many, many lines in an editor. Fortunately, it’s easy to include the classpath inside the JAR manifest during the Maven package:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <archiveClasses>true</archiveClasses>
    <archive>
      <manifest>
        <addClasspath>true</addClasspath>
        <mainClass>…</mainClass>
      </manifest>
    </archive>
  </configuration>
</plugin>

The <addClassPath> bit tells Maven to include all of the other dependencies in the manifest file. This is a big deal, as it accomplishes two things: it takes care of me having to write a script to generate the classpath dynamically and it allows me to have a very reasonable length command line statement.

Thanks to letting Maven create a JAR file with its manifest managing the classpath, my resulting java command looks like this: java -cp MyProject.jar:… MyProjectRunner (where MyProjectRunner is a class that I want to execute).

Here’s how to replace JCL with SLF4J:

<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>99.0-does-not-exist</version>
</dependency>
<dependency>
  <artifactId>jcl-over-slf4j</artifactId>
  <groupId>org.slf4j</groupId>
  <version>1.5.6</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>1.5.6</version>
  <scope>runtime</scope>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>1.5.6</version>
</dependency>

Here’s an explanation of what’s going on:

1. The first dependency tells Maven that commons logging will be using a non-existent version.  You’ll need to use an empty JAR file or find a repository that will serve you such an empty JAR.  The trick is that the version number is ridiculously high and trumps all other versions of JCL.
2. The second dependency tells Maven to use SLF4J to provide the API for JCL.  All Java commons logging calls will then use the SLF4J runtime implementation to provide logging.
3. The third dependency is the runtime implementation of SLF4J over log4j. In essence, the only calls to log4j are made through SLF4J.
4. Finally, we’ll bring in the SLF4J API so our code can use SLF4J instead of JCL or log4j.

Here’s an example of replacing log4j with SLF4J:

Old Version

private static final org.apache.log4j.Logger LOG = org.apache.log4j.Logger.getLogger( Taco.class );

New Version

private static final org.slf4j.Logger LOG = org.slf4j.LoggerFactory.getLogger( Taco.class );

This one line change allows you to change out your runtime logger at will

The day after my 29th birthday, Inkscape hit 0.46 and brought with it a ton of new features.  Most of these features I could care less about (though it is fun to use the sculpt tool) but there is something new that just totally rocks my world.

As I mentioned recently, I finished the book Dreaming in Code.  In that book there’s a bit where one of the original Macintosh developers discussed taking out a text-editing feature from MacPaint for fear of it being used to do word processing instead of drawing.

I can understand why that was important to a program like MacPaint, but I’m quite happy that Inkscape does differently.

Here’s what I love about the new version: you can edit a text object inside of its group.  I’m pretty sure this is new.  What this means for me is this: I can create a complicated object (say a UML diagram), group it, move it around, and then edit its text without ungrouping it.

For me, this totally justifies the cost of upgrading to Inkscape 0.46.

Oh wait, the program is free

URL Rewriting is a great technology that makes Cool URIs much easier to obtain and manage.  Essentially you run a filter on your web server that listens to everything and can interpret various expressions as different requests.  That sounds pretty vague and complicated so here’s an example: RewriteRule /favicon.ico /images/favicon.ico [RP]. In this example, an incoming request for /favicon.ico will be redirected to /images/facicon.ico. This lets you keep a tidier filesystem without breaking links for people.

URL Rewriting does a lot more than mere redirects though.  You can redesign paths to contain variables in them RewriteRule /images/(\w|\d+)/blank.png /spambot/identify.php?id=$1 is a way to uniquely identify someone with an alphanumeric id via a HTML image link. Like I said earlier, the example above can allow someone to be identified in an image linked in the body of an email.

Today I realized that I can use URL Rewriting to save me a lot of trouble switching between development and production environments.

In this case, we can match a condition of the request and see what server is referring the URL to my server.  In other words, a link from http://josh-peters.name/ can be handled differently than a link from http://blog.josh-peters.name/ even though they both link to the same address (in this case, say http://example.org/foo).

The benefit is huge!  I can push out the same markup to a development server as I do a production server and then simply redirect the development resources as needed.  Currently I’m involved in a project where someone else is serving the pages and I provide the styling rules and scripting.  I’ve setup the rewrite rules such that when someone comes from http://dev.example.com/ they are treated differently than from http://www.example.com/.  No forking of the markup is needed, which translates into one less problem area for rolling out changes

I love it when a plan comes together!

The idea is an old one: link to another folder (or file) in a repository.  The benefits of doing so are wonderful.

For each JSP project the following are commonplace:

• the tag library
• a folder for dependencies
• a folder for Java source

Now, I’ve been storing each of these in different parts of the repository.  Given a project A its Java source exists in /source/branches/projectName/src, its compile-time dependencies in /source/branches/projectName/deps, and its tag library has been a SVN copy of the RELEASE tag of our jsp tag library.

What a mess it was: building the source was in a separate part of the repository (which aided things like testing and continuous integration) and one had to manually update a project when the JSP tag library had a new release.  We also had to use a wonky build script I wrote in Ant to pull the resultant JAR file from the repository into the web project—it was annoying I tells ya!

Creating a new project now is much, much easier in Subversion: I just copy a template project and update its svn:externals property to point to the appropriate branch of my source tree.  An update will then update the externals alongside the rest of the project, so my JSP tag library is always up-to-date, and a modification to the Ant build file means that compiling the web project is one step again.  The best part: everything that was broken up remains broken up, which aids in the management of those resources.  The JSP tags are a perfect example of this: someone who knows what they’re doing can work on them and update the RELEASE tag when they’re done.  When someone who depends on those tag libraries does their next update (which is pretty much once a day at least) they automatically receive those changes without the JSP tag library person getting involved or (worse yet) invading my project in SVN.

Finally, since externals allows you to point to any SVN repository, you can remix and combine repositories really nicely.  For instance, you can run a repo for web projects that links to the repo for Java sources which in turn links to the Spring Framework’s latest and greatest release as a dependency.

We’re adopting a new system at work that is quite complicated and has many, many parts to it. Since discovering Spring I can say that I’m less than impressed with a lot of the technologies within it, but it gets the job done (for some values of “job”). Specifically the version of Apache Struts pales in comparison to what’s available now with SpringMVC, Web Flow, and even Struts 2.0 (and don’t get me started on the funky use of OJB).

Being in class makes me wish I was a paid consultant instead of a day-to-day worker. Management listens much more to a consultant’s suggestions and looks up to them as informed gurus, as opposed to a peon who can’t fathom the vision that is being cast. Ugh.

The class itself has been pretty good so far. The instructor (from a company named ImplMentor) is pretty knowledgeable and has been a good sport about many of my questions (though I wish the rest of the class would ask more questions).

Overall I’ve learned some interesting things and in a mere four days (plus two other days of a crash course and not something I want to do again anytime soon) I’ve become learned enough to be dangerous in the new system.

The biggest issue is that there’s a huge issue with plugging it into our campus that was either glossed over or blatantly ignored the first few times we had the rSmart people in to our campus: the Kuali System is a huge lock-in to Oracle, which we don’t use. This is a big deal which will cause untold numbers of headaches in the future.

Ah well, keeps me gainfully employed I guess.

I’ve definitely been hard-pressed in some of my beliefs and training in respectful communication.

If you’re a person who prays, please pray for me that I won’t let my frustration lead me to say or do something that is wrong. I’ve been thinking a lot about Psalm 1 since there seems to be a bit of scoffing going around. It’s something that is really hard to resist joining in on.

If you wanna hear more, send me email or talk to me in person.