Difference between Java implementation and UML specification wrt interfaces and abstract classes

Various similar-looking questions exist but I could find none that responds to my query.

My question concerns implementation of Design Patterns in Java. For the ease of explanation, I'm considering the Command design pattern as shown in this diagram.

Since this UML representation requires that "Invoker" should be an interface and that it should also have an N-ary aggregation relationship with the "Command" interface, it's not possible to implement it if I define Invoker as a Java interface because I can't declare non-static non-final attributes in a Java interface and I do need to define a non-final Collection of "Command" objects to establish that aggregation relationship between "Invoker" and "Command".

So, I went ahead and implemented Invoker as an abstract class, which lets me have the aggregation and also provides abstraction to the implementations of "Invoker" but I'm wondering if it is a good design practice because UML does have a stereotype <<abstract>> but the UML class diagram for this pattern explicitly specifies using an interface rathern than an abstract class. I've also done the same for "Subject" interface of "Observer" pattern implementation in Java for a similar reason.

Please let me know if there's a way to keep "Invoker" as an interface in Java and still achieve the aggregation relationship with the specified multiplicity. If what I did is the best way to do it, please let me know if it may have some adverse effects on the structure of a program I build using the pattern this way.