cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: JDK 1.3 vs JDK 1.4 issue
Date Thu, 18 Apr 2002 16:43:24 GMT
As Sam points out, the incompatibility in the JDBC APIs was raised 
during 1.4 development, but fell on deaf ears at the time.

For a technical workaround, you might want to take a look at the kludge 
adopted by the DBCP package in jakarta-commons -- in essence, we 
simulated an #ifdef/#endif structure by using Ant filtering to remove 
some comment markers on a 1.4 system, but left the new methods commented 
out otherwise.  In testing so far, it appears that you still get 
portability both directions if you're not using the new methods. 
 However, you'd want to make sure that release builds of Cocoon are 
compiled with 1.4.

Craig McClanahan

Stefano Mazzocchi wrote:

>Carsten Ziegeler wrote:
>>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     ?
>The fact that Cocoon isn't compilable without the ant script doesn't
>bother me at all. You could state the same for almost any serious java
>product out there and all modern java IDEs have support for Ant, so this
>is not a real concern (IMO).
>The fact that a Cocoon compiled under 1.3 doesn't work on 1.4 and
>viceversa breaks WORA and it's, IMO, a shame but it's definately not our
>fault. I wonder what they smoked in the JSR that came out with this.
>Anyway, in the past we were not allowed to ship any of the java.* or
>javax.* classes (I'm copying the, so please confirm
>here), unless explicitly agreed with Sun (we do it for javax.servlet.*
>and javax.xml.* but that's it).
>How the new JSR licensing will impact this is not something I know
>(again, please chime in)..
>So, legally, I can't say this is allowed or not, nor I can say this will
>be in the future.
>About the 'good idea', I honestly don't know, but for sure, the ultimate
>goal is to resort Cocoon WORA back to its splendor.
>The idea of using a Proxy is something that we could think about, but I
>have no idea on how this would impact WORA and/or performance.
>We could also have our representatives for Java 1.5 ask the reasons why
>the JDBC were modified in a back incompatible way and what is the
>solution they thought (if any) about allowing WORA between java versions
>(if they thought about it at all for JDBC).

View raw message