«

On 24/09/2011 02:40, Roedy Green allegedly 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?
> Does all of class A get put in B's jar?
>
>
> If so, it suggests you are better off to have a tiny common class and
> have A and B reference it.

If someone showed me that code (class B) and told me they didn't intend
to include class A in the runtime, my first question would be: "then why
do you reference it?"

If you want to decouple, decouple properly. Use a common class, a
resource file, a service provider interface, whatever. But don't rely on
intrinsics -- even if in this case those are fairly basic and
well-understood intrinsics. That's just begging for trouble.

--
DF.
Determinism trumps correctness.

On 9/24/2011 8:09 PM, Roedy Green wrote:
> On Fri, 23 Sep 2011 17:40:20 -0700, Roedy Green
> <> wrote, quoted or indirectly quoted
> someone who said :
>
>> class A
>> {
>> static String VERSION = "1.0b";
>> }
>>
>> and
>> class B
>> {
>> static String VERSION = A.VERSION;
>> }
>
> restating, if the expression for A.VERSION cannot be evaluated an
> compile time, even final won't rescue you from having to include both
> A in your jar and indirectly loading A when you load B.
>
> So the rule of thumb use static final with values known at compile
> time to avoid needless class loading. But be aware, you must recompile
> B if the value of A.VERSION changes, or you will get the old value.
>
> Another rule of thumb may be, instead of cross linking classes with
> references to each others constants, refactor out the constants to a
> third class, and reference it or extend it.
>
> In a number of my projects I have a Config class where everything
> constant (possibly computed) needed to configure a program for a
> particular use are collected.

Rule of thumb: don't worry about the microseconds spend on class
initialization and spend the time on something relevant.

The requirement to recompile B if A is changed for constants
can be a much more severe problem than class init.

Arne

On 9/24/2011 9:18 PM, markspace wrote:
> On 9/24/2011 5:09 PM, Roedy Green wrote:
>> Another rule of thumb may be, instead of cross linking classes with
>> references to each others constants, refactor out the constants to a
>> third class, and reference it
>
> Generally, no. It's been tried, and found to not work well. A class full
> of unrelated constants is just that: a class full of unrelated
> constants. Put the constants where they belong.

That is very basic good design.

Arne