-----BEGIN PGP SIGNED MESSAGE----- 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 me?): > 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 communication 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). Dan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCARMUIv0S4qsbfuQRAkrtAKC5Z3QkDuLlFnvRzhMPO1nvlryhhQCg3KmZ 3uwuu1vHtN41SB14fgm163o= =tPRW -----END PGP SIGNATURE-----
