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.hol...@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
<blackd...@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
