[Db-derby Wiki] Update of "JavaPackageConventions" by BryanPendleton

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by BryanPendleton:
http://wiki.apache.org/db-derby/JavaPackageConventions

The comment on the change is:
Edited notes from an email from Dan

New page:
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.