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 21:56:28 GMT
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 current approach. Data can be 
> stored in a shared location, and therefore, we can avoid problems such 
> as use of duplicate values.
> b) It ensures efficient access by allowing modules to continue using 
> constants for such values.
> c) It makes the system more modular, as each module references only 
> those constants that it defines itself - there is no need for a shared 
> interface that defines all constants.
> I don't see any particular disadvantage in taking this approach.

I see a couple:

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 classes, e.g.

   public static final String JMX = "derby.system.jmx";

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.

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 cases it may make sense to move specific classes 
from a central reference area to a more specific are, e.g. jdbc 
constants could move to o.a.d.iapi.jdbc, but doing so is not improving 
the modularity of Derby, it's just a preference of location.


View raw message