Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8253

Re: borrowing Constants

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

borrowing Constants Roedy Green <see_website@mindprod.com.invalid> - 2011-09-23 17:40 -0700
  Re: borrowing Constants Arne Vajhøj <arne@vajhoej.dk> - 2011-09-23 20:44 -0400
    Re: borrowing Constants Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-23 22:10 -0300
      Re: borrowing Constants Roedy Green <see_website@mindprod.com.invalid> - 2011-09-23 18:39 -0700
        Re: borrowing Constants Arne Vajhøj <arne@vajhoej.dk> - 2011-09-23 22:17 -0400
        Re: borrowing Constants Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-09-25 11:25 -0700
          Re: borrowing Constants Lew <lewbloch@gmail.com> - 2011-09-25 11:36 -0700
      Re: borrowing Constants Arne Vajhøj <arne@vajhoej.dk> - 2011-09-23 22:30 -0400
  Re: borrowing Constants Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-23 21:15 -0400
    Re: borrowing Constants Roedy Green <see_website@mindprod.com.invalid> - 2011-09-23 18:43 -0700
  Re: borrowing Constants markspace <-@.> - 2011-09-23 18:44 -0700
    Re: borrowing Constants Lew <lewbloch@gmail.com> - 2011-09-23 19:19 -0700
    Re: borrowing Constants Arne Vajhøj <arne@vajhoej.dk> - 2011-09-23 22:32 -0400
  Re: borrowing Constants Lew <lewbloch@gmail.com> - 2011-09-23 19:11 -0700
    Re: borrowing Constants Lew <lewbloch@gmail.com> - 2011-09-23 19:26 -0700
  Re: borrowing Constants v_borchert@despammed.com (Volker Borchert) - 2011-09-24 09:44 +0000
  Re: borrowing Constants Roedy Green <see_website@mindprod.com.invalid> - 2011-09-24 15:38 -0700
  Re: borrowing Constants Roedy Green <see_website@mindprod.com.invalid> - 2011-09-24 17:09 -0700
    Re: borrowing Constants Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-24 20:14 -0400
    Re: borrowing Constants markspace <-@.> - 2011-09-24 18:18 -0700
      Re: borrowing Constants Arne Vajhøj <arne@vajhoej.dk> - 2011-09-25 22:36 -0400
    Re: borrowing Constants Arne Vajhøj <arne@vajhoej.dk> - 2011-09-25 22:35 -0400
  Re: borrowing Constants Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-09-26 01:22 +0200

csiph-web