perhaps except for ByteBuffers + some reflection voodoo
Voodoo is kind of nonspecific as far as implementation strategy descriptions go.
I guess we need to reuse such a wrapper object if we must take a reflection-based instantiation hit each time.
DirectByteBuffers + reflection does open up the possibility of using the unsafe directly to manage memory, which may be desirable.
Isn't this undesirable? Unsafe is a vendor specific extension. Even then Oracle recently ran a public survey asking what uses of Unsafe are common and what would happen if it went away. We do use Unsafe and have some exposure to this, but do have an un-Unsafe fallback in those places.
This has the benefit of sticking with the JVM "native" APIs,
Don't the "native" ByteBuffer method calls tend not to be inlined? I have heard the complaint but have not personally examined JIT disassembly (yet). Aren't there boundary checks and index compensations sprinkled throughout? (which Netty does away with in the simple ByteBuf types)
As you say, more investigation is necessary
Great, let's proceed. At the moment this issue is about what happens if you even try to bring in 4. On that, N pointed me to TestHCM#testClusterStatus, which tests the multicast status publisher he implemented with Netty 3 channels. My port of that to Netty 4 APIs fails if I remove the @Ignore decoration, so I don't have it right yet.