cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Heid <>
Subject AW: JDK 1.3 vs JDK 1.4 issue
Date Wed, 17 Apr 2002 11:12:36 GMT

Here's a proxy solution if I do understand the problem correctly (I
haven't looked into the sources so I may be wrong). 

1. EsqlConnection must NOT implement the java.sql.Connection interface.
But it has to have all methods implemented.
2. Whenever a java.sql.Connection implementation is needed you can use
the following code (1.3 or 1.4 required):

class EsqlConnection {

public java.sqlConnection getConnection () {
   final EsqlConnection con = new EsqlConnection ();
   return (java.sqlConnection) Proxy.newProxyInstance (
             con.getClass ().getClassLoader(),
             new Class[] { java.sql.Connection.class },

             new InnvocationHandler () {
               public Object invoke (Object proxy, Method method,
Object[] args) {
                  // perhaps you have to take care of 1.4 methods if the
method signature has changed
                  return method.invoke (con, args);

-----Urspr√ľngliche Nachricht-----
Von: Carsten Ziegeler [] 
Gesendet: Mittwoch, 17. April 2002 12:20
An: Cocoon-Dev
Betreff: JDK 1.3 vs JDK 1.4 issue

We are struggling a little bit with the differences between the JDK 1.3
and JDK 1.4 with regards to the JDBC interfaces.

We have one class (EsqlConnection) implementing the java.sql.Connection
interface. Unfortunately this interface has changed in JDK 1.4.

This little change forces us to test during compilation(!) of Cocoon
whether we are in a 1.3 or in a 1.4 environment and changing with the
ant build script the source of the EsqlConnection class.

This mechanism works of course but has the great disadvantage that
Cocoon compiled with JDK 1.3 does not work with JDK 1.4 and even worse
Cocoon is not compilable without the ant script!

Now, a hacky solution for this would be that we include the required JDK
1.4 interfaces (java.sql.Connection and three more) in Cocoon only 
for compilation, so we would avoid compile errors.

So, is this
a) a good idea ?
b) allowed     ?

Comments are welcome


To unsubscribe, e-mail:
For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message