netty / netty-jni-util

Netty Project

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

Links

• Web Site
• Downloads
• Documentation
• @netty_project
• Official Discord server

How to build

For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.

You require the following to build Netty:

• Latest stable OpenJDK 8
• Latest stable Apache Maven
• If you are on Linux or MacOS, you need additional development packages installed on your system, because you'll build the native transport.

Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+ / 4.1+) is enough to run your Netty-based application.

Branches to look

Development of all versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.1 resides in the branch '3.9' and the branch '4.1' respectively.

Usage with JDK 9+

Netty can be used in modular JDK9+ applications as a collection of automatic modules. The module names follow the reverse-DNS style, and are derived from subproject names rather than root packages due to historical reasons. They are listed below:

• io.netty.all
• io.netty.buffer
• io.netty.codec
• io.netty.codec.dns
• io.netty.codec.haproxy
• io.netty.codec.http
• io.netty.codec.http2
• io.netty.codec.memcache
• io.netty.codec.mqtt
• io.netty.codec.redis
• io.netty.codec.smtp
• io.netty.codec.socks
• io.netty.codec.stomp
• io.netty.codec.xml
• io.netty.common
• io.netty.handler
• io.netty.handler.proxy
• io.netty.resolver
• io.netty.resolver.dns
• io.netty.transport
• io.netty.transport.epoll (native omitted - reserved keyword in Java)
• io.netty.transport.kqueue (native omitted - reserved keyword in Java)
• io.netty.transport.unix.common (native omitted - reserved keyword in Java)
• io.netty.transport.rxtx
• io.netty.transport.sctp
• io.netty.transport.udt

Automatic modules do not provide any means to declare dependencies, so you need to list each used module separately in your module-info file.

netty-jni-util's Issues

netty-jni-util is incompatible with static compilation

When building statically there is only one copy of netty-jni-util. This means 1) all parts of the binary must use the same version of netty-jni-util and 2) static variables are shared. This is an issue if epoll and tcnative both are in the same static binary.

(1) introduces a bit of a theoretical problem. Since there is no API stability for netty-jni-util we need to make sure that both netty and netty-tcnative releases use the same version of netty-jni-util. Or there's weak enough stability to allow a little version skew between the projects (preferred, isn't always necessary). Either way this is probably easy and close to what might be done anyway, but didn't seem guaranteed.

(2) means that either the static variables must be shareable or they must be defined by each consumer of netty-jni-util instead. staticPackagePrefix is not shareable.

Would it be better to define staticPackagePrefix in the callers (maybe exposed as one member of a struct) and have it be passed by address to Load/Unload to be maintained by netty-jni-util? Or would it be better to just have the load_function() do a strcpy at the end of load_function() and store in its own static?