I haven't looked closely at JDBC 3.0, but I suspect it would be
straightforward to at least define these methods in the pooling wrappers in
DBCP, and have them throw UnsupportedOperationException or something like
that.
It will be a little trickier to make it work with both JDBC 2 and JDBC 3,
since all these wrapper objects do is delegate to the underlying objects.
If the methods aren't defined there, there's not much we can do. I guess we
could add a JDBC 2/JDBC 3 wrapper (much like the SAX1/SAX2 adapters), or use
reflection to make the error happen at run time rather than compile time.
(I'd still love more detail on Gump, by the way. Is there a way I can run
it "locally" either from my own machine or from daedalus?)
-----Original Message-----
From: Sam Ruby [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 01, 2001 11:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [GUMP] Build Failure - dbcp
Craig R. McClanahan wrote:
>
> As Sam warned us, GUMP is experimentally using the JDK 1.4 beta for Linux
> for a while. The failures below are due to some JDBC 3.0 methods that
> were added to some of the javax.sql interfaces -- everything still works
> fine with JDK 1.3.
>
> FWIW, this is why I migrated Struts to mostly using base classes instead
> of interfaces for public APIs -- adding a new method to an interface
> breaks *everybody's* old code.
So the questions are
(1) Is it worth (or even possible?) to add those methods in anticipation of
JDBC 3.0? Such methods might not be called with prior versions of JDBC,
but otherwise are likely harmless.
(2) Should we provide feedback to the people writing the JDBC 3.0 specs?
Perhaps suggest an alternative?
- Sam Ruby
P.S. The whole point of Gump is to experimentally use the latest versions
of dependencies...
