Differences between revisions 1 and 2
Revision 1 as of 2006-10-31 17:18:53
Size: 2384
Comment: Edited notes from an email from Dan
Revision 2 as of 2009-09-20 22:12:05
Size: 2384
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

This page explains some of the reasoning behind the Java package conventions that Derby uses.

org.apache.derby.* is currently used for all classes that form the runtime part of Derby, the engine, the network server and the tools.

Other classes that are part of Derby but not part of the runtime are:

org.apache.derbyBuild.*

Classes related to building Derby

org.apache.derbyTesting.*

Classes related to testing Derby

org.apache.derbyDemo.*

Classes related to Derby demos

Such a high level split makes it much easier keep the clean separation between runtime (or "product") classes and others. Prior to being open sourced all of the java code was in one single package hierarchy and one top-level folder. This lead to frequent bugs with extra classes becoming part of the product jars and to test code including engine code.

With the high level split the simple rule is: all classes in the runtime jars must start with 'org.apache.derby.'. If one moves the split down then the test becomes more complicated and thus subject to mistakes. E.g. not o.a.d.demo or o.a.d.testing or o.a.d.build etc.

Then there is the security aspect, currently a Java function or procedure can map to any Java class including those in the runtime code. This is a security problem with Derby, e.g. one can call directly into low level Derby code from SQL thus inheriting the permissions granted to derby.jar, possibly allowing a function/procedure to by-pass grant revoke and have full access to the database files. One way to stop this is to disallow any SQL routine to map to a class that starts with 'org.apache.derby.' and disallow the user code in the routine to resolve classes that start with 'org.apache.derby.'. If one moves non-runtime code into that name space then again the check to ensure the class is allowed or not becomes more complex, the runtime code for example would have to allow routines that map to o.a.d.demo or o.a.d.testing. (Or disallow a specific list, but that runs the risk of the list becoming out of date).

The split also protects us against the small chance of a bug, if the class loading for routines treated the 'org.apache.derby.*' name space specially and thus all the tests work because they use routines in that space (o.a.d.testing for example), but any user routine fails because it is in a separate name space.

JavaPackageConventions (last edited 2009-09-20 22:12:05 by localhost)