kevinrushforth
commented
6 years ago With jigsaw modularization, there is no concept of "internal API". An interface is either exported and part of the API or it isn't. This makes it clear what can change at will (anything not exported) vs what is a contract with the application. Without command line options specified at runtime to "break in" to internal interfaces, an application cannot even access anything that isn't exported.
So, if we were to ever do something like this -- perhaps taking a page from jawt -- it would need to be a formalized, specified interface, even if it were some sort of "expert mode" with caveats. It is something we could consider in the future, but would need to be done very carefully, and in a way that doesn't preclude a new underlying platform library (e.g., I would oppose any API that assumes a particular platform graphics library like OpenGL being available).
mikehearn
I realise this may be a controversial request, but sometimes there are effects you can only get by using the native OS APIs and the developer is willing to take the hit of platform specific code. In these cases it can be useful to get hold of the native OS pointers/handles without needing to request them back from the OS so they can be used. For instance, NSWindow, HWND, etc.
If JavaFX exposed these values in a more convenient place - even if it was internal API - this would make various kinds of effects easier to achieve. The underlying platform APIs are relatively stable anyway (maybe not on Linux) so exposing these pointers would not be a big compatibility problem, although of course, app devs can get themselves into a mess by interfering with state JavaFX wants to own.