In Sasl.createSaslServer() method, the serverName argument is documented as "[t]he non-null fully qualified host name of the server". This means a SASL service must specify the exact hostname it is serving at (say, my.host.com). This is not true any more in today's virtualized world in which a service might be serving clients from different networks by exposing different service names.
Update: the main bug will cover the SASL API change and trivial changes to mechanisms. Further enhancement for the GSSAPI/krb5 mech will be addressed in a sub task.
The What's New section of the release notes links to the Enhancements page of the security guide (docs/technotes/guides/security/enhancements-8.html), which contains a summary of this change.
scope: Java SE
text: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME.