Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29698

Re: Accessibility of suBclass-fields from suPERclass (reflection)

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-15 00:58 +0000
  Re: Accessibility of suBclass-fields from suPERclass (reflection) Lew <lewbloch@gmail.com> - 2014-08-15 15:20 -0700
    Re: Accessibility of suBclass-fields from suPERclass (reflection) Steven Simpson <ss@domain.invalid> - 2014-08-16 00:11 +0100
      Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-16 00:10 +0000
  Re: Accessibility of suBclass-fields from suPERclass (reflection) Arne Vajhøj <arne@vajhoej.dk> - 2014-08-15 23:26 -0400
    Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-16 08:46 +0000
      Re: Accessibility of suBclass-fields from suPERclass (reflection) Robert Klemme <shortcutter@googlemail.com> - 2014-08-16 12:27 +0200
        Re: Accessibility of suBclass-fields from suPERclass (reflection) "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-16 13:37 +0100
          Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-16 09:47 -0400
          Re: Accessibility of suBclass-fields from suPERclass (reflection) Robert Klemme <shortcutter@googlemail.com> - 2014-08-17 13:19 +0200
        Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-16 22:37 +0000
          Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-16 20:22 -0400
            Re: Accessibility of suBclass-fields from suPERclass (reflection) Josip Almasi <joe@vrspace.org> - 2014-08-17 12:51 +0200
              Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-17 07:54 -0400
                Re: Accessibility of suBclass-fields from suPERclass (reflection) "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-17 13:44 +0100
                Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-17 17:42 +0000
                Re: Accessibility of suBclass-fields from suPERclass (reflection) Arne Vajhøj <arne@vajhoej.dk> - 2014-08-18 20:45 -0400
                Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-20 18:47 +0000
                Re: Accessibility of suBclass-fields from suPERclass (reflection) Josip Almasi <joe@vrspace.org> - 2014-08-18 17:19 +0200
            Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-17 18:04 +0000
              Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-17 15:24 -0400
                Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-17 21:35 +0000
      Re: Accessibility of suBclass-fields from suPERclass (reflection) Josip Almasi <joe@vrspace.org> - 2014-08-16 12:31 +0200
      Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-16 10:51 -0400
      Re: Accessibility of suBclass-fields from suPERclass (reflection) Arne Vajhøj <arne@vajhoej.dk> - 2014-08-16 11:00 -0400

csiph-web