Rick Hillegas <[EMAIL PROTECTED]> writes: > Hi Knut Anders, > > I don't understand part of your experiment. The implementation of > createQueryObject() refers to another class, QueryObjectFactory, which > was introduced by JDK 1.6. How did EmbeddedDataSource compile with > this reference?
We need to use reflection either in createQueryObject() or at class load time. For instance, we could have a static initializer in EmbeddedDataSource which sets a static field to an instance of a helper class. We could have two versions of the helper class, one for pre-jdbc4 and one for jdbc4. The pre-jdbc4 version has a createQueryObject() method that returns null, and the jdbc4 version invokes QueryObjectFactory.createQueryObject(). There is however one problem with my approach. The jdbc40 tests run just fine because they are written against the DataSource interface, but applications that use EmbeddedDataSource directly might get problems at compile time. This works fine DataSource ds = getDataSourceFromSomewhere(); MyQuery mq = ds.createQueryObject(MyQuery.class); but this won't compile EmbeddedDataSource eds = (EmbeddedDataSource) getDataSourceFromSomewhere(); MyQuery mq = eds.createQueryObject(MyQuery.class); because the return type of EmbeddedDataSource.createQueryObject() is BaseQuery, not <T extends BaseQuery>. It must be rewritten to MyQuery mq = (MyQuery) eds.createQueryObject(MyQuery.class); or MyQuery mq = ((DataSource) eds).createQueryObject(MyQuery.class); Since we can't expect applications to access the EmbeddedDataSource objects through the DataSource interface, I guess my approach falls apart. But it was worth a try... Unless someone knows how to manipulate method signatures when a class is loaded, or how to make a constructor return a subtype, I think we are stuck with the current solution. -- Knut Anders
