It depends entirely on how cluttered your UI object is and the type of work that needs to be done in the listener.
are bad. Don't use them. A UI object which implements many listeners and handles many diverse aspects of its controls can get bulky and what may initially be a single-responsibility class may become some grotesque god object doing many different things. In this case, the answer is no. Clearly you need to extend some of the functionality to utility classes in that case. Create a namespace or package for the express purpose of containing listeners and create a class for each handler until your god class turns into something of a demigod class at least.
That said, if you're handling a single property listener and the UI class is reasonably self-contained, nobody will frown at you for extending a simple interface for a simple listener.
are bad. Specifically listener methods performing many many complex operations. Even if the class which contains it is simple, I would create my own
PropertyChangeListener implementation to deal with an action involving anything more complicated than opening a window or updating a button label.
If you find that this method requires many instances contained in your UI class, don't be afraid to pass the necessary instances to its constructor. If you wind up with many tedious low-level statements, consider creating helper classes which can simplify these calls into one single static method call. If you need to perform complex actions such as connecting to a database and performing a query, try to put dao operations into its own classes, and the listener would only need to call them.
Even with these considerations, should your method end up complicated and bulky, it makes an excellent candidate to be put into its own implementation and broken up into submethod calls. This allows you to free up your UI class, and it remains very much a single-responsibility class.
If you have any further questions, just ask in the comment section, and I'll respond as soon as I can.