On 1/5/2017 1:16 PM, Rony G. Flatscher wrote:
The rule for using the Java bridge for the Rexx programmers has always been 
very simple: you are
only allowed to use public Java classes, public Java fields and public Java 
methods as these are
guaranteed to be available to everyone at all times.

This is what happens in this case too: the public Java class java.awt.Toolkit 
gets loaded, its
public class method getDefaultToolkit() gets invoked and a java.awt.Toolkit 
object gets returned by
that method.

The returned Toolkit object is known from the documentation to allow access to 
all documented public
methods, so its class (or one of its superclasses) must have the public 
abstract method
getScreenDimension() implemented (being a subclass of java.awt.Toolkit it must 
implement all
abstract members otherwise no instance could be created from it), therefore 
getting that Method
object and invoking it.

There has been no reason since the beginning of Java to know from a 
programmer's point of view how
the implementation of the class took place for the returned object (e.g. which 
package serves as its
home) as long as it was a subclass of that public Java class and as long as we 
have adhered to its
its public members only.

The j.l.r.Method object on which you call invoke() should not be obtained by inspecting the methods of the implementation class given by getDefaultToolkit().getClass(). Implementation classes (i.e. classes in non-exported packages) cannot be instantiated, nor their members manipulated, by code outside their module.

The j.l.r.Method object on which you call invoke() should be obtained by inspecting the methods of the "public Java class" java.awt.Toolkit. The first argument that you pass to invoke(), indicating the receiver, can still be instanceof the implementation class.

(Also, I would expect to be able to access any additional public members of
such a subclass, irrespectible of its implementation, just from knowing that in 
Java one can always
access public classes and public members.)

Nope, because access to members is gated by access to the enclosing class. If the enclosing class is inaccessible then its members are inaccessible.

Alex

Reply via email to