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:
[EMAIL PROTECTED]">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 [EMAIL PROTECTED], 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, [EMAIL PROTECTED]< /a> 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).
