0

My understanding is that com.sun.* API that is currently restricted but still used for JavaFX controls will no longer be accessible as and when Java9 is released; however, the ‘skin’ API will be made public or otherwise accessible so that this change will effectively apply only to the ‘behavior’ API. This view is based on my reading of the most recent update for JEP 253 (two weeks old so relatively recent). For those having more experience with JavaFX and its evolutionary process than I (that doesn’t require much), is it safe to assume that current ‘skin’ API will remain accessible (and become non-restricted)? I don’t expect any guarantees, but if this is an iffy proposition then a best-guess estimate of what might happen would be appreciated.

Thanks in advance for any response!

jfr
  • 397
  • 2
  • 17
  • 1
    My understanding from talking with the JavaFX guys is Skins will become public, but Behaviors will not. – purring pigeon Sep 14 '16 at 20:16
  • 2
    The skin API will become public, but the package names will (necessarily) change for that to happen (to `javafx.scene.control.skin`). Behaviours will not be public. – James_D Sep 14 '16 at 21:17
  • Thanks @purringpigeon your reply, it's helpful. How can I give you 'credit' for your answer? – jfr Sep 15 '16 at 06:15
  • Thanks @James_D your reply, it's helpful. How can I give you 'credit' for your answer? – jfr Sep 15 '16 at 06:15

1 Answers1

1

As JEP 253 states:

With the forthcoming release of Java 9, and in particular with the introduction of strong boundaries between modules in Project Jigsaw, developers will find that their code will no longer compile or run since the com.sun.* packages will no longer be accessible.

In order to provide some support for developers who have subclassed the skin classes in com.sun.javafx.scene.control.skin, these classes will be moved to a public package javafx.scene.control.skin in JavaFX 9. The JEP is not shy about stating that this is to support developers who have ignored official advice about using these classes in the first place.

The JEP also states

The intention is to move many JavaFX control skins into the appropriate public package, most probably javafx.scene.control.skin. There is no intent to also move the related behavior classes.

This means that the behavior classes will remain in the non-public API and thus will become inaccessible in Java 9. Skin classes will move to a different package, so code that relies on the current com.sun.javafx.scene.control.skin package will not compile or run in Java 9, but can be modified to do so. Code that relies on the behavior classes will not compile or run, and will not be able to be modified to do so.

The JEP lists classes that have been moved. Also, current early access API documentation for JavaFX 9, with the skin classes moved to javafx.scene.control.skin can be seen here.

James_D
  • 201,275
  • 16
  • 291
  • 322
  • thanks for your reply, it raises another question as to what qualifies as ‘skin’ as opposed to ‘behavior’ (in several parts). My initial question resulted from attempting to add additional functionality to the TextField's context menu . An earlier SO post (https://stackoverflow.com/questions/32980159/javafx-append-to-right-click-menu-for-textfield/32980464#32980464) rightly points out that adding menu items to the existing context menu is problematic, warns that the solution suggested in that post would probably break under Java 9, and references JEP 253 for more info. – jfr Sep 15 '16 at 17:50
  • The solution in the above-mentioned post involves an override of the public TextInputControlSkin#populateContextMenu(ContextMenu). This is most interesting because this method is missing from the API for TextInputControlSkin and TextFieldSkin, which is odd inasmuch as the method and how it seems to work seems to have much more of a ‘skin’ flavor than ‘behavior’. It was also interesting to note the cross-references between the ‘skin’ class(es) and the ‘behavior’. – jfr Sep 15 '16 at 17:52
  • While the populateContextMenu() method makes no direct reference to anything in the ‘behavior’ class it does use an inner class (ContextMenuItem) to construct the menu’s items, and that inner class does refer to the ‘behavior’, which isn’t the end of the story because the ‘behavior’ that is referenced refers back to the relevant ‘skin’ classes. – jfr Sep 15 '16 at 17:53
  • What this seems to mean is that there is no clear line between ‘skin’ and ‘behavior’ for purposes of separating the two in anticipation of Java9. While this context menu experience is admittedly very limited, if it is representative of other areas then most cross-referencing runs in one direction behavior-to-skin, with not much going the other way. However, cross-referencing between skin and behavior does exist and muddles the process. The omission of the populateContextMenu() method from the new APIs is an example of what might happen. – jfr Sep 15 '16 at 17:53