If DBCP is compiled with JDK 1.3 then some methods are commented out because they are only in the JDBC3 spec (included in JDK1.4). So then we need 2 releases.

To trigger the dbcp incompatibility I has to set the defaultReadOnly property. The class with the JDK1.4 method call was loaded normally in a tomcat running with JDK1.3 and worked fine as long as you don't use the offending method.

DBCP 1.1 was also compiled with JDK1.4 so I think we're safe for now.

I don't follow the f(T) thing.
But as I only use JDK1.4 in my development & production systems, I feel more at ease with a JDK1.4 build.


But more cooperation/integration testing would be nice. Does the James or tomcat group do a JDK1.3 compatibility check?

-- Dirk

Noel J. Bergman wrote:

Was there anything similar in Pool?  And can we compile the
release packages with JDK 1.3?


I tested Pool 1.2 and it can be compiled with JDK 1.3.1_01.
So that one should be OK.


Ideally, all Commons release packages would be compiled with JDK 1.3, not
1.4.  The problem with compiling with 1.4 is that it is possible, although I
don't know if we have any of these collisions, to run into:

  JDK 1.3: f(T)
  JDK 1.4: f(DerivedT)
   Client: f(DerivedT)

which results in code that compiles fine with both JDK 1.3 and JDK 1.4, but
is NOT binary compatible if compiled with JDK 1.4.  Do you know if we have
any such issues?

        --- Noel






--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to