Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #29676
| Newsgroups | comp.lang.java.programmer |
|---|---|
| Date | 2014-08-15 15:20 -0700 |
| References | <slrnluqmpu.fp3.avl@login.logic.tuwien.ac.at> |
| Message-ID | <8ebedaf9-6487-4897-8c97-a83356444138@googlegroups.com> (permalink) |
| Subject | Re: Accessibility of suBclass-fields from suPERclass (reflection) |
| From | Lew <lewbloch@gmail.com> |
Andreas Leitgeb wrote:
> It is clear to me, that a class may need to protect its fields from direct
> access by subclasses or unrelated classes, mostly because the developer of
> a base class doesn't always know all derived or unrelated classes ahead of
> time.
>
> Otoh, someone who derives a class, or even does it in a statement block of
> 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 has 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 block - 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 block. 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 access
> 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 class
> 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 against
> field access from code within a known Baseclass.
--
Lew
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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