Currently it's not possible to configure hostname verification with SSLOptions, see the discussion on this pull request. In addition, it's not possible to use Netty's own SslContext, which uses OpenSSL for optimal performance.
The workaround to both of these problems is to implement a custom NettyOptions to register the SslHandler yourself, but it would be nice to refactor SSLOptions in order to have a more user-friendly API.
To elaborate on the changes, I think the solution would be to turn SSLOptions into an interface with a single createSSLHandler() method.
That method would be used in Connection.Initializer#initChannel() instead of building the SslHandler manually.
Then we could provide out-of-the-box implementations:
one that builds the SslHandler from Netty's SslContext. It should be the default because Netty can take advantage of OpenSSL if it is present, yielding better performance. (actually the default is no SSL)
one that builds the SslHandler from a JDK's SslEngine like the current code does. It would serve as a legacy option if some people want to stick to JDK's SSL and are more comfortable configuring the SslEngine directly, and/or if they use the shaded JAR.
We should also take into account the remarks in JAVA-948.