The Importance of API
Having a consistent and functional API is critical in a software component. There is a famous saying: "API is forever". This is true. Once a class, interface or method is public or protected, it cannot be deleted and is expected to function until the end of time, even when deprecated.
In OpenJFX, due to package visibility or other reasons, sometimes a method needs to be public or protected so that it can be called as part of the implementation of the toolkit. Such methods have the "imp_" prefix. These methods are not API and can be deleted or changed at any time (the JavaDoc clearly states this).
Steps for API Review
Because API is so important, there are a few more restrictions over and above the normal code review process:
- Ensure that there is a JIRA that covers the work
- Add the label 'api' to the JIRA
- Ensure there is a pre-commit review of the code in the JIRA
- Send an email to openjfx@java.net with the title: "[<release>] API Review for <bug-id>: <summary>"
- In addition to the normal reviewers, a +1 is required from the Team Lead or an Architect before the code is committed
Behavioural Changes
Changes in behaviour can break the users of the toolkit. Major changes in behaviour such as threading should be treated like API and require the same steps as an API review. It is critical that the Team Lead and Architects are aware of how the toolkit behaves and understand how it is used.
While API is easy to define, behavioural changes can be fuzzy. When in doubt, ask.
FXML Considerations
When defining API, it's often easy to forget to take into account how the API will be accessed from FXML. New events and properties are easily consumed by FXML. In constructors, use of @NamedArg() allows FXML to construct objects, often to be assigned to properties.
When defining an API, if applicable, ensure that the API can be consumed from FXML and provide test cases that show how it is done.
Overview
Content Tools
ThemeBuilder