You’ve probably heard about Java providing features like records, multi-line text blocks or sealed types and you’d like to try them.

Those features are called feature previews and it means a couple of things:

1. the Java team wants you to test them and give feedback. They want honest feedback about how it feels to use them, whether you like them or not. Both ways, feedback is important.

2. because they are feature previews, you shouldn’t them use in production, but you can play with them for toy projects.

There’s actually an important thing about point 2 if you are a library author: never, ever publish a library which uses feature previews on Maven Central. The reason is that the feature previews leak to consumers: as soon as you start using them, any project depending on your code will also have to enable them. This is not a problem for toy projects, it’s clearly a problem for published libraries. In particular, there are no guarantees that the generated bytecode will be compatible with future Java releases, and there are no guarantees that the feature preview will make it to Java eventually.

The goal of this blog post is not to explain what records or sealed classes are, there’s already a lot of litterature about it. Instead, we’re going to explain how to configure your Gradle build to use feature previews and therefore report issues/bugs to the JDK team.