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.
