Binary incompatibility with netty 4.0.*

Continuing the discussion on the commit that broke this.

Expected behavior

Code compiled against netty 4.0.* should run fine with a later runtime.

Actual behavior

Classes compiled against 4.0.* methods using ByteBufProcessor produce NoSuchMethodErrors since they were migrated to ByteProcessor in 4.1:

Exception in thread "main" java.lang.NoSuchMethodError: io.netty.buffer.ByteBuf.forEachByte(Lio/netty/buffer/ByteBufProcessor;)I
	at Test.main(Test.java:7)

Steps to reproduce

1. Compile the code below against netty-buffer and netty-common version 4.0.48.Final
2. Run the code against the same libraries version 4.1.0.Final
3. Receive the exception pasted above.

Minimal yet complete reproducer code (or URL to code)

import io.netty.buffer.Unpooled;
import io.netty.buffer.ByteBufProcessor;

public class Test {
	public static void main(String[] args) {
		ByteBufProcessor proc = b -> true;
		Unpooled.buffer().forEachByte(proc);
	}
}

Netty version

not applicable

JVM version (e.g. java -version)

Java 8

OS version (e.g. uname -a)

not applicable

---

The commit includes multiple kinds of this issue that would be nice to be fixed, with varying degrees of difficulty:

• abstract methods with changed parameter types can simply have another method of the old type added which delegates to the new type.
• some interface methods with changed parameter types could be fixed with a default method - I’m not up-to-date with the state of netty using java 8 so I don’t know how realistic this is.
• methods with changed return types could be migrated with tooling like bridger. This is probably overkill.

It would be nice to verify a possible fix to this issue automatically by scanning the method signatures, but this is not necessary.

Also note that this issue was introduced in a beta version, so it might not be necessary to fix all incompatibilities in this commit since some may only affect older beta versions, not 4.0.*.

I’m willing to spend some time fixing this after a discussion on how to approach this issue but it could take ~weeks since I’m a bit busy with other work.

[yawkat]

That makes using libraries using netty (such as the mongo java driver, vert.x, apparently even spring) much more difficult. Can you add a more visible note on your website saying so then? It can be very difficult recompiling libraries for a project because there is a version conflict (that’s how I found the issue in the first place).

[Scottmitch]

Another aspect of the problem is the Netty project has become a large conglomeration of relatively independent modules all versioned together. This makes inclusion of Netty simpler and management is all in a single place, but makes the threshold for a major version bump higher. An alternative is to break the Netty project up and independently version modules/projects. This will allow us to make more targeted changes and do major version bumps at the expense of complicating the inclusion of Netty into applications (and maybe require some sort of version compatibility matrix/story).