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

[David Holmes]

On 16/01/2018 11:08 PM, jeffrey kutcher wrote:
> Trying to find documentation for the method resolution process.

The JVMS defines the rules for method resolution (and subsequent selection).

David
------

> Found this:
> 
> https://stackoverflow.com/questions/6021109/java-runtime-method-resolution
> 
> which leads to
> 
> http://www.cowtowncoder.com/blog/archives/2010/12/entry_436.html
> 
> Maybe this is an opportunity for someone to put together a class library that does the right thing all the time regarding the method resolution process. Does the Java library already have this somewhere in it's source? If so, why not expose it making it easier for others so those interested don't have to reinvent the wheel every time.
> 
> 
> Is there official documentation explaining the method resolution process somewhere?
> 
> 
> On Monday, January 15, 2018, 4:02:44 PM CST, David Holmes <david.holmes at oracle.com> wrote:
> 
> 
> 
> 
> 
> On 16/01/2018 4:27 AM, jeffrey kutcher wrote:
>>    
>> 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?
> 
> I recall a very similar discussion in the past. You have to start with
> (public) statically known types, not with the dynamic type of the
> instances involved. In essence you have to reflectively emulate the
> method resolution process that occurs with a direct call and which uses
> static type information.
> 
> David
> 
> -----
> 
>> 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
>>