On 24.01.2018 19:11, Rony G. Flatscher wrote:
... cut ... > So the rule is, that a reflected object is not accessible by default, such > that one needs to use the > setAccessible() method. > > * Javadocs 9; this rewrites the documentation to read: > > public class AccessibleObject > extends Object > implements AnnotatedElement > > The AccessibleObject class is the base class for Field, Method, and > Constructor objects (known > as reflected objects). It provides the ability to flag a reflected object > as suppressing checks > for Java language access control when it is used. This permits > sophisticated applications with > sufficient privilege, such as Java Object Serialization or other > persistence mechanisms, to > manipulate objects in a manner that would normally be prohibited. > > Java language access control prevents use of private members outside > their class; package access > members outside their package; protected members outside their package or > subclasses; and public > members outside their module unless they are declared in an exported > package and the user reads > their module. By default, Java language access control is enforced (with > one variation) when > Fields, Methods, or Constructors are used to get or set fields, to invoke > methods, or to create > and initialize new instances of classes, respectively. Every reflected > object checks that the > code using it is in an appropriate class, package, or module. > > The one variation from Java language access control is that the checks by > reflected objects > assume readability. That is, the module containing the use of a reflected > object is assumed to > read the module in which the underlying field, method, or constructor is > declared. > > Whether the checks for Java language access control can be suppressed > (and thus, whether access > can be enabled) depends on whether the reflected object corresponds to a > member in an exported > or open package (see setAccessible(boolean)). > > Since: > 1.2 > > All of a sudden it states that "access control prevents use of (...) package > access members outside > their package (...)" by the "Java language access control", however the > compiled Java program is > allowed to do so! Sorry, misread that part in my rush (short break between two short meetings): it is of course o.k. to not allow access to package access members outside their package or subclasses! There is no general rule here that would prevent access to public access members, except for the new Module system. > I think it makes perfect sense that if a public subclass having package > access and > returning an object that the receiver of that object is rightfully entitled > to use its public > members available in its class and all of its superclasses. There is no risk > that the one who has a > reference to such an object can do any harm, if using public members. (As > package classes have > always access to their peer package classes and access to their peer's > package members it would > probably not make sense to allow "public" in that context, if access to those > members was not > allowed to become "public" outside of the package eventually.) > > For the module system it states "(...) prevents (...) public members outside > their module unless > they are declared in an exported package and the user reads their module". I > think this is not > specified enough. Using the same arguments as in the above paragraph: once an > object is handed out, > and if its class or one of its superclasses got exported, then starting with > the exported class all > public members of that class and all of its superclasses should be accessible > via reflection as > well. There is no risk that the one who has a reference to such an object can > do any harm to the > module system, if being restricted of using public members starting with the > first exported class > and then all of its superclasses as well. > > ---rony > ... cut ... ---rony
