Thread: Adding JDK1.5 removing 1.1 support.
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? 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. This means something like AbstractJdbc2Connection.setTypeMap(Map) would be renamed to something like setTypeMapImpl(Map) and setTypeMap(Map) would be added to Jdbc2Connection and Jdbc3Connection while Jdbc3gConnection would have setTypeMap(Map<String, Class<?>>) that would all just call setTypeMapImpl. Does this make sense to people? Kris Jurka
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). > 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. That works. -O
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
Kris Jurka wrote: > 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 have to admit I haven't looked too hard at this area, but I don't understand why we need versioned implementations of DataSource at all. Don't they all end up delegating to the Driver to create the connection anyway? I couldn't see anything in the JDBC3 implementations that seems JDBC3-specific.. We currently use the jdbc2.optional datasource implementations under a 1.4 JDK, for historical reasons more than anything. But it appears to work fine. -O
On Fri, 16 Jul 2004, Oliver Jowett wrote: > I have to admit I haven't looked too hard at this area, but I don't > understand why we need versioned implementations of DataSource at all. > Don't they all end up delegating to the Driver to create the connection > anyway? I couldn't see anything in the JDBC3 implementations that seems > JDBC3-specific.. There's really nothing in the JDBC3 implementations. Personally I don't know why we have them at all. The problem is that the 1.5 JDK has changed the API for ObjectFactory which means that PGObjectFactory and Jdbc3ObjectFactory cannot be compiled at the moment. It looks like adding a Jdbc3gObjectFactory can't be done without also adding 3g versions of the other classes and also making some Abstract classes to house the implementation. Forcing the user to select which implementation to use just seems klunky especially if they aren't really different. Kris Jurka
Kris Jurka wrote: > The problem is that the 1.5 JDK has changed > the API for ObjectFactory which means that PGObjectFactory and > Jdbc3ObjectFactory cannot be compiled at the moment. Aha, I see. generics strike again. We could deal with the non-pooling datasources by no longer implementing Referenceable and relying on serialization to preserve state. Then we do not need an ObjectFactory at all. For pooling DataSources (I mean jdbc2.optional.PoolingDataSource, not jdbc2.optional.ConnectionPool -- those are badly named!) we could implement readResolve()/writeReplace() to translate to/from a lookup handle into the registry of known pools when serialized. But that gets a bit hairy. It's probably simpler to just do conditional compilation of the signature of PGObjectFactory.getObjectInstance() if we want to support the pooling DataSources. I'm actually tempted to drop the pooling DataSource implementations altogther. Does anyone on the list actually use these? I think the more common approach is for a higher layer to use our ConnectionPoolDataSource implementation (or plain DataSource, even) plus their own pooling logic.. -O
On Fri, 16 Jul 2004, Oliver Jowett wrote:
> I'm actually tempted to drop the pooling DataSource implementations
> altogther. Does anyone on the list actually use these? I think the more
> common approach is for a higher layer to use our
> ConnectionPoolDataSource implementation (or plain DataSource, even) plus
> their own pooling logic..
The spec seems to have been originally written so that any
middleware should use ConnectionPoolDataSource. In practice, that seems
pretty rare -- every app server I've worked with uses an XADataSource or
DriverManager. On the other hand, most end users don't seem to know what
to make of a ConnectionPoolDataSource, since it's neither a DataSource nor
a Connection, and they don't want to implement their own pooling logic.
So if we were to drop support for anything but ConnectionPoolDataSource,
then I'm not sure that anyone would really use this stuff at all!
That said, it's hardly a scientific opinion, and I would also be
interested to hear if anyone speaks up and indicates that they're using
ConnectionPoolDataSource.
Aaron
Oliver Jowett wrote: > I'm actually tempted to drop the pooling DataSource implementations > altogther. Does anyone on the list actually use these? I think the > more common approach is for a higher layer to use our > ConnectionPoolDataSource implementation (or plain DataSource, even) > plus their own pooling logic.. I certainly do use Jdbc3PoolingDataSource, and would hate to see it go away. -- www.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation