Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 24 Jul 2006 11:47:10 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Are separate JDBC 4.0 versions of the DataSource classes really
 needed?
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <wjo8bqrfibc1.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (usg-unix-v)

Hi,

I started looking at our implementation of JDBC 4.0 data sources when
I saw Rick updating the documentation with information about using
Embedded*DataSource40 when running jvm>=1.6. I think it is problematic
to have this split between pre-JDBC4 data sources and JDBC4 data
sources for a number of reasons:

  - it is confusing for the users to have thirteen different data
    source implementations (EmbeddedSimpleDataSource,
    EmbeddedDataSource, EmbeddedConnectionPoolDataSource,
    EmbeddedXADataSource, EmbeddedDataSource40,
    EmbeddedConnectionPoolDataSource40, EmbeddedXADataSource40,
    ClientDataSource, ClientConnectionPoolDataSource,
    ClientXADataSource, ClientDataSource40,
    ClientConnectionPoolDataSource40, ClientXADataSource40)

  - it is difficult to maintain and document properly

  - applications that use data sources don't automatically start using
    JDBC 4.0 when upgrading to Derby 10.2

  - how should we name the classes when we start implementing JDBC
    5.0? DataSource40 will be misleading and DataSource50 will only
    increase the confusion (it would give a total of nineteen classes)

For the internal implementation classes, this is not a big problem
since the users don't see their names, but the DataSource classes are
in our published API and therefore visible to our users.

The rationale behind adding new classes for the JDBC 4.0 data sources
was that they contained generic method signatures which wouldn't
compile under jdk<1.6. The problematic method signatures are

  <T> T unwrap(Class<T>)
  <T extends BaseQuery> createQueryObject(Class<T>)
  <T extends BaseQuery> createQueryObject(Class<T>, DataSource)

However, the actual signatures of the compiled methods are

  Object unwrap(Class)
  BaseQuery createQueryObject(Class)
  BaseQuery createQueryObject(Class, DataSource)

I tried to put these methods with modified signatures into
EmbeddedDataSource and removed them from Embedded*DataSource40. To
make it compile, I had to modify the build.xml script to add an empty
java.sql.BaseQuery class to the classpath when compiling
EmbeddedDataSource.

The conclusion from this experiment was: it compiles, it runs under
jvm1.6 (jdbc40 suite passed without errors), and it runs under jvm1.3,
jvm1.4 and jvm1.5.

Does anyone see any serious problems with this approach? Although it's
a dirty hack, I think it is much better than shipping a double set of
data sources.

-- 
Knut Anders