Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8076423

JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization

    Details

    • Author:
      Jonathan Giles
    • JEP Type:
      Feature
    • Exposure:
      Open
    • Subcomponent:
    • Scope:
      JDK
    • Discussion:
      openjfx dash dev at openjdk dot java dot net
    • Effort:
      L
    • Duration:
      L
    • Alert Status:
       Green
    • Alert Reason:
      Completed
    • JEP Number:
      253

      Description

      Summary

      Define public APIs for the JavaFX UI controls and CSS functionality that is presently only available via internal APIs and will hence become inaccessible due to modularization.

      Goals

      Many developers who use the UI controls and CSS functionality of JavaFX have historically ignored the warnings to avoid the internal com.sun.* APIs. In many cases, to achieve a desired result, developers have no choice but to use these internal APIs. 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. The goal of this JEP is to define public APIs for the functionality presently offered by the internal APIs.

      Non-Goals

      Given the implications of modularization, that is, the forthcoming inaccessibility of the com.sun.* packages, there is no way to do this in a manner that retains any degree of backward compatibility. It is, therefore, not a goal of this JEP to retain backward compatibility. This does not mean that we can break anything we like; our intention is to only introduce new API (and evolve existing private API) that is directly broken by the enforcement of module boundaries. All other existing APIs that are not impacted by modularization will remain the same.

      Success Metrics

      Success can be measured in two ways:

      • Projects that depend on JavaFX internal APIs, in particular Scene Builder, ControlsFX, and JFXtras, continue to work after updating to the new API with no loss of functionality. These three projects are all open source, and they will provide an excellent test bed to ensure that all necessary APIs have been provided.

      • The result of discussions around new APIs, such as the input-map work required for control behaviors, results in improved functionality that developers have long requested. Ultimately, if all works to plan, third-party controls should be buildable without any dependency upon internal APIs.

      Motivation

      Without this work being done, many projects will need to significantly reduce the functionality that they offer, and for some projects this may prove fatal. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable---certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder. The same argument holds for most other JavaFX-based projects with any degree of custom control or CSS implementation.

      Description

      This JEP is broken down into two semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

      Project One: Make UI control skins into public APIs

      At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g., the TextFieldSkin) to add additional functionality, to override an existing method, or otherwise to modify the visuals or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public APIs, but we have long discussed making this API public so as to better enable third party modification of UI controls.

      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.

      The vast bulk of this work is to review each existing skin class, ensuring the following:

      • That there is API consistency between skins,

      • That high-quality Javadoc and unit tests exist, and

      • That the API in each class is kept to a minimum by changing public methods to private.

      This research is already quite far progressed in a separate sandbox repo, and whilst time-consuming, there are only a few classes of concern, such as utility classes, duplicated classes, and truly implementation-only classes, that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package or, at the least, will need further consideration since they are not truly skins. These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField. Finally, there are a few classes where, ideally, methods would be made private, except for the fact that other, implementation-only classes rely on this API. Solutions will be investigated for all of these issues, and no major concerns exist.

      The intent of making the skins into public API in 9 is to ensure their continued availability. The API will be purposefully kept to the bare minimum and reduced as significantly as possible, with the intention to follow this up in subsequent releases with more useful APIs that developers request. As is well appreciated, APIs are (mostly) forever, so allowing for the public skin API to mature over a few update releases seems like the best course of action.

      As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into javafx.scene.control.skin as public API:

      • AccordionSkin
      • ButtonBarSkin
      • ButtonSkin
      • CellSkinBase
      • CheckBoxSkin
      • ChoiceBoxSkin
      • ColorPickerSkin
      • ComboBoxBaseSkin
      • ComboBoxListViewSkin
      • ComboBoxPopupControl
      • ContextMenuSkin
      • DateCellSkin
      • DatePickerSkin
      • HyperlinkSkin
      • LabelSkin
      • LabeledSkinBase
      • ListCellSkin
      • ListViewSkin
      • MenuBarSkin
      • MenuButtonSkin
      • MenuButtonSkinBase
      • NestedTableColumnHeader
      • PaginationSkin
      • ProgressBarSkin
      • ProgressIndicatorSkin
      • RadioButtonSkin
      • ScrollBarSkin
      • ScrollPaneSkin
      • SeparatorSkin
      • SliderSkin
      • SpinnerSkin
      • SplitMenuButtonSkin
      • SplitPaneSkin
      • TabPaneSkin
      • TableCellSkin
      • TableCellSkinBase
      • TableColumnHeader
      • TableHeaderRow
      • TableRowSkin
      • TableRowSkinBase
      • TableViewSkin
      • TableViewSkinBase
      • TextAreaSkin
      • TextFieldSkin
      • TextInputControlSkin
      • TitledPaneSkin
      • ToggleButtonSkin
      • ToolBarSkin
      • TooltipSkin
      • TreeCellSkin
      • TreeTableCellSkin
      • TreeTableRowSkin
      • TreeTableViewSkin
      • TreeViewSkin
      • VirtualContainerBase
      • VirtualFlow

      These classes, as of mid-June, are stripped of almost any API that is not inherited from SkinBase. Moving forward, the intention is to add back useful API as feedback is received based on early access builds. Some classes, such as the text input controls and virtualised controls, have additional API already to support their functionality.

      Project Two: Review and make public relevant CSS APIs

      As with Project One, this project relates to bringing out into the public APIs that currently reside in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

      The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9, with the appropriate modifications.

      As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into javafx.css as public API:

      CascadingStyle.java:public class CascadingStyle implements Comparable<CascadingStyle> {
      CascadingStyle.java:    public Style getStyle() {
      CascadingStyle.java:    public CascadingStyle(final Style style, Set<PseudoClass> pseudoClasses,
      CascadingStyle.java:    public String getProperty() {
      CascadingStyle.java:    public Selector getSelector() {
      CascadingStyle.java:    public Rule getRule() {
      CascadingStyle.java:    public StyleOrigin getOrigin() {
      CascadingStyle.java:    public ParsedValueImpl getParsedValueImpl() {
      
      CompoundSelector.java:final public class CompoundSelector extends Selector {
      CompoundSelector.java:    public List<SimpleSelector> getSelectors() {
      CompoundSelector.java:    public CompoundSelector(List<SimpleSelector> selectors, List<Combinator> relationships)
      CompoundSelector.java:    public Match createMatch() {
      
      CssError.java:public class CssError {
      CssError.java:    public static void setCurrentScene(Scene scene) {
      CssError.java:    public final String getMessage() {
      CssError.java:    public CssError(String message) {
      CssError.java:    public final static class PropertySetError extends CssError {
      CssError.java:        public PropertySetError(CssMetaData styleableProperty,
      
      Declaration.java:final public class Declaration {
      Declaration.java:    public ParsedValue getParsedValue() {
      Declaration.java:    public String getProperty() {
      Declaration.java:    public Rule getRule() {
      
      Rule.java:final public class Rule {
      Rule.java:    public final ObservableList<Declaration> getDeclarations() {
      Rule.java:    public final ObservableList<Selector> getSelectors() {
      Rule.java:    public Stylesheet getStylesheet() {
      Rule.java:    public StyleOrigin getOrigin() {
      
      Selector.java:abstract public class Selector {
      Selector.java:    public Rule getRule() {
      Selector.java:    public void setOrdinal(int ordinal) {
      Selector.java:    public int getOrdinal() {
      Selector.java:    public abstract Match createMatch();
      Selector.java:    public abstract boolean applies(Styleable styleable);
      Selector.java:    public abstract boolean applies(Styleable styleable, Set<PseudoClass>[] triggerStates, int bit);
      Selector.java:    public abstract boolean stateMatches(Styleable styleable, Set<PseudoClass> state);
      Selector.java:    public static Selector createSelector(final String cssSelector) {
      Selector.java:    protected void writeBinary(DataOutputStream os, StringStore stringStore)
      
      SimpleSelector.java:final public class SimpleSelector extends Selector {
      SimpleSelector.java:    public String getName() {
      SimpleSelector.java:    public List<String> getStyleClasses() {
      SimpleSelector.java:    public Set<StyleClass> getStyleClassSet() {
      SimpleSelector.java:    public String getId() {
      SimpleSelector.java:    public NodeOrientation getNodeOrientation() {
      
      Size.java:final public class Size {
      Size.java:    public Size(double value, SizeUnits units) {
      Size.java:    public double getValue() {
      Size.java:    public SizeUnits getUnits() {
      Size.java:    public boolean isAbsolute() {
      Size.java:    public double pixels(double multiplier, Font font) {
      Size.java:    public double pixels(Font font) {
      Size.java:    public double pixels() {
      
      Style.java:final public class Style {
      Style.java:    public Selector getSelector() {
      Style.java:    public Declaration getDeclaration() {
      Style.java:    public Style(Selector selector, Declaration declaration) {
      
      Stylesheet.java:public class Stylesheet {
      Stylesheet.java:    public String getUrl() {
      Stylesheet.java:    public StyleOrigin getOrigin() {
      Stylesheet.java:    public void setOrigin(StyleOrigin origin) {
      Stylesheet.java:    public List<Rule> getRules() {
      Stylesheet.java:    public List<FontFace> getFontFaces() {
      Stylesheet.java:    public static Stylesheet loadBinary(URL url) throws IOException {
      Stylesheet.java:    public static void convertToBinary(File source, File destination) throws IOException {
      
      CssParser.java:final public class CssParser {
      CssParser.java:    public CssParser() {
      CssParser.java:    public Stylesheet parse(final String stylesheetText) {
      CssParser.java:    public Stylesheet parse(final URL url) throws IOException {
      CssParser.java:    public Stylesheet parseInlineStyle(final Styleable node) {
      CssParser.java:    public ParsedValueImpl parseExpr(String property, String expr) {
      CssParser.java:    public static ObservableList<CssError> errorsProperty() { 

      Summary

      The end result of these two projects is the creation of:

      • A new package javafx.scene.control.skin for UI control skins, after being reviewed, documented, and tested;

      • The moving and review, documentation, and testing of necessary CSS-related classes.

      Testing

      Testing will be limited to additional unit tests that have no special platform or hardware requirements.

      Risks and Assumptions

      The primary risk is that the scope of work exceeds what is anticipated. Some research has been done to better understand the requirements, but there is no denying that producing good APIs will require a decent investment of time.

        Issue Links

          Activity

          jgiles Jonathan Giles created issue -
          jgiles Jonathan Giles made changes -
          Field Original Value New Value
          Labels team-corelibs team-clientlibs
          jgiles Jonathan Giles made changes -
          Link This issue is blocked by JDK-8076424 [ JDK-8076424 ]
          jgiles Jonathan Giles made changes -
          Link This issue is blocked by JDK-8076425 [ JDK-8076425 ]
          jgiles Jonathan Giles made changes -
          Link This issue is blocked by JDK-8076426 [ JDK-8076426 ]
          jgiles Jonathan Giles made changes -
          Link This issue is blocked by JDK-8076430 [ JDK-8076430 ]
          jgiles Jonathan Giles made changes -
          Scope SE [ 19106 ] JDK [ 19107 ]
          vdyakov Victor Dyakov made changes -
          Labels team-clientlibs modularization team-clientlibs
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). Similar arguments exist for many other JavaFX-based projects.

          Description
          -----------

          This JEP is broken down into a few semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been exploration in this area as part of RT-21598 [1], which is ongoing now.

          [1] https://javafx-jira.kenai.com/browse/RT-21598

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). Similar arguments exist for many other JavaFX-based projects.

          Description
          -----------

          This JEP is broken down into a few semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been exploration in this area as part of RT-21598 [1], which is ongoing now.

          [1] https://javafx-jira.kenai.com/browse/RT-21598

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). Similar arguments exist for many other JavaFX-based projects.

          Description
          -----------

          This JEP is broken down into a few semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been exploration in this area as part of RT-21598 [1], which is ongoing now.

          [1] https://javafx-jira.kenai.com/browse/RT-21598

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          Having already been briefly reviewed, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of RT-21598 [1], which has been intermittently returned to since mid-2012. The current implementations being explored presently hold a lot of promise. They considerably clean up the

          [1] https://javafx-jira.kenai.com/browse/RT-21598

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          Having already been briefly reviewed, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of RT-21598 [1], which has been intermittently returned to since mid-2012. The current implementations being explored presently hold a lot of promise. They considerably clean up the

          [1] https://javafx-jira.kenai.com/browse/RT-21598

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          Having already been briefly reviewed, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of RT-21598, which has been intermittently returned to since mid-2012. The current implementations being explored presently hold a lot of promise. They considerably clean up the

          [1] https://javafx-jira.kenai.com/browse/RT-21598

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          Having already been briefly reviewed, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of RT-21598, which has been intermittently returned to since mid-2012. The current implementations being explored presently hold a lot of promise. They considerably clean up the

          [1] https://javafx-jira.kenai.com/browse/RT-21598

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          Having already been briefly reviewed, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has been intermittently returned to and revised since mid-2012. The current implementations being explored presently hold a lot of promise - they considerably clean up the behavior code, and additionally expose the behavior mappings in a simple way, allowing for easier modification of input maps at runtime by external users.

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          Having already been briefly reviewed, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has been intermittently returned to and revised since mid-2012. The current implementations being explored presently hold a lot of promise - they considerably clean up the behavior code, and additionally expose the behavior mappings in a simple way, allowing for easier modification of input maps at runtime by external users.

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The intention would be to move many JavaFX control skins into the appropriate package, most probably javafx.scene.control.skin. There is no intention to also move across the related behavior classes, as these will be handled separately as part of project two below.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          Having already been briefly reviewed, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has been intermittently returned to and revised since mid-2012. The current implementations being explored presently hold a lot of promise - they considerably clean up the behavior code, and additionally expose the behavior mappings in a simple way, allowing for easier modification of input maps at runtime by external users.

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).

          ### Summary

          The end result of these three projects is the creation of:

          - A new package 'javafx.scene.control.skin' for UI control skins, after being API reviewed, standardised, documented, and tested.
          - Additional API for specifying input mappings
          - The translation of existing UI control behavior classes to the new input map API
          - The possible creation of a javafx.scene.control.behavior' package for these input map classes, to more easily allow for subclassing and stronger input mapping customising of existing UI controls.
          - The moving and API review, standardisation, documentation, and testing of necessary CSS-related classes.


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          jgiles Jonathan Giles made changes -
          Link This issue is blocked by JDK-8077099 [ JDK-8077099 ]
          jgiles Jonathan Giles made changes -
          Link This issue is blocked by JDK-8077100 [ JDK-8077100 ]
          leifs Leif Samuelsson (Inactive) made changes -
          Reviewed By [leifs]
          ant Anton Tarasov made changes -
          Reviewed By [leifs] [ant, leifs]
          kcr Kevin Rushforth made changes -
          Endorsed By [kcr]
          Reviewed By [ant, leifs] [ant, kcr, leifs]
          vdyakov Victor Dyakov made changes -
          Fix Version/s 9 [ 14949 ]
          Priority P4 [ 4 ] P3 [ 3 ]
          vdyakov Victor Dyakov made changes -
          Reviewed By [ant, kcr, leifs] [ant, kcr, leifs, vdyakov]
          jgiles Jonathan Giles made changes -
          Due Date 2015-10-15
          Integration Due 2015-08-14
          vdyakov Victor Dyakov made changes -
          Assignee Jonathan Giles [ jgiles ] Victor Dyakov [ vdyakov ]
          vdyakov Victor Dyakov made changes -
          Status Draft [ 10001 ] Submitted [ 10002 ]
          vdyakov Victor Dyakov made changes -
          Assignee Victor Dyakov [ vdyakov ] Jonathan Giles [ jgiles ]
          vdyakov Victor Dyakov made changes -
          Alert Status Red [ 3 ]
          Alert Reason Waiting for candidate review
          vdyakov Victor Dyakov made changes -
          Assignee Jonathan Giles [ jgiles ] Mark Reinhold [ mr ]
          alioffe Alexander Ioffe (Inactive) made changes -
          Alert Reason Waiting for candidate review Waiting for candidate review
          SQE do not have resource for testing now.
          Test plan creation is not even started - no resources
          vdyakov Victor Dyakov made changes -
          Alert Reason Waiting for candidate review
          SQE do not have resource for testing now.
          Test plan creation is not even started - no resources
          Waiting for candidate review. Eng Dev plan is ready and funded. This is critical JEP for FX and modularization.
          SQE do not have resource for testing now.
          Test plan creation is not even started - no resources.
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, many developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, many developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to therefore provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          ### Project One: Make UI control skins public API

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The intention would be to move many JavaFX control skins into the appropriate package, most probably javafx.scene.control.skin. There is no intention to also move across the related behavior classes, as these will be handled separately as part of project two below.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          Having already been briefly reviewed, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField.

          ### Project Two: Improve support for input mapping

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has been intermittently returned to and revised since mid-2012. The current implementations being explored presently hold a lot of promise - they considerably clean up the behavior code, and additionally expose the behavior mappings in a simple way, allowing for easier modification of input maps at runtime by external users.

          ### Project Three: Review and make public relevant CSS API

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).

          ### Summary

          The end result of these three projects is the creation of:

          - A new package 'javafx.scene.control.skin' for UI control skins, after being API reviewed, standardised, documented, and tested.
          - Additional API for specifying input mappings
          - The translation of existing UI control behavior classes to the new input map API
          - The possible creation of a javafx.scene.control.behavior' package for these input map classes, to more easily allow for subclassing and stronger input mapping customising of existing UI controls.
          - The moving and API review, standardisation, documentation, and testing of necessary CSS-related classes.


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility. Of course, this does not mean that we can break anything we like - our intention is to only introduce new API (and evolve existing private API) that is directly broken as a result of the modularity restrictions. All other existing APIs that are not impacted by modularity will remain the same.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          **Project One: Make UI control skins public API**

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The intention would be to move many JavaFX control skins into the appropriate package, most probably javafx.scene.control.skin. There is no intention to also move across the related behavior classes, as these will be handled separately as part of project two below.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          This research is already quite far progressed in a separate sandbox repo, and whilst time-consuming, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField. Finally, there are a few classes where ideally methods would be made private, except for the fact that other, implementation-only classes rely on this API. Solutions will be investigated for all of these issues, and no major concerns exist.

          It should be noted that the intent in moving skins into public API in 9 is to ensure their availability in a jigsaw world. The API will be purposefully kept to the bare minimum (and reduced as significantly as possible), with the intention to follow this up in subsequent releases with more useful API that developers request. As is well appreciated, API is (mostly) forever, so allowing for the public skin API to mature over a few (update) releases seems like the best course of action.

          **Project Two: Improve support for input mapping**

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has been intermittently returned to and revised since mid-2012. The current implementations being explored presently hold a lot of promise - they considerably clean up the behavior code, and additionally expose the behavior mappings in a simple way, allowing for easier modification of input maps at runtime by external users.

          The current state of this project is that all JavaFX UI controls have been ported to a prototype InputMap implementation with excellent results. The intention will be to expose this API to more developers ASAP to gather feedback and to revise it. There are no major concerns with this project as of now.

          **Project Three: Review and make public relevant CSS API**

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).

          At present this work has only been investigated lightly - much more work needs to be done to get this across the line.

          **Summary**

          The end result of these three projects is the creation of:

          - A new package 'javafx.scene.control.skin' for UI control skins, after being API reviewed, standardised, documented, and tested.
          - Additional API for specifying input mappings
          - The translation of existing UI control behavior classes to the new input map API
          - The moving and API review, standardisation, documentation, and testing of necessary CSS-related classes.


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          vdyakov Victor Dyakov made changes -
          Component/s javafx [ 11900 ]
          Component/s client-libs [ 10307 ]
          vdyakov Victor Dyakov made changes -
          Subcomponent controls [ 1378 ]
          vdyakov Victor Dyakov made changes -
          Component/s client-libs [ 10307 ]
          Component/s javafx [ 11900 ]
          vdyakov Victor Dyakov made changes -
          Subcomponent controls [ 1378 ]
          mr Mark Reinhold made changes -
          Description Summary
          -------

          Provide new API to work around forthcoming compilation and runtime issues in JavaFX UI controls / CSS due to reliance on com.sun.* packaged classes by external developers.

          Goals
          -----

          Many developers who use JavaFX UI controls and CSS functionality ignore the warnings to avoid com.sun.* internal APIs. In many cases to achieve the desired result, developers have no choice but to use these internal APIs. With the forthcoming release of Java 9 and jigsaw modularity, developers will find that their software will no longer compile or execute, given the loss of com.sun.* packages from their scope. The goal of this JEP is to provide public API that re-offers the functionality that has been lost.

          Non-Goals
          ---------

          Given the implications of jigsaw modularity (that is, com.sun.* disappears from public access), there is no way to do this in a way that retains any degree of backwards compatibility. Therefore, there is no intention as part of this JEP to retain backwards compatibility. Of course, this does not mean that we can break anything we like - our intention is to only introduce new API (and evolve existing private API) that is directly broken as a result of the modularity restrictions. All other existing APIs that are not impacted by modularity will remain the same.

          Success Metrics
          ---------------

          Success can be measured in two ways:

          - That projects that depend on JavaFX internal API (such as Scene Builder, ControlsFX, JFXtras, etc) can continue to operate after updating to the new API with no loss of functionality. Given that the three mentioned projects are all open source, they provide an excellent test bed to ensure that all necessary API has been provided.
          - That the result of discussions around new API (such as the input map work required for control behaviors) results in improved functionality that the community has long asked for. Ultimately, if all works to plan, third party controls should be buildable without any dependency on internal API.

          Motivation
          ----------

          Without this work being done, many projects will need to significantly strip back the functionality that they offer, and in some cases this may prove fatal to certain projects. For example, without access to the internal API that Scene Builder currently has, it may struggle to be viable - certainly its ability to offer functionality around CSS styling and manipulation of control properties will be severely undermined, and these are two of the core pieces of functionality of Scene Builder (along with its ability to lay out user interfaces). The same argument exists for most other JavaFX-based projects with any degree of custom control or CSS implementation.

          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of which is important in reaching the final goal. There is no particular order to which these projects must be undertaken.

          **Project One: Make UI control skins public API**

          At present all skins are located in com.sun.javafx.scene.control.skin. This means that third parties who have extended a skin (e.g. the TextFieldSkin) to add additional functionality, to override an existing method, or to otherwise modify the visuals and / or behavior of the control skin, will be left without a functioning application in JDK 9. Of course, this is the fault of users who depended on non-public API, but it has long been discussed to make this API public, to better enable third party modification of UI controls. JDK 9 modularity is a strong argument towards undertaking this work.

          The intention would be to move many JavaFX control skins into the appropriate package, most probably javafx.scene.control.skin. There is no intention to also move across the related behavior classes, as these will be handled separately as part of project two below.

          The vast bulk of this work is to review each existing skin class, ensuring the following:

          - That there is API consistency between skins.
          - That high-quality javadoc and unit tests exist.
          - That the API in each class is kept to a minimum by changing public methods to private.

          This research is already quite far progressed in a separate sandbox repo, and whilst time-consuming, there are only a few classes of concern (utility classes, duplicated classes, truly implementation-only classes) that need further analysis. On top of this, there is a handful of classes that may qualify for being brought into the javafx.scene.control package (or at the least, will need further consideration as they are not truly skins). These include FXVK (the virtual keyboard), ColorPalette, CustomColorDialog, DatePickerContent, and InputField. Finally, there are a few classes where ideally methods would be made private, except for the fact that other, implementation-only classes rely on this API. Solutions will be investigated for all of these issues, and no major concerns exist.

          It should be noted that the intent in moving skins into public API in 9 is to ensure their availability in a jigsaw world. The API will be purposefully kept to the bare minimum (and reduced as significantly as possible), with the intention to follow this up in subsequent releases with more useful API that developers request. As is well appreciated, API is (mostly) forever, so allowing for the public skin API to mature over a few (update) releases seems like the best course of action.

          **Project Two: Improve support for input mapping**

          At present input mapping (that is, the 'Controller' aspect of the JavaFX UI controls MVC design pattern) is handled entirely as an implementation detail. All third party UI controls that wanted to define behaviors either had the choice of using private API, or to co-mingle their controller code inside the view code. Neither of these approaches is anywhere near ideal.

          Because of this lack of public API, a major API gap exists - the ability to easily add, remove, and modify keyboard / mouse / touch / etc mappings in a clean and well-defined fashion.

          There has been a fairly considerable amount of exploration in this area as part of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has been intermittently returned to and revised since mid-2012. The current implementations being explored presently hold a lot of promise - they considerably clean up the behavior code, and additionally expose the behavior mappings in a simple way, allowing for easier modification of input maps at runtime by external users.

          The current state of this project is that all JavaFX UI controls have been ported to a prototype InputMap implementation with excellent results. The intention will be to expose this API to more developers ASAP to gather feedback and to revise it. There are no major concerns with this project as of now.

          **Project Three: Review and make public relevant CSS API**

          As with project one, this project relates to bringing out into the public API that currently resides in com.sun.* packages. Again, this will require code review to minimise the API, as well as additional unit tests and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder to compile in JDK 9 (with the appropriate modifications - as noted these changes will not be backwards compatible).

          At present this work has only been investigated lightly - much more work needs to be done to get this across the line.

          **Summary**

          The end result of these three projects is the creation of:

          - A new package 'javafx.scene.control.skin' for UI control skins, after being API reviewed, standardised, documented, and tested.
          - Additional API for specifying input mappings
          - The translation of existing UI control behavior classes to the new input map API
          - The moving and API review, standardisation, documentation, and testing of necessary CSS-related classes.


          Alternatives
          ------------

          The only alternative approach is to not do this work. The implications to the wider JavaFX community will be significant, and as mentioned, to many projects either fatal or at the very least hugely inconveniencing and / or will result in the need to remove functionality from their offerings.

          Testing
          -------

          Testing will be limited to additional unit tests that require no special platform or hardware requirements.

          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is anticipated. Some research has been performed to better understand the requirements, but there is no denying that to end up with a good API will require a decent investment of time.

          This work could of course become entirely unnecessary if the implication of modules on com.sun.* packaged internal API were not to exist. As of now I am not aware of this changing, hence the planning that has already been done, and the end result being the introduction of this JEP.

          Dependences
          -----------

          There are no dependences from this JEP to other JEPs.
          Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The current state of this project is that all JavaFX UI controls have
          been ported to a prototype `InputMap` implementation with excellent
          results. The intent is to expose this API to more developers ASAP to
          gather feedback and to revise it. There are no major concerns with this
          project as of now.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          mr Mark Reinhold made changes -
          Assignee Mark Reinhold [ mr ] Jonathan Giles [ jgiles ]
          mr Mark Reinhold made changes -
          Author jgiles
          jgiles Jonathan Giles made changes -
          Assignee Jonathan Giles [ jgiles ] Mark Reinhold [ mr ]
          jgiles Jonathan Giles made changes -
          Summary Improving JavaFX UI Controls for JDK 9 Modularization Prepare JavaFX UI Controls and CSS APIs for Modularization
          mr Mark Reinhold made changes -
          Status Submitted [ 10002 ] Candidate [ 10003 ]
          JEP Number 253
          mr Mark Reinhold made changes -
          Summary Prepare JavaFX UI Controls and CSS APIs for Modularization JEP 253: Prepare JavaFX UI Controls and CSS APIs for Modularization
          mr Mark Reinhold made changes -
          Security Confidential [ 10000 ]
          mr Mark Reinhold made changes -
          Summary JEP 253: Prepare JavaFX UI Controls and CSS APIs for Modularization JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization
          jgiles Jonathan Giles made changes -
          Author Jonathan Giles
          vdyakov Victor Dyakov made changes -
          Alert Reason Waiting for candidate review. Eng Dev plan is ready and funded. This is critical JEP for FX and modularization.
          SQE do not have resource for testing now.
          Test plan creation is not even started - no resources.
          Eng Dev plan is ready and funded. This is critical JEP for FX and modularization.
          SQE do not have resource for testing now.
          Test plan creation is not even started - no resources.
          vdyakov Victor Dyakov made changes -
          Alert Status Red [ 3 ] Green [ 1 ]
          vdyakov Victor Dyakov made changes -
          Alert Reason Eng Dev plan is ready and funded. This is critical JEP for FX and modularization.
          SQE do not have resource for testing now.
          Test plan creation is not even started - no resources.
          Eng Dev plan is ready and funded.
          vdyakov Victor Dyakov made changes -
          Assignee Mark Reinhold [ mr ] Jonathan Giles [ jgiles ]
          jgiles Jonathan Giles made changes -
          Status Candidate [ 10003 ] Proposed to Target [ 10004 ]
          vdyakov Victor Dyakov made changes -
          Assignee Jonathan Giles [ jgiles ] Victor Dyakov [ vdyakov ]
          vdyakov Victor Dyakov made changes -
          Status Proposed to Target [ 10004 ] Candidate [ 10003 ]
          vdyakov Victor Dyakov made changes -
          Assignee Victor Dyakov [ vdyakov ] Jonathan Giles [ jgiles ]
          vdyakov Victor Dyakov made changes -
          Alert Status Green [ 1 ] Yellow [ 2 ]
          vdyakov Victor Dyakov made changes -
          Alert Reason Eng Dev plan is ready and funded. Pending SQE plan before moving to Proposed To Target and review for Targeted state.
          Eng Dev plan is ready and funded.
          vdyakov Victor Dyakov made changes -
          Alert Reason Pending SQE plan before moving to Proposed To Target and review for Targeted state.
          Eng Dev plan is ready and funded.
          Pending SQE plan before moving to Proposed To Target by June 3rd and review for Targeted state.
          Eng Dev plan is ready and funded.
          mchung Mandy Chung made changes -
          Labels modularization team-clientlibs jdkinternals modularization team-clientlibs
          apikalev Andrey Pikalev made changes -
          Labels jdkinternals modularization team-clientlibs jdkinternals modularization no-tck team-clientlibs
          vdyakov Victor Dyakov made changes -
          Alert Reason Pending SQE plan before moving to Proposed To Target by June 3rd and review for Targeted state.
          Eng Dev plan is ready and funded.
          Eng Dev plan is ready and funded. Test Plan is created.
          vdyakov Victor Dyakov made changes -
          Alert Status Yellow [ 2 ] Green [ 1 ]
          vdyakov Victor Dyakov made changes -
          Assignee Jonathan Giles [ jgiles ] Victor Dyakov [ vdyakov ]
          vdyakov Victor Dyakov made changes -
          Status Candidate [ 10003 ] Proposed to Target [ 10004 ]
          vdyakov Victor Dyakov made changes -
          Assignee Victor Dyakov [ vdyakov ] Jonathan Giles [ jgiles ]
          vdyakov Victor Dyakov made changes -
          Integration Due 2015-08-14 2015-08-28
          vdyakov Victor Dyakov made changes -
          Due Date 2015-10-15 2015-10-29
          vdyakov Victor Dyakov made changes -
          Alert Reason Eng Dev plan is ready and funded. Test Plan is created. Pending move to Targeted state.
          Eng Dev plan is ready and funded. Test Plan is created.
          vdyakov Victor Dyakov made changes -
          Alert Status Green [ 1 ] Red [ 3 ]
          vdyakov Victor Dyakov made changes -
          Alert Reason Pending move to Targeted state.
          Eng Dev plan is ready and funded. Test Plan is created.
          Pending review to move on Targeted state.
          Eng Dev plan is ready and funded. Test Plan is created.
          vdyakov Victor Dyakov made changes -
          Link This issue is blocked by JDK-8081524 [ JDK-8081524 ]
          vdyakov Victor Dyakov made changes -
          Link This issue is blocked by JDK-8081525 [ JDK-8081525 ]
          vdyakov Victor Dyakov made changes -
          Link This issue is blocked by JDK-8081526 [ JDK-8081526 ]
          vdyakov Victor Dyakov made changes -
          Due Date 2015-10-29 2015-11-27
          vdyakov Victor Dyakov made changes -
          Alert Status Red [ 3 ] Green [ 1 ]
          vdyakov Victor Dyakov made changes -
          Alert Reason Pending review to move on Targeted state.
          Eng Dev plan is ready and funded. Test Plan is created.
          Ready for review to move on Targeted status.
          Eng Dev plan is ready and funded. Test Plan is created.
          mr Mark Reinhold made changes -
          Status Proposed to Target [ 10004 ] Candidate [ 10003 ]
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The current state of this project is that all JavaFX UI controls have
          been ported to a prototype `InputMap` implementation with excellent
          results. The intent is to expose this API to more developers ASAP to
          gather feedback and to revise it. There are no major concerns with this
          project as of now.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`
          `ButtonBarSkin`
          `ButtonSkin`
          `CellSkinBase`
          `CheckBoxSkin`
          `ChoiceBoxSkin`
          `ColorPickerSkin`
          `ComboBoxBaseSkin`
          `ComboBoxListViewSkin`
          `ComboBoxPopupControl`
          `ContextMenuSkin`
          `DateCellSkin`
          `DatePickerSkin`
          `HyperlinkSkin`
          `LabelSkin`
          `LabeledSkinBase`
          `ListCellSkin`
          `ListViewSkin`
          `MenuBarSkin`
          `MenuButtonSkin`
          `MenuButtonSkinBase`
          `NestedTableColumnHeader`
          `PaginationSkin`
          `ProgressBarSkin`
          `ProgressIndicatorSkin`
          `RadioButtonSkin`
          `ScrollBarSkin`
          `ScrollPaneSkin`
          `SeparatorSkin`
          `SliderSkin`
          `SpinnerSkin`
          `SplitMenuButtonSkin`
          `SplitPaneSkin`
          `TabPaneSkin`
          `TableCellSkin`
          `TableCellSkinBase`
          `TableColumnHeader`
          `TableHeaderRow`
          `TableRowSkin`
          `TableRowSkinBase`
          `TableViewSkin`
          `TableViewSkinBase`
          `TextAreaSkin`
          `TextFieldSkin`
          `TextInputControlSkin`
          `TitledPaneSkin`
          `ToggleButtonSkin`
          `ToolBarSkin`
          `TooltipSkin`
          `TreeCellSkin`
          `TreeTableCellSkin`
          `TreeTableRowSkin`
          `TreeTableViewSkin`
          `TreeViewSkin`
          `VirtualContainerBase`
          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          javafx.scene.input.InputMap
          javafx.scene.input.InputMap.Mapping
          javafx.scene.input.InputMap.KeyMapping
          javafx.scene.input.InputMap.KeyMappingInterceptor
          javafx.scene.input.InputMap.MouseMapping
          javafx.scene.input.InputMap.MouseMappingInterceptor
          javafx.scene.input.KeyBinding

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

          /**
           * Creates the new InputMap instance which is related specifically to the
           * given Node.
           * @param node The Node for which this InputMap is attached.
           */
          public InputMap(N node);

          /**
           * A mutable list of interceptors. The interceptors list is a collection of
           * {@link Predicate predicates} that are run whenever an event is being
           * looked up. If any of the interceptor predicates return true, the event is
           * not handled and it is not consumed.
           */
          public final ObservableList<Predicate<? extends Event>> getInterceptors();

          /**
           * The Node for which this InputMap is attached.
           */
          public final N getNode();

          /**
           * A mutable list of input mappings. Each will be considered whenever an
           * input event is being looked up, and one of which may be used to handle
           * the input event, based on the specifificity returned by each mapping
           * (that is, the mapping with the highest specificity wins).
           */
          public ObservableList<Mapping<?>> getMappings();

          /**
           * A mutable list of child InputMaps. An InputMap may have child input maps,
           * as this allows for easy addition
           * of mappings that are state-specific. For example, if a Node can be in two
           * different states, and the input mappings are different for each, then it
           * makes sense to have one root (and empty) InputMap, with two children
           * input maps, where each is populated with the specific input mappings for
           * one of the two states. To prevent the wrong input map from being considered,
           * it is simply a matter of setting appropriate
           * {@link #getInterceptors() interceptors} on each map, so that they are only
           * considered in one of the two states.
           */
          public ObservableList<InputMap<N>> getChildInputMaps();

          /**
           * Disposes all child InputMaps, removes all event handlers from the Node,
           * and clears the mappings list.
           */
          public void dispose();

          // This is the API inherited by implementing the EventHandler<Event> interface,
          // and is what is called whenever the owner Node receives events on the event
          // handlers that this InputMap has installed into it.
          @Override public void handle(Event e)

          /**
           * Looks up the most specific mapping given the input, ignoring all
           * interceptors. The valid values that can be passed into this method is
           * based on the values returned by the {@link Mapping#getMappingKey()}
           * method. Based on the subclasses of Mapping that ship with JavaFX, the
           * valid values are therefore:
           *
           * <ul>
           * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
           * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
           * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
           * </ul>
           *
           * For other Mapping subclasses, refer to their javadoc, and specifically
           * what is returned by {@link Mapping#getMappingKey()},
           *
           * @param mappingKey
           * @return
           */
          public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`
          `ButtonBarSkin`
          `ButtonSkin`
          `CellSkinBase`
          `CheckBoxSkin`
          `ChoiceBoxSkin`
          `ColorPickerSkin`
          `ComboBoxBaseSkin`
          `ComboBoxListViewSkin`
          `ComboBoxPopupControl`
          `ContextMenuSkin`
          `DateCellSkin`
          `DatePickerSkin`
          `HyperlinkSkin`
          `LabelSkin`
          `LabeledSkinBase`
          `ListCellSkin`
          `ListViewSkin`
          `MenuBarSkin`
          `MenuButtonSkin`
          `MenuButtonSkinBase`
          `NestedTableColumnHeader`
          `PaginationSkin`
          `ProgressBarSkin`
          `ProgressIndicatorSkin`
          `RadioButtonSkin`
          `ScrollBarSkin`
          `ScrollPaneSkin`
          `SeparatorSkin`
          `SliderSkin`
          `SpinnerSkin`
          `SplitMenuButtonSkin`
          `SplitPaneSkin`
          `TabPaneSkin`
          `TableCellSkin`
          `TableCellSkinBase`
          `TableColumnHeader`
          `TableHeaderRow`
          `TableRowSkin`
          `TableRowSkinBase`
          `TableViewSkin`
          `TableViewSkinBase`
          `TextAreaSkin`
          `TextFieldSkin`
          `TextInputControlSkin`
          `TitledPaneSkin`
          `ToggleButtonSkin`
          `ToolBarSkin`
          `TooltipSkin`
          `TreeCellSkin`
          `TreeTableCellSkin`
          `TreeTableRowSkin`
          `TreeTableViewSkin`
          `TreeViewSkin`
          `VirtualContainerBase`
          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          javafx.scene.input.InputMap
          javafx.scene.input.InputMap.Mapping
          javafx.scene.input.InputMap.KeyMapping
          javafx.scene.input.InputMap.KeyMappingInterceptor
          javafx.scene.input.InputMap.MouseMapping
          javafx.scene.input.InputMap.MouseMappingInterceptor
          javafx.scene.input.KeyBinding

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

          /**
           * Creates the new InputMap instance which is related specifically to the
           * given Node.
           * @param node The Node for which this InputMap is attached.
           */
          public InputMap(N node);

          /**
           * A mutable list of interceptors. The interceptors list is a collection of
           * {@link Predicate predicates} that are run whenever an event is being
           * looked up. If any of the interceptor predicates return true, the event is
           * not handled and it is not consumed.
           */
          public final ObservableList<Predicate<? extends Event>> getInterceptors();

          /**
           * The Node for which this InputMap is attached.
           */
          public final N getNode();

          /**
           * A mutable list of input mappings. Each will be considered whenever an
           * input event is being looked up, and one of which may be used to handle
           * the input event, based on the specifificity returned by each mapping
           * (that is, the mapping with the highest specificity wins).
           */
          public ObservableList<Mapping<?>> getMappings();

          /**
           * A mutable list of child InputMaps. An InputMap may have child input maps,
           * as this allows for easy addition
           * of mappings that are state-specific. For example, if a Node can be in two
           * different states, and the input mappings are different for each, then it
           * makes sense to have one root (and empty) InputMap, with two children
           * input maps, where each is populated with the specific input mappings for
           * one of the two states. To prevent the wrong input map from being considered,
           * it is simply a matter of setting appropriate
           * {@link #getInterceptors() interceptors} on each map, so that they are only
           * considered in one of the two states.
           */
          public ObservableList<InputMap<N>> getChildInputMaps();

          /**
           * Disposes all child InputMaps, removes all event handlers from the Node,
           * and clears the mappings list.
           */
          public void dispose();

          // This is the API inherited by implementing the EventHandler<Event> interface,
          // and is what is called whenever the owner Node receives events on the event
          // handlers that this InputMap has installed into it.
          @Override public void handle(Event e)

          /**
           * Looks up the most specific mapping given the input, ignoring all
           * interceptors. The valid values that can be passed into this method is
           * based on the values returned by the {@link Mapping#getMappingKey()}
           * method. Based on the subclasses of Mapping that ship with JavaFX, the
           * valid values are therefore:
           *
           * <ul>
           * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
           * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
           * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
           * </ul>
           *
           * For other Mapping subclasses, refer to their javadoc, and specifically
           * what is returned by {@link Mapping#getMappingKey()},
           *
           * @param mappingKey
           * @return
           */
          public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`

          `ButtonBarSkin`

          `ButtonSkin`

          `CellSkinBase`

          `CheckBoxSkin`

          `ChoiceBoxSkin`

          `ColorPickerSkin`
          `ComboBoxBaseSkin`
          `ComboBoxListViewSkin`
          `ComboBoxPopupControl`
          `ContextMenuSkin`
          `DateCellSkin`
          `DatePickerSkin`
          `HyperlinkSkin`
          `LabelSkin`
          `LabeledSkinBase`
          `ListCellSkin`
          `ListViewSkin`
          `MenuBarSkin`
          `MenuButtonSkin`
          `MenuButtonSkinBase`
          `NestedTableColumnHeader`
          `PaginationSkin`
          `ProgressBarSkin`
          `ProgressIndicatorSkin`
          `RadioButtonSkin`
          `ScrollBarSkin`
          `ScrollPaneSkin`
          `SeparatorSkin`
          `SliderSkin`
          `SpinnerSkin`
          `SplitMenuButtonSkin`
          `SplitPaneSkin`
          `TabPaneSkin`
          `TableCellSkin`
          `TableCellSkinBase`
          `TableColumnHeader`
          `TableHeaderRow`
          `TableRowSkin`
          `TableRowSkinBase`
          `TableViewSkin`
          `TableViewSkinBase`
          `TextAreaSkin`
          `TextFieldSkin`
          `TextInputControlSkin`
          `TitledPaneSkin`
          `ToggleButtonSkin`
          `ToolBarSkin`
          `TooltipSkin`
          `TreeCellSkin`
          `TreeTableCellSkin`
          `TreeTableRowSkin`
          `TreeTableViewSkin`
          `TreeViewSkin`
          `VirtualContainerBase`
          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          javafx.scene.input.InputMap
          javafx.scene.input.InputMap.Mapping
          javafx.scene.input.InputMap.KeyMapping
          javafx.scene.input.InputMap.KeyMappingInterceptor
          javafx.scene.input.InputMap.MouseMapping
          javafx.scene.input.InputMap.MouseMappingInterceptor
          javafx.scene.input.KeyBinding

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

          /**
           * Creates the new InputMap instance which is related specifically to the
           * given Node.
           * @param node The Node for which this InputMap is attached.
           */
          public InputMap(N node);

          /**
           * A mutable list of interceptors. The interceptors list is a collection of
           * {@link Predicate predicates} that are run whenever an event is being
           * looked up. If any of the interceptor predicates return true, the event is
           * not handled and it is not consumed.
           */
          public final ObservableList<Predicate<? extends Event>> getInterceptors();

          /**
           * The Node for which this InputMap is attached.
           */
          public final N getNode();

          /**
           * A mutable list of input mappings. Each will be considered whenever an
           * input event is being looked up, and one of which may be used to handle
           * the input event, based on the specifificity returned by each mapping
           * (that is, the mapping with the highest specificity wins).
           */
          public ObservableList<Mapping<?>> getMappings();

          /**
           * A mutable list of child InputMaps. An InputMap may have child input maps,
           * as this allows for easy addition
           * of mappings that are state-specific. For example, if a Node can be in two
           * different states, and the input mappings are different for each, then it
           * makes sense to have one root (and empty) InputMap, with two children
           * input maps, where each is populated with the specific input mappings for
           * one of the two states. To prevent the wrong input map from being considered,
           * it is simply a matter of setting appropriate
           * {@link #getInterceptors() interceptors} on each map, so that they are only
           * considered in one of the two states.
           */
          public ObservableList<InputMap<N>> getChildInputMaps();

          /**
           * Disposes all child InputMaps, removes all event handlers from the Node,
           * and clears the mappings list.
           */
          public void dispose();

          // This is the API inherited by implementing the EventHandler<Event> interface,
          // and is what is called whenever the owner Node receives events on the event
          // handlers that this InputMap has installed into it.
          @Override public void handle(Event e)

          /**
           * Looks up the most specific mapping given the input, ignoring all
           * interceptors. The valid values that can be passed into this method is
           * based on the values returned by the {@link Mapping#getMappingKey()}
           * method. Based on the subclasses of Mapping that ship with JavaFX, the
           * valid values are therefore:
           *
           * <ul>
           * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
           * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
           * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
           * </ul>
           *
           * For other Mapping subclasses, refer to their javadoc, and specifically
           * what is returned by {@link Mapping#getMappingKey()},
           *
           * @param mappingKey
           * @return
           */
          public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`

          `ButtonBarSkin`

          `ButtonSkin`

          `CellSkinBase`

          `CheckBoxSkin`

          `ChoiceBoxSkin`

          `ColorPickerSkin`
          `ComboBoxBaseSkin`
          `ComboBoxListViewSkin`
          `ComboBoxPopupControl`
          `ContextMenuSkin`
          `DateCellSkin`
          `DatePickerSkin`
          `HyperlinkSkin`
          `LabelSkin`
          `LabeledSkinBase`
          `ListCellSkin`
          `ListViewSkin`
          `MenuBarSkin`
          `MenuButtonSkin`
          `MenuButtonSkinBase`
          `NestedTableColumnHeader`
          `PaginationSkin`
          `ProgressBarSkin`
          `ProgressIndicatorSkin`
          `RadioButtonSkin`
          `ScrollBarSkin`
          `ScrollPaneSkin`
          `SeparatorSkin`
          `SliderSkin`
          `SpinnerSkin`
          `SplitMenuButtonSkin`
          `SplitPaneSkin`
          `TabPaneSkin`
          `TableCellSkin`
          `TableCellSkinBase`
          `TableColumnHeader`
          `TableHeaderRow`
          `TableRowSkin`
          `TableRowSkinBase`
          `TableViewSkin`
          `TableViewSkinBase`
          `TextAreaSkin`
          `TextFieldSkin`
          `TextInputControlSkin`
          `TitledPaneSkin`
          `ToggleButtonSkin`
          `ToolBarSkin`
          `TooltipSkin`
          `TreeCellSkin`
          `TreeTableCellSkin`
          `TreeTableRowSkin`
          `TreeTableViewSkin`
          `TreeViewSkin`
          `VirtualContainerBase`
          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          javafx.scene.input.InputMap
          javafx.scene.input.InputMap.Mapping
          javafx.scene.input.InputMap.KeyMapping
          javafx.scene.input.InputMap.KeyMappingInterceptor
          javafx.scene.input.InputMap.MouseMapping
          javafx.scene.input.InputMap.MouseMappingInterceptor
          javafx.scene.input.KeyBinding

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

          /**
           * Creates the new InputMap instance which is related specifically to the
           * given Node.
           * @param node The Node for which this InputMap is attached.
           */
          public InputMap(N node);

          /**
           * A mutable list of interceptors. The interceptors list is a collection of
           * {@link Predicate predicates} that are run whenever an event is being
           * looked up. If any of the interceptor predicates return true, the event is
           * not handled and it is not consumed.
           */
          public final ObservableList<Predicate<? extends Event>> getInterceptors();

          /**
           * The Node for which this InputMap is attached.
           */
          public final N getNode();

          /**
           * A mutable list of input mappings. Each will be considered whenever an
           * input event is being looked up, and one of which may be used to handle
           * the input event, based on the specifificity returned by each mapping
           * (that is, the mapping with the highest specificity wins).
           */
          public ObservableList<Mapping<?>> getMappings();

          /**
           * A mutable list of child InputMaps. An InputMap may have child input maps,
           * as this allows for easy addition
           * of mappings that are state-specific. For example, if a Node can be in two
           * different states, and the input mappings are different for each, then it
           * makes sense to have one root (and empty) InputMap, with two children
           * input maps, where each is populated with the specific input mappings for
           * one of the two states. To prevent the wrong input map from being considered,
           * it is simply a matter of setting appropriate
           * {@link #getInterceptors() interceptors} on each map, so that they are only
           * considered in one of the two states.
           */
          public ObservableList<InputMap<N>> getChildInputMaps();

          /**
           * Disposes all child InputMaps, removes all event handlers from the Node,
           * and clears the mappings list.
           */
          public void dispose();

          // This is the API inherited by implementing the EventHandler<Event> interface,
          // and is what is called whenever the owner Node receives events on the event
          // handlers that this InputMap has installed into it.
          @Override public void handle(Event e)

          /**
           * Looks up the most specific mapping given the input, ignoring all
           * interceptors. The valid values that can be passed into this method is
           * based on the values returned by the {@link Mapping#getMappingKey()}
           * method. Based on the subclasses of Mapping that ship with JavaFX, the
           * valid values are therefore:
           *
           * <ul>
           * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
           * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
           * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
           * </ul>
           *
           * For other Mapping subclasses, refer to their javadoc, and specifically
           * what is returned by {@link Mapping#getMappingKey()},
           *
           * @param mappingKey
           * @return
           */
          public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`

          `ButtonBarSkin`

          `ButtonSkin`

          `CellSkinBase`

          `CheckBoxSkin`

          `ChoiceBoxSkin`

          `ColorPickerSkin`

          `ComboBoxBaseSkin`

          `ComboBoxListViewSkin`

          `ComboBoxPopupControl`

          `ContextMenuSkin`

          `DateCellSkin`

          `DatePickerSkin`

          `HyperlinkSkin`

          `LabelSkin`

          `LabeledSkinBase`

          `ListCellSkin`

          `ListViewSkin`

          `MenuBarSkin`

          `MenuButtonSkin`

          `MenuButtonSkinBase`

          `NestedTableColumnHeader`

          `PaginationSkin`

          `ProgressBarSkin`

          `ProgressIndicatorSkin`

          `RadioButtonSkin`

          `ScrollBarSkin`

          `ScrollPaneSkin`

          `SeparatorSkin`

          `SliderSkin`

          `SpinnerSkin`

          `SplitMenuButtonSkin`

          `SplitPaneSkin`

          `TabPaneSkin`

          `TableCellSkin`

          `TableCellSkinBase`

          `TableColumnHeader`

          `TableHeaderRow`

          `TableRowSkin`

          `TableRowSkinBase`

          `TableViewSkin`

          `TableViewSkinBase`

          `TextAreaSkin`

          `TextFieldSkin`

          `TextInputControlSkin`

          `TitledPaneSkin`

          `ToggleButtonSkin`

          `ToolBarSkin`

          `TooltipSkin`

          `TreeCellSkin`

          `TreeTableCellSkin`

          `TreeTableRowSkin`

          `TreeTableViewSkin`

          `TreeViewSkin`

          `VirtualContainerBase`

          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          javafx.scene.input.InputMap
          javafx.scene.input.InputMap.Mapping
          javafx.scene.input.InputMap.KeyMapping
          javafx.scene.input.InputMap.KeyMappingInterceptor
          javafx.scene.input.InputMap.MouseMapping
          javafx.scene.input.InputMap.MouseMappingInterceptor
          javafx.scene.input.KeyBinding

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

          /**
           * Creates the new InputMap instance which is related specifically to the
           * given Node.
           * @param node The Node for which this InputMap is attached.
           */
          public InputMap(N node);

          /**
           * A mutable list of interceptors. The interceptors list is a collection of
           * {@link Predicate predicates} that are run whenever an event is being
           * looked up. If any of the interceptor predicates return true, the event is
           * not handled and it is not consumed.
           */
          public final ObservableList<Predicate<? extends Event>> getInterceptors();

          /**
           * The Node for which this InputMap is attached.
           */
          public final N getNode();

          /**
           * A mutable list of input mappings. Each will be considered whenever an
           * input event is being looked up, and one of which may be used to handle
           * the input event, based on the specifificity returned by each mapping
           * (that is, the mapping with the highest specificity wins).
           */
          public ObservableList<Mapping<?>> getMappings();

          /**
           * A mutable list of child InputMaps. An InputMap may have child input maps,
           * as this allows for easy addition
           * of mappings that are state-specific. For example, if a Node can be in two
           * different states, and the input mappings are different for each, then it
           * makes sense to have one root (and empty) InputMap, with two children
           * input maps, where each is populated with the specific input mappings for
           * one of the two states. To prevent the wrong input map from being considered,
           * it is simply a matter of setting appropriate
           * {@link #getInterceptors() interceptors} on each map, so that they are only
           * considered in one of the two states.
           */
          public ObservableList<InputMap<N>> getChildInputMaps();

          /**
           * Disposes all child InputMaps, removes all event handlers from the Node,
           * and clears the mappings list.
           */
          public void dispose();

          // This is the API inherited by implementing the EventHandler<Event> interface,
          // and is what is called whenever the owner Node receives events on the event
          // handlers that this InputMap has installed into it.
          @Override public void handle(Event e)

          /**
           * Looks up the most specific mapping given the input, ignoring all
           * interceptors. The valid values that can be passed into this method is
           * based on the values returned by the {@link Mapping#getMappingKey()}
           * method. Based on the subclasses of Mapping that ship with JavaFX, the
           * valid values are therefore:
           *
           * <ul>
           * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
           * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
           * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
           * </ul>
           *
           * For other Mapping subclasses, refer to their javadoc, and specifically
           * what is returned by {@link Mapping#getMappingKey()},
           *
           * @param mappingKey
           * @return
           */
          public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`

          `ButtonBarSkin`

          `ButtonSkin`

          `CellSkinBase`

          `CheckBoxSkin`

          `ChoiceBoxSkin`

          `ColorPickerSkin`

          `ComboBoxBaseSkin`

          `ComboBoxListViewSkin`

          `ComboBoxPopupControl`

          `ContextMenuSkin`

          `DateCellSkin`

          `DatePickerSkin`

          `HyperlinkSkin`

          `LabelSkin`

          `LabeledSkinBase`

          `ListCellSkin`

          `ListViewSkin`

          `MenuBarSkin`

          `MenuButtonSkin`

          `MenuButtonSkinBase`

          `NestedTableColumnHeader`

          `PaginationSkin`

          `ProgressBarSkin`

          `ProgressIndicatorSkin`

          `RadioButtonSkin`

          `ScrollBarSkin`

          `ScrollPaneSkin`

          `SeparatorSkin`

          `SliderSkin`

          `SpinnerSkin`

          `SplitMenuButtonSkin`

          `SplitPaneSkin`

          `TabPaneSkin`

          `TableCellSkin`

          `TableCellSkinBase`

          `TableColumnHeader`

          `TableHeaderRow`

          `TableRowSkin`

          `TableRowSkinBase`

          `TableViewSkin`

          `TableViewSkinBase`

          `TextAreaSkin`

          `TextFieldSkin`

          `TextInputControlSkin`

          `TitledPaneSkin`

          `ToggleButtonSkin`

          `ToolBarSkin`

          `TooltipSkin`

          `TreeCellSkin`

          `TreeTableCellSkin`

          `TreeTableRowSkin`

          `TreeTableViewSkin`

          `TreeViewSkin`

          `VirtualContainerBase`

          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          javafx.scene.input.InputMap
          javafx.scene.input.InputMap.Mapping
          javafx.scene.input.InputMap.KeyMapping
          javafx.scene.input.InputMap.KeyMappingInterceptor
          javafx.scene.input.InputMap.MouseMapping
          javafx.scene.input.InputMap.MouseMappingInterceptor
          javafx.scene.input.KeyBinding

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

          /**
           * Creates the new InputMap instance which is related specifically to the
           * given Node.
           * @param node The Node for which this InputMap is attached.
           */
          public InputMap(N node);

          /**
           * A mutable list of interceptors. The interceptors list is a collection of
           * {@link Predicate predicates} that are run whenever an event is being
           * looked up. If any of the interceptor predicates return true, the event is
           * not handled and it is not consumed.
           */
          public final ObservableList<Predicate<? extends Event>> getInterceptors();

          /**
           * The Node for which this InputMap is attached.
           */
          public final N getNode();

          /**
           * A mutable list of input mappings. Each will be considered whenever an
           * input event is being looked up, and one of which may be used to handle
           * the input event, based on the specifificity returned by each mapping
           * (that is, the mapping with the highest specificity wins).
           */
          public ObservableList<Mapping<?>> getMappings();

          /**
           * A mutable list of child InputMaps. An InputMap may have child input maps,
           * as this allows for easy addition
           * of mappings that are state-specific. For example, if a Node can be in two
           * different states, and the input mappings are different for each, then it
           * makes sense to have one root (and empty) InputMap, with two children
           * input maps, where each is populated with the specific input mappings for
           * one of the two states. To prevent the wrong input map from being considered,
           * it is simply a matter of setting appropriate
           * {@link #getInterceptors() interceptors} on each map, so that they are only
           * considered in one of the two states.
           */
          public ObservableList<InputMap<N>> getChildInputMaps();

          /**
           * Disposes all child InputMaps, removes all event handlers from the Node,
           * and clears the mappings list.
           */
          public void dispose();

          // This is the API inherited by implementing the EventHandler<Event> interface,
          // and is what is called whenever the owner Node receives events on the event
          // handlers that this InputMap has installed into it.
          @Override public void handle(Event e)

          /**
           * Looks up the most specific mapping given the input, ignoring all
           * interceptors. The valid values that can be passed into this method is
           * based on the values returned by the {@link Mapping#getMappingKey()}
           * method. Based on the subclasses of Mapping that ship with JavaFX, the
           * valid values are therefore:
           *
           * <ul>
           * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
           * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
           * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
           * </ul>
           *
           * For other Mapping subclasses, refer to their javadoc, and specifically
           * what is returned by {@link Mapping#getMappingKey()},
           *
           * @param mappingKey
           * @return
           */
          public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`

          `ButtonBarSkin`

          `ButtonSkin`

          `CellSkinBase`

          `CheckBoxSkin`

          `ChoiceBoxSkin`

          `ColorPickerSkin`

          `ComboBoxBaseSkin`

          `ComboBoxListViewSkin`

          `ComboBoxPopupControl`

          `ContextMenuSkin`

          `DateCellSkin`

          `DatePickerSkin`

          `HyperlinkSkin`

          `LabelSkin`

          `LabeledSkinBase`

          `ListCellSkin`

          `ListViewSkin`

          `MenuBarSkin`

          `MenuButtonSkin`

          `MenuButtonSkinBase`

          `NestedTableColumnHeader`

          `PaginationSkin`

          `ProgressBarSkin`

          `ProgressIndicatorSkin`

          `RadioButtonSkin`

          `ScrollBarSkin`

          `ScrollPaneSkin`

          `SeparatorSkin`

          `SliderSkin`

          `SpinnerSkin`

          `SplitMenuButtonSkin`

          `SplitPaneSkin`

          `TabPaneSkin`

          `TableCellSkin`

          `TableCellSkinBase`

          `TableColumnHeader`

          `TableHeaderRow`

          `TableRowSkin`

          `TableRowSkinBase`

          `TableViewSkin`

          `TableViewSkinBase`

          `TextAreaSkin`

          `TextFieldSkin`

          `TextInputControlSkin`

          `TitledPaneSkin`

          `ToggleButtonSkin`

          `ToolBarSkin`

          `TooltipSkin`

          `TreeCellSkin`

          `TreeTableCellSkin`

          `TreeTableRowSkin`

          `TreeTableViewSkin`

          `TreeViewSkin`

          `VirtualContainerBase`

          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          `javafx.scene.input.InputMap`

          `javafx.scene.input.InputMap.Mapping`

          `javafx.scene.input.InputMap.KeyMapping`

          `javafx.scene.input.InputMap.KeyMappingInterceptor`

          `javafx.scene.input.InputMap.MouseMapping`

          `javafx.scene.input.InputMap.MouseMappingInterceptor`

          `javafx.scene.input.KeyBinding`

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

              /**
               * Creates the new InputMap instance which is related specifically to the
               * given Node.
               * @param node The Node for which this InputMap is attached.
               */
              public InputMap(N node);

          /**
           * A mutable list of interceptors. The interceptors list is a collection of
           * {@link Predicate predicates} that are run whenever an event is being
           * looked up. If any of the interceptor predicates return true, the event is
           * not handled and it is not consumed.
           */
          public final ObservableList<Predicate<? extends Event>> getInterceptors();

          /**
           * The Node for which this InputMap is attached.
           */
          public final N getNode();

          /**
           * A mutable list of input mappings. Each will be considered whenever an
           * input event is being looked up, and one of which may be used to handle
           * the input event, based on the specifificity returned by each mapping
           * (that is, the mapping with the highest specificity wins).
           */
          public ObservableList<Mapping<?>> getMappings();

          /**
           * A mutable list of child InputMaps. An InputMap may have child input maps,
           * as this allows for easy addition
           * of mappings that are state-specific. For example, if a Node can be in two
           * different states, and the input mappings are different for each, then it
           * makes sense to have one root (and empty) InputMap, with two children
           * input maps, where each is populated with the specific input mappings for
           * one of the two states. To prevent the wrong input map from being considered,
           * it is simply a matter of setting appropriate
           * {@link #getInterceptors() interceptors} on each map, so that they are only
           * considered in one of the two states.
           */
          public ObservableList<InputMap<N>> getChildInputMaps();

          /**
           * Disposes all child InputMaps, removes all event handlers from the Node,
           * and clears the mappings list.
           */
          public void dispose();

          // This is the API inherited by implementing the EventHandler<Event> interface,
          // and is what is called whenever the owner Node receives events on the event
          // handlers that this InputMap has installed into it.
          @Override public void handle(Event e)

          /**
           * Looks up the most specific mapping given the input, ignoring all
           * interceptors. The valid values that can be passed into this method is
           * based on the values returned by the {@link Mapping#getMappingKey()}
           * method. Based on the subclasses of Mapping that ship with JavaFX, the
           * valid values are therefore:
           *
           * <ul>
           * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
           * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
           * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
           * </ul>
           *
           * For other Mapping subclasses, refer to their javadoc, and specifically
           * what is returned by {@link Mapping#getMappingKey()},
           *
           * @param mappingKey
           * @return
           */
          public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`

          `ButtonBarSkin`

          `ButtonSkin`

          `CellSkinBase`

          `CheckBoxSkin`

          `ChoiceBoxSkin`

          `ColorPickerSkin`

          `ComboBoxBaseSkin`

          `ComboBoxListViewSkin`

          `ComboBoxPopupControl`

          `ContextMenuSkin`

          `DateCellSkin`

          `DatePickerSkin`

          `HyperlinkSkin`

          `LabelSkin`

          `LabeledSkinBase`

          `ListCellSkin`

          `ListViewSkin`

          `MenuBarSkin`

          `MenuButtonSkin`

          `MenuButtonSkinBase`

          `NestedTableColumnHeader`

          `PaginationSkin`

          `ProgressBarSkin`

          `ProgressIndicatorSkin`

          `RadioButtonSkin`

          `ScrollBarSkin`

          `ScrollPaneSkin`

          `SeparatorSkin`

          `SliderSkin`

          `SpinnerSkin`

          `SplitMenuButtonSkin`

          `SplitPaneSkin`

          `TabPaneSkin`

          `TableCellSkin`

          `TableCellSkinBase`

          `TableColumnHeader`

          `TableHeaderRow`

          `TableRowSkin`

          `TableRowSkinBase`

          `TableViewSkin`

          `TableViewSkinBase`

          `TextAreaSkin`

          `TextFieldSkin`

          `TextInputControlSkin`

          `TitledPaneSkin`

          `ToggleButtonSkin`

          `ToolBarSkin`

          `TooltipSkin`

          `TreeCellSkin`

          `TreeTableCellSkin`

          `TreeTableRowSkin`

          `TreeTableViewSkin`

          `TreeViewSkin`

          `VirtualContainerBase`

          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          `javafx.scene.input.InputMap`

          `javafx.scene.input.InputMap.Mapping`

          `javafx.scene.input.InputMap.KeyMapping`

          `javafx.scene.input.InputMap.KeyMappingInterceptor`

          `javafx.scene.input.InputMap.MouseMapping`

          `javafx.scene.input.InputMap.MouseMappingInterceptor`

          `javafx.scene.input.KeyBinding`

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

              /**
               * Creates the new InputMap instance which is related specifically to the
               * given Node.
               * @param node The Node for which this InputMap is attached.
               */
              public InputMap(N node);

          /**
           * A mutable list of interceptors. The interceptors list is a collection of
           * {@link Predicate predicates} that are run whenever an event is being
           * looked up. If any of the interceptor predicates return true, the event is
           * not handled and it is not consumed.
           */
          public final ObservableList<Predicate<? extends Event>> getInterceptors();

          /**
           * The Node for which this InputMap is attached.
           */
          public final N getNode();

          /**
           * A mutable list of input mappings. Each will be considered whenever an
           * input event is being looked up, and one of which may be used to handle
           * the input event, based on the specifificity returned by each mapping
           * (that is, the mapping with the highest specificity wins).
           */
          public ObservableList<Mapping<?>> getMappings();

          /**
           * A mutable list of child InputMaps. An InputMap may have child input maps,
           * as this allows for easy addition
           * of mappings that are state-specific. For example, if a Node can be in two
           * different states, and the input mappings are different for each, then it
           * makes sense to have one root (and empty) InputMap, with two children
           * input maps, where each is populated with the specific input mappings for
           * one of the two states. To prevent the wrong input map from being considered,
           * it is simply a matter of setting appropriate
           * {@link #getInterceptors() interceptors} on each map, so that they are only
           * considered in one of the two states.
           */
          public ObservableList<InputMap<N>> getChildInputMaps();

          /**
           * Disposes all child InputMaps, removes all event handlers from the Node,
           * and clears the mappings list.
           */
          public void dispose();

          // This is the API inherited by implementing the EventHandler<Event> interface,
          // and is what is called whenever the owner Node receives events on the event
          // handlers that this InputMap has installed into it.
          @Override public void handle(Event e)

          /**
           * Looks up the most specific mapping given the input, ignoring all
           * interceptors. The valid values that can be passed into this method is
           * based on the values returned by the {@link Mapping#getMappingKey()}
           * method. Based on the subclasses of Mapping that ship with JavaFX, the
           * valid values are therefore:
           *
           * <ul>
           * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
           * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
           * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
           * </ul>
           *
           * For other Mapping subclasses, refer to their javadoc, and specifically
           * what is returned by {@link Mapping#getMappingKey()},
           *
           * @param mappingKey
           * @return
           */
          public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          At present this work has only been investigated lightly---much more work
          needs to be done to get this across the line.


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`

          `ButtonBarSkin`

          `ButtonSkin`

          `CellSkinBase`

          `CheckBoxSkin`

          `ChoiceBoxSkin`

          `ColorPickerSkin`

          `ComboBoxBaseSkin`

          `ComboBoxListViewSkin`

          `ComboBoxPopupControl`

          `ContextMenuSkin`

          `DateCellSkin`

          `DatePickerSkin`

          `HyperlinkSkin`

          `LabelSkin`

          `LabeledSkinBase`

          `ListCellSkin`

          `ListViewSkin`

          `MenuBarSkin`

          `MenuButtonSkin`

          `MenuButtonSkinBase`

          `NestedTableColumnHeader`

          `PaginationSkin`

          `ProgressBarSkin`

          `ProgressIndicatorSkin`

          `RadioButtonSkin`

          `ScrollBarSkin`

          `ScrollPaneSkin`

          `SeparatorSkin`

          `SliderSkin`

          `SpinnerSkin`

          `SplitMenuButtonSkin`

          `SplitPaneSkin`

          `TabPaneSkin`

          `TableCellSkin`

          `TableCellSkinBase`

          `TableColumnHeader`

          `TableHeaderRow`

          `TableRowSkin`

          `TableRowSkinBase`

          `TableViewSkin`

          `TableViewSkinBase`

          `TextAreaSkin`

          `TextFieldSkin`

          `TextInputControlSkin`

          `TitledPaneSkin`

          `ToggleButtonSkin`

          `ToolBarSkin`

          `TooltipSkin`

          `TreeCellSkin`

          `TreeTableCellSkin`

          `TreeTableRowSkin`

          `TreeTableViewSkin`

          `TreeViewSkin`

          `VirtualContainerBase`

          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          `javafx.scene.input.InputMap`

          `javafx.scene.input.InputMap.Mapping`

          `javafx.scene.input.InputMap.KeyMapping`

          `javafx.scene.input.InputMap.KeyMappingInterceptor`

          `javafx.scene.input.InputMap.MouseMapping`

          `javafx.scene.input.InputMap.MouseMappingInterceptor`

          `javafx.scene.input.KeyBinding`

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

              /**
               * Creates the new InputMap instance which is related specifically to the
               * given Node.
               * @param node The Node for which this InputMap is attached.
               */
              public InputMap(N node);
              
              /**
               * A mutable list of interceptors. The interceptors list is a collection of
               * {@link Predicate predicates} that are run whenever an event is being
               * looked up. If any of the interceptor predicates return true, the event is
               * not handled and it is not consumed.
               */
              public final ObservableList<Predicate<? extends Event>> getInterceptors();
              
              /**
               * The Node for which this InputMap is attached.
               */
              public final N getNode();
              
              /**
               * A mutable list of input mappings. Each will be considered whenever an
               * input event is being looked up, and one of which may be used to handle
               * the input event, based on the specifificity returned by each mapping
               * (that is, the mapping with the highest specificity wins).
               */
              public ObservableList<Mapping<?>> getMappings();
              
              /**
               * A mutable list of child InputMaps. An InputMap may have child input maps,
               * as this allows for easy addition
               * of mappings that are state-specific. For example, if a Node can be in two
               * different states, and the input mappings are different for each, then it
               * makes sense to have one root (and empty) InputMap, with two children
               * input maps, where each is populated with the specific input mappings for
               * one of the two states. To prevent the wrong input map from being considered,
               * it is simply a matter of setting appropriate
               * {@link #getInterceptors() interceptors} on each map, so that they are only
               * considered in one of the two states.
               */
              public ObservableList<InputMap<N>> getChildInputMaps();
              
              /**
               * Disposes all child InputMaps, removes all event handlers from the Node,
               * and clears the mappings list.
               */
              public void dispose();
              
              // This is the API inherited by implementing the EventHandler<Event> interface,
              // and is what is called whenever the owner Node receives events on the event
              // handlers that this InputMap has installed into it.
              @Override public void handle(Event e)
              
              /**
               * Looks up the most specific mapping given the input, ignoring all
               * interceptors. The valid values that can be passed into this method is
               * based on the values returned by the {@link Mapping#getMappingKey()}
               * method. Based on the subclasses of Mapping that ship with JavaFX, the
               * valid values are therefore:
               *
               * <ul>
               * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
               * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
               * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
               * </ul>
               *
               * For other Mapping subclasses, refer to their javadoc, and specifically
               * what is returned by {@link Mapping#getMappingKey()},
               *
               * @param mappingKey
               * @return
               */
              public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.css` as public API:

              CascadingStyle.java:public class CascadingStyle implements Comparable<CascadingStyle> {
              CascadingStyle.java: public Style getStyle() {
              CascadingStyle.java: public CascadingStyle(final Style style, Set<PseudoClass> pseudoClasses,
              CascadingStyle.java: public String getProperty() {
              CascadingStyle.java: public Selector getSelector() {
              CascadingStyle.java: public Rule getRule() {
              CascadingStyle.java: public StyleOrigin getOrigin() {
              CascadingStyle.java: public ParsedValueImpl getParsedValueImpl() {

              CompoundSelector.java:final public class CompoundSelector extends Selector {
              CompoundSelector.java: public List<SimpleSelector> getSelectors() {
              CompoundSelector.java: public CompoundSelector(List<SimpleSelector> selectors, List<Combinator> relationships)
              CompoundSelector.java: public Match createMatch() {

              CssError.java:public class CssError {
              CssError.java: public static void setCurrentScene(Scene scene) {
              CssError.java: public final String getMessage() {
              CssError.java: public CssError(String message) {
              CssError.java: public final static class PropertySetError extends CssError {
              CssError.java: public PropertySetError(CssMetaData styleableProperty,

              Declaration.java:final public class Declaration {
              Declaration.java: public ParsedValue getParsedValue() {
              Declaration.java: public String getProperty() {
              Declaration.java: public Rule getRule() {

              Rule.java:final public class Rule {
              Rule.java: public final ObservableList<Declaration> getDeclarations() {
              Rule.java: public final ObservableList<Selector> getSelectors() {
              Rule.java: public Stylesheet getStylesheet() {
              Rule.java: public StyleOrigin getOrigin() {

              Selector.java:abstract public class Selector {
              Selector.java: public Rule getRule() {
              Selector.java: public void setOrdinal(int ordinal) {
              Selector.java: public int getOrdinal() {
              Selector.java: public abstract Match createMatch();
              Selector.java: public abstract boolean applies(Styleable styleable);
              Selector.java: public abstract boolean applies(Styleable styleable, Set<PseudoClass>[] triggerStates, int bit);
              Selector.java: public abstract boolean stateMatches(Styleable styleable, Set<PseudoClass> state);
              Selector.java: public static Selector createSelector(final String cssSelector) {
              Selector.java: protected void writeBinary(DataOutputStream os, StringStore stringStore)

              SimpleSelector.java:final public class SimpleSelector extends Selector {
              SimpleSelector.java: public String getName() {
              SimpleSelector.java: public List<String> getStyleClasses() {
              SimpleSelector.java: public Set<StyleClass> getStyleClassSet() {
              SimpleSelector.java: public String getId() {
              SimpleSelector.java: public NodeOrientation getNodeOrientation() {

              Size.java:final public class Size {
              Size.java: public Size(double value, SizeUnits units) {
              Size.java: public double getValue() {
              Size.java: public SizeUnits getUnits() {
              Size.java: public boolean isAbsolute() {
              Size.java: public double pixels(double multiplier, Font font) {
              Size.java: public double pixels(Font font) {
              Size.java: public double pixels() {

              Style.java:final public class Style {
              Style.java: public Selector getSelector() {
              Style.java: public Declaration getDeclaration() {
              Style.java: public Style(Selector selector, Declaration declaration) {

              Stylesheet.java:public class Stylesheet {
              Stylesheet.java: public String getUrl() {
              Stylesheet.java: public StyleOrigin getOrigin() {
              Stylesheet.java: public void setOrigin(StyleOrigin origin) {
              Stylesheet.java: public List<Rule> getRules() {
              Stylesheet.java: public List<FontFace> getFontFaces() {
              Stylesheet.java: public static Stylesheet loadBinary(URL url) throws IOException {
              Stylesheet.java: public static void convertToBinary(File source, File destination) throws IOException {

              CssParser.java:final public class CssParser {
              CssParser.java: public CssParser() {
              CssParser.java: public Stylesheet parse(final String stylesheetText) {
              CssParser.java: public Stylesheet parse(final URL url) throws IOException {
              CssParser.java: public Stylesheet parseInlineStyle(final Styleable node) {
              CssParser.java: public ParsedValueImpl parseExpr(String property, String expr) {
              CssParser.java: public static ObservableList<CssError> errorsProperty() {


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

          `AccordionSkin`

          `ButtonBarSkin`

          `ButtonSkin`

          `CellSkinBase`

          `CheckBoxSkin`

          `ChoiceBoxSkin`

          `ColorPickerSkin`

          `ComboBoxBaseSkin`

          `ComboBoxListViewSkin`

          `ComboBoxPopupControl`

          `ContextMenuSkin`

          `DateCellSkin`

          `DatePickerSkin`

          `HyperlinkSkin`

          `LabelSkin`

          `LabeledSkinBase`

          `ListCellSkin`

          `ListViewSkin`

          `MenuBarSkin`

          `MenuButtonSkin`

          `MenuButtonSkinBase`

          `NestedTableColumnHeader`

          `PaginationSkin`

          `ProgressBarSkin`

          `ProgressIndicatorSkin`

          `RadioButtonSkin`

          `ScrollBarSkin`

          `ScrollPaneSkin`

          `SeparatorSkin`

          `SliderSkin`

          `SpinnerSkin`

          `SplitMenuButtonSkin`

          `SplitPaneSkin`

          `TabPaneSkin`

          `TableCellSkin`

          `TableCellSkinBase`

          `TableColumnHeader`

          `TableHeaderRow`

          `TableRowSkin`

          `TableRowSkinBase`

          `TableViewSkin`

          `TableViewSkinBase`

          `TextAreaSkin`

          `TextFieldSkin`

          `TextInputControlSkin`

          `TitledPaneSkin`

          `ToggleButtonSkin`

          `ToolBarSkin`

          `TooltipSkin`

          `TreeCellSkin`

          `TreeTableCellSkin`

          `TreeTableRowSkin`

          `TreeTableViewSkin`

          `TreeViewSkin`

          `VirtualContainerBase`

          `VirtualFlow`


          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

          `javafx.scene.input.InputMap`

          `javafx.scene.input.InputMap.Mapping`

          `javafx.scene.input.InputMap.KeyMapping`

          `javafx.scene.input.InputMap.KeyMappingInterceptor`

          `javafx.scene.input.InputMap.MouseMapping`

          `javafx.scene.input.InputMap.MouseMappingInterceptor`

          `javafx.scene.input.KeyBinding`

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

              /**
               * Creates the new InputMap instance which is related specifically to the
               * given Node.
               * @param node The Node for which this InputMap is attached.
               */
              public InputMap(N node);
              
              /**
               * A mutable list of interceptors. The interceptors list is a collection of
               * {@link Predicate predicates} that are run whenever an event is being
               * looked up. If any of the interceptor predicates return true, the event is
               * not handled and it is not consumed.
               */
              public final ObservableList<Predicate<? extends Event>> getInterceptors();
              
              /**
               * The Node for which this InputMap is attached.
               */
              public final N getNode();
              
              /**
               * A mutable list of input mappings. Each will be considered whenever an
               * input event is being looked up, and one of which may be used to handle
               * the input event, based on the specifificity returned by each mapping
               * (that is, the mapping with the highest specificity wins).
               */
              public ObservableList<Mapping<?>> getMappings();
              
              /**
               * A mutable list of child InputMaps. An InputMap may have child input maps,
               * as this allows for easy addition
               * of mappings that are state-specific. For example, if a Node can be in two
               * different states, and the input mappings are different for each, then it
               * makes sense to have one root (and empty) InputMap, with two children
               * input maps, where each is populated with the specific input mappings for
               * one of the two states. To prevent the wrong input map from being considered,
               * it is simply a matter of setting appropriate
               * {@link #getInterceptors() interceptors} on each map, so that they are only
               * considered in one of the two states.
               */
              public ObservableList<InputMap<N>> getChildInputMaps();
              
              /**
               * Disposes all child InputMaps, removes all event handlers from the Node,
               * and clears the mappings list.
               */
              public void dispose();
              
              // This is the API inherited by implementing the EventHandler<Event> interface,
              // and is what is called whenever the owner Node receives events on the event
              // handlers that this InputMap has installed into it.
              @Override public void handle(Event e)
              
              /**
               * Looks up the most specific mapping given the input, ignoring all
               * interceptors. The valid values that can be passed into this method is
               * based on the values returned by the {@link Mapping#getMappingKey()}
               * method. Based on the subclasses of Mapping that ship with JavaFX, the
               * valid values are therefore:
               *
               * <ul>
               * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
               * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
               * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
               * </ul>
               *
               * For other Mapping subclasses, refer to their javadoc, and specifically
               * what is returned by {@link Mapping#getMappingKey()},
               *
               * @param mappingKey
               * @return
               */
              public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.css` as public API:

              CascadingStyle.java:public class CascadingStyle implements Comparable<CascadingStyle> {
              CascadingStyle.java: public Style getStyle() {
              CascadingStyle.java: public CascadingStyle(final Style style, Set<PseudoClass> pseudoClasses,
              CascadingStyle.java: public String getProperty() {
              CascadingStyle.java: public Selector getSelector() {
              CascadingStyle.java: public Rule getRule() {
              CascadingStyle.java: public StyleOrigin getOrigin() {
              CascadingStyle.java: public ParsedValueImpl getParsedValueImpl() {

              CompoundSelector.java:final public class CompoundSelector extends Selector {
              CompoundSelector.java: public List<SimpleSelector> getSelectors() {
              CompoundSelector.java: public CompoundSelector(List<SimpleSelector> selectors, List<Combinator> relationships)
              CompoundSelector.java: public Match createMatch() {

              CssError.java:public class CssError {
              CssError.java: public static void setCurrentScene(Scene scene) {
              CssError.java: public final String getMessage() {
              CssError.java: public CssError(String message) {
              CssError.java: public final static class PropertySetError extends CssError {
              CssError.java: public PropertySetError(CssMetaData styleableProperty,

              Declaration.java:final public class Declaration {
              Declaration.java: public ParsedValue getParsedValue() {
              Declaration.java: public String getProperty() {
              Declaration.java: public Rule getRule() {

              Rule.java:final public class Rule {
              Rule.java: public final ObservableList<Declaration> getDeclarations() {
              Rule.java: public final ObservableList<Selector> getSelectors() {
              Rule.java: public Stylesheet getStylesheet() {
              Rule.java: public StyleOrigin getOrigin() {

              Selector.java:abstract public class Selector {
              Selector.java: public Rule getRule() {
              Selector.java: public void setOrdinal(int ordinal) {
              Selector.java: public int getOrdinal() {
              Selector.java: public abstract Match createMatch();
              Selector.java: public abstract boolean applies(Styleable styleable);
              Selector.java: public abstract boolean applies(Styleable styleable, Set<PseudoClass>[] triggerStates, int bit);
              Selector.java: public abstract boolean stateMatches(Styleable styleable, Set<PseudoClass> state);
              Selector.java: public static Selector createSelector(final String cssSelector) {
              Selector.java: protected void writeBinary(DataOutputStream os, StringStore stringStore)

              SimpleSelector.java:final public class SimpleSelector extends Selector {
              SimpleSelector.java: public String getName() {
              SimpleSelector.java: public List<String> getStyleClasses() {
              SimpleSelector.java: public Set<StyleClass> getStyleClassSet() {
              SimpleSelector.java: public String getId() {
              SimpleSelector.java: public NodeOrientation getNodeOrientation() {

              Size.java:final public class Size {
              Size.java: public Size(double value, SizeUnits units) {
              Size.java: public double getValue() {
              Size.java: public SizeUnits getUnits() {
              Size.java: public boolean isAbsolute() {
              Size.java: public double pixels(double multiplier, Font font) {
              Size.java: public double pixels(Font font) {
              Size.java: public double pixels() {

              Style.java:final public class Style {
              Style.java: public Selector getSelector() {
              Style.java: public Declaration getDeclaration() {
              Style.java: public Style(Selector selector, Declaration declaration) {

              Stylesheet.java:public class Stylesheet {
              Stylesheet.java: public String getUrl() {
              Stylesheet.java: public StyleOrigin getOrigin() {
              Stylesheet.java: public void setOrigin(StyleOrigin origin) {
              Stylesheet.java: public List<Rule> getRules() {
              Stylesheet.java: public List<FontFace> getFontFaces() {
              Stylesheet.java: public static Stylesheet loadBinary(URL url) throws IOException {
              Stylesheet.java: public static void convertToBinary(File source, File destination) throws IOException {

              CssParser.java:final public class CssParser {
              CssParser.java: public CssParser() {
              CssParser.java: public Stylesheet parse(final String stylesheetText) {
              CssParser.java: public Stylesheet parse(final URL url) throws IOException {
              CssParser.java: public Stylesheet parseInlineStyle(final Styleable node) {
              CssParser.java: public ParsedValueImpl parseExpr(String property, String expr) {
              CssParser.java: public static ObservableList<CssError> errorsProperty() {


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

           - `AccordionSkin`
           - `ButtonBarSkin`
           - `ButtonSkin`
           - `CellSkinBase`
           - `CheckBoxSkin`
           - `ChoiceBoxSkin`
           - `ColorPickerSkin`
           - `ComboBoxBaseSkin`
           - `ComboBoxListViewSkin`
           - `ComboBoxPopupControl`
           - `ContextMenuSkin`
           - `DateCellSkin`
           - `DatePickerSkin`
           - `HyperlinkSkin`
           - `LabelSkin`
           - `LabeledSkinBase`
           - `ListCellSkin`
           - `ListViewSkin`
           - `MenuBarSkin`
           - `MenuButtonSkin`
           - `MenuButtonSkinBase`
           - `NestedTableColumnHeader`
           - `PaginationSkin`
           - `ProgressBarSkin`
           - `ProgressIndicatorSkin`
           - `RadioButtonSkin`
           - `ScrollBarSkin`
           - `ScrollPaneSkin`
           - `SeparatorSkin`
           - `SliderSkin`
           - `SpinnerSkin`
           - `SplitMenuButtonSkin`
           - `SplitPaneSkin`
           - `TabPaneSkin`
           - `TableCellSkin`
           - `TableCellSkinBase`
           - `TableColumnHeader`
           - `TableHeaderRow`
           - `TableRowSkin`
           - `TableRowSkinBase`
           - `TableViewSkin`
           - `TableViewSkinBase`
           - `TextAreaSkin`
           - `TextFieldSkin`
           - `TextInputControlSkin`
           - `TitledPaneSkin`
           - `ToggleButtonSkin`
           - `ToolBarSkin`
           - `TooltipSkin`
           - `TreeCellSkin`
           - `TreeTableCellSkin`
           - `TreeTableRowSkin`
           - `TreeTableViewSkin`
           - `TreeViewSkin`
           - `VirtualContainerBase`
           - `VirtualFlow`

          These classes, as of mid-June, are stripped of almost any API that is not inherited from SkinBase. Moving forward, the intention is to add back useful API as feedback is received based on early access builds. Some classes, such as the text input controls and virtualised controls, have additional API already to support their functionality.

          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

           - `javafx.scene.input.InputMap`
           - `javafx.scene.input.InputMap.Mapping`
           - `javafx.scene.input.InputMap.KeyMapping`
           - `javafx.scene.input.InputMap.KeyMappingInterceptor`
           - `javafx.scene.input.InputMap.MouseMapping`
           - `javafx.scene.input.InputMap.MouseMappingInterceptor`
           - `javafx.scene.input.KeyBinding`

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

              /**
               * Creates the new InputMap instance which is related specifically to the
               * given Node.
               * @param node The Node for which this InputMap is attached.
               */
              public InputMap(N node);
              
              /**
               * A mutable list of interceptors. The interceptors list is a collection of
               * {@link Predicate predicates} that are run whenever an event is being
               * looked up. If any of the interceptor predicates return true, the event is
               * not handled and it is not consumed.
               */
              public final ObservableList<Predicate<? extends Event>> getInterceptors();
              
              /**
               * The Node for which this InputMap is attached.
               */
              public final N getNode();
              
              /**
               * A mutable list of input mappings. Each will be considered whenever an
               * input event is being looked up, and one of which may be used to handle
               * the input event, based on the specifificity returned by each mapping
               * (that is, the mapping with the highest specificity wins).
               */
              public ObservableList<Mapping<?>> getMappings();
              
              /**
               * A mutable list of child InputMaps. An InputMap may have child input maps,
               * as this allows for easy addition
               * of mappings that are state-specific. For example, if a Node can be in two
               * different states, and the input mappings are different for each, then it
               * makes sense to have one root (and empty) InputMap, with two children
               * input maps, where each is populated with the specific input mappings for
               * one of the two states. To prevent the wrong input map from being considered,
               * it is simply a matter of setting appropriate
               * {@link #getInterceptors() interceptors} on each map, so that they are only
               * considered in one of the two states.
               */
              public ObservableList<InputMap<N>> getChildInputMaps();
              
              /**
               * Disposes all child InputMaps, removes all event handlers from the Node,
               * and clears the mappings list.
               */
              public void dispose();
              
              // This is the API inherited by implementing the EventHandler<Event> interface,
              // and is what is called whenever the owner Node receives events on the event
              // handlers that this InputMap has installed into it.
              @Override public void handle(Event e)
              
              /**
               * Looks up the most specific mapping given the input, ignoring all
               * interceptors. The valid values that can be passed into this method is
               * based on the values returned by the {@link Mapping#getMappingKey()}
               * method. Based on the subclasses of Mapping that ship with JavaFX, the
               * valid values are therefore:
               *
               * <ul>
               * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
               * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
               * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
               * </ul>
               *
               * For other Mapping subclasses, refer to their javadoc, and specifically
               * what is returned by {@link Mapping#getMappingKey()},
               *
               * @param mappingKey
               * @return
               */
              public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.css` as public API:

              CascadingStyle.java:public class CascadingStyle implements Comparable<CascadingStyle> {
              CascadingStyle.java: public Style getStyle() {
              CascadingStyle.java: public CascadingStyle(final Style style, Set<PseudoClass> pseudoClasses,
              CascadingStyle.java: public String getProperty() {
              CascadingStyle.java: public Selector getSelector() {
              CascadingStyle.java: public Rule getRule() {
              CascadingStyle.java: public StyleOrigin getOrigin() {
              CascadingStyle.java: public ParsedValueImpl getParsedValueImpl() {

              CompoundSelector.java:final public class CompoundSelector extends Selector {
              CompoundSelector.java: public List<SimpleSelector> getSelectors() {
              CompoundSelector.java: public CompoundSelector(List<SimpleSelector> selectors, List<Combinator> relationships)
              CompoundSelector.java: public Match createMatch() {

              CssError.java:public class CssError {
              CssError.java: public static void setCurrentScene(Scene scene) {
              CssError.java: public final String getMessage() {
              CssError.java: public CssError(String message) {
              CssError.java: public final static class PropertySetError extends CssError {
              CssError.java: public PropertySetError(CssMetaData styleableProperty,

              Declaration.java:final public class Declaration {
              Declaration.java: public ParsedValue getParsedValue() {
              Declaration.java: public String getProperty() {
              Declaration.java: public Rule getRule() {

              Rule.java:final public class Rule {
              Rule.java: public final ObservableList<Declaration> getDeclarations() {
              Rule.java: public final ObservableList<Selector> getSelectors() {
              Rule.java: public Stylesheet getStylesheet() {
              Rule.java: public StyleOrigin getOrigin() {

              Selector.java:abstract public class Selector {
              Selector.java: public Rule getRule() {
              Selector.java: public void setOrdinal(int ordinal) {
              Selector.java: public int getOrdinal() {
              Selector.java: public abstract Match createMatch();
              Selector.java: public abstract boolean applies(Styleable styleable);
              Selector.java: public abstract boolean applies(Styleable styleable, Set<PseudoClass>[] triggerStates, int bit);
              Selector.java: public abstract boolean stateMatches(Styleable styleable, Set<PseudoClass> state);
              Selector.java: public static Selector createSelector(final String cssSelector) {
              Selector.java: protected void writeBinary(DataOutputStream os, StringStore stringStore)

              SimpleSelector.java:final public class SimpleSelector extends Selector {
              SimpleSelector.java: public String getName() {
              SimpleSelector.java: public List<String> getStyleClasses() {
              SimpleSelector.java: public Set<StyleClass> getStyleClassSet() {
              SimpleSelector.java: public String getId() {
              SimpleSelector.java: public NodeOrientation getNodeOrientation() {

              Size.java:final public class Size {
              Size.java: public Size(double value, SizeUnits units) {
              Size.java: public double getValue() {
              Size.java: public SizeUnits getUnits() {
              Size.java: public boolean isAbsolute() {
              Size.java: public double pixels(double multiplier, Font font) {
              Size.java: public double pixels(Font font) {
              Size.java: public double pixels() {

              Style.java:final public class Style {
              Style.java: public Selector getSelector() {
              Style.java: public Declaration getDeclaration() {
              Style.java: public Style(Selector selector, Declaration declaration) {

              Stylesheet.java:public class Stylesheet {
              Stylesheet.java: public String getUrl() {
              Stylesheet.java: public StyleOrigin getOrigin() {
              Stylesheet.java: public void setOrigin(StyleOrigin origin) {
              Stylesheet.java: public List<Rule> getRules() {
              Stylesheet.java: public List<FontFace> getFontFaces() {
              Stylesheet.java: public static Stylesheet loadBinary(URL url) throws IOException {
              Stylesheet.java: public static void convertToBinary(File source, File destination) throws IOException {

              CssParser.java:final public class CssParser {
              CssParser.java: public CssParser() {
              CssParser.java: public Stylesheet parse(final String stylesheetText) {
              CssParser.java: public Stylesheet parse(final URL url) throws IOException {
              CssParser.java: public Stylesheet parseInlineStyle(final Styleable node) {
              CssParser.java: public ParsedValueImpl parseExpr(String property, String expr) {
              CssParser.java: public static ObservableList<CssError> errorsProperty() {


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          vdyakov Victor Dyakov made changes -
          Assignee Jonathan Giles [ jgiles ] Victor Dyakov [ vdyakov ]
          vdyakov Victor Dyakov made changes -
          Status Candidate [ 10003 ] Proposed to Target [ 10004 ]
          vdyakov Victor Dyakov made changes -
          Assignee Victor Dyakov [ vdyakov ] Jonathan Giles [ jgiles ]
          mr Mark Reinhold made changes -
          Labels jdkinternals modularization no-tck team-clientlibs jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs
          vdyakov Victor Dyakov made changes -
          Component/s javafx [ 11900 ]
          Component/s client-libs [ 10307 ]
          vdyakov Victor Dyakov made changes -
          Subcomponent controls [ 1378 ]
          mr Mark Reinhold made changes -
          Status Proposed to Target [ 10004 ] Targeted [ 10005 ]
          vdyakov Victor Dyakov made changes -
          Labels jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs client-jdkinternals jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs
          vdyakov Victor Dyakov made changes -
          Integration Due 2015-08-28 2015-09-21
          jgiles Jonathan Giles made changes -
          Description Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into three semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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, since these will be
          handled separately as part of Project Two below.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

           - `AccordionSkin`
           - `ButtonBarSkin`
           - `ButtonSkin`
           - `CellSkinBase`
           - `CheckBoxSkin`
           - `ChoiceBoxSkin`
           - `ColorPickerSkin`
           - `ComboBoxBaseSkin`
           - `ComboBoxListViewSkin`
           - `ComboBoxPopupControl`
           - `ContextMenuSkin`
           - `DateCellSkin`
           - `DatePickerSkin`
           - `HyperlinkSkin`
           - `LabelSkin`
           - `LabeledSkinBase`
           - `ListCellSkin`
           - `ListViewSkin`
           - `MenuBarSkin`
           - `MenuButtonSkin`
           - `MenuButtonSkinBase`
           - `NestedTableColumnHeader`
           - `PaginationSkin`
           - `ProgressBarSkin`
           - `ProgressIndicatorSkin`
           - `RadioButtonSkin`
           - `ScrollBarSkin`
           - `ScrollPaneSkin`
           - `SeparatorSkin`
           - `SliderSkin`
           - `SpinnerSkin`
           - `SplitMenuButtonSkin`
           - `SplitPaneSkin`
           - `TabPaneSkin`
           - `TableCellSkin`
           - `TableCellSkinBase`
           - `TableColumnHeader`
           - `TableHeaderRow`
           - `TableRowSkin`
           - `TableRowSkinBase`
           - `TableViewSkin`
           - `TableViewSkinBase`
           - `TextAreaSkin`
           - `TextFieldSkin`
           - `TextInputControlSkin`
           - `TitledPaneSkin`
           - `ToggleButtonSkin`
           - `ToolBarSkin`
           - `TooltipSkin`
           - `TreeCellSkin`
           - `TreeTableCellSkin`
           - `TreeTableRowSkin`
           - `TreeTableViewSkin`
           - `TreeViewSkin`
           - `VirtualContainerBase`
           - `VirtualFlow`

          These classes, as of mid-June, are stripped of almost any API that is not inherited from SkinBase. Moving forward, the intention is to add back useful API as feedback is received based on early access builds. Some classes, such as the text input controls and virtualised controls, have additional API already to support their functionality.

          ### Project Two: Improve support for input mapping

          At present input mapping, that is, the "Controller" aspect of the JavaFX
          UI controls MVC design pattern, is handled entirely as an implementation
          detail. All-third party UI controls that define their own behaviors had
          the choice of either using a private API or co-mingling their controller
          code inside the view code. Neither of these approaches is anywhere near
          ideal.

          Because of this lack of public APIs, a major API gap exists, namely the
          ability to easily add, remove, and modify keyboard, mouse, touch, and
          related mappings in a clean and well-defined fashion.

          There has been a considerable amount of exploration in this area as part
          of [RT-21598](https://javafx-jira.kenai.com/browse/RT-21598), which has
          been intermittently returned to and revised since mid-2012. The current
          implementations being explored presently hold a lot of promise---they
          significantly clean up the behavior code and expose the behavior mappings
          in a simple way, allowing for easier modification of input maps at run
          time by external users.

          The primary new API in this aspect of the JEP is the InputMap class. The
          InputMap class can at a high level be considered as a map between user
          inputs (most notably mouse and keyboard) and event handlers that will be
          called when the input is received by the attached Node. The current plan is
          for the InputMap class, as well as its related classes, to be located within the
          `javafx.scene.input` package, with the` javafx.scene.Node` class having an
          `inputMap` property added to it (it will be null by default, but the
          `javafx.scene.control.Control` subclass will make this non-null, given that
          this is the primary consumer of the InputMap API).

          The current public API classes are as follows:

           - `javafx.scene.input.InputMap`
           - `javafx.scene.input.InputMap.Mapping`
           - `javafx.scene.input.InputMap.KeyMapping`
           - `javafx.scene.input.InputMap.KeyMappingInterceptor`
           - `javafx.scene.input.InputMap.MouseMapping`
           - `javafx.scene.input.InputMap.MouseMappingInterceptor`
           - `javafx.scene.input.KeyBinding`

          Most importantly, the InputMap class currently has the following public API, consisting of one constructor and seven public methods:

              /**
               * Creates the new InputMap instance which is related specifically to the
               * given Node.
               * @param node The Node for which this InputMap is attached.
               */
              public InputMap(N node);
              
              /**
               * A mutable list of interceptors. The interceptors list is a collection of
               * {@link Predicate predicates} that are run whenever an event is being
               * looked up. If any of the interceptor predicates return true, the event is
               * not handled and it is not consumed.
               */
              public final ObservableList<Predicate<? extends Event>> getInterceptors();
              
              /**
               * The Node for which this InputMap is attached.
               */
              public final N getNode();
              
              /**
               * A mutable list of input mappings. Each will be considered whenever an
               * input event is being looked up, and one of which may be used to handle
               * the input event, based on the specifificity returned by each mapping
               * (that is, the mapping with the highest specificity wins).
               */
              public ObservableList<Mapping<?>> getMappings();
              
              /**
               * A mutable list of child InputMaps. An InputMap may have child input maps,
               * as this allows for easy addition
               * of mappings that are state-specific. For example, if a Node can be in two
               * different states, and the input mappings are different for each, then it
               * makes sense to have one root (and empty) InputMap, with two children
               * input maps, where each is populated with the specific input mappings for
               * one of the two states. To prevent the wrong input map from being considered,
               * it is simply a matter of setting appropriate
               * {@link #getInterceptors() interceptors} on each map, so that they are only
               * considered in one of the two states.
               */
              public ObservableList<InputMap<N>> getChildInputMaps();
              
              /**
               * Disposes all child InputMaps, removes all event handlers from the Node,
               * and clears the mappings list.
               */
              public void dispose();
              
              // This is the API inherited by implementing the EventHandler<Event> interface,
              // and is what is called whenever the owner Node receives events on the event
              // handlers that this InputMap has installed into it.
              @Override public void handle(Event e)
              
              /**
               * Looks up the most specific mapping given the input, ignoring all
               * interceptors. The valid values that can be passed into this method is
               * based on the values returned by the {@link Mapping#getMappingKey()}
               * method. Based on the subclasses of Mapping that ship with JavaFX, the
               * valid values are therefore:
               *
               * <ul>
               * <li><strong>KeyMapping:</strong> A valid {@link KeyBinding}.</li>
               * <li><strong>MouseMapping:</strong> A valid {@link MouseEvent} event
               * type (e.g. {@code MouseEvent.MOUSE_PRESSED}).</li>
               * </ul>
               *
               * For other Mapping subclasses, refer to their javadoc, and specifically
               * what is returned by {@link Mapping#getMappingKey()},
               *
               * @param mappingKey
               * @return
               */
              public Optional<Mapping<?>> lookupMapping(Object mappingKey);

          All nomenclature is placeholder, and in general the API is still exploratory in nature. However, as of early June, there exists an InputMap class (as well as support classes), as well as a unit test suite, that has this API. More importantly, all JavaFX UI controls have been ported to use this InputMap implementation, and this has helped confirm that the API works well. The remaining tasks are for API review, javadoc documentation, as well as community testing and feedback. Based on this, the API may of course change as time progresses.


          ### Project Three: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.css` as public API:

              CascadingStyle.java:public class CascadingStyle implements Comparable<CascadingStyle> {
              CascadingStyle.java: public Style getStyle() {
              CascadingStyle.java: public CascadingStyle(final Style style, Set<PseudoClass> pseudoClasses,
              CascadingStyle.java: public String getProperty() {
              CascadingStyle.java: public Selector getSelector() {
              CascadingStyle.java: public Rule getRule() {
              CascadingStyle.java: public StyleOrigin getOrigin() {
              CascadingStyle.java: public ParsedValueImpl getParsedValueImpl() {

              CompoundSelector.java:final public class CompoundSelector extends Selector {
              CompoundSelector.java: public List<SimpleSelector> getSelectors() {
              CompoundSelector.java: public CompoundSelector(List<SimpleSelector> selectors, List<Combinator> relationships)
              CompoundSelector.java: public Match createMatch() {

              CssError.java:public class CssError {
              CssError.java: public static void setCurrentScene(Scene scene) {
              CssError.java: public final String getMessage() {
              CssError.java: public CssError(String message) {
              CssError.java: public final static class PropertySetError extends CssError {
              CssError.java: public PropertySetError(CssMetaData styleableProperty,

              Declaration.java:final public class Declaration {
              Declaration.java: public ParsedValue getParsedValue() {
              Declaration.java: public String getProperty() {
              Declaration.java: public Rule getRule() {

              Rule.java:final public class Rule {
              Rule.java: public final ObservableList<Declaration> getDeclarations() {
              Rule.java: public final ObservableList<Selector> getSelectors() {
              Rule.java: public Stylesheet getStylesheet() {
              Rule.java: public StyleOrigin getOrigin() {

              Selector.java:abstract public class Selector {
              Selector.java: public Rule getRule() {
              Selector.java: public void setOrdinal(int ordinal) {
              Selector.java: public int getOrdinal() {
              Selector.java: public abstract Match createMatch();
              Selector.java: public abstract boolean applies(Styleable styleable);
              Selector.java: public abstract boolean applies(Styleable styleable, Set<PseudoClass>[] triggerStates, int bit);
              Selector.java: public abstract boolean stateMatches(Styleable styleable, Set<PseudoClass> state);
              Selector.java: public static Selector createSelector(final String cssSelector) {
              Selector.java: protected void writeBinary(DataOutputStream os, StringStore stringStore)

              SimpleSelector.java:final public class SimpleSelector extends Selector {
              SimpleSelector.java: public String getName() {
              SimpleSelector.java: public List<String> getStyleClasses() {
              SimpleSelector.java: public Set<StyleClass> getStyleClassSet() {
              SimpleSelector.java: public String getId() {
              SimpleSelector.java: public NodeOrientation getNodeOrientation() {

              Size.java:final public class Size {
              Size.java: public Size(double value, SizeUnits units) {
              Size.java: public double getValue() {
              Size.java: public SizeUnits getUnits() {
              Size.java: public boolean isAbsolute() {
              Size.java: public double pixels(double multiplier, Font font) {
              Size.java: public double pixels(Font font) {
              Size.java: public double pixels() {

              Style.java:final public class Style {
              Style.java: public Selector getSelector() {
              Style.java: public Declaration getDeclaration() {
              Style.java: public Style(Selector selector, Declaration declaration) {

              Stylesheet.java:public class Stylesheet {
              Stylesheet.java: public String getUrl() {
              Stylesheet.java: public StyleOrigin getOrigin() {
              Stylesheet.java: public void setOrigin(StyleOrigin origin) {
              Stylesheet.java: public List<Rule> getRules() {
              Stylesheet.java: public List<FontFace> getFontFaces() {
              Stylesheet.java: public static Stylesheet loadBinary(URL url) throws IOException {
              Stylesheet.java: public static void convertToBinary(File source, File destination) throws IOException {

              CssParser.java:final public class CssParser {
              CssParser.java: public CssParser() {
              CssParser.java: public Stylesheet parse(final String stylesheetText) {
              CssParser.java: public Stylesheet parse(final URL url) throws IOException {
              CssParser.java: public Stylesheet parseInlineStyle(final Styleable node) {
              CssParser.java: public ParsedValueImpl parseExpr(String property, String expr) {
              CssParser.java: public static ObservableList<CssError> errorsProperty() {


          ### Summary

          The end result of these three projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - Additional APIs for specifying input mappings;

            - The translation of existing UI-control behavior classes to the new
              input map API; and

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          Summary
          -------

          Define public APIs for the JavaFX UI controls and CSS functionality that
          is presently only available via internal APIs and will hence become
          inaccessible due to modularization.


          Goals
          -----

          Many developers who use the UI controls and CSS functionality of JavaFX
          have historically ignored the warnings to avoid the internal `com.sun.*`
          APIs. In many cases, to achieve a desired result, developers have no
          choice but to use these internal APIs. With the forthcoming release of
          Java 9, and in particular with the introduction of strong boundaries
          between modules in [Project Jigsaw][jig], developers will find that their
          code will no longer compile or run since the `com.sun.*` packages will no
          longer be accessible. The goal of this JEP is to define public APIs for
          the functionality presently offered by the internal APIs.


          Non-Goals
          ---------

          Given the implications of modularization, that is, the forthcoming
          inaccessibility of the `com.sun.*` packages, there is no way to do this
          in a manner that retains any degree of backward compatibility. It is,
          therefore, not a goal of this JEP to retain backward compatibility. This
          does not mean that we can break anything we like; our intention is to
          only introduce new API (and evolve existing private API) that is directly
          broken by the enforcement of module boundaries. All other existing APIs
          that are not impacted by modularization will remain the same.


          Success Metrics
          ---------------

          Success can be measured in two ways:

            - Projects that depend on JavaFX internal APIs, in particular Scene
              Builder, ControlsFX, and JFXtras, continue to work after updating to
              the new API with no loss of functionality. These three projects are
              all open source, and they will provide an excellent test bed to
              ensure that all necessary APIs have been provided.

            - The result of discussions around new APIs, such as the input-map work
              required for control behaviors, results in improved functionality
              that developers have long requested. Ultimately, if all works to
              plan, third-party controls should be buildable without any dependency
              upon internal APIs.


          Motivation
          ----------

          Without this work being done, many projects will need to significantly
          reduce the functionality that they offer, and for some projects this may
          prove fatal. For example, without access to the internal API that Scene
          Builder currently has, it may struggle to be viable---certainly its
          ability to offer functionality around CSS styling and manipulation of
          control properties will be severely undermined, and these are two of the
          core pieces of functionality of Scene Builder. The same argument holds
          for most other JavaFX-based projects with any degree of custom control or
          CSS implementation.


          Description
          -----------

          This JEP is broken down into two semi-related subprojects, each of
          which is important in reaching the final goal. There is no particular
          order to which these projects must be undertaken.


          ### Project One: Make UI control skins into public APIs

          At present all skins are located in
          `com.sun.javafx.scene.control.skin`. This means that third parties who
          have extended a skin (e.g., the `TextFieldSkin`) to add additional
          functionality, to override an existing method, or otherwise to modify the
          visuals or behavior of the control skin, will be left without a
          functioning application in JDK 9. Of course, this is the fault of users
          who depended on non-public APIs, but we have long discussed making this
          API public so as to better enable third party modification of UI
          controls.

          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.

          The vast bulk of this work is to review each existing skin class,
          ensuring the following:

            - That there is API consistency between skins,

            - That high-quality Javadoc and unit tests exist, and

            - That the API in each class is kept to a minimum by changing public
              methods to private.

          This research is already quite far progressed in a separate sandbox repo,
          and whilst time-consuming, there are only a few classes of concern, such
          as utility classes, duplicated classes, and truly implementation-only
          classes, that need further analysis. On top of this, there is a handful
          of classes that may qualify for being brought into the
          `javafx.scene.control` package or, at the least, will need further
          consideration since they are not truly skins. These include `FXVK` (the
          virtual keyboard), `ColorPalette`, `CustomColorDialog`,
          `DatePickerContent`, and `InputField`. Finally, there are a few classes
          where, ideally, methods would be made private, except for the fact that
          other, implementation-only classes rely on this API. Solutions will be
          investigated for all of these issues, and no major concerns exist.

          The intent of making the skins into public API in 9 is to ensure their
          continued availability. The API will be purposefully kept to the bare
          minimum and reduced as significantly as possible, with the intention to
          follow this up in subsequent releases with more useful APIs that
          developers request. As is well appreciated, APIs are (mostly) forever, so
          allowing for the public skin API to mature over a few update releases
          seems like the best course of action.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.scene.control.skin` as public API:

           - `AccordionSkin`
           - `ButtonBarSkin`
           - `ButtonSkin`
           - `CellSkinBase`
           - `CheckBoxSkin`
           - `ChoiceBoxSkin`
           - `ColorPickerSkin`
           - `ComboBoxBaseSkin`
           - `ComboBoxListViewSkin`
           - `ComboBoxPopupControl`
           - `ContextMenuSkin`
           - `DateCellSkin`
           - `DatePickerSkin`
           - `HyperlinkSkin`
           - `LabelSkin`
           - `LabeledSkinBase`
           - `ListCellSkin`
           - `ListViewSkin`
           - `MenuBarSkin`
           - `MenuButtonSkin`
           - `MenuButtonSkinBase`
           - `NestedTableColumnHeader`
           - `PaginationSkin`
           - `ProgressBarSkin`
           - `ProgressIndicatorSkin`
           - `RadioButtonSkin`
           - `ScrollBarSkin`
           - `ScrollPaneSkin`
           - `SeparatorSkin`
           - `SliderSkin`
           - `SpinnerSkin`
           - `SplitMenuButtonSkin`
           - `SplitPaneSkin`
           - `TabPaneSkin`
           - `TableCellSkin`
           - `TableCellSkinBase`
           - `TableColumnHeader`
           - `TableHeaderRow`
           - `TableRowSkin`
           - `TableRowSkinBase`
           - `TableViewSkin`
           - `TableViewSkinBase`
           - `TextAreaSkin`
           - `TextFieldSkin`
           - `TextInputControlSkin`
           - `TitledPaneSkin`
           - `ToggleButtonSkin`
           - `ToolBarSkin`
           - `TooltipSkin`
           - `TreeCellSkin`
           - `TreeTableCellSkin`
           - `TreeTableRowSkin`
           - `TreeTableViewSkin`
           - `TreeViewSkin`
           - `VirtualContainerBase`
           - `VirtualFlow`

          These classes, as of mid-June, are stripped of almost any API that is not inherited from SkinBase. Moving forward, the intention is to add back useful API as feedback is received based on early access builds. Some classes, such as the text input controls and virtualised controls, have additional API already to support their functionality.

          ### Project Two: Review and make public relevant CSS APIs

          As with Project One, this project relates to bringing out into the public
          APIs that currently reside in `com.sun.*` packages. Again, this will
          require code review to minimise the API, as well as additional unit tests
          and vastly more documentation.

          The driver for this work will be to continue to allow for Scene Builder
          to compile in JDK 9, with the appropriate modifications.

          As of mid June, this project is at the point where almost all code is moved and cleaned up. The intention is to make this public in a JDK 9 build around mid-July to early August. The following is a list of all classes that have moved into `javafx.css` as public API:

              CascadingStyle.java:public class CascadingStyle implements Comparable<CascadingStyle> {
              CascadingStyle.java: public Style getStyle() {
              CascadingStyle.java: public CascadingStyle(final Style style, Set<PseudoClass> pseudoClasses,
              CascadingStyle.java: public String getProperty() {
              CascadingStyle.java: public Selector getSelector() {
              CascadingStyle.java: public Rule getRule() {
              CascadingStyle.java: public StyleOrigin getOrigin() {
              CascadingStyle.java: public ParsedValueImpl getParsedValueImpl() {

              CompoundSelector.java:final public class CompoundSelector extends Selector {
              CompoundSelector.java: public List<SimpleSelector> getSelectors() {
              CompoundSelector.java: public CompoundSelector(List<SimpleSelector> selectors, List<Combinator> relationships)
              CompoundSelector.java: public Match createMatch() {

              CssError.java:public class CssError {
              CssError.java: public static void setCurrentScene(Scene scene) {
              CssError.java: public final String getMessage() {
              CssError.java: public CssError(String message) {
              CssError.java: public final static class PropertySetError extends CssError {
              CssError.java: public PropertySetError(CssMetaData styleableProperty,

              Declaration.java:final public class Declaration {
              Declaration.java: public ParsedValue getParsedValue() {
              Declaration.java: public String getProperty() {
              Declaration.java: public Rule getRule() {

              Rule.java:final public class Rule {
              Rule.java: public final ObservableList<Declaration> getDeclarations() {
              Rule.java: public final ObservableList<Selector> getSelectors() {
              Rule.java: public Stylesheet getStylesheet() {
              Rule.java: public StyleOrigin getOrigin() {

              Selector.java:abstract public class Selector {
              Selector.java: public Rule getRule() {
              Selector.java: public void setOrdinal(int ordinal) {
              Selector.java: public int getOrdinal() {
              Selector.java: public abstract Match createMatch();
              Selector.java: public abstract boolean applies(Styleable styleable);
              Selector.java: public abstract boolean applies(Styleable styleable, Set<PseudoClass>[] triggerStates, int bit);
              Selector.java: public abstract boolean stateMatches(Styleable styleable, Set<PseudoClass> state);
              Selector.java: public static Selector createSelector(final String cssSelector) {
              Selector.java: protected void writeBinary(DataOutputStream os, StringStore stringStore)

              SimpleSelector.java:final public class SimpleSelector extends Selector {
              SimpleSelector.java: public String getName() {
              SimpleSelector.java: public List<String> getStyleClasses() {
              SimpleSelector.java: public Set<StyleClass> getStyleClassSet() {
              SimpleSelector.java: public String getId() {
              SimpleSelector.java: public NodeOrientation getNodeOrientation() {

              Size.java:final public class Size {
              Size.java: public Size(double value, SizeUnits units) {
              Size.java: public double getValue() {
              Size.java: public SizeUnits getUnits() {
              Size.java: public boolean isAbsolute() {
              Size.java: public double pixels(double multiplier, Font font) {
              Size.java: public double pixels(Font font) {
              Size.java: public double pixels() {

              Style.java:final public class Style {
              Style.java: public Selector getSelector() {
              Style.java: public Declaration getDeclaration() {
              Style.java: public Style(Selector selector, Declaration declaration) {

              Stylesheet.java:public class Stylesheet {
              Stylesheet.java: public String getUrl() {
              Stylesheet.java: public StyleOrigin getOrigin() {
              Stylesheet.java: public void setOrigin(StyleOrigin origin) {
              Stylesheet.java: public List<Rule> getRules() {
              Stylesheet.java: public List<FontFace> getFontFaces() {
              Stylesheet.java: public static Stylesheet loadBinary(URL url) throws IOException {
              Stylesheet.java: public static void convertToBinary(File source, File destination) throws IOException {

              CssParser.java:final public class CssParser {
              CssParser.java: public CssParser() {
              CssParser.java: public Stylesheet parse(final String stylesheetText) {
              CssParser.java: public Stylesheet parse(final URL url) throws IOException {
              CssParser.java: public Stylesheet parseInlineStyle(final Styleable node) {
              CssParser.java: public ParsedValueImpl parseExpr(String property, String expr) {
              CssParser.java: public static ObservableList<CssError> errorsProperty() {


          ### Summary

          The end result of these two projects is the creation of:

            - A new package `javafx.scene.control.skin` for UI control skins, after
              being reviewed, documented, and tested;

            - The moving and review, documentation, and testing of necessary
              CSS-related classes.


          Testing
          -------

          Testing will be limited to additional unit tests that have no special
          platform or hardware requirements.


          Risks and Assumptions
          ---------------------

          The primary risk is that the scope of work exceeds what is
          anticipated. Some research has been done to better understand the
          requirements, but there is no denying that producing good APIs will
          require a decent investment of time.


          [jig]: http://openjdk.java.net/projects/jigsaw/
          jgiles Jonathan Giles made changes -
          Status Targeted [ 10005 ] Integrated [ 10007 ]
          mrkam Alexander Kuznetcov (Inactive) made changes -
          Link This issue relates to INTJDK-7621000 [ INTJDK-7621000 ]
          mrkam Alexander Kuznetcov (Inactive) made changes -
          Link This issue relates to INTJDK-7621011 [ INTJDK-7621011 ]
          vdyakov Victor Dyakov made changes -
          Alert Reason Ready for review to move on Targeted status.
          Eng Dev plan is ready and funded. Test Plan is created.
          Integrated.
          Pending test cycle
          mrkam Alexander Kuznetcov (Inactive) made changes -
          Link This issue relates to INTJDK-7621041 [ INTJDK-7621041 ]
          kcr Kevin Rushforth made changes -
          Link This issue relates to JDK-8139682 [ JDK-8139682 ]
          vdyakov Victor Dyakov made changes -
          Due Date 2015-11-27 2015-12-10
          vdyakov Victor Dyakov made changes -
          Alert Reason Integrated.
          Pending test cycle
          Integrated (Dev- GREEN]
          Pending SQE test development completion [SQE - YELLOW]
          ecaspole Eric Caspole made changes -
          Link This issue is blocked by JDK-8068210 [ JDK-8068210 ]
          vdyakov Victor Dyakov made changes -
          Alert Reason Integrated (Dev- GREEN]
          Pending SQE test development completion [SQE - YELLOW]
          Integrated (Dev- GREEN]
          Still pending SQE test development update [SQE - YELLOW]
          vdyakov Victor Dyakov made changes -
          Due Date 2015-12-10 2016-01-29
          scfitch Stephen Fitch made changes -
          Labels client-jdkinternals jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs client-jdkinternals jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs toi=yes
          vdyakov Victor Dyakov made changes -
          Due Date 2016-01-29 2016-03-04
          vdyakov Victor Dyakov made changes -
          Alert Reason Integrated (Dev- GREEN]
          Still pending SQE test development update [SQE - YELLOW]
          Integrated (Dev- GREEN]
          Due Date is updated to follow SQE update [SQE - GREEN]
          jgiles Jonathan Giles made changes -
          Link This issue relates to JDK-8148573 [ JDK-8148573 ]
          vdyakov Victor Dyakov made changes -
          Due Date 2016-03-04 2016-03-11
          vdyakov Victor Dyakov made changes -
          Due Date 2016-03-11 2016-03-24
          vdyakov Victor Dyakov made changes -
          Due Date 2016-03-24 2016-04-20
          vdyakov Victor Dyakov made changes -
          Due Date 2016-04-20 2016-07-15
          vdyakov Victor Dyakov made changes -
          Alert Status Green [ 1 ] Yellow [ 2 ]
          vdyakov Victor Dyakov made changes -
          Alert Reason Integrated (Dev- GREEN]
          Due Date is updated to follow SQE update [SQE - GREEN]
          Integrated (Dev- GREEN]
          Due Date is updated to follow SQE test base update completion [SQE - YELLOW]
          jgodinez Jennifer Godinez (Inactive) made changes -
          Workflow JEP Workflow [ 4778921 ] JEP Workflow INFRA-2743 [ 4887876 ]
          jgodinez Jennifer Godinez (Inactive) made changes -
          Workflow JEP Workflow INFRA-2743 [ 4887876 ] JEP Workflow [ 4888625 ]
          vdyakov Victor Dyakov made changes -
          Alert Status Yellow [ 2 ] Green [ 1 ]
          vdyakov Victor Dyakov made changes -
          Link This issue relates to JDK-8081290 [ JDK-8081290 ]
          vdyakov Victor Dyakov made changes -
          Labels client-jdkinternals jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs toi=yes client-jdkinternals jdk9-fc-request jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs toi=yes
          vdyakov Victor Dyakov made changes -
          Labels client-jdkinternals jdk9-fc-request jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs toi=yes client-jdkinternals jdk9-fc-request jdk9-fc-yes jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs toi=yes
          eyavits Evgeny Yavits (Inactive) made changes -
          Due Date 2016-07-15 2016-08-26
          eyavits Evgeny Yavits (Inactive) made changes -
          Integration Due 2015-09-21 2016-08-19
          vdyakov Victor Dyakov made changes -
          Labels client-jdkinternals jdk9-fc-request jdk9-fc-yes jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs toi=yes client-jdkinternals jdk9-fc-request jdk9-fc-yes jdk9-ptt-2015-06-22 jdkinternals modularization no-tck release-note=yes team-clientlibs toi=yes
          vdyakov Victor Dyakov made changes -
          Due Date 2016-08-26 2016-09-02
          vdyakov Victor Dyakov made changes -
          Alert Reason Integrated (Dev- GREEN]
          Due Date is updated to follow SQE test base update completion [SQE - YELLOW]
          Integrated (Dev- GREEN]
          Due Date is updated to follow SQE test base update completion [SQE - GREEN]
          vdyakov Victor Dyakov made changes -
          Due Date 2016-09-02 2016-09-06
          vdyakov Victor Dyakov made changes -
          Due Date 2016-09-06 2016-09-01
          vdyakov Victor Dyakov made changes -
          Alert Reason Integrated (Dev- GREEN]
          Due Date is updated to follow SQE test base update completion [SQE - GREEN]
          Integrated (Dev- GREEN]
          Test development completed [SQE - GREEN]
          vdyakov Victor Dyakov made changes -
          Assignee Jonathan Giles [ jgiles ] Victor Dyakov [ vdyakov ]
          vdyakov Victor Dyakov made changes -
          Status Integrated [ 10007 ] Completed [ 10008 ]
          vdyakov Victor Dyakov made changes -
          Assignee Victor Dyakov [ vdyakov ] Jonathan Giles [ jgiles ]
          vdyakov Victor Dyakov made changes -
          Alert Reason Integrated (Dev- GREEN]
          Test development completed [SQE - GREEN]
          Completed
          vdyakov Victor Dyakov made changes -
          Assignee Jonathan Giles [ jgiles ] Victor Dyakov [ vdyakov ]
          vdyakov Victor Dyakov made changes -
          Resolution Delivered [ 17 ]
          Status Completed [ 10008 ] Closed [ 6 ]
          vdyakov Victor Dyakov made changes -
          Assignee Victor Dyakov [ vdyakov ] Jonathan Giles [ jgiles ]
          vdyakov Victor Dyakov made changes -
          Labels client-jdkinternals jdk9-fc-request jdk9-fc-yes jdk9-ptt-2015-06-22 jdkinternals modularization no-tck release-note=yes team-clientlibs toi=yes client-jdkinternals jdk9-fc-request jdk9-fc-yes jdk9-ptt-2015-06-22 jdkinternals modularization no-tck team-clientlibs toi=yes
          ostuart Owen Stuart made changes -
          Link This issue relates to JDK-8176005 [ JDK-8176005 ]
          ostuart Owen Stuart made changes -
          Link This issue relates to JDK-8176504 [ JDK-8176504 ]

            People

            • Assignee:
              jgiles Jonathan Giles
              Reporter:
              jgiles Jonathan Giles
              Owner:
              Jonathan Giles
              Reviewed By:
              Anton Tarasov, Kevin Rushforth, Leif Samuelsson (Inactive), Victor Dyakov
              Endorsed By:
              Kevin Rushforth
            • Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:
                Integration Due: