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