Swing Application Framework @Action annotation ? what for ?

Question

I'm actually using the Swing Application Framework on a desktop application and make good use of the session state persistence and resource manager (great for globalization)

Now I have been testing the @Action annotation feature, and really I don't see any advantage over NOT using it. The official doc lists mainly these advantages:

you can conveniently put all the relevant visual cues and the event-processing logic for a component in one place.

Yes this place storing the visual cues is the resource bundle. (can be used with Resource Manager) Yes the event-processing logic in one place is within a common method. but no need to annotate a method in order to make it common to several events.

Another convenient benefit of using Action interfaces is that you can reuse the same action across multiple UI components. GUIs often provide multiple ways to accomplish a task

Yes, obviously event-processing can be common to different events, but again using the @Action annotation isn't required to call a common method from different action listeners methods.

I don't see much of an advantage writing this :

 openButton.setAction(actionMap.get("open"));
 // NOI18N

 @Action public void open() {
     // processing logic 
 }

instead of:

 openButton.addActionListener(new
 java.awt.event.ActionListener() {
             public void actionPerformed(java.awt.event.ActionEvent evt) {
                 openButtonActionPerformed(evt);
             } });

 private void openButtonActionPerformed(java.awt.event.ActionEvent evt) {
     // processing logic 
 }

To mention that using the latter, I keep my method private, which is neater, and I also keep control over specific components getting added the listener (as each of them will have their own resources, instead of sharing the same visual cue!)

Anyone found an real interest in using @Action annotations ?

Answer 1

Just to discuss your last two code snips.

You should never actually type either of those lines of code. This kind of code tends to be very redundant if you don't figure out how to make it data driven.

In order to make it data driven, you extract the changeable pieces. For your first example:

openButton.setAction(actionMap.get("open")); // NOI18N

@Action public void open() { // processing logic }

The changable pieces are openButton and the string "open". The code to write this generically is pretty easy to see--the data could simply be whatever data is required to create a button. Binding the action to the button is done through a string which is easily stored in your data along with the data required to create the button itself.

In the second, in order to bind the button to a particular event with data, you are required to use reflection in your binding code.

they just abstracted out the reflection piece (which is extremely helpful--reflection is always a giant gaping hole in your compile-time type safety).

Answer 2

When I use NetBeans every method marked with @Action will be automatically available in the NetBeans GUI for setting actions on components.