What if we had a way of testing APIs before they were released? We are not talking of tests by in-house developers who could be blind to actual faults that the average user finds daunting. What if we had a way of getting users to test it before standardizing it? Oracle has promised us pretty much the same for some time now.
With the Incubating Modules in Java 9, Oracle now allows developers to get their say in the developmental process. Incubator modules put APIs that are still in the developmental stage in the user’s domain. This is even as the API’s fate in being decided, its standardization or even removal is under consideration.
The Incubator Module
In some ways it may seem similar to Project Amber that was released early this year in that both deal with unfinished APIs. However, there are differences in how their developmental process is approach. While the goal behind Project Amber is to bring a time-bound priorityin API maturation, incubator modules is asking the wider OpenJDK Community to enhance the API itself.
Under the incubator module, Oracle will put unfinished APIs in the public domain. Developers can work on these making changes and modifications. The new JDK release may include the changes and standardize the API or it may remove it entirely. The API can also be assimilated in an existing module.
But why would Oracle distribute a weaker, incubating API that is still undergoing development? This is not a simple PR strategy. Rather, it is a smart well-thought out tactic to reduce the chances for any mistake in the Java SE Platform. The APIs available in the incubating module will typically be those applications that need work before being standardized, where Oracle will need a better idea of user reception and functionality of the application.
This is just a clever way of creating a more favorable market reception, while testing it out prior to release. This will be a time-bound project with a limited incubation period with the API’s fate decided in the next release. It is believed that these SE platform APIs will benefit from going throughthe JDK Release Project where even developers from outside the OpenJDK Community will use it and provide valuable feedback.
Oracle has also made clear what the incubation project is NOT. It has made clear that this will be applied in only some APIs and not every application that is under consideration. This will not be a general-purpose mechanism nor a defined lifecycle for every API.
An incubating module will have no more than one incubating feature and it will be clearly defined. This is important to avoid cluttering up any one module or the dumping of a module with all incubating features. It also establishes a clear ownership as well as make it easy for us to track the progress. Further it will not be automatically a lifetime part of its original JDK Release Project. It can be removed from the next updates or evolve further. Each module will keep a record of changes made during the incubation.
As with any new feature, there is a healthy debate on the positives and limitations of the incubation module. The challenge obviously lies in dependency issue. The developers have to be ready to work on an API which is still evolving and change significantly later on. It can even be removed. But this can be compared to developers who prefer to wait for the GA release of a new version instead of opting for the EA Release. In other words, developers who work on incubating features will be well aware and willing to work in an evolving API.
The benefits are obvious and Oracle has made it pretty clear in stating the goal for the module. It ultimately aims for reducing mistakes. But there are other benefits incurred as well:
With incubating modules Java 9 is making a bold attempt for a greater involvement of the developer community in the development of its APIs. It could help in weeding out the errors, while enhancing the functionality of its applications. Contact Us For Java Application Development Services.