Summary

This JEP proposes a policy change to disable all experimental features in the default OpenJDK build. The main benefit of this new policy is that developers that are not involved in any given experimental feature will not have to consider the consequences for that experimental feature in their day-to-day work.

Non-Goals

Motivation

Implementation details of experimental features should not bleed into the implementation work of regular features and maintenance work of the generally supported codebase. Only those using an experimental feature should need to be involved in supporting the feature.

With a scheme like this, experimental code is not compiled by others than those who actually is using the features. This enables larger experimental features to be included in the JDK source base as long as they can be easily separated out using #ifdef and macro definitions.

This scheme will also simplify development in environments that don't support all experimental features and where some of the C++ code simply won't build.

Description

The JDK project allows to some extent experimental features to be included in the code base. An experimental feature is a feature that for instance needs time to mature, or which's value is still to be determined before becoming a regular feature. As these features are experimental they can't be enabled by default but require some command line option in conjunction with the flag -XX:+UnlockExperimentalVMOptions to be enabled.

To obtain a clean base for the OpenJDK community to build on we propose that no experimental features should be included in a default build of the OpenJDK. Any code related to these features should be disabled using macro definitions in the source code. To enable experimental features, the corresponding flags should be included when configuring the build.

At the time of writing the experimental features included in the OpenJDK are:

• AppCDS
• ZGC
• Epsilon GC
• Graal

Any vendor is obviously free to enable any experimental features in their OpenJDK distributions.

Testing

No particular testing is required for this policy change. The implementation required to support this change can be tested using simple regression tests that verifies that none of the known experimental features are present in a default OpenJDK build.

Risks and Assumptions

If maintainers of experimental features are not actively testing and updating their feature there is a risk that an experimental feature will suffer from code rot and stop working after some time. We assume that maintainers of experimental features will assume the responsibility of maintaining their features.