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

[jeffrey kutcher]

 So developers have to be concerned with how the underlying classes are implemented and code to the implementation. This breaks the contract that is fundamental to Java. For example, the point to garbage collection was don't worry about how garbage collection works. Write your code in the pure sense and over time the garbage collector will get better due to the wizards that are interested in making the garbage collector scream. Leverage the technology and your code will inherently get better because the underlying technology being used is so much better. That holds true for the compiler and every other component of the JDK.
Stay away from native functions. You will break portability.
Again, there should be no concern about the underlying architecture. The example code provided in this post is 100% portable. So either reflection needs to be rewritten or deprecated or classes like <x>Map and <x>Box that can be reflected on needs rewriting so reflection can work properly. If a developer has to worry about how libraries are written, the libraries need to be rewritten.
Maybe those libraries that have internal private classes need to provide the necessary getters and setters so that it won't be necessary to access those internal private classes. Instead of calling vbox.getChildren().add(..) maybe provide vbox.add(..) which will intern call vbox.getChildren().add(..).
Some libraries work as expected. ArrayList, BitSet or JRadioButton are good examples, among many others (proof it has be done).
Just because you can doesn't mean you should.
As a side note which may contribute to resolving this post's issue, internal classes should never be used. First, reflecting on a private class can possibly happen resulting in this post's issue. Second, if you're using an internal class then you're saying that the code will have no use elsewhere which contradicts write once, run anywhere because everyone knows that the point of objects is reuse and if you build something that good, it's a sin to keep it private. Other's will inevitably cut and paste the code elsewhere duplicating the code adding system bloat and now support in more than one location suggesting that the private class should be made public and accessible to others which will contribute to resolving this post's original issue. The internal private class giving us this issue is no longer private.
Just because you can use internal classes doesn't mean you should. From a purist standpoint, this is an easy fix. Just don't do it by convention. The result is all related problems have a probability of zero that they will ever exist. That's pretty good for adhering to simple convention.
    On Monday, January 15, 2018, 1:24:30 PM CST, Alan Bateman <Alan.Bateman at oracle.com> wrote:  
 
 On 15/01/2018 18:27, jeffrey kutcher wrote:
> 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.
It's always been possible for getClass() to return a non-public class 
and for the Method invoke in the code example to fail with 
IllegalAccessException. You may have just got lucky in the past.  At 
some point then I would expect the JavaFX modules to not be open by 
default so maybe now is the time to fix the issues. You can run with 
`--illegal-access=warn` to help track down other code that may be 
accidentally trying to access members of JDK internal classes.  You can 
run with `--illegal-access=deny` to see how that code behaves when the 
classes in the JDK modules are not open for illegal access.

-Alan