You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/04/17 12:19:33 UTC
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
Cheers
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JDK 1.3 vs JDK 1.4 issue
Posted by Berin Loritsch <bl...@apache.org>.
Craig McClanahan wrote:
> 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
Ummm, and the classes output as JDK 1.2 compatible. I made the mistake
of releasing Avalon compiled on JDK 1.4--the class format has
sufficiently changed that at runtime, the classes will not work with
other classes compiled in a prior JDK. By adding the flag to javac
that lets the class files be JDK 1.2 compatible, we had the benefit
of the new JDBC compatibility and the ability to run it with classes
compiled for older JVMs.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JDK 1.3 vs JDK 1.4 issue
Posted by Craig McClanahan <Cr...@sun.com>.
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 jcp@apache.org, 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, jcp@apache.org 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).
>
Re: JDK 1.3 vs JDK 1.4 issue
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
> 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).
Ste, can you remind me about it in (let's say) 3/4 weeks? I'm on the 1.5 EG,
and I can ask, but it still didn't start...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JDK 1.3 vs JDK 1.4 issue
Posted by Stefano Mazzocchi <st...@apache.org>.
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 jcp@apache.org, 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, jcp@apache.org 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).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: JDK 1.3 vs JDK 1.4 issue
Posted by Jörn Heid <he...@fh-heilbronn.de>.
java.lang.reflect.Proxy
-----Ursprüngliche Nachricht-----
Von: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
Gesendet: Mittwoch, 17. April 2002 12:46
An: cocoon-dev@xml.apache.org
Betreff: RE: JDK 1.3 vs JDK 1.4 issue
> -----Original Message-----
> From: Jörn Heid [mailto:heid@fh-heilbronn.de]
> Sent: Wednesday, April 17, 2002 12:35 PM
> To: cocoon-dev@xml.apache.org
> Subject: AW: JDK 1.3 vs JDK 1.4 issue
>
>
> It should be possible to use the proxy api for that I think.
>
What exactly do you mean by proxy api ?
Thanks
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Jörn Heid [mailto:heid@fh-heilbronn.de]
> Sent: Wednesday, April 17, 2002 12:35 PM
> To: cocoon-dev@xml.apache.org
> Subject: AW: JDK 1.3 vs JDK 1.4 issue
>
>
> It should be possible to use the proxy api for that I think.
>
What exactly do you mean by proxy api ?
Thanks
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: JDK 1.3 vs JDK 1.4 issue
Posted by Jörn Heid <he...@fh-heilbronn.de>.
It should be possible to use the proxy api for that I think.
There would be a little performance disadvantage and you need 1.3 or
above but it would work....
-----Ursprüngliche Nachricht-----
Von: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
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
Cheers
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> 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 ?
No - the only disadvantage is that you need the ant build script. It
is not worth to throw in a hackish solution to solve that problem,
as hackish solutions have a tendency to stay.
Long term solution would be to factor out the esql code into a separate
compilation package, much like Stefano's vision for Cocoon blocks. If
more and more features are crammed into the base Cocoon distribution
we will soon have to include all of JDK1.4 or drop JDK1.3
compatibility.
Another option is to have two Cocoon source packages - one for 1.3 and
one for 1.4. (That would be needed/desired for the esql package I
mentioned above, I think.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: JDK 1.3 vs JDK 1.4 issue
Posted by Jörn Heid <he...@fh-heilbronn.de>.
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 [mailto:cziegeler@s-und-n.de]
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
Cheers
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Torsten Curdt <tc...@dff.st>.
> > great we are. still talking about things that already work ;-))
>
> In fact that's much better than talking about things that will
> never work!
...a wise man has spoken ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> On Wed, 17 Apr 2002, Carsten Ziegeler wrote:
> > before we all get too confused with all these tags and
> > /*, // and */...I would suggest you have a look at the
> > latest CVS. I already changed everything (java class
> > and build.xml) and using the build script with jdk1.3
> > and jdk1.4 works for me now.
>
> great we are. still talking about things that already work ;-))
In fact that's much better than talking about things that will
never work!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Torsten Curdt <tc...@dff.st>.
On Wed, 17 Apr 2002, Carsten Ziegeler wrote:
> before we all get too confused with all these tags and
> /*, // and */...I would suggest you have a look at the
> latest CVS. I already changed everything (java class
> and build.xml) and using the build script with jdk1.3
> and jdk1.4 works for me now.
great we are. still talking about things that already work ;-))
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
before we all get too confused with all these tags and
/*, // and */...I would suggest you have a look at the
latest CVS. I already changed everything (java class
and build.xml) and using the build script with jdk1.3
and jdk1.4 works for me now.
Carsten
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, April 17, 2002 3:35 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: JDK 1.3 vs JDK 1.4 issue
>
>
> Torsten Curdt wrote:
>
> <snip/>
>
> > with ant:
> > jdk13:
> > /*
> > JDK 1.4 extra code
> > */
> >
> > COMPILES
> >
> > jdk14:
> > /* */
> > JDK 1.4 extra code
> > /* */
> >
> > COMPILES
> >
> > That's better than it is with *little* changes...
>
>
> Ok. Currently, @JDBC_START@ is "/*" and @JDBC_END@ is "*/".
>
> You would have to change them in the build script && change the fact
> that they are populated by the proper JDK.
>
> That would work.
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JDK 1.3 vs JDK 1.4 issue
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
<snip/>
> with ant:
> jdk13:
> /*
> JDK 1.4 extra code
> */
>
> COMPILES
>
> jdk14:
> /* */
> JDK 1.4 extra code
> /* */
>
> COMPILES
>
> That's better than it is with *little* changes...
Ok. Currently, @JDBC_START@ is "/*" and @JDBC_END@ is "*/".
You would have to change them in the build script && change the fact
that they are populated by the proper JDK.
That would work.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JDK 1.3 vs JDK 1.4 issue
Posted by Torsten Curdt <tc...@dff.st>.
> > /* @JDBC3_START@
> > JDK 1.4 extra code
> > @JDBC3_END@ */
>
> Change that!
>
> // @JDBC3_START@
>
> // @JDBC3_END@
>
> Because if we are not using JDK 1.4, the special tags are changed to:
>
> // /*
>
> // */
>
> Hmm, that might not work.
>
> /* /*
>
> */ */
>
> That will not compile.
>
> If we have JDK 1.4, the tags substitute for nothing, so we don't want
> them commented out all the time.
>
> It's not an easy thing to fix for both ways.....
Did I get something wrong?
Would it be this way:
without ant:
jdk13:
/* @JDBC3_START@
JDK 1.4 extra code
@JDBC3_END@ */
COMPILES
jdk14:
/* @JDBC3_START@
JDK 1.4 extra code
@JDBC3_END@ */
WILL NOT COMPILE
with ant:
jdk13:
/*
JDK 1.4 extra code
*/
COMPILES
jdk14:
/* */
JDK 1.4 extra code
/* */
COMPILES
That's better than it is with *little* changes...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JDK 1.3 vs JDK 1.4 issue
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Torsten Curdt wrote:
>
>>>The main problem I have is that I cannot combile Cocoon without the Ant
>>>script because of the special tags in the EsqlConnection.java.
>>>And this is bad (at least for me).
>>
>>true... if you don't have ant integrated in you IDE this sucks...
>>
>
> Definitly!
>
>
>>so... what to do?
>
> Very good question! I don't want to have two source trees (one for JDK 1.3
> and
> one for JDK 1.4).
>
> I think a quick solution is to change the tags used in the source. What do
> you think of:
>
> /* @JDBC3_START@
> JDK 1.4 extra code
> @JDBC3_END@ */
Change that!
// @JDBC3_START@
// @JDBC3_END@
Because if we are not using JDK 1.4, the special tags are changed to:
// /*
// */
Hmm, that might not work.
/* /*
*/ */
That will not compile.
If we have JDK 1.4, the tags substitute for nothing, so we don't want
them commented out all the time.
It's not an easy thing to fix for both ways.....
>
> - the class is always compilable (with JDK 1.3)
> - ant replaces the tags with "" on JDK 1.3
> - ant replaces the tags with */ and /* on JDK 1.4
>
> Carsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Torsten Curdt <tc...@dff.st>.
On Wed, 17 Apr 2002, Carsten Ziegeler wrote:
>
> Torsten Curdt wrote:
> >
> > > The main problem I have is that I cannot combile Cocoon without the Ant
> > > script because of the special tags in the EsqlConnection.java.
> > > And this is bad (at least for me).
> >
> > true... if you don't have ant integrated in you IDE this sucks...
> >
> Definitly!
>
> > so... what to do?
> Very good question! I don't want to have two source trees (one for JDK 1.3
> and
> one for JDK 1.4).
>
> I think a quick solution is to change the tags used in the source. What do
> you think of:
>
> /* @JDBC3_START@
> JDK 1.4 extra code
> @JDBC3_END@ */
>
> - the class is always compilable (with JDK 1.3)
> - ant replaces the tags with "" on JDK 1.3
> - ant replaces the tags with */ and /* on JDK 1.4
smart :-)...at least this solves the problems when compiling without
ant for jdk 1.3. And it's only a small change (4 chars?) so I don't think
anyone will care about the comment-trick...
I would say: go ahead...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> > The main problem I have is that I cannot combile Cocoon without the Ant
> > script because of the special tags in the EsqlConnection.java.
> > And this is bad (at least for me).
>
> true... if you don't have ant integrated in you IDE this sucks...
>
Definitly!
> so... what to do?
Very good question! I don't want to have two source trees (one for JDK 1.3
and
one for JDK 1.4).
I think a quick solution is to change the tags used in the source. What do
you think of:
/* @JDBC3_START@
JDK 1.4 extra code
@JDBC3_END@ */
- the class is always compilable (with JDK 1.3)
- ant replaces the tags with "" on JDK 1.3
- ant replaces the tags with */ and /* on JDK 1.4
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Torsten Curdt <tc...@dff.st>.
On Wed, 17 Apr 2002, Carsten Ziegeler wrote:
> Torsten Curdt wrote:
> >
> > On Wed, 17 Apr 2002, 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.
> >
> > ...as seen on many POSTs on cocoon-users as well
> >
> > > 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.
> >
> > even worse... ant seems not always to get it right...
> >
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101424515522929&w=2
> >
> > > 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!
> >
> > but is this really a problem? if you want it to run it on jdk 1.4 you need
> > to compile it on jdk 1.4 - as easy as that... as long as our releases work
> > with both jdks we should be fine...
> >
> > as long at it compiles on the very same system it is supposed to run on...
> > or do I see this too pragmatic?
> >
> The main problem I have is that I cannot combile Cocoon without the Ant
> script because of the special tags in the EsqlConnection.java.
> And this is bad (at least for me).
true... if you don't have ant integrated in you IDE this sucks...
so... what to do?
(sometimes I really hate the missing #define and #ifdef ;-)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> On Wed, 17 Apr 2002, 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.
>
> ...as seen on many POSTs on cocoon-users as well
>
> > 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.
>
> even worse... ant seems not always to get it right...
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101424515522929&w=2
>
> > 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!
>
> but is this really a problem? if you want it to run it on jdk 1.4 you need
> to compile it on jdk 1.4 - as easy as that... as long as our releases work
> with both jdks we should be fine...
>
> as long at it compiles on the very same system it is supposed to run on...
> or do I see this too pragmatic?
>
The main problem I have is that I cannot combile Cocoon without the Ant
script because of the special tags in the EsqlConnection.java.
And this is bad (at least for me).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JDK 1.3 vs JDK 1.4 issue
Posted by Torsten Curdt <tc...@dff.st>.
On Wed, 17 Apr 2002, 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.
...as seen on many POSTs on cocoon-users as well
> 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.
even worse... ant seems not always to get it right...
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101424515522929&w=2
> 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!
but is this really a problem? if you want it to run it on jdk 1.4 you need
to compile it on jdk 1.4 - as easy as that... as long as our releases work
with both jdks we should be fine...
as long at it compiles on the very same system it is supposed to run on...
or do I see this too pragmatic?
> 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.
You're sure this works? Anyway it also smells like a LICENCE including
interfaces from the jdk... (don't know for sure though)
:-/
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
>
> Vadim Gritsenko wrote:
> > ...
> >
> > I don't think so. See EsqlConnection:
> >
> > -----------------
> > @JDBC3_START@
> > public void setHoldability(int holdability)
> > throws SQLException
> > {
> > connection.setHoldability(holdability);
> > }
> > -----------------
> >
> > When compiled with JDK1.4, and used on JDK1.3,
connection.setHoldability
> > would not be found and class (EsqlConnection) would not be loaded.
> >
> Why do you think so?
Don't know.
> I thought that as long as setHoldability is not called
> I don't get any problems with this. And it shouldn't be called with
1.3 as
> it does not belong to the Connection interface.
> Or am I wrong here?
No, you are right: unless you call it, you are Ok. We can then produce
release compiled on JDK1.4 and which works with JDK1.3, can we?
Vadim
> Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
> ...
>
> I don't think so. See EsqlConnection:
>
> -----------------
> @JDBC3_START@
> public void setHoldability(int holdability)
> throws SQLException
> {
> connection.setHoldability(holdability);
> }
> -----------------
>
> When compiled with JDK1.4, and used on JDK1.3, connection.setHoldability
> would not be found and class (EsqlConnection) would not be loaded.
>
Why do you think so? I thought that as long as setHoldability is not called
I don't get any problems with this. And it shouldn't be called with 1.3 as
it
does not belong to the Connection interface.
Or am I wrong here?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: JDK 1.3 vs JDK 1.4 issue
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> 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 ?
I don't think so. See EsqlConnection:
-----------------
@JDBC3_START@
public void setHoldability(int holdability)
throws SQLException
{
connection.setHoldability(holdability);
}
-----------------
When compiled with JDK1.4, and used on JDK1.3, connection.setHoldability
would not be found and class (EsqlConnection) would not be loaded.
Vadim
> b) allowed ?
>
> Comments are welcome
>
> Cheers
> Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org