That's one of the "against" reasons I thought of. Nevertheless, Tomcat 3 and 4 already exist, so that solution is already available to users of such platforms. Furthermore, Tomcat is not the only Servlet/JSP engine out there, so there are still alternatives for these platforms. I'm not generally for jumping automatically to the latest version of software, but I do think JDK1.4 offers a lot of benefits for server-type applications, and may therefore be worth targetting.
In any case, such developments would probably take quite a lot of time to do well (especially the new I/O architecture), so the stability of the final JDK1.4 release should be well known before any such upgrade of Tomcat becomes available. -Chris ----- Original Message ----- From: "Ralph Einfeldt" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 01, 2001 11:21 AM Subject: AW: Ideas for future versions of Tomcat (a bit controversial maybe)? Technically I like that idea. BUT expierence shows that it is not a good option to jump to early on new JDK for tools like tomcat. >From listening to this list, I've got the feeling that there are several people in the world that don't have the will or the chance to upgrade to the newest JDK. Some use operating systems that are always a bit behind with the JDK (AIX, Mac OS, ...) some deploy to an ISP that won't upgrade that fast). > -----Ursprüngliche Nachricht----- > Von: chris brown [mailto:[EMAIL PROTECTED]] > Gesendet: Montag, 1. Oktober 2001 10:54 > An: [EMAIL PROTECTED] > Betreff: Ideas for future versions of Tomcat (a bit controversial > maybe)? > > > Hello, > > I've been trying out JDK 1.4 quite a lot, and like it a lot! I was > wondering, given that Tomcat is a "reference implementation" of the > Servlet/JSP APIs, if it would be a good idea to become a very > good example > of certain new APIs as well. > > I've suggested a while back that the "New scalable I/O" > channels could be > used to boost performance. Since then, I've seen other > opportunities for > increasing effeciency, simplifying code, etc. For example, instead of > maintaining and downloading APIs for logging, it might be > better to depend > upon the newer logging APIs. The same thing could be said of certain > example applications (such as making Struts use the > java.util.regex package > instead of an external regular expression package -- but > then, that's going > a bit OT as there's a list for Struts too...!). Perhaps also the > configuration could be stored using the preferences API, but > I don't see so > many benefits with a change of this type. > > Obviously, this would limit the accessibility of any such > future version > Tomcat to users of JDK 1.4, but I don't think that's a major > problem in the > majority of deployment situations (I'm guessing here, but I > suspect it's > quite likely to be true). Nevertheless, I think it would be > a good step > forward. > > -Chris > > >
