Craig R. McClanahan wrote:
>
>> (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.
>>
>
>That's a good idea, although we'll also have to track any changes as JDK
>1.4 goes through its beta cycle.
>
>I don't have time to work on it -- volunteers?
>
>> (2) Should we provide feedback to the people writing the JDBC 3.0 specs?
>> Perhaps suggest an alternative?
>>
>
>Doing the implementation now will force us to understand what's being
>proposed (instead of waiting for it to be a fait acompli). I need to look
>at it more before knowing what feedback I'd want to give -- there might
>very well be compelling reasons to add methods to the interfaces in spite
>of the impact on all existing JDBC driver and connection pool
>implementations.
To me, this is no different then my attempting to get people who might be
considering adding a dependency on a jakarta-commons package to also track
changes done here.
In fact, I must confess that both of the answers above make me want to hold
the course with JDK 1.4 and send out nightly reminders...
;-)
>> - Sam Ruby
>>
>> P.S. The whole point of Gump is to experimentally use the latest versions
>> of dependencies...
>
>I guess I didn't make it clear -- I wasn't complaining! I just wanted to
>warn people who didn't see your earlier messages about why the failures
>just started occurring.
Just to be clear -- I didn't say that you were complaining! ;-)
>Are you also continuing to run GUMP (in parallel) under 1.3? If not, that
>would still be useful.
I haven't upgraded my Windows machine, that's why I'm confident that these
errors reported are 1.4 specific.
For some projects, I do continue to compile with servletApi (3), and with
others Xalan 1. I've always wanted to be very the JDK level on a project
by project basis (e.g., compile Tomcat 3 with JDK 1.1). Perhaps now is the
time to do so...
- Sam Ruby
