The zookeeper client currently contains a StaticHostProvider and no means to replace it with your own implementation of the existing HostProvider interface. It would be great if the zookeeper client would enable you to create an instance with your own implementation of the HostProvider interface.
We have been testing this change with our implementation of HostProvider which does the name to ip lookup at the time of finding the next() server to connect to. In our AWS based deployments, this enables that applications can actually connect to swapped out zookeeper-servers which typically get a new ip address. With the current StaticHostProvider in practice you will need to restart the application to see the replaced zookeeper as the application continues to try to connect to the old no longer existing IP address.
With this little change plus a straightforward implementation of the HostProvider interface (our LateResolvingHostProvider), we can replace the zookeeper servers one at a time, re-assigning the elastic ips we use for the zookeeper servers, and have the application servers re-connect to the zookeeper cluster including the replaced ones without any downtime and without having to rely on the elastic ips for client to zookeeper-server connections. The reason for not using elastic-ips in the connect-strings but use the names which map to the (changing) private ips is to be able to rely on security-groups to control access.
While this seems very specific for AWS, this anyway seems a generic improvement for other deployments where the mapping from server name to IP address is not static.