Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > borrowing Constants

Reply
Thread Tools

borrowing Constants

 
 
Roedy Green
Guest
Posts: n/a
 
      09-24-2011
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.
--
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      09-24-2011
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?


I don't think it can just initialize what is needed.

The overhead must be microscopic anyway.

> Does all of class A get put in B's jar?


That depends on the one doing the "putting".

> If so, it suggests you are better off to have a tiny common class and
> have A and B reference it.


You should stick to good design and keep the versions where they
logical belong.

Arne

 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      09-24-2011
On 11-09-23 09:44 PM, Arne Vajh°j wrote:
> 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?

>
> I don't think it can just initialize what is needed.
>
> The overhead must be microscopic anyway.
>
>> Does all of class A get put in B's jar?

>
> That depends on the one doing the "putting".
>
>> If so, it suggests you are better off to have a tiny common class and
>> have A and B reference it.

>
> You should stick to good design and keep the versions where they
> logical belong.
>
> Arne
>

Which logical place is not in the code at all. Granted, I don't know
that Roedy's example is doing anything more than using "VERSION" as a
generic variable name (I hope).

I'm not going to be unyielding on this, but I have personally never
encountered or read of any situation where source code needed to be
annotated with configuration or version control information. This
includes the RCS-style keywords; the argument is that these help if a
file is exported outside the development environment, but that's not a
compelling argument for me.

AHS

--
Romper, bomper, stomper boo. Tell me, tell me, tell me, do. Magic
Mirror, tell me today, have all my friends had fun at play?
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      09-24-2011
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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-24-2011
On Fri, 23 Sep 2011 22:10:28 -0300, Arved Sandstrom
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>Which logical place is not in the code at all. Granted, I don't know
>that Roedy's example is doing anything more than using "VERSION" as a
>generic variable name (I hope).


I chose it as an easy-to-understand example. In my example, VERSION
is something you might display in a an About box.

The question is really about accidentally dragging in some giant class
when you had no intention of using its code.
--
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-24-2011
On Fri, 23 Sep 2011 21:15:20 -0400, Eric Sosman
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

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


At the JVM level there is. When you first use a class, e.g. reference
a static variable of that class or invoke a static method, a class
object is allocated for that class (1 per class per classloader). This
has nothing to do with instatiating new objects of that class.

Since this is not something that normally concerns application
programmers, I don't know if there is official terminology for it.

--
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      09-24-2011
On 9/23/2011 5:40 PM, Roedy Green wrote:

> When you use Class B, does all of class A get instantiated?
> Does all of class A get put in B's jar?



I think so, yes. Not "instantiated" as others pointed out but
initialized. But yes, regardless.

I believe you can get around this by making VERSION final. The compiler
is allowed (possibly required?) to copy final static values as a kind of
constant, in order to avoid this kind of unneeded initialization.

class A
{
static final String VERSION = "1.0b";
}
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      09-24-2011
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?


Strictly speaking, and I am fairly sure you don't mean this, a class with only static members might never, or cannot ever be instantiated (depending on the use of certain idioms).

As you know, I favor exactitude, some think colo-rectitude in certain terminologies. It cuts both ways - I have to relearn terms when I have them wrong.

That aside, you no doubt refer to the evil twin processes of class loading and class initialization.

Without going all lawyerly, let's just note that there is a precise order of those stages and rather ornate rules to them.

Which all boil down to that you get a class all or nothing.

So yes, you will need the entire class in both the build and runtime paths of its clients.

> Does all of class A get put in B's jar?


Short answer: Yes, it would have to. Classes are loaded in what the Java Language Specification (JLS) calls "compilation units". For this question, the key word is "unit".

Under certain circumstances you get more than one class at a time from the same compilation unit. These come all or nothing all together or not at all.

> If so, it suggests you are better off to have a tiny common class and
> have A and B reference it.


That's debatable for certain scenarios, but yes, absolutely it would suggest that otherwise.

The niggle is that such a rule shouldn't be too restrictive. Placement of members flows from architecture and design. You get a few utility classes, sure, but don't overdo it. Things belong where they belong.

--
Lew
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      09-24-2011
On 9/23/2011 9:39 PM, Roedy Green wrote:
> The question is really about accidentally dragging in some giant class
> when you had no intention of using its code.


Can you provide an example where it is even measurable to load a
single class (with only simple initialization of fields)?

Arne
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      09-24-2011
markspace wrote:
> Roedy Green wrote:
>> When you use Class B, does all of class A get instantiated?
>> Does all of class A get put in B's jar?

>
> I think so, yes. Not "instantiated" as others pointed out but
> initialized. But yes, regardless.
>
> I believe you can get around this by making VERSION final. The compiler
> is allowed (possibly required?) to copy final static values as a kind of
> constant, in order to avoid this kind of unneeded initialization.
>
> class A
> {
> static final String VERSION = "1.0b";
> }


You are correct. That has an interesting side effect on builds. Clients of class 'A', above:

class B
{
static final String FOO_VERSION = "Foo-" + A.VERSION;
}

can use the compile-time constant (there are rules for that) to build its own compile-time constant.

But B's view of 'A.VERSION' doesn't necessarily change when 'A' changes it.Constants are baked into the class file, so until 'B' recompiles, it willload the old version of 'A.VERSION' at runtime. Other classes in the application might see the change at different builds, depending on when they were last recompiled and which copies of which ".class" files were in the waywhen they compiled.

One can be surprised by this behavior. Cargo cults preach "rebuild the world" as the only true preventative. For any reasonably-organized project it's good advice.

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Making C better (by borrowing from C++) Masood C Programming 247 01-14-2008 05:42 AM
Borrowing a PC? Put Linux on it, via a USB drive Au79 Computer Support 0 08-01-2006 05:53 AM
Making C better (by borrowing from C++) masood.iqbal@lycos.com C Programming 86 02-28-2005 07:04 AM
TIME borrowing in synthesis whizkid VHDL 1 11-02-2004 03:39 PM
Borrowing someone else's XP disc - some questions Gary Glencross Computer Information 4 03-05-2004 03:48 AM



Advertisments