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