Re: Accessibility of suBclass-fields from suPERclass (reflection)
On 8/16/2014 4:46 AM, Andreas Leitgeb wrote:
Arne Vajh??j <arne@vajhoej.dk> wrote:
Can you produce an example showing the problem?
My 'problem' is understanding, why setAccessible(true) is even necessary
My first attempt:
[...]
private static void test(Base o) {
System.out.print(o.getClass().getName() + " : ");
try {
Field f = o.getClass().getField("v");
int v = f.getInt(o);
System.out.println(v);
} catch (NoSuchFieldException | SecurityException |
[throws...]
private static void testWith(Base o) {
System.out.print(o.getClass().getName() + " (with) : ");
try {
Field f = o.getClass().getDeclaredField("v");
f.setAccessible(true);
int v = f.getInt(o);
System.out.println(v);
} catch (NoSuchFieldException | SecurityException |
[throws not]
which looks consistent to me.
Consistent maybe, but why cannot Base access these fields by default?
I'm not complaining about that extra setAccessibility(true), I just
would like to see an example of where a Base-class accessing its children
could be a security issue. I'm not talking of some arbitrary class
attempting access, but about the target class's parent (or grandparent)
class.
I'm probably unaware of some risk, and learning about it was my reason
for the posting.
Perhaps the risk is in constraining the subclass' implementation.
I'm writing a new subclass of Base, and I want it to implement
the Dijkstrable interface. Dijkstrable calls for methods named p()
and v(), which I duly write. Since I've got a method named v, I'd
prefer not to use v as the name of something else altogether, so I
name my private int field x instead ...
... and all of a sudden, my class (which compiles with not so
much as a warning, never mind an error) won't work. Base insists
that I must have a field named v, and although this requirement is
stated somewhere in Base's Javadoc it is not stated in a way that
the compiler can understand or enforce. Is this good design?
Alternatively, I've understood the requirement for a field
named v and have provided it. However, my subclass deals with
very large numbers and makes v a long -- and again, my class won't
work with Base because f.getInt() throws IllegalArgumentException
(still with nary a peep from the compiler). Is this good design?
Java has ways to insist on the presence of methods with given
names, parameters, return types, and throwables. It does not have
similar mechanisms to insist on data structures of specified
types and names. Language theorists might regard this as a flaw
(I'm not equipped to debate that), but that's how it is -- and
I think that using reflection in an attempt to evade Java's design
is probably ill-conceived. If you're fighting with the language,
perhaps you should instead be looking for a different one.
--
esosman@comcast-dot-net.invalid