Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Accessibility of suBclass-fields from suPERclass (reflection) Date: Sat, 16 Aug 2014 10:51:11 -0400 Organization: A noiseless patient Spider Lines: 69 Message-ID: References: <53eecf6a$0$300$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 16 Aug 2014 14:51:17 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="bd4e1cba8d8592bec5d5ed9e4537fbfd"; logging-data="24125"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18AchxxQhsfhmjkYKnhUEKx" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: Cancel-Lock: sha1:px0tYq3qRkaVWEGUYBaF4f246xU= Xref: csiph.com comp.lang.java.programmer:29698 On 8/16/2014 4:46 AM, Andreas Leitgeb wrote: > Arne Vajhøj 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