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.bate...@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
