Sorry I was wrong about the immutability, my bad. I was just looking at the diff and it must have been wishful thinking on my behalf. I would like to make it immutable since it IMO generally improves construction logic and forces you to create objects in a given order - as required by the problem domain - it usually just drives towards better code. But as you'll see making it immutable involves a fair amount of change.
The current situation wrt jdk 1.3 is that the forked side of the booter and the junit 3.x provider can actually fork down to 1.3. I am no particular fan of this feature, but that'd have to be a ML discussion of sorts. We will not be getting rid of 1.4 yet and I don't personally see the big difference in supporting 1.3.
But the booter module is basically split in 2, the "remote" part, which is 1.3 and the "plugin" side which is 1.4. I have tried to increase this separation by moving the classes that belong only on the "plugin" side out of the booter project and into org.apache.maven.plugin.surefire.booterclient.
So the issues you found in PropertiesWrapper and SurefireStarter are real, since that's 1.3 code. The others questionable, since we somehow need 1.4 to build I will look at your patch tonight and fix the constructors too.
I don't like the 1.3 situation since it's really not sustainable; 1.3 compatibility was broken in from 2.4.2->2.6 and I restored it in 2.7. I have to run in virtualbox to even test this stuff, since there is no 1.3 available for my platform. But I suppose I've just decided to look at it as a challenge since I never have to deal with this in my day job.