How does one handle a java method which returns a non-public sub-type via reflection?

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: How does one handle a java method which returns a non-public sub-type via reflection?

jeffrey kutcher
 In this example, if I can access and execute the method vbox.getChildren().add() with no warnings or errors, which is accessing a non-public class, then I should also able to access that very same class and execute the same method using reflection with no warnings or errors and expect the same results. If not, the inconsistency may be a bug, feature or broken. Maybe that's the way it's suppose to work. Inconsistency however tells me something isn't quite right and if ignored will cause more issues later on. In this particular case, a lock down will completely stop currently working code. I'd like to not see that happen. If it does? I'll move on.
I don't disagree that there are good reasons for using non-public classes.
    On Tuesday, January 16, 2018, 8:23:50 AM CST, Kevin Rushforth <[hidden email]> wrote:  
 
 There are many good reasons for using non-public classes in the
implementation of a class library, the main one being to keep
implementation details from leaking into the public API. So while I
"get" that it causes difficulties in your specific case, I don't agree
that the solution is to avoid using non-public syb-types.

-- Kevin


jeffrey kutcher wrote:

>  There's nothing in the JLS by that name however, section 4.5 Parameterized Types, might be close to what I'm looking for.
> Even in a single inheritance system, resolving methods and types is a multi-dimensional process.
> I still say that by not allowing private inner classes, resolving this issue would be much easier (or providing the access methods in the parent class of the private internal class would work also ... calling getChildren() really is a dependency on the underlying classes implementation which I really don't understand why is declared private and not accessible. There has to be a good reason otherwise it should be changed or eliminated [get rid of inner classes]).
>    On Tuesday, January 16, 2018, 7:21:32 AM CST, dalibor topic <[hidden email]> wrote: 


>
> On 16.01.2018 14:08, jeffrey kutcher wrote> Is there official
> documentation explaining the method resolution process somewhere?
> I'd suggest taking a look at the Java Language specification and JVM
> specification for details.
>
> cheers,
> dalibor topic
 
Reply | Threaded
Open this post in threaded view
|

Re: How does one handle a java method which returns a non-public sub-type via reflection?

Jochen Theodorou


Am 18.01.2018 um 14:59 schrieb jeffrey kutcher:
>   In this example, if I can access and execute the method vbox.getChildren().add() with no warnings or errors, which is accessing a non-public class

In Java the static type is the important one. Of course you can do

VBox vbox = .... // returns implementation from nonexported package
vbox.getChildren().add()

This will work as long as VBox is accessible. the getChildren call is
not done using the implementation type, but VBox. And for this it does
not matter that vbox has a "forbidden" type at runtime at all.
Conclusively you have to do more at runtime if all you have is the
runtime type of vbox. You have to check if this type is accessible to
you and if not go to a super class. You would then maybe also end up in
Vbox and invoke the method you get for VBox, not for the implementation
of VBox. You still do a virtual method call, so the implementation
method is still called

> then I should also able to access that very same class and execute the same method using reflection with no warnings or errors and expect the same results. If not, the inconsistency may be a bug, feature or broken.

design choice I would claim.

> Maybe that's the way it's suppose to work. Inconsistency however tells me something isn't quite right and if ignored will cause more issues later on.

That is because Reflection has been declared as broken in that it has a
tradition of allowing too much. Now this has been restricted, leading to
problems. But in this case you just have to use the type the Java
compiler would, which is VBOX.

> In this particular case, a lock down will completely stop currently working code.

You are not alone here.

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: How does one handle a java method which returns a non-public sub-type via reflection?

jeffrey kutcher
 VBox class hierarchy shows getChildren() are implemented in Parentand Pane. vbox.getChildren() returns an instance of Parent which isprotected rather than public found in Pane. Accessing the Listreturned by Parent is an illegal reference because it is protectedwhile accessing the List returned by Pane should be legal, butthis isn't whats returned.
VBox Class Hierarchy:
java.lang.Objectjavafx.scene.Nodejavafx.scene.Parent -> protected ObservableList<Node> getChildren​()javafx.scene.layout.Regionjavafx.scene.layout.Pane -> public ObservableList<Node> getChildren()javafx.scene.layout.VBox
Class instance of vbox.getChildren() is:
vbox.getChildren().getClass() -> class javafx.scene.Parent$3
Pane is widening the access restrictions of Parent. Is this intentional?Does it have any effect? Should Parent's access restrictions of getChildren()be public also or should Pane's be protected?
My thought is public for both.
Reply | Threaded
Open this post in threaded view
|

Re: How does one handle a java method which returns a non-public sub-type via reflection?

jeffrey kutcher
 
  VBox class hierarchy shows getChildren() is implemented in Parent
and Pane. vbox.getChildren() returns an instance of Parent which is
protected rather than public found in Pane. Accessing the List
returned by Parent is an illegal reference because it is protected
while accessing the List returned by Pane should be legal, but
this isn't whats returned.

VBox Class Hierarchy:

java.lang.Object
javafx.scene.Node
javafx.scene.Parent -> protected ObservableList<Node> getChildren​()
javafx.scene.layout.Region
javafx.scene.layout.Pane -> public ObservableList<Node> getChildren()
javafx.scene.layout.VBox

Class instance of vbox.getChildren() is:

vbox.getChildren().getClass() -> class javafx.scene.Parent$3

Pane is widening the access restrictions of Parent. Is this intentional?
Does it have any effect? Should Parent's access restrictions of getChildren()
be public or should Pane's be protected?

My thought is public for both.

 
Reply | Threaded
Open this post in threaded view
|

Re: How does one handle a java method which returns a non-public sub-type via reflection?

Kevin Rushforth


jeffrey kutcher wrote:

>  
>   VBox class hierarchy shows getChildren() is implemented in Parent
> and Pane. vbox.getChildren() returns an instance of Parent which is
> protected rather than public found in Pane. Accessing the List
> returned by Parent is an illegal reference because it is protected
> while accessing the List returned by Pane should be legal, but
> this isn't whats returned.
>
> VBox Class Hierarchy:
>
> java.lang.Object
> javafx.scene.Node
> javafx.scene.Parent -> protected ObservableList<Node> getChildren​()
> javafx.scene.layout.Region
> javafx.scene.layout.Pane -> public ObservableList<Node> getChildren()
> javafx.scene.layout.VBox
>
> Class instance of vbox.getChildren() is:
>
> vbox.getChildren().getClass() -> class javafx.scene.Parent$3
>
> Pane is widening the access restrictions of Parent. Is this intentional?
> Does it have any effect? Should Parent's access restrictions of getChildren()
> be public or should Pane's be protected?
>
> My thought is public for both.
>  

Yes, this is intentional. It is fine for a subclass to widen the access
from protected to public. No, we don't want to make Parent::getChildren
public, since there are some subclasses that do not want to expose
direct access to application.

-- Kevin

12