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

Groups > comp.lang.java.programmer > #29669 > unrolled thread

Accessibility of suBclass-fields from suPERclass (reflection)

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#29710

On 8/17/2014 2:04 PM, Andreas Leitgeb wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>> On 8/16/2014 6:37 PM, Andreas Leitgeb wrote:
>>> I have a special Base class, and each of its subclasses serve exactly
>>> one purpose: a collection of name/value associations where the java-
>>> compiler knows about the valid names, so as to detect accesses to
>>> non-existing names already at compile-time.  (without that last premise,
>>> I would have used HashMaps instead of subclasses)
>>       Would an EnumMap serve?
>
> In principle yes, but...
>
> ... element-access would look like:
>
>       someSpecificEnumMapInstance.get( SomeSpecificEnum.itemName )
>
> instead of:
>
>       someSpecificSubClassInstance.itemName

     We can all bemoan Java's occasional wordiness, but wasn't your
original code something like

	Value value;
	try {
	    Field f = someSpecificSubClassInstance
	       .getClass().getField("itenName");
	    f.setAccessible(true);  // if needed
	    value = (Value) f.get(someSpecificSubClassInstance);
	} catch (NoSuchFieldException | SecurityException | ... ex) {
	    throw SelfInflictedWoundException(ex);
	}

?  This is way wordier than using an EnumMap, *and* it prevents rather
than enables compile-time checking -- did you spot the typo?

     I'm confident that you've got a credible use case, but I'm less
confident that you've got a credible use case for this technique.  If
you'd reveal a little more about the larger problem, perhaps someone
could suggest an alternative approach -- that might even turn out to
be a better choice all around.

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29711

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> On 8/17/2014 2:04 PM, Andreas Leitgeb wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>> On 8/16/2014 6:37 PM, Andreas Leitgeb wrote:
>>>> I have a special Base class, and each of its subclasses serve exactly
>>>> one purpose: a collection of name/value associations where the java-
>>>> compiler knows about the valid names, so as to detect accesses to
>>>> non-existing names already at compile-time.  (without that last premise,
>>>> I would have used HashMaps instead of subclasses)
>>>       Would an EnumMap serve?
>> In principle yes, but...
>> ... element-access would look like:
>>       someSpecificEnumMapInstance.get( SomeSpecificEnum.itemName )
>> instead of:
>>       someSpecificSubClassInstance.itemName
>
>      We can all bemoan Java's occasional wordiness, but wasn't your
> original code something like
>
> 	Value value;
> 	try {
> 	    Field f = someSpecificSubClassInstance
> 	       .getClass().getField("itenName");
> 	    f.setAccessible(true);  // if needed
> 	    value = (Value) f.get(someSpecificSubClassInstance);
> 	} catch (NoSuchFieldException | SecurityException | ... ex) {
> 	    throw SelfInflictedWoundException(ex);
> 	}

That's a funny collage of a couple of separate snippets I mentioned in
separate posts :-)  Of course, the base class in my case doesn't
hardcode any field names as String-literals. That was only to give
some context for setAccessibility.

The code involving setAccessibility() exists only once, whereas accessing
those fields directly as foo.bar happens lots of times.

This thread is actually finished already, as I found a probable answer
to my own question:  reflection just doesn't know/care where it is called 
from, so it can't make any special cases for base classes. It's default
view on accessibility is solely based on target class's public'ness.

[toc] | [prev] | [next] | [standalone]

#29693

On 08/16/2014 10:46 AM, Andreas Leitgeb wrote:
>
> 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 think it's an unintended side-effect of language design - 
setters/getters everywhere, variables are evil, use them only locally.

Unintended like, 'protected' means visible to subclasses, noone ever 
mentioned superclass.
So, superclass is treated just as any other class.
I don't think there's any security issue specific to superclass.

Regards...

[toc] | [prev] | [next] | [standalone]

#29698

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

[toc] | [prev] | [next] | [standalone]

#29699

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.

The docs for setAccessible says:

<quote>
Set the accessible flag for this object to the indicated boolean value. 
A value of true indicates that the reflected object should suppress Java 
language access checking when it is used. A value of false indicates 
that the reflected object should enforce Java language access checks.

First, if there is a security manager, its checkPermission method is 
called with a ReflectPermission("suppressAccessChecks") permission.
</quote>

I read the first paragraph as:

call with false (and default) => access will only be allowed if access 
would have been allowed without the use of reflection

call with true => allow access (if call succeed)

Since the access we are discussing would not be possible without
reflection, then with that interpretation of the docs the call to
setAccessible is indeed necessary.

The second paragraphs explains that a security manager may prevent
this form for access.

I guess this is done to prevent code in restricted context
(typical Java applet) from corrupting the state of instances
of the Java runtime classes.

Like switching a flag somewhere changing context from
restricted to non-restricted.

I doubt that there are any special case for base class
access to subclass.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web