Go to file
Chris Vest 6cc49c1c62 Turn ByteIterator into ByteCursor
Motivation:
Cursors are better than iterators in that they only need to check boundary conditions once per iteration, when processed in a loop.
This should make them easier for the compiler to optimise.

Modification:
Change the ByteIterator to a ByteCursor. The API is almost the same, but with a few subtle differences in semantics.
The primary difference is that the cursor movement and boundary condition checking and position movement happen at the same time, and do not need to occur when the values are fetched out of the cursor.
An iterator, on the other hand, needs to throw an exception if "next" is called too many times.

Result:
Simpler code, and hopefully faster code as well.
2020-12-09 11:02:51 +01:00
.github/workflows Capture build artifacts for failed builds 2020-12-01 14:38:09 +01:00
src Turn ByteIterator into ByteCursor 2020-12-09 11:02:51 +01:00
.dockerignore Add a docker-based build 2020-11-18 17:16:37 +01:00
.gitignore Prepare incubator repo for new buffer API 2020-11-17 14:56:28 +01:00
Dockerfile Try a different caching mechanism 2020-11-21 15:26:10 +01:00
Makefile Capture build artifacts for failed builds 2020-12-01 14:38:09 +01:00
pom.xml The assertj-core dependency should only be available in test scope 2020-11-23 18:11:22 +01:00
README.md Explain the make build in the README.md file 2020-11-18 17:32:42 +01:00

Netty Incubator Buffer API

This repository is incubating a new buffer API proposed for Netty 5.

Building and Testing

Short version: just run make.

The project currently relies on snapshot versions of the Panama Foreign fork of OpenJDK. This allows us to test out the must recent version of the jdk.incubator.foreign APIs, but also make building and local development more involved. To simplify things, we have a Docker based build, controlled via a Makefile with the following commands:

  • image build the docker image. This includes building a snapshot of OpenJDK, and download all relevant Maven dependencies.
  • test run all tests in a docker container. This implies image. The container is automatically deleted afterwards.
  • dbg drop into a shell in the build container, without running the build itself. The debugging container is not deleted afterwards.
  • clean remote the debugging container created by dbg.
  • build build binaries and run all tests in a container, and copy the target directory out of the container afterwards. This is the default build target.