Ich schreibe an einer Anwendung die ein ziemlich großes Menü und eine Toolbar und mehrere Kontextmenüs haben wird. Zum Teil werden Funktionen im (Kontext-)Menü und in der Toolbar gleichzeitig verfügbar sein. Jetzt überlege ich, wie ich es am dümmsten anstelle, dass ich nicht mehrere ActionListener-Objekte im Speicher habe, die alle doch nur das gleiche machen.
Ich habe an eine Lösung mit AbstractAction gedacht, aber hier ist das Problem, dass sich die Icons in Toolbar und (Kontext-)Menü hinsichtlich ihrer Größe unterscheiden.
Hat jemand Denkanstoß für mich, wie ich das Dilemma lösen kann?
das Icon kannste ja noch zusätzlich setzen wenn das nicht geht machste einfach mehrere Listener die brauchen kaum Speicher 
In der API steht, dass Action zwei verschiedene Icons haben kann:
icon
All buttons except of JCheckBox, JToggleButton and JRadioButton.
either LARGE_ICON_KEY or SMALL_ICON
The JMenuItem subclasses only use SMALL_ICON. All other buttons will use LARGE_ICON_KEY; if the value is null they use SMALL_ICON.
a.putValue( Action.LARGE_ICON_KEY, kleinesIcon );
a.putValue( Action.SMALL_ICON, grossesIcon );```
**[Edit: wie ich gerade sehe, gibt es die Unterscheidung erst ab Java 1.6]**Ich bin schon froh, dass ich Java 1.5 benutzen kann. Die anderen Anwendungen, die benutzt werden, laufen noch auf 1.4.2 und werden hinsichtlich ihrer Lauffähigkeit auf 1.5 stückenweise getestet.
Bleibt mir wohl nichts übrig, als die Listener in jeweils eigene Klassen zulegen und falls notwendig durchzureichen.
Wie wäre es ein Action zu schreiben, welche die Werte einer anderen Action verwendet (bis auf gewisse Ausnahmen, ein Icon zum Beispiel), und so ein Art Wrapper für Actions, die auf die Toolbar oder das Menü kommen, zu machen?
Das Action-Interface ist nicht gross, und Actions haben so grosse Vorteile gegenüber einem ActionListener, da lohnt sich ein bisschen Aufwand.
Starre Actionstrukturen sind sicherlich begrenzt brauchbar 
Wäre eine Möglichkeit. Muss ich mal drüber nachdenken.
André, ich verstehe deine Aussage nicht. 
Das Actionkonzept dient ja der Gleichschaltung bestimmter Eigenschaften, nicht wahr?
Diese Gleichschaltung stört demnach dort, wo eine Eigenschaft gleichzeitig verschiedene Werte haben soll.
Das stimmt schon, hast du dann noch eine andere Idee? Wie würdest du das machen?
Naja, ich hab keine Standardlösung. Nach Beni geht’s ja wohl mit Actions.
Ansonsten gibt’s imho nicht viel Alternativen:
entweder mehrere Listener machen, wie EagleEye vorschlug,
oder einen Listener, der die Quellkomponenten mittels getSource() unterscheidet.
Oder eine Kombination dieser Lösungen.
Je nach Kontext könnte man abwägen, was am besten passt.