Package layout reasoning. WAS Re: [jira] Commented: (DERBY-1993) Check in the demo used by the Java in the Database session at Apachecon 2006

[Daniel John Debrunner <dj...@apache.org>]

Bryan Pendleton wrote:
>>    org.apache.derbyDemo
>>
>> rather than org.apache.derby.demo.
> 
> I'm not quite following why one of these is better than
> the other. Can you explain in more detail?

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

My belief is 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. 
I believe 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).

Then 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.

Hope this was clear,
Dan.