db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: code organization
Date Wed, 02 Feb 2005 17:51:16 GMT
Hash: SHA1

shahbaz chaudhary wrote:

> I'm curious to hear some thoughts on code organization from the experts
> here.  While looking at the code, the following issues seemd interesting:
> 1. Some of the terms used are not immediately obvious (perhaps just to
> DRDA (network code?), IAPI (interface api?), (vtit...?), noputresultset
> (NoPut ?)

A glossary sounds like a good idea.

drda is a open standard, Distributed Relational Database Architecture,
the network server and jcc client are based upon that protocol for
iapi is internal api, as opposed to external or public api which is for
application use.
vti is Virtual Table Interface

> 2. Is it necessary to keep implementation and interfaces in completely
> seperate packages (impl | iapi)...since implementation packages contain
> abstract classes?  What about simply refactoring interface files and
> adding an 'I' in front to distinguish...many implementation classes
> already have *Impl* in their name.  Basically this will reduce the
> number of directories and packages one has to traverse to find the right
> set of code files.

I'll explain the reasoning behind it. The idea was to enforce a strict
split between the internal api (iapi) and any implementations (impl).
The split at the high level allows easy visual feedback of if an
incorrect dependency exists on an implementation by looking for
org.apache.derby.impl imports. In addition an internal api package or
module may be implemented in multiple ways, some of these might be very
different to each other. Thus putting all the implementations and the
internal api in a single package might be more confusing than keeping
them separate, and potentially increasing the chance of independent
implementations accidentally becoming dependent on each other, or the
implementations bleeding into the api.
The abstract classes in the implementation side tend to be to support
implementation variants within a common base, not as part of any api. An
alternate implementation is not required to use those abstract classes.

Does the current directory structure cause problems with IDEs such as
Eclipse or Netbeans, don't their indexing and search mechanisms mean
that a developer doesn't have to traverse trees?

> 3. If I remember correctly, org.apache.derby.*.sql package has around
> 500 files, ...sql.execute has about 150 files.  Could this be broken out
> more?  For example, couldn't the various CursorResultSet derivitives
> have their own package...so even a quick look at just packages gives an
> overview of the architecture?

One of the issues with breaking out implementation packages is that it
tends to increase the number of public methods, this I think is bad for
a couple of reasons. One that the domain search for use of that method
increases to the complete code tree, the other is general security
concerns, public methods can be called from anywhere, so how does that
affect security.
An example is the impl.jdbc package, sometime before the product was
open-sourced it used to be three packages, jdbc12, jdbc20 and jdbc30
with various public methods that allowed jdbc20 and jdbc30 classes to
access key internal methods in the base classes. Since these public
methods on are classes that are directly handed back to applications (as
java.sql.* objects) there is a chance that some code will use reflection
to find the additional public methods and then call them, possibly
gaining access to objects that should not be accessed. Maybe this isn't
a concern because this is only true in embedded mode and the ability to
install malicious code is blocked elsewhere (or its your own machine!).

Instead of moving code around to an alternate convention (I_/Impl class
name tags iapi/impl packages) that as you say gains no functional value,
I would prefer to see activity around reducing footprint by removing the
iapi/impl split and merging classes in *some* situations. I think we
went a little too far on some of the splits, and so maybe could some of
them be merged back to a single concrete implementation that is the
internal api. It would be worth working out which abstract classes and
interfaces only have a single implementation, and then discuss on the
list if that code is suitable for compacting. An example is the type
system, will there every be a separate type system, most unlikely,
though some isolation is required. The lack of BigDecimal in J2ME and
the changes in BigDecimal in J2SE 5.0 so there needs to be some
separation of api and implementation. But maybe the root of the type
system (interface) DataValueDescriptor should be replaced by the
abstract class that all types are based upon (DataType with renaming as
it's not a type but a value).

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message