# Getting Started

This section contains information that should help you get going with `Reactor Netty`. It includes the following information:

- Introducing Reactor Netty

- Prerequisites

- Understanding the BOM and versioning scheme

- Getting Reactor Netty

## 1. Introducing Reactor Netty

Suited for Microservices Architecture, `Reactor Netty` offers backpressure-ready network engines for `HTTP` (including Websockets), `TCP`, and `UDP`.

## 2. Prerequisites

`Reactor Netty` runs on `Java 8` and above.

It has transitive dependencies on:

- Reactive Streams v1.0.4

- Reactor Core v3.x

- Netty v4.2.x

## 3. Understanding the BOM and versioning scheme

`Reactor Netty` is part of the `Project Reactor BOM` (since the `Aluminium` release train). This curated list groups artifacts that are meant to work well together, providing the relevant versions despite potentially divergent versioning schemes in these artifacts.

| The versioning scheme has changed between 0.9.x and 1.0.x (Dysprosium and Europium).

Artifacts follow a versioning scheme of `MAJOR.MINOR.PATCH-QUALIFIER` while the BOM is versioned using a CalVer inspired scheme of `YYYY.MINOR.PATCH-QUALIFIER`, where:

- `MAJOR` is the current generation of Reactor, where each new generation can bring fundamental changes to the structure of the project (which might imply a more significant migration effort)

- `YYYY` is the year of the first GA release in a given release cycle (like 1.0.0 for 1.0.x)

- `.MINOR` is a 0-based number incrementing with each new release cycle

  - in the case of projects, it generally reflects wider changes and can indicate a moderate migration effort

  - in the case of the BOM it allows discerning between release cycles in case two get first released the same year

- `.PATCH` is a 0-based number incrementing with each service release

- `-QUALIFIER` is a textual qualifier, which is omitted in the case of GA releases (see below)

The first release cycle to follow that convention is thus `2020.0.x`, codename `Europium`. The scheme uses the following qualifiers (note the use of dash separator), in order:

- `-M1`..`-M9`: milestones (we don’t expect more than 9 per service release)

- `-RC1`..`-RC9`: release candidates (we don’t expect more than 9 per service release)

- `-SNAPSHOT`: snapshots

- no qualifier for GA releases

| Snapshots appear higher in the order above because, conceptually, they’re always "the freshest pre-release" of any given PATCH. Even though the first deployed artifact of a PATCH cycle will always be a -SNAPSHOT, a similarly named but more up-to-date snapshot would also get released after eg. a milestone or between release candidates.

Each release cycle is also given a codename, in continuity with the previous codename-based scheme, which can be used to reference it more informally (like in discussions, blog posts, etc…​). The codenames represent what would traditionally be the MAJOR.MINOR number. They (mostly) come from the Periodic Table of Elements, in increasing alphabetical order.

| Up until Dysprosium, the BOM was versioned using a release train scheme with a codename followed by a qualifier, and the qualifiers were slightly different. For example: Aluminium-RELEASE (first GA release, would now be something like YYYY.0.0), Bismuth-M1, Californium-SR1 (service release would now be something like YYYY.0.1), Dysprosium-RC1, Dysprosium-BUILD-SNAPSHOT (after each patch, we’d go back to the same snapshot version. would now be something like YYYY.0.X-SNAPSHOT so we get 1 snapshot per PATCH)

## 4. Getting Reactor Netty

As mentioned earlier, the easiest way to use `Reactor Netty` in your core is to use the `BOM` and add the relevant dependencies to your project. Note that, when adding such a dependency, you must omit the version so that the version gets picked up from the `BOM`.

However, if you want to force the use of a specific artifact’s version, you can specify it when adding your dependency as you usually would. You can also forego the `BOM` entirely and specify dependencies by their artifact versions.

### 4.1. Maven Installation

The `BOM` concept is natively supported by `Maven`. First, you need to import the `BOM` by adding the following snippet to your `pom.xml`. If the top section (`dependencyManagement`) already exists in your pom, add only the contents.

    <dependencyManagement> (1)
        <dependencies>
            <dependency>
                <groupId>io.projectreactor</groupId>
                <artifactId>reactor-bom</artifactId>
                <version>2025.0.6</version> (2)
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

1 | Notice the `dependencyManagement` tag. This is in addition to the regular `dependencies` section.
2 | As of this writing, `2025.0.6` is the latest version of the `BOM`. Check for updates at github.com/reactor/reactor/releases.

Next, add your dependencies to the relevant reactor projects, as usual (except without a `<version>`). The following listing shows how to do so:

    <dependencies>
        <dependency>
            <groupId>io.projectreactor.netty</groupId>
            <artifactId>reactor-netty-core</artifactId> (1)
            (2)
        </dependency>
    </dependencies>
    <dependencies>
        <dependency>
            <groupId>io.projectreactor.netty</groupId>
            <artifactId>reactor-netty-http</artifactId>
        </dependency>
    </dependencies>

1 | Dependency on `Reactor Netty`
2 | No version tag here

### 4.2. Gradle Installation

The `BOM` concept is supported in Gradle since version 5. The following listing shows how to import the `BOM` and add a dependency to `Reactor Netty`:

    dependencies {
        // import a BOM
        implementation platform('io.projectreactor:reactor-bom:2025.0.6') (1)

        // define dependencies without versions
        implementation 'io.projectreactor.netty:reactor-netty-core' (2)
        implementation 'io.projectreactor.netty:reactor-netty-http'
    }

1 | As of this writing, `2025.0.6` is the latest version of the `BOM`. Check for updates at github.com/reactor/reactor/releases.
2 | There is no third `:` separated section for the version. It is taken from the `BOM`.

### 4.3. Milestones and Snapshots

Milestones and release candidates are distributed through `Maven Central`.

| Milestone and release candidate releases are for testing purposes and are not intended for production use.

Snapshots are distributed through the `Spring Snapshots` repository rather than `Maven Central`. To add it to your build configuration file, use the following snippet: (for both Maven and Gradle):

-SNAPSHOTs in Maven

    <repositories>
    	<repository>
    		<id>spring-snapshots</id>
    		<name>Spring Snapshot Repository</name>
    		<url>https://repo.spring.io/snapshot</url>
    	</repository>
    </repositories>

-SNAPSHOTs in Gradle

    repositories {
      maven { url 'https://repo.spring.io/snapshot' }
      mavenCentral()
    }

## 5. Support and policies

The entries below are mirroring github.com/reactor/.github/blob/main/SUPPORT.adoc

### 5.1. Do you have a question?

| Search Stack Overflow first; discuss if necessary

If you’re unsure why something isn’t working or wondering if there is a better way of doing it please check on Stack Overflow first and if necessary start a discussion. Use relevant tags among the ones we monitor for that purpose:

- `reactor-netty` for specific reactor-netty questions

- `project-reactor` for generic reactor questions

If you prefer real-time discussion, we also have a few Gitter channels:

- `reactor` is the historic most active one, where most of the community can help

- `reactor-core` is intended for more advanced pinpointed discussions around the inner workings of the library

- `reactor-netty` is intended for netty-specific questions

Refer to each project’s README for potential other sources of information.

We generally discourage opening GitHub issues for questions, in favor of the two channels above.

### 5.2. Our policy on deprecations

When dealing with deprecations, given a version `A.B.C`, we’ll ensure that:

- deprecations introduced in version `A`.`B`.`0` will be removed no sooner than version `A`.`B+1`.`0`

- deprecations introduced in version `A`.`B`.`1+` will be removed no sooner than version `A`.`B+2`.`0`

- we’ll strive to mention the following in the deprecation javadoc:

  - target minimum version for removal

  - pointers to replacements for the deprecated method

  - version in which method was deprecated

| This policy is officially in effect as of January 2021, for all modules in `2020.0` BOMs and newer release trains, as well as `Dysprosium` releases after `Dysprosium-SR15`.

| Deprecation removal targets are not a hard commitment, and the deprecated methods could live on further than these minimum target GA versions (ie. only the most problematic deprecated methods will be removed aggressively).

| That said, deprecated code that has outlived its minimum removal target version may be removed in any subsequent release (including patch releases, aka service releases) without further notice. So users should still strive to update their code as early as possible.

### 5.3. Support Timeline

For a summary of support dates for each individual project and BOM support, please refer to the Reactor Support page.

- Related Project Reactor Documentation
  - Reactor Core
  - Reactor Netty
  - Reactor Kafka
  - Reactor BlockHound

Search in all Project Reactor Docs