Hi,
As part of my investigation for DERBY-3351 I am looking at the ways
in which modules interact with each other.
From an overall layered architecture viewpoint, I feel that the
rules should be that:
Services layer should not have a dependency on or knowledge of any of
the higher layer
Dibyendu Majumdar wrote:
2) Such constants would probably no-longer be in-lined by the java
compiler, leading to potentially slower code as a field lookup is needed.
Not sure about this, as a final value should be in-lined regardless of
how it is initialized. But this can be tested, I suppose
On 11 Feb 2008, at 21:56, Daniel John Debrunner wrote:
1) To me this seems to be making something simple much more complex
for no real benefit. It's good if open source code is easy to
understand and follows existing practices. Java defines constants
as static final fields in interfaces or
Dibyendu Majumdar wrote:
Modules that need to have their own set of "constants", can initialize
them as follows:
static final String A_CONSTANT = Component.get("namespace", "my.key");
The advantage of this approach over the current approach is that:
a) It maintains all the objectives of the
On 11 Feb 2008, at 04:59, Daniel John Debrunner wrote:
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 exter
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 boundari
Dibyendu Majumdar wrote:
On 11 Feb 2008, at 21:56, Daniel John Debrunner wrote:
I guess I don't quite see what the issue is with a "shared interface
that defines all [related] constants." These are compile time only
artifacts as they only contain literal constants.
I agree that in some cas
On 12 Feb 2008, at 05:45, Daniel John Debrunner wrote:
Not much, but I don't think any scheme will stop that. If the coder
thought that the function was appropriate then they will code it no
matter what. If the constant they need is not available (e.g. not
public), then they will simply m
