Some methods/fields have been switched from public/protected to package-protected or private in JDK 9.

This prevents the SpreadsheetView and other components from ControlsFX to work.
Back in 2013 before JDK 8 was released, I pledged to open some methods in order to override some com.sun.XXX.skin classes. Now we have made a move forward and switch these skin into public API. But that cannot be done if you switch back some methods into private because it makes impossible to create new components.

In javafx.scene.control.skin.TableHeaderRow:
getRootHeader() should be protected but since the method "createRootHeader()" is protected, one can access the rootHeader when actually creating it.
updateTableWidth() should be protected
updateScrollX() should be protected

These three methods are necessary if anyone wants to override the TableHeaderRow. See JDK-8102843

In javafx.scene.control.skin.TableColumnHeader
getTableHeaderRow() should be protected
getTableSkin() should be protected

In javafx.scene.control.skin. TableViewSkinBase:
scrollHorizontally() should be protected
scrollHorizontally(TC col) should be protected
getTableHeaderRow() should be protected because the method createTableHeaderRow() is itself protected. What's the point of allowing the customization of the TableHeaderRow if you don't give access to it..?

In javafx.scene.control.skin.VirtualFlow:
getHbar() was protected and should remain
getVbar() was protected and should remain
reconfigureCells() was protected and should remain
getCells() was protected and should remain
getFirstVisibleCellWithinViewPort() was public and should at least be protected
getLastVisibleCellWithinViewPort() was public and should at least be protected
resizeCellSize()
getPrivateCell()

The access to the VirtualFlow was made possible with that ticket : JDK-8187379
But we should go back to the way it was in JDK 8 with these tickets : JDK-8103193
JDK-8102946
If anyone wants to override the VirtualFlow, it's because he wants to add some cells, to remove some, to play with it. We should allow that otherwise it's pointless.

I know I'm late in the process and we are already in RDP1. But if this go through, we could have a working version of ControlsFX for JDK 11 which is the next LTS and that would be much appreciated.

I'm listed as an "author" here : http://openjdk.java.net/census#openjfx
I don't know what that actually means but I'm willing to provide Pull requests if necessary to ease the process as much as I can.