J
Jamin
Anyone have a good example why one would use a static inner class?
Thanks,
Jamin
Thanks,
Jamin
Jamin said:Anyone have a good example why one would use a static inner class?
Jamin said:Anyone have a good example why one would use a static inner class?
John said:Static nested classes give you two main benefits:
(1) Name scoping
(2) access control
John C. Bollinger said:(3) Static nested classes can access private members of their
enclosing classes.
(3) Static nested classes can access private members of their enclosing
classes.
I, like alan, am mystified by this.
It does work, but why and what is the justification?
Bent C Dalager said:I, like alan, am mystified by this.
It does work, but why and what is the justification?
Consistency I suppose.
Any part of a given class C has access to the private fields of that
class C. A nested class C.A is part of the class within which it is
nested (class C) and so gets this level of access to its outer class.
Static methods also have access to the private fields of its class.
Why shouldn't static nested classes have it?
public class Test
{
private int a;
static class Inner
{
public void wowMe()
{
Test test = new Test();
test.a = 3;
System.out.println("a is " + test.a);
}
}
public static void main(String[] args)
{
Test.Inner inner = new Test.Inner();
inner.wowMe();
}
}
secret said:If it's a "static" nested class, how can it access any members (private or
otherwise) of an instance of the enclosing class?
And you refer to
"instances of the nested class" which also implies it's not static.
If the members are static temselves, otherwise through an instance it's
given
(e.g. as a method parameter).
Tor said:More precisely: The compiler synthesizes accessors for private members
used by nested classes.
John C. Bollinger said:No, as far as I can tell synthetic accessors are an implementation
choice, not a requirement specified by the language. It is possible
that this is the only viable implementation given the current JVM
specifications, but I don't think it is correct to describe it as a
general property of static nested classes.
Tor said:Until class verification changes, it is. A different class cannot
access another class' private members as long as JVM spec § 5.4.4 is
worded the way it is and the checks done in pass 4 of class
verification are as they are.
John said:<opinion whose="mine">
Reference to the JVM spec is not relevant. That directs how the
language feature can be implemented, not what the language feature _is_.
The JLS (plus associated corrections, addenda, etc.) defines the
language, and I have found no reference to synthetic accessors there.
It is a nontrivial distinction, essentially between interface and
implementation, that in this case is bridged by java compilers.
</opinion>
John C. Bollinger said:Reference to the JVM spec is not relevant.
That directs how the language feature can be implemented, not what
the language feature _is_.
The JLS (plus associated corrections, addenda, etc.) defines the
language, and I have found no reference to synthetic accessors
there.
Chris said:John C. Bollinger wrote:
While I agree with your position in principle, the pragmatic reality is that
most Java is intended to run on a JVM. That leads to a reflection:
It's becoming increasingly clear to me that there's something of a division
developing between the programmers who think in terms of Java-the-language, and
for whom the JVM is an implementation detail. And those who think of
Java-the-platform, for whom the JVM is central, and Java-the-language is just
one way of creating classfiles for running on that platform.
That wouldn't cause a problem, except that the features of Java-the-language
are
diverging increasingly from those of Java-the-platform. Static inner classes'
access to private variables is a case-in-point. For a Java-the-language man
(as you appear to be, judging only by your <option/> above) the synthetic
accessors are an implementation detail, at the discretion of the compiler. You
(as a competent programmer) will undoubtedly know that they are generated, and
may -- in some circumstances -- consider the effects they have, on security for
instance.
For a Java-the-platform man, such as myself, the position is rather different.
I work mostly at the bytecode/JNI level, so I'm probably more JVM-oriented than
most, but for me the ability of a static nested class to access private
variables of its enclosing class is a complete myth. As is the "nested" class
itself. The unreality of such constructs, and the reality of synthetic
accessors (etc) is not just a theoretical concern, but (an irritating) part of
my day-to-day work.
I'm not saying that everyone should adopt my rather extreme perspective, but I
do think that a good Java programmer (assuming they are targeting a JVM)
should be able to switch easily between Java-the-language and Java-the-platform
according to the needs of their current tasks/problems.
Tor said:It is: Unless stated otherwise, people will assume that when you write
Java it is to compile it to the Java VM. And if you talk about class
files for the JVM then that is the only way to implement access to
private members.
The JLS is pointless without an implementation. And most use one that
compiles to the JVM. De Facto versus de Jure.
John C. Bollinger said:Terminology first: if it's static then it isn't an inner class. (It's a
"static nested class".) Inner class instances have associated instances
of all lexically enclosing classes, up to the innermost top-level class.
Static nested classes and classes that are package members are
top-level classes.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.