I only see a problem with this from a theoretical point of view, while having these two quotes from JCIP in mind:
You should avoid the temptation to think that there are “special” situations in which this rule does not apply. A program that omits needed synchronization might appear to work, passing its tests and performing well for years, but it is still broken and may fail at any moment.
But an object is in a predictable, consistent state only after its constructor returns, so publishing an object from within its constructor can publish an incompletely constructed object. This is true even if the publication is the last statement in the constructor.
Only wanted to point it out. I am no concurrency expert, but appearently there can be "hidden" (/non-obvious) vulnerabilities.
A scenario might be if a ConnectionCreationListener creates a new Thread (actually doing this from within the Connection's constructor) and accesses the yet incomplete Connection instance and might face visibility or similar concurrency issues (which I think can't be circumvented with usual synchronization).
ConnectionCreationListener might not start threads within Smack, but nonetheless it's public API and we are using it outside of Smack, too. We don't start threads, but other users might do so.