Noel J. Bergman wrote:
I was thinking about this some, specifically your JDBC v3 comment. The thing is though, this only gives us the API, not the driver capabilities. For instance, we've been running JDK 1.4 on our prod systems within a few months of when it came out, but the JDBC driver we purchased doesn't have the v3 pooling. Ok, we're cheap and don't want to pay for the upgrade, but this is an enterprise-wide license so it isn't cheap.There are lots of benefits to JDK 1.4.1:- JNDI DNS Service - JDBC v3 - Better networking - java.nio (too bad NBIO isn't more portable; we should look a SEDA, too) - ... We ought to consider whether we are willing to maintain James v2 for JRE 1.3+ and James v3 for JRE 1.4+. Considering that James v2 works well, and James v3 will be a while in development, I have some inclination to suggest that we adopt JRE 1.4+ for James v3. On the other hand, there is always some risk involved in moving raising the JRE required. Thoughts?
Since we have a pooler readily available (DBCP), and I don't know of any other compeling requirement for raising the JRE required. Sure it'd be nice, but that's almost always the case. I think the only reason we even require JDK 1.3 is because of the shutdown-hooks. I'd almost prefer figuring out a way to make that support optional and then support JDK 1.2.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
