Re: borrowing Constants
On 9/23/2011 8:40 PM, Roedy Green wrote:
If you have some code like this:
class A
{
static String VERSION = "1.0b";
}
and
class B
{
static String VERSION = A.VERSION;
}
When you use Class B, does all of class A get instantiated?
"Instantiated" seems like the wrong word here; there's no
`new' or clone() or deserialization, so no "instantiation" in
the way the word is ordinarily used.
Class A certainly gets looked up, and loaded, and byte-code
verified, and initialized, and so on (my own grasp of all the
steps in preparing a class is rather feeble; I've only needed to
go into detail once, and that rather shallowly). But it's clear
that A must be "prepared" at least as far as running its static
initializers; otherwise, its VERSION would not have a value for
class B to copy. The `final' modifier might or might not make
a difference (that's where my grasp starts to slip).
Does all of class A get put in B's jar?
Who builds the jar?
If so, it suggests you are better off to have a tiny common class and
have A and B reference it.
Possibly, if you think that initializing a "tiny" class is
significantly cheaper than initializing class A. In the example
shown, it doesn't seem likely that a class "tinier" than A could
be of much use. And even if A were considerably bigger, how many
times do you expect to initialize B? (That's not a purely rhetorical
question: Try to estimate an actual number.)
Still, for something like VERSION it seems pretty weird for
class B to declare "My version is, is, well, it's whatever A says.
Although my source code hasn't been touched in three years, A's
never-ending churn of changes somehow makes me different. Or, A
is the placid one that's remained untouched for three years, while
I've changed so much that not a single original source line remains
(even the "class B" line has gained an "implements") -- no matter: A
hasn't changed, so neither have I." Neither stance seems to make
much sense, so you might want to refactor this on design grounds.
--
Eric Sosman
esosman@ieee-dot-org.invalid