Re: Accessibility of suBclass-fields from suPERclass (reflection)
Andreas Leitgeb wrote:
It is clear to me, that a class may need to protect its fields from direc=
t
access by subclasses or unrelated classes, mostly because the developer o=
f
a base class doesn't always know all derived or unrelated classes ahead o=
f
time.
Otoh, someone who derives a class, or even does it in a statement block o=
f
their own code, obviously can be expected to "know" and "trust" those
classes he derives or includes derivatives of.
E.g., someone writing this:
public class Outer extends Base {
static {
class Inner extends Base { ... }
}
}
had better know/trust "class Base", and have no need to have his code
protected from reflective examination by class Base.
Declaring that 'Inner' class inside the static initializer like that makes =
it deucedly hard to use.
Now, apparently, the designers of Java felt differently, and to examine (=
by
use of reflection) the fields of "Inner" from within Base's code, Base ha=
s to
It might have been easier if 'Inner' were an inner class of 'Outer'. I don'=
t quite know how to parse out an inner class inside a static initializer bl=
ock - it doesn't become an inner class of 'Outer', and it doesn't become a =
nested class of 'Outer' exactly. I think it can only be used inside that bl=
ock. Honestly this one is a bit of a stumper for me.
Can you show me how to use such a declared class?
jump an extra hoop (namely calling setAccessibility(true)), requesting ac=
cess
from an eventually installed SecurityManager.
Surprisingly (or not), that extra hoop is not required to examine "Outer"=
's
fields from within "Base". Also, it is not possible to mark an inner cla=
ss
as public in an attempt to grant accessibility of "Inner" to "Base".
It makes no sense to me, why there is any defense-mechanism at all agains=
t
field access from code within a known Baseclass.
--
Lew