Hi Dan,
Thanks for your comments on Narayanan's proposal:
1) You want to trim Derby footprint by not creating unnecessary classes.
2) You want to be able to use package protection across the jdbc
implementations.
I think that (1) is a generally good idea although the code can be
muddled by pressing it too far. In this case I think it makes sense
since you can gather the extension methods into tidy, well-commented
code blocks.
Issue (2) is also compelling.
Cheers,
-Rick
Daniel John Debrunner wrote:
V Narayanan wrote:
1) build a stub foundation into which we can plug additional features
incrementally and in parallel
steps in doing this
b) extend classes in the org.apache.derby.impl.jdbc package
The approach Derby has taken is to only have specific version classes if
there is a real need. E.g. EmbedDatabaseMetaData is a single class
supporting JSR169, JDBC2 and JDBC3. A real need occurs if the JDBC 4
class has new methods that reference new Java types introduced in JDBC4.
A new real need is probably if the method signature has generics.
c) provide implementation for methods in the JDBC4.0 spec that
are not currently present in the JDBC layer of derby.
It's sometime useful to push the methods as far into the parent classes
as possible, thus if a method is introduced in JDBC 4 that does not
reference any new JDBC 4 classes, then it is safe to include it in the
base class or the one for JDBC 2.0 or JDBC 3.0. This is helpful for the
JDBC subsets for J2ME. This is because JSR 169 is a subset of JDBC 3.0
thus needs some of the methods from JDBC 3.0. Assuming a similar
subsetting of JDBC 4 in the future then pushing them up is helpful.
Dan.
