Hi, Wolfgang,
If all free java sdks implement jdbc3, I don't see any real reason to
provide jdbc2 builds at all. AFAIK, JDBC standards are meant to be
compatible for older clients, so every jdbc2 app should work fine
against jdbc3 implementations.
Alternatively, what do you think about having a
Hi, Wolfgang,
Wolfgang Baer schrieb:
I had success with using gcj-3.4 as it's based on an older gnu classpath
release. Maybe try against gcj-3.3 or gcj-3.4 - don't know at which
JDBC level they are. Give them a try :-)
At least gij-3.3 fails to build with libant1.6 for me because it cannot
On Wed, Mar 30, 2005 at 06:41:44PM +0200, Markus Schaber wrote:
So I'm afraid that it does not build using gij.
gcj 3.3 and 3.4 are super-old and known to fail. 4.0 just works.
Michael
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the
Hi, Michael,
Michael Koch schrieb:
So I'm afraid that it does not build using gij.
gcj 3.3 and 3.4 are super-old and known to fail. 4.0 just works.
I know. I just tried them as Wolfgang Baer suggested because I wanted to
find a JDBC2 JDK.
Markus
--
Der Trick ist, die Grate zwischen den eigenen
Hi,
I now can successfully build it using libant1.6, kaffe and jikes, using
an additional small source patch. I can build with and without SSL, but
I can only build the jdbc3 version.
Building the JDBC version (forced with -D switches) fails due to not
implemented abstract methods.
What's the
Hi Markus,
Markus Schaber wrote:
Hi,
I now can successfully build it using libant1.6, kaffe and jikes, using
an additional small source patch. I can build with and without SSL, but
I can only build the jdbc3 version.
Building the JDBC version (forced with -D switches) fails due to not
implemented
6 matches
Mail list logo
