On 12 May 2005, at 16:49, Matthew D. Fleming wrote:
We use WAS 4.0 and Castor which uses a 1.2 JDK. We can't upgrade the app server for a variety of reasons in any short period of time. I vote for some form of conditional compilation.
I'd like to make a point, here.
- Conditional compilation means building more than one implementation, or at minimum, keeping around a weaker one.
- This takes time, effort, and someone to care.
- This takes resources.
It's time people started to think about whether the cry for progress, performance, and new features is louder than the cry for absolute backwards compatibility and support for what can only be described as historical platforms.
I'm not saying no - I'm saying that 1.2 doesn't come free. Bugs *will* begin to exist which only exist in certain environments, for example, the moment conditional code begins to take effect. Coverage will be harder; testing will be harder; etc.
Personally? Jettison everything but 1.5, that's my opinion. But I'm an extreme case; and I fully expect that to be an unreasonable statement. In my guts, though, I'm of the opinion that there's an awful lot of improvements, even in 1.3, and building backwards- compatible implementations just can't be the best use of developer time. I ask that people seriously and sincerely consider whether they should expect that the product should always support 1.2.
IMO? You're free to keep using historical versions; but sooner or later, real functionality is going to be tied to later JDKs. I'm not sure conditional compilation is going to fix the fact that once things really start kicking into gear, some features just aren't going to *exist* on the older JDKs - so why pretend. Lock your version until you can upgrade your JDK.
OTOH, some people are loathe to change production environments, or haven't the ability to do so in the managed environment they operate; they want to continue to build modern, supported applications on what is quickly becoming an antiquated platform, and that's their perrogative - and as such, perhaps if the framework is in place, developers who care about backwards compatibility can step in and provide high-performance options for those running old JDKs. But I *am* fundamentally against large amounts of developer time, should it come to this, spent to ensure 1.2 compatibility instead of improving features and performance for the rest of the modern universe not locked into age-old editions of the JDK. It has a crappy garbage collector, poor threading performance and management, etc. IMO, if we were using 1.4, we could have an even better implementation of some of the stuff going into the next TransactionManager patch, instead of having to build our own identity hashmap implementations or nick those implementations from others. And if we *do* keep 1.2, we need to, in turn, relax our restrictions on which external libraries can be used, so that we can start including libraries which provide the same functionality for JDK1.2 users that exist under 1.4/1.5 environments - to do anything else is to demand mirroring JDK functionality via wheel-reinvention instead of using someone else's already purpose-built wheel for 1.2-1.x environments, for those who have already run into the problem.
So something will have to give, in the long term. Either support for 1.2 will go, or this project will start having to use more and more external libraries to supply the functionality which is missing. There's a reason that the Jakarta projects are as incestuous as they are, and one of those reasons is the 1.2-compatible label peppered all over them.
And I apologise for the rant. Too much to do, too little time spent with castor as it is - I just don't want that time to be stretched even thinner. :/
