On Fri, 16 Jul 2004, Oliver Jowett wrote:
> Kris Jurka wrote:
> > The new V3 protocol code has removed support for compiling with a 1.1 JDK,
> > but we still have the core implementation split between jdbc1 and jdbc2
> > classes. Should be combine these all into jdbc2 or is there a reason to
> > keep these separate?
>
> That sounds reasonable unless there's some reason you'd want to run
> JDK1.2 + JDBC1 (I can't think of one).
Well, you can't. Previously you could run a JDBC1 build under a higher
JDK, but now we don't have the ability to compile a JDBC1 build. I've
made this change to the source tree.
>
> > To add JDK1.5 support I originally considered an ant conditional
> > compilation method, but that was really ugly. Another idea I have is to
> > create a jdbc3g subdirectory (JDBC3 w/ Generics) that wouldn't house any
> > implementation (AbstractJdbc3g* classes), but would just have the classes
> > to offer the API desired by the 1.5 JDK.
>
I've done this for the core driver, but I'm kind of stuck on how to get
this to work for the various DataSource implementations. These don't
have the same multi-version architecture and users are required to
know what JDK they are dealing with in their configuration. I don't
think I want to implement jdbc3g versions of these and have to document
when that is available and so on. I'm thinking this needs to be
redesigned to work in a general way where the correct implementation class
is selected for the user instead of requiring them to specify it directly.
This has the possibility of renaming some classes which would prevent
directly dropping a new jar file into an existing deployment without
changing some configurations, but I'm OK with that if I can get it to
work.
Kris Jurka