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.
Thanks,
Dan.
