«

Can somebody please tell me a practical reason why you couldn't have
static members (not constants) within an inner class? I know that this
is forbidden, but I haven't found a practical, concrete reason for
this... I was wondering if this was just a whimsical decision from the
designers of the language.

Thanks a lot in advance...

IIRC you can have a static member within a _static_ inner class.

If the inner class is not static, I'm not sure it makes sense to have a
static member. This would rightly be a member of the owning class.

"maxw_cc" <> wrote in message
news: om...
> Can somebody please tell me a practical reason why you couldn't have
> static members (not constants) within an inner class? I know that this
> is forbidden, but I haven't found a practical, concrete reason for
> this... I was wondering if this was just a whimsical decision from the
> designers of the language.
>
> Thanks a lot in advance...

maxw_cc wrote:

> Can somebody please tell me a practical reason why you couldn't have
> static members (not constants) within an inner class? I know that this
> is forbidden, but I haven't found a practical, concrete reason for
> this... I was wondering if this was just a whimsical decision from the
> designers of the language.

Put it down to whimsy.

I think there was some feeling that it couldn't be needed, and that forbidding
static members made the construct somehow "cleaner" (which is laughable).
There is no *technical* reason for it in the sense that the current
implementation would work just as well if static members were allowed.

-- chris

"maxw_cc" <> wrote in message
news: om...
> Can somebody please tell me a practical reason why you couldn't have
> static members (not constants) within an inner class? I know that this
> is forbidden, but I haven't found a practical, concrete reason for
> this... I was wondering if this was just a whimsical decision from the
> designers of the language.
>
> Thanks a lot in advance...

The practical answer is that Sun couldn't decide on the best
time to initialize the static fields of the inner class. There
are complicated issues when initializing static fields. It's
not simply a matter of "initialize all static fields of all
inner classes when the enclosing class is initialized", because
it gets very complex (you can have any number of enclosing
classes). They just threw up their hands and said "don't allow
it for now". A static nested class can be initialized on its
first reference, just like any other "normal" class, but an
inner class presents some complex issues regarding timing.

2 cents worth. Your mileage may vary.

Chris Uppal wrote:

> maxw_cc wrote:
>
>
>>Can somebody please tell me a practical reason why you couldn't have
>>static members (not constants) within an inner class? I know that this
>>is forbidden, but I haven't found a practical, concrete reason for
>>this... I was wondering if this was just a whimsical decision from the
>>designers of the language.
>
>
> Put it down to whimsy.
>
> I think there was some feeling that it couldn't be needed, and that forbidding
> static members made the construct somehow "cleaner" (which is laughable).

I think the prohibition protects novice and journeyman programmers who
might be inclined to assume that inner classes' static members (if they
could have any) were scoped to a particular enclosing class instance.
The inner class itself is not static after all. (Weak, I know.)

Certainly it is the case that since all inner classes must have a static
or top-level containing instance, the inner class' static data can be
assigned to the class of that containing instance.

> There is no *technical* reason for it in the sense that the current
> implementation would work just as well if static members were allowed.

Yes, that's absolutely true. I do wonder whether the designers at the
time were also trying to hedge against a future implementation where the
difference might matter, however.


John Bollinger

John C. Bollinger wrote:

> > There is no *technical* reason for it in the sense that the current
> > implementation would work just as well if static members were allowed.
>
> Yes, that's absolutely true. I do wonder whether the designers at the
> time were also trying to hedge against a future implementation where the
> difference might matter, however.

That's a good point.

Personally, I think the implementation is pretty much set in stone, but the
fact that *I* think that *now* doesn't mean that *they* thought that *then*

-- chris

On Tue, 02 Dec 2003 22:27:18 -0800, maxw_cc wrote:

> Can somebody please tell me a practical reason why you couldn't have
> static members (not constants) within an inner class? I know that this
> is forbidden, but I haven't found a practical, concrete reason for
> this... I was wondering if this was just a whimsical decision from the
> designers of the language.
>
> Thanks a lot in advance...

An inner class can access the non-static fields/methods of the containing
object. This makes the inner class relevant only to the containing class.
Therefore, to have a static inner field would mean one single field being
updated according to the state of many different, diverse, objects.

This is not only a horrible programming gotcha to spot/debug, it is (I
would suggest) an abuse of the data encapsulation Java is built on and
it is certainly useless. If you want a static field, just use one in the
containing class!!

HTH
Jim