This looks interesting; can you provide an example of usage (showcasing its improvements over the listener interface)? Also, is there any particular reason for making the fields public instead of final private fields?

This model would allow you to do something like this:

IPCFunctionalListener listener = new IPCFunctionalListener();
listener.readyHandler = (client)->System.out.println("Ready");
listener.onError = this::disconnectHandler; // private void disconnectHandler(IPCClient, Throwable)
client.setListener(listener);

Having them be fields is just a "ease of use" thing. Since there would be no restrictions beyond the normal Java type system you don't need any extra setter checks. They can't be final in this model because they are not set during object creation.

In theory this might be a touch slower, but the modern JVM should optimize it enough so it does not mater as well as the infrequent use of the callbacks.

Usually for adapters like this (and other things that activate on events) you'd want to make the fields final for safety as things get passed around (and a builder pattern for creation of the adapter).

For something that shouldn't be final, the java bean pattern should probably be used.

I'll change that in a couple of days.