Summary
The other day, I wrote a little testing tool for Java. It’s a simple little thing, just a set of classes that you can use with JUnit to make refactoring a little easier. When I was done, I looked at it and I realized that I’d made a bit of a mistake. I wrote the tool using Java 5.
Advertisement
The other day, I wrote a little testing tool for Java. It’s a simple little thing, just a set of classes that you can use with JUnit to make refactoring a little easier. When I was done, I looked at it and I realized that I’d made a bit of a mistake. I wrote the tool using Java 5.
Sure, using Java 5 made my life easier; I was able to use generics and a couple of other cool features, but it didn’t look like it would make things much better for users. Not everyone is using Java 5. Many of the teams that I visit now are stuck using 1.4.2 and occasionally, I visit some who (gasp, shudder) are using 1.3.1.
So, what did I do? Well, I backported the tool to 1.4.2 and I may yet move it back to 1.3.1.
I’ve done this sort of thing before. Early on, I did a port of JUnit to C++. Immediately, I was inundated with email from people who were stuck using some earlier version of C++ and they each had a laundry list of features that their compiler didn’t support. What did I do? I wrote another testing framework and tried to make it adhere to the earliest widespread standard in C++, the language as it was defined in the Annotated Reference Manual back in 1990.
Now, I did both of these backports nearly reflexively, without thinking about it. I recognize, though, that this is almost exactly the opposite of what many people do when they write tools and frameworks. Often what they do is target their software for the latest version of the language. Sometimes they hang back a little and write to the last version until the newest one takes off, but most of the time, they target the latest and greatest.
Do they do it consciously? I know that they do sometimes. The theory goes like this: “If I use Java 5 or TR1 features in C++ (or whatever); it’s progress. I’ll create a pull that will get more people to upgrade to the latest and greatest version of the language.” That’s fine as far as it goes, but it doesn’t do much for the people who for one reason or another can’t upgrade.
People who believe in the “pull theory” might consider what I’m doing a moral hazard, but for tools which are designed specifically to help people in hard circumstances, I think it’s the right thing to do. Aside from that it’s fun. There’s a weird kick you can get from trying to do something in a reduced subset of a language. It presents some interesting design challenges. Sometimes, you actually end up with simpler software.
If you only need to binary to be usable in Java 1.4.2, you could conceivably use Retrotranslator (http://retrotranslator.sourceforge.net/). Future versions of Java will hopefully strive to support automatic backporting of binary code as part of the release.
If you're writing the tool for the masses then I agree with the approach you took. If however this tool is only for internal use within a company I have used this kind of situation as an excuse to upgrade projects to use Java 5. This can help convince management to allocate time for an upgrade so the tool can be used across different projects which makes my life easier since I'm the one doing the development.
I hear you, but the Java 5 features are a huge leap and people should be agressively encouraged to adopt them. Frankly, generics (templates, thank you very much) should have been in from day 1. Java is so much easier to upgrade on than C++ used to be, there really is no good excuse to go on for years and years without upgrading (yes individually the reason may be good, but collectively, no). At our company, we're stuck with a vendor problem; they took 2 years to upgrade to 1.4. Now we want to go to 1.5 and they have no guidance on when they are targeting that version! That is unacceptable, but it doesn't seem to concern them in the least. Truth is, it just isn't a priority for their marketing department, because they still manage to dump out new feature releases like crazy. Instead of cautioning developers to show restraing, maybe make a little more noise about vendors and IT departments not keeping up to date might help to cure the disease instead of managing the symptoms.
Yeah, and it's precisely for that reason that I backported. One kink in the chain and you have people living with older versions. Actually, it doesn't even take kinks, all it takes is for an application to become a little less vital.. important enough to maintain but not important enough to leap to the next version. I'm not saying I agree with the reasoning, but there are a lot of those applications out there.
The thing is, people forget that every time they version a language, they leave ghettos in their wake.
At the risk of hijacking my own thread, yes, I like the features in Java 5, but to me they are nothing miraculous. The one I like the most is the short form for the for-statement. But, I'm a "less is more" kind of guy.
> If you only need to binary to be usable in Java 1.4.2, you > could conceivably use Retrotranslator > (http://retrotranslator.sourceforge.net/). Future versions > of Java will hopefully strive to support automatic > backporting of binary code as part of the release.