As it turns out you can pretty easily download the new 1.5 JDK, but there are a few wrinkles. It doesn’t become your default JDK unless you do some tweaking. In my case this involved IntelliJ as well.

The first step involves downloading the 1.5 JDK from apple.

I then assumed running

would show me the new 1.5 version. Instead I got:

>java -version
java version '1.4.2_07'

Next step is to change the default JDK:

>cd /System/Library/Frameworks/JavaVM.framework/Versions 
>sudo rm CurrentJDK 
>sudo ln -s 1.5.0 CurrentJDK 

Now when I run

I get the expected:

>java -version
java version '1.5.0_02'

After that I had to download IntelliJ IDEA 5 from intellij.net, because as it turns out the Mac OS X version of 4.5 didn’t support the 1.5 JDK. Makes sense since Apple didn’t release 1.5 until just recently so they couldn’t have built 4.5 to support it. Anyway it’s a bit beta software so far, but it does let force me to realize the new 1.5 context, which is part of the point. Now I’m up and running.

In an article on O’Reilly’s On Java site, Michael Juntao Yuan compares Spring versus the EJB 3.0 spec. His essential argument is that EJB 3.0 “learned the lessons from Spring and Hibernate so well that, in most cases, EJB 3.0 addresses what most developers need with a standard API.”

We also learn in the scope of the article that Spring “is a popular but non-standard open source framework.” I’m really not sure what an how an open source framework is non-standard. This applies as well to ant, JUnit, log4J, and a host of other commonly used open source java tools. If it means it doesn’t have an official JCP blessed spec, then I suppose it is technically non-standard. And with open source frameworks popularity means its instantly more useful because of a large community of users and contributors.

Since even with the EJB 3.0 spec parts of it can be difficult to test outside of the container we learn that “in-container tests are recommended, as they are easier, more robust, and more accurate than the mock objects approach.” The reality is in-container tests are possibly OK for functional tests that CruiseControl runs, but they blow for unit tests as the overhead is simply far to high leading them to be commented out, etc. I’ve seen my developers fail to run unit tests over and over again because of dependencies on things like rules engine environment, JBoss servers, and databases. They simply take too long so they don’t get run.

I’m cherry picking things from the article here, but I don’t think it’s fair to come after Spring when the EJB 3.0 spec still isn’t finalized and won’t have much vendor support for a few years. And of course the author works for JBoss. And since I haven’t had to build anything that required EJB so far I find that Spring is likely to be a lot more useful to me in my everyday work. At the end of the day I need more easily testable POJOs, not another promise of better EJBs.

Over a lunch break today I pulled down Fitnesse and started it up. I used it in two sessions at Software Development 2005, but I haven’t gotten a chance to really run through it on my own since then. I’m hoping it’s a simple enough framework to really automate some acceptance tests. The wiki interface with simple tables with parameters, expected, and actual values could really work well.

Still hooking the fixtures into our code seems a little murky. The first example bundled with Fitnesse is the ‘Two Minute Example’ that simply does division with a numerator and denominator. I downloaded the newest release and ran into the first little issue after I tried to run the ‘Two Minute Example’ locally.

Exception in thread 'main' 
java.lang.NoClassDefFoundError: fit/FitServer

Turns out after 20 minutes something is missing in the newest release from 4/5/2005. I downloaded the prior release and the problem disappeared. Since lunch isn’t that long and I leave my door open that was about as far as I got. Hopefully tomorrow I can setup a fixture that hooks in some of our code.

Working through some nasty NullPointer exceptions on a project now. It was a fairly well done project, no unit tests but run as an experimental Scrum project and all of the developers were fairly good about testing the apps by hand. Way too much deployment to Tomcat, but it seemed to meet the requirements and it worked OK for the first phase.

So the second phase includes more functionality, but again the developers seemed to deliver another solid release. Then everyone went on vacations as QA continued testing. Somehow some basic defects were missed or introduced accidentally. Since they’re aren’t any unit tests to speak of, it’s become painful to find the bugs. If we had been doing real unit testing we’d have tests for these cases and we’d be passing in nulls to make sure they were handled. Anyway it’s more ammunition now for adding unit tests to all our new projects. Tomorrow we’ll try to add test cases and solve the issues, no sense in continuing legacy code.

A problem that crops up over and over again in my world is that a developer or two completes their coding assignments on a project and the project moves into a formal testing cycle. If the developer has done a quality job and done a lot of unit testing the code base is likely to be in pretty good shape with few bugs. Still since it can take testers quite a while to test they end up with bench time waiting around for the few bugs that do come in.

Typically the developer has some research/cleanup items that can occupy a couple of days, but then comes the idle time. If I can’t find some new work quickly they become tempted to ‘add’ functionality which can be a dangerous game, or merely get bored idling. I’m still working on ways to get around this, but it appears to be a persistent problem. My guess is as we experiment with pulling in QA really early in the development process and help them write tests, that we’ll see less of this problem in the future. I certainly hope so.