Costin Manolache wrote:
Shapira, Yoav wrote:
It depends how you define support, right? Does "support" mean by default everything is configured for JDK 1.3, and Tomcat is built with target="1.3" ? Or does it means there's an easy way to set this target parameter (e.g. a build.properties setting) and build your own Tomcat for 1.3?
What is the cost of having "target=1.3" by default ? It means the class
files and the release will work with jdk1.3 - and it will also run on 1.4 or 1.5.
What is the benefit of having target=1.4 and forcing people who use 1.3 to recompile the entire tomcat ?
Despite my own feeling that 1.3 has gone the way of the dodo bird, this is a good question. The only thing I know of offhand is that 1.4 gives you assert().
Stability versus featurism is much more of a judgment call IMHO. Does stability mean we stick with an old platform (JDK 1.3) and jump through hoops (e.g. runtime detection) to use newer (JDK 1.4, JDK 1.5) features? If so, then at what point does the cost (e.g. performance) become higher than the benefit (ease of use for old platform users)? It's a subjective call I think.
That's a question for Sun :-), who is forcing people to jump through the hoops by bundling all features with the VM.
Most of the features that are interesting in 1.5 have to be to be done right...
Tomcat core already works with 1.3 - and you can have optional connectors/valves/etc that only work with 1.5 or 1.6 - with just a simple conditional compilation.
I understand why MSFT is forcing people to upgrade windows - they make a lot of money from that, and don't care how much the users will suffer to upgrade. But we don't gain that much by forcing people to upgrade the VM to use the latest version of tomcat. I wish Sun would sell and make money on the VM - so at least someone would gets some benefit from this forced upgrade cycle :-)
The reasons to force upgrades are:
1. Ability to fully leverage compelling runtime features for end-user
benefit (e.g. in the case of 1.5, better concurrency utilities,
built-in JMX, etc; in the case of 1.4 this might possibly include
NIO stuff for loading static files or some such)
2. Ability to use compelling development features (e.g. generics in
the case of dropping releases prior to 1.5, improved/easier-to-use
APIs in cases, etc)
3. Narrower platform mix to mess with supporting / answering
questions on, etc.-- Jess Holle
