Annotations statt Listeners?

[Landei]

Zwei Fragen:
- Haltete ihr das für eine gute Idee (ich habe da so meine Zweifel)?
- Gibt es vielleicht sowas schon als Bibliothek?

@Target({FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface CallAction {
  String value();
}

...
JFrame frame = new JFrame("Test") {
      @CallAction("buttonPressed")
      public JButton button = new JButton("Press me!");
      {
             setSize(200,200);
             setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
             getContentPane().add(button);
      }
      public void buttonPressed() {
            System.out.println("Press harder, I can take it!");
      }
};
process(frame);  //<------- Installiert die annotierten ActionListener per Reflection
frame.setVisible(true);
...

Funktionieren tut das schon (die process-Methode ist nur so hässlich, das ich sie nicht posten will)...

Die nächsten logischen Schritte wären:
- Alle Top-Level-Container (JFrame, JDialog, JInternalFrame...) abzuleiten, damit sie process schon im Konstruktor aufrufen
- verschachtelte Container rekursiv nach Annotations abzusuchen
- andere Listener zu unterstützen

Edit: Natürlich kommt man auch an private-Felder ran, wenn die Policy es nicht verbietet, siehe z.B. Javax Den: Hack any Java class using Reflection

 

[bygones]

ich bin der meinung erstmals alles was dem Anwender vereinfacht Code zu schreiben bzw zu verstehen ist lohnenswert.

Falls dieser Gewinn nicht zu teuer ist (allen voran performance) - go for it ....

soviel zur Theorie...

Ein konkretes Problem was ich hier bei den Annotation - wie schauts da mit Parametern aus ? also den beruehmten EventObjects ?

da find ich den Builder/Closure ansatz in Groovy (und wo auch immer noch) um einiges angenehmer

 

[Der Müde Joe]

Wir haben auch mal so was gebastelt. @History auf attribute, welche über eine GenericBase via reflection einen Setter aufrufen und falls Annotiert ein History Objekt erzeugen. Alles in allem: Debuggers Hell.... Aber von der Idee her ists interessant.

 

[byte]

Sowas ähnliches gibts bereits in Form der EventBus Library. Ist zwar nicht das gleiche (also nicht für explizit für Swing Komponenten), lässt sich aber perfekt in Swing MVC Konzepte fürs Event Handling integrierern.

Ich habe mir was ähnliches geschrieben für die Actions in der GUI. Ich kann Methoden mit @Action annotieren. Diese Actions werden registriert und über die Registry kann man sich dann eine Swing-Action holen für Menüs, ToolBars, Buttons etc. Die Actions laufen bei Bedarf nebenläufig in nem Workerthread. Ausserdem können sie mit Rollen annotiert werden. Dann gibts automatisch einen SecurityCheck, der prüft, ob der aktuelle Nutzer die Berechtigung hat.

Annotierte Methoden lassen sich übrigens recht komfortable mit AspectJ verarbeiten. Mein Security Check sieht z.B. so aus (Secured ist hier der Annotation Typ):

    @Before(
            value="execution(public * de.myproject.some.package...*.*(..)) && @annotation(secured)",
            argNames="secured")
    public void doAccessCheck(Secured secured) {
    ...
}

 

[Landei]

ich bin der meinung erstmals alles was dem Anwender vereinfacht Code zu schreiben bzw zu verstehen ist lohnenswert.

Falls dieser Gewinn nicht zu teuer ist (allen voran performance) - go for it ....

soviel zur Theorie...

Ein konkretes Problem was ich hier bei den Annotation - wie schauts da mit Parametern aus ? also den beruehmten EventObjects ?

da find ich den Builder/Closure ansatz in Groovy (und wo auch immer noch) um einiges angenehmer

Ich hatte mir das in der nächsten "Ausbaustufe" so gedacht: Ich suche nach der Methode mit dem gegebenen Namen. Wenn diese das richtige Event-Objekt erwartet, bekommt sie es übergeben, bei leerer Argumentliste eben nicht. Ist die Methode nicht eindeutig, oder besitzt sie keine passende Argumentliste, wird ein Fehler geworfen.

 

[Gelöschtes Mitglied 5909]

das gibts doch auch schon im Swing Application Framework, oder irr ich mich?
Bin nicht os der GUI bauer...

https://appframework.dev.java.net/intro/index.html

 

[byte]

Jo, aber der JSR war lange eingefroren und niemand wusste so genau, wie es damit weiter geht. Keine Ahnung, wie der aktuelle Stand ist, zumindest ist der Status ja wieder In Progress.

 

[Noctarius]

Ich habe sowas ähnliches auch umgesetzt, allerdings als generelles Eventsystem. Du kannst die Eventklasse immer selber erstellen (mit beliebig vielen Fields oder von mir aus nenn es in diesem Fall Parameter) und dann mit fireEvent werfen.

http://www.castellcore.org/svn/cast...astellcore/api/support/annotations/Event.java

 

[palador]

Hätte noch eine Idee, damit du nicht alle Klassen ableiten musst.

Baue dir doch einfach eine statische Methode die du auf alle JComponents anwenden kannst, z.B.: public static void setup4Events. Diese parst die JComponent nach addABCListener(JComponent setupMe) methoden. Und fügt dann alle möglichen Listener hinzu. Der Clou: die Listener durchsuchen dein Object nach Annotierten Methoden und führen sie aus, sobald ein event eingetreten ist. Den Ansatz müsste man noch zuende denken, aber er würde dir auf jeden Fall das Erweitern aller JComponent erweiternder Klassen ersparen und würde auch mit JComponents, die andere implementiert haben funktionieren...

 

[Noctarius]

Einen ähnlichen Ansatz habe ich gewählt. Es gibt einen EventManager der sich um die Verteilung der Events kümmert und entsprechend in den Klassen die annotierten Methoden aufruft.

 

[Landei]

Hätte noch eine Idee, damit du nicht alle Klassen ableiten musst.

Baue dir doch einfach eine statische Methode die du auf alle JComponents anwenden kannst, z.B.: public static void setup4Events. Diese parst die JComponent nach addABCListener(JComponent setupMe) methoden. Und fügt dann alle möglichen Listener hinzu. Der Clou: die Listener durchsuchen dein Object nach Annotierten Methoden und führen sie aus, sobald ein event eingetreten ist. Den Ansatz müsste man noch zuende denken, aber er würde dir auf jeden Fall das Erweitern aller JComponent erweiternder Klassen ersparen und würde auch mit JComponents, die andere implementiert haben funktionieren...

Ich brauche bei meinem Ansatz nicht alle JComponents zu erweitern. Ich kann für die Top-Level-Klassen (JFrame, JDialog, JInternalFrame...) Bequemlichkeitsversionen machen, aber selbst die braucht man nur, wenn man zu faul ist, in jedem Fenster einmal eine statische Methode auszuführen.

Der Entwurf sieht bisher so aus:
Für jede Listener-Methode (actionPerformed, mouseMoved, keyPressed...) gibt es eine Annotation (@ActionPerformed, @MouseMoved, @KeyPressed...). Meine statische Methode sucht ausgehend vom (fertig zusammengebauten) Fenster aus rekursiv alle Komponenten nach annotierten Feldern ab. Wird ein annotiertes Feld gefunden, wird in der entsprechenden Klasse und rekursiv in allen parents nach der in der Annotation spezifizierten Methode gesucht und dann ein entsprechender Listener installiert, der Methode und zugehöriges Objekte ganz normal übergeben bekommt und dann im Falle eines Events "invoked". Ich versuche, mich auf das nicht zu vermeindende Reflection zu beschränken, und soviel wie möglich konventionell zu lösen. Ist zwar etwas mehr Code als eine "komplett reflection-basierte" Variante, hat aber den Vorteil, das Fehler schon beim Auslesen und nicht erst beim Aufruf bemerkt werden.

Falls die Telekom es jemals hinbekommt, endlich mein DSL zu reparieren, gibt es das Ganze demnächst als Google Code Projekt. Ich bin zwar noch immer nicht ganz davon überzeugt, dass das eine gute Idee ist, aber es ist halt so coooool

 

[Noctarius]

Alternativ kannst du beim Instanzieren (z.B. durch einen extra Classloader) eine Subclass erzeugen und die Methoden mit den Annotations aus den üblichen Listenern (die du in der Subclass erzeugst) aufrufen. Da diese dann kompiliert und geladen (und vor allem zurückgegeben wird) sparst du das Reflection (außer zum Erzeugen der Subclass und dem Finden der Annotations an Methoden) und nach dem Kompilieren läuft alles in native Speed.

Und ja ich weiß, Bytecode Enhancement, Teufel, Pfui und so ;-)

 

[Landei]

Hört sich interessant an, vielleicht wäre es sinnvoll, beide Varianten anzubieten.

Allerdings sehe ich nicht ganz, wie bei deiner Lösung Methoden, die in den Parents definiert sind, gefunden werden sollen (aber ich bin nun wirklich nicht der ClassLoader-Hacker).

Bei mir würde folgendes funktionieren:

//SwFrame ist die "Bequemlichkeitsimplementierung", die automatisch nach Annotations sucht
new SwFrame() { 
   {
       getContentPane().add(new MyPanel())
       ...
       setVisible(true);
   }
   private void callMe() {  System.out.println("He called me!"); }
}
new SwFrame() { 
   {
       getContentPane().add(new MyPanel())
       ...
       setVisible(true);
   }
   private void callMe() {  System.out.println("No, he called me!"); }
}

public class MyPanel extends JPanel {
   @ActionPerformed("callMe")
   private JButton button = new JButton("press me");
   public MyPanel() {
       add(button);
   }
}

 

[Noctarius]

Annotations haben grundsätzlich einen Nachteil. Sie sind nur vererbbar, wenn sie sich in einer Superclass befinden. Annotations in Interfaces werden normalerweise vernachlässigt.

Ich habe einen AnnotationHelper gebaut, der neben den Superclasses auch Interfaces absucht.

 

[Landei]

Aber hier will ich doch gar keine Annotations vererben, wozu auch?

 

[Noctarius]

Allerdings sehe ich nicht ganz, wie bei deiner Lösung Methoden, die in den Parents definiert sind, gefunden werden sollen (aber ich bin nun wirklich nicht der ClassLoader-Hacker).

Was meintest du dann?

 

[Landei]

Hmmm, ich glaube wir reden aneinander vorbei. Aber da eine Zeile Code mehr sagt als tausend Kommentare...

swirrel - Project Hosting on Google Code

 

[DamienX]

Jo, aber der JSR war lange eingefroren und niemand wusste so genau, wie es damit weiter geht. Keine Ahnung, wie der aktuelle Stand ist, zumindest ist der Status ja wieder In Progress.

Schon n paar Tage her aber dennoch...

Unter SAF and JDK7 | Java.net ist von Alexander Potochkin nun zu lesen:

After much discussion it's become clear that the Swing Application Framework API as it is today hasn't reached consensus and we feel still needs further design work done.

Since the SAF API was committed to milestone 5 of JDK7 and that time is already here, this date is now impossible, and we need to decommit SAF from any specific JDK 7 milestone

Link: Java Blog: Swing Application Framework fliegt aus Java 7 raus | Javainsel-Blog

Schade drum... aber ich geb die Hoffnung nicht auf.

Mfg Alex

 

[Landei]

Swirrel 0.2: Downloads - swirrel - Project Hosting on Google Code

Sind ein paar Listener und ein besseres Beispielprogramm dazugekommen. Ich würde mich natürlich über Feedback freuen.

 

[Noctarius]

Sieht weiterhin ganz nett aus

Da du das Thema aber grad wieder aufwärmst, noch mal auf die late Frage zurück: "Wieso sollte man Annotations vererben wollen?"

...eine Zeile Code mehr sagt als tausend Kommentare...

public class Base extends SwFrame {
	@ActionPerformed("buttonPressed")
	private JButton button = new JButton("Press me!");
	
	protected void buttonPressed(ActionEvent ae) {
		System.out.println("Press harder, I can take it! " + ae.toString());
	}
}

public class Extended extends Base {
	@Override
	protected void buttonPressed(ActionEvent ae) {
		System.out.println("Don't press THAT hard, §$(§($%§(/$! " + ae.toString());
	}
}

public interface ClassWithButtonPressed {
	// In this case you could automatically bind all 
	// JButtons to that handler method
	@ActionPerformed("buttonPressed")
	void buttonPressed(ActionEvent ae);
}

public class Impl implements ClassWithButtonPressed {
	private JButton button = new JButton("Press me!");

	protected void buttonPressed(ActionEvent ae) {
		System.out.println("Press harder, I can take it! " + ae.toString());
	}
}

Die Frage besteht halt, ob das Annotation dann auch noch gefunden wird.

 

[Landei]

Ich durchsuche die Klasse und alle ihre Superklassen nach Annotations, deshalb braucht nichts vererbt zu werden.

    public static void process(final Container comp) {
          ...
            //Für diese Klasse und alle Unterklassen: Suche nach annotierten Feldern
            for (Class clazz = comp.getClass(); !clazz.equals(Component.class); clazz = clazz.getSuperclass()) {
                for (Field field : clazz.getDeclaredFields()) {
                    checkListeners(comp, field);
                }
            }
            //Für alle Container: Tue in den Unterkomponenten das gleiche
            for (Component subComp : comp.getComponents()) {
                if (subComp instanceof Container) {
                    process((Container) subComp);
                }
            }
          ...
    }

Fall 1 wird demnach gefunden (hab's zur Sicherheit getestet) und auch die richtige Funktion (nämlich die von Extended) aufgerufen.

Fall 2 ist "falschrum", das Feld wird annotiert (das wäre hier button) und nicht die aufzurufende Methode. Da es in Interfaces keine Felder gibt, wird dort auch nicht nach Annotations gesucht. So eine "generelle" Funktionalität wie du dort willst würde sowieso besser mit einer eigenen JButton-Unterklasse implementiert.

 

[Noctarius]

Naja mit dem Interface als "Marker" könnte ich es aber auch markieren Käme dann der eigenen JButton-Subclass nahe, wäre aber globaler ^^

 

[Landei]

Ich will alles so einfach wie möglich halten. Die einzige Regel, die man lernen muss ist: "Statt Listener dranzuhängen Feld annotieren". Dabei möchte ich es (erst mal?) belassen. Swirrel ist bereits "mächtiger" als normale Listener, aber das ergibt sich automatisch aus der Arbeitsweise. Die beiden (mir bekannten) Effekte sind:

1) Man kann mit einer Methode verschiedene Listenertypen bedienen. Z.B. gibt diese Methode alle Events (egal ob vom ActionListener, MouseListener u.s.w.) in meinem TestFenster aus:

    public void call(Object obj) {
        //area ist ein JTextArea 
        area.append(obj.toString() + "\n");
    }

2) Eine Unterkomponente kann verschiedene Methoden aufrufen, je nachdem wo sie eingesetzt wird:

public class ModifyPanel extends JPanel {
   @ActionPerformed("add"); 
   JButton addButton = new JButton("Add");
   @ActionPerformed("edit"); 
   JButton editButton = new JButton("Edit");
   @ActionPerformed("delete"); 
   JButton deleteButton = new JButton("Delete");
   ...
}

Egal wo ich den ModifyPanel hinpacke, ich brauche nur die drei Methoden add(), edit() und delete() zu implementieren - keine zusätzliche "Verkabelung" nötig. Natürlich muss man mit dieser Technik vorsichtig sein, für meinen Geschmack ist das schon wieder zuviel "Magie".

 

[byte]

Grundsätzlich eine gute Sache. Leider ergibt sich durch die Strings ein Refactoring Problem. Benennt nämlich jemand später die Methoden um, muss auch der String manuell angepasst werden, sonst läuft der Code nicht mehr.

Das ist leider ein Problem, dass viele Frameworks haben. Bei Hibernate ist das ganz übel imo.

 

[Noctarius]

Daher hab ich es bei meinem Framework anders gemacht. Ich hab die methode annotiert und dem Event Annotation einen Klassentyp mitgegeben, damit kann man allerdings dann nicht mehrere Buttons auf verschiedene Methoden aufteilen. Man kann eben nicht alles haben

 

[Landei]

Grundsätzlich eine gute Sache. Leider ergibt sich durch die Strings ein Refactoring Problem. Benennt nämlich jemand später die Methoden um, muss auch der String manuell angepasst werden, sonst läuft der Code nicht mehr.

Das ist leider ein Problem, dass viele Frameworks haben. Bei Hibernate ist das ganz übel imo.

Das gefällt mir auch nicht, aber da fällt mir auch keine einfache Lösung für ein. Auf der GoogleCode-Seite empfehle ich, die Methode mit einem Kommentar zu versehen, dass sie "Ziel" eines Listeners ist.

Man könnte natürlich Feld und Methode annotieren, und dabei ein gemeinsames Tag vereinbaren, aber bei einer größeren Applikation sind dann Namens-Clashs sehr wahrscheinlich. Im Prinzip sind alles Notlösungen, solange Java keine Closures hat.

 

[byte]

Du könntest es z.B. so lösen, dass Du der @ActionListener nicht direkt den Methodennamen als String übergibst, sondern die Zielmethode auch annotierst. Du könntest z.B. eine @Action Annotation definieren, die als Property einen Identifier hat. In @ActionListener gibt man dann den Identifier an und nicht den Methodennamen. Auf diese Weise könnte man den Methodennamen ändern, ohne die Strings anzufassen.

Evtl. könnte man dann noch mehr Funktionalität an eine mit @Action annotierte Methode verknüpfen. Spontan fällt mir da folgendes ein: Nebenläufigkeit (falls Action lange Operation ist) und Security (Aufruf nur mit erlaubten Rollen).


Du kannst Dir auch mal die EventBus-Library angucken. Dort ist ähnliches imo recht gut gelöst.

 

[Noctarius]

public class MyActionPerformedEvent extends Event {
    // Event.class could be some simple marker
}

public class Foo {
    @ ActionPerformed(MyActionPerformedEvent.class)
    private JButton button = new JButton("Click Me!");

    @Action(MyActionPerformedEvent.class)
    public void actionPerformed(ActionEvent ae) {
        // ...
    }
}

 

[byte]

Das wäre imo mehr Aufwand als einfach zu schreiben:

JButton addButton = new JButton("Add");
addButton.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent ae) {
        add();
    }
});

public void add() {
  // do some adding
}

 

[Noctarius]

Hab ja auch nicht behauptet, dass es weniger ist. Sieht aber immer noch sauberer aus

 

[byte]

Hab ja auch nicht behauptet, dass es weniger ist. Sieht aber immer noch sauberer aus

Bei 100 Buttons hast Du dann 100 Event-Klassen!? Find ich nich so sauber.


Dann schon eher so:

public class Foo {
    @ActionPerformed(ref="add")
    private JButton button = new JButton("Click Me!");
 
    @Action(id="add")
    public void add() {
        // ...
    }
}

 

[Noctarius]

Joar so geht es auch

 

[Landei]

Genau das hatte ich ja mit

Man könnte natürlich Feld und Methode annotieren, und dabei ein gemeinsames Tag vereinbaren,

gemeint, aber meinen Bedenken gleich mit

aber bei einer größeren Applikation sind dann Namens-Clashs sehr wahrscheinlich.

Ausdruck verliehen. Mit einem String "add" wird man nicht glücklich werden, wenn man erst mal eine etwas umfangreichere GUI hat. Außerdem möchte ich insbesondere den Reflection-Code nicht ohne Not aufblähen.

 

[byte]

Namenskonflikte fallen doch direkt bei Programmstart, also beim Annotation Processing auf. Finde ich jetzt weniger tragisch. Man wirft ne entsprechende RuntimeException und der Entwickler weiss direkt, was schief gelaufen ist.

Aber perfekt ist es nicht, da hast Du schon recht. Die Lösung mit den Events ist da natürlich sicherer, allerdings auch mehr Aufwand für den Entwickler, zumal bei einem einfachen ActionEvent ja keinerlei weitere Informationen am Event Objekt hängen.

EventBus hat übrigens beide Möglichkeiten: Event Subscriber und Topic Subscriber (Strings).

 

[Landei]

Als Erweiterung experimentiere ich gerade mit dem Erzeugen von Actions:

public class ActionWrapperExampleSwFrame extends SwFrame {
  
  @ActionPerformed("call")
  private final JButton button = new JButton();
  
  public ActionWrapperExampleSwFrame() {
    super("Swirrel ActionWrapper example");
    setSize(500,500);
    JPanel panel = new JPanel(new FlowLayout(FlowLayout.CENTER));
    panel.add(button);
    getContentPane().add(panel);
    setDefaultCloseOperation(EXIT_ON_CLOSE);
    setVisible(true);
  }
  
  @ActionWrapper(name="An interesting name", 
                 shortDescription="short description",
                 smallIcon="calculate.png") //Icon über Class.getResource, hier also im gleichen Package
  private void call() {
    JOptionPane.showMessageDialog(this, "I react!");
  }
  
  public static void main(String[] args) {
    new ActionWrapperExampleSwFrame();
  }
}

Mit der @ActionPerformed-Annotation allein würde einfach wie gehabt ein ActionListener erstellt, der call() aufruft. Mit der zusätzlichen @ActionWrapper-Annotation wird dagegen eine Action (mit den entsprechenden Attributen) registriert, die natürlich auch call() aufruft. Mehrere Komponenten, die auf call() verweisen würden, würden sich eine Action-Instanz teilen (die Actions werden in einer Map verwaltet).

Der Code ist eingecheckt, aber es gibt noch kein neues Release (wer zu faul zum Compilieren ist, muss also auf Swirrel-0.3.jar warten). Vorher teste ich lieber noch ein bisschen...

 

[Landei]

Release 0.3 mit ActionWrapper, mehr Listenern und besseren Beispielen ist da.

 

[Landei]

Swirrel 0.4 ist da. Wichtigste Neuerung ist, dass man die Zielmethode auch in einem neuen Thread ausführen lassen kann. Dazu muss man nur statt...

@ActionPerformed("slowFileOperation")
JButton button = new Button("I'm blocking");

private void slowFileOperation() {
  //sloooooow
}

...schreiben...

@ActionPerformed(value = "slowFileOperation", threaded = true)
JButton button = new Button("I'm not blocking");

private void slowFileOperation() {
  //sloooooow
}

Das funktionert für beliebige Listener. Natürlich müssen dann GUI-Manipulationen dann wie gewohnt mit SwingWorker oder so im EDT ausgeführt werden.

Dann sind noch die Beispiele erweitert und zusätzliche Listener implementiert worden (als wichtigste hatten noch Component- und ContainerListener gefehlt).