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

[jeffrey kutcher]

Thanks for your thoughts Jochen. I have a section of code that does just that; function search and casting return values. Not easy ... nor as easy as it should be.
You would think however, that if a function call would cause no issues, say vbox.getChildren().add(x), that there should similarly be no issues referencing each of the pieces of the same call set via reflection. If not, then something is up with the design. It should be this simple. The point to object oriented programming is to understand the pattern and then leverage that pattern so when another object mimics a prior pattern you know how it works increasing your productivity exponentially. In this case, it's not a different object pattern. It's the very same object/pattern, just referenced differently. If not, then the point of object programming is defeated.
Introspection of vbox.getChildren().add(x) should be just as simple as calling vbox.getChildren().add(x) itself, otherwise why have introspection at all?

Simple is hard. Steve Jobs demanded elegance as well as performance and if not it was back to the drawing board until it worked ... and looked good doing it. He was ruthless. Look at the behemoth he created. Yes there are lots of different ways of doing things, especially in programming, but in an object system, if by convention objects are being leveraged improperly, then cracks are being introduced and over time will implode under its own weight. One offs are bad for an object system.
I understand, practically speaking, this isn't how it works, even in Java. There are always nuances. It sometime takes extreme effort to eliminate those nuances.
Looking for an Oracle to glean insight (implications of a lock down)
I've worked with Java since 1995. This example represents an issue that was never an issue up until Java9. Even then, I had no idea it was my code that was the issue since my code never directly referenced illegal classes. I code to write once, run anywhere and never use native method calls to maintain independence. What I can say from this exercise is if this lock down does come to pass, the past 17 years worth of code will no longer work.
I've built special code to handle cases because lists where different from the standard list, for example. That special code should and will go away when Java libraries collapse it's implementation.
It looks like I'll have to make a decision. Never upgrade again or move on and say good-bye to 17 years worth of work. It was a good run. I suppose nothing lasts forever.

I'm sure there are others.
    On Monday, January 15, 2018, 8:44:46 AM CST, Jochen Theodorou <blackdrag at gmx.org> wrote:  
 
 

Am 12.01.2018 um 22:49 schrieb Michał Zegan:
> well you rather know what getChildren returns, so you know what the
> returned object is, like generally.

but as soon as the method you want to call is not on the statically 
declared type, nor within a set of known statically types you are having 
a problem. There is no good way (good in terms of usability and 
performance) to get an arbitrary valid method object without static 
information. You are always forced to traverse the hierarchy to find the 
most accessible type. You will have to check access... and then of 
course there the two bad scenarios where invocation and search are not 
the same class or actual caller and caller are not equal. Which leads to 
a lengthy search using reflection to find a method, transfer it to a 
method handle and then let the invoker do the actual call.

bye Jochen