V Narayanan wrote: > Queries > ------- > > 1) we observed that in the current build we have support for > JDBC2.0 and JDBC3.0 within the same package viz. > org.apache.derby.impl.jdbc (e.g EmbedPreparedStatement30 extends > EmbedPreparedStatement20 inside the same package). > > we had decided on a seperate package because we thought this would > result in a cleaner build. would this be the best approach or should it >> be part of the same package?
Derby (as Cloudscape) used to have the different jdbc drivers in different packages. The trouble with this approach is that is begins to force implementation classes and methods to be public, so they can be called from all drivers. Since these classes are returned to applications, these methods can then be called by applications, potentially leading to security issues. Keeping the classes in the same package allows the members to be package protected which are a lot easier to be protect from malicious use. I'm not saying Derby's perfect in this area now, in fact I'm spending some time looking at these issues. So I would recommend continuing the use of a single package, unless there's a good reason for a separate one. The build system handles separate builds in the same package, so that's not an issue. Dan.
