tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Einfeldt" <>
Subject AW: Ideas for future versions of Tomcat (a bit controversial maybe)?
Date Mon, 01 Oct 2001 09:21:56 GMT
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 

> -----Urspr√ľngliche Nachricht-----
> Von: chris brown []
> Gesendet: Montag, 1. Oktober 2001 10:54
> An:
> 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

View raw message