db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Reducing module dependencies
Date Mon, 11 Feb 2008 04:59:33 GMT
Dibyendu Majumdar wrote:

> While most of the Derby code is well-behaved with respect to the rules 
> above, there are occasions when the inter-module dependencies appear 
> unsatisfactory. Here is a sample:
> 1) The org.apache.derby.iapi.reference package contains constants that 
> go across the boundaries of the layers. I can see the rationale behind 
> having a central location for reference data, but would it be better 
> from a modularity perspective, for each of the layers to have its own 
> reference data?

Not sure, it might make sense for some but not for others. One of the 
reasons for the central location was an easy way to sure that these 
reference classes were not included in the jar files. Since they are 
only intended to hold constants seeing if the jars included the 
reference package was a way to tell something wrong was going on.

> 2) A somewhat similar but different issue is that all the Stored Format 
> Ids of all objects, regardless of layer, module, etc., is stored in 
> org.apache.derby.iapi.services.io.StoredFormatIds. In this case, it is 
> probably better to externalize this information and load it at system 
> startup.    

Not sure what you mean here, these are just constants so not sure what 
it means to load it at system startup. One issue with distributing 
information is ensuring that different modules do not define identical 
values in the same space. That's really the purpose of StoredFormatIds 
(and some similarly shared classes), to ensure a single allocation for 
each value.

> I would like to submit patches to fix some of these and similar issues, 
> but before doing so, would like to know if there are any violent 
> objections to the general module interaction principles stated above.

I think it's going to be on a case by case basis. In general it sounds 
like a good idea, but it's good to state the advantages of what you are 
proposing and be open about any disadvantages.


View raw message