First of all, this is a very theoretic question, there is a little wall of text ahead, I am sorry to take away so much of your precious time with this, but I would very much appreciate some opinions of more experienced programmers on this topic.

I know that the majority of standard java classes uses listeners when they are supposed to interact with application logic; for example AWT and Swing GUI components have listeners as a way to interact with the end user.
I personally have never really liked the listener approach in java because it forces you to write huge amounts of code for simple problems. At least thats my opinion.

If I have a GUI with a button, and, for example, and I want to invoke some method when the button is pressed I would have something like this in my initialization code:

Thats five lines of code, even when trying to make it somewhat small. I mean, I could always sprinkle in some white-lines to make it more friendly to the eyes, but I would not like to make it any smaller then this to keep it easily readable.

When the button is pressed the internal logic would do something like this:

Code :

public void onPress() {
this.method.invoke(source, null);
}

Now both alternatives would obviously work. But I would like to know what the pros and cons would be, or what you would think they would be.
For example, would there be any major performance difference between both methods? Does one need significantly more ram? Might there be any compatibility issues that could come up in the future?
Just tell me anything you could think about.

Thank you all very much, I really appreciate any kind of input on this topic.

The Listener approach is a standard design pattern called the Observer pattern (google it). The idea is that it creates a one-to-many relationship between an object and those that are supposed to be notified upon changes (or actions) of said object. This allows a programmer to write code such that it can respond in more ways than one to an action (or change), the responses can be reused in other contexts, and these responses can be added or removed at any time. The reflection approach you outlined suggests a one-to-one relationship, and if one wants a program to respond in multiple ways to a button action, one must jump through hoops (or write their own library) to do so. Another con of the reflection approach is that it can result in runtime errors (rather than compile time errors) that can deleteriously affect functionality.

Copeg is spot on. Only use Reflection when absolutely necessary (there are cases, but they are rare). Reflection can lead to seemingly random and inconsistent runtime errors, which we all know is the most annoying things ever to debug. Notice the word "seemingly", because the exceptions thrown by Reflection are usually not immediately obvious that they are caused by code which uses Reflection.
A general rule of thumb for programming: if you are going to use something that causes an error, make sure it consistently causes an error. An inconsistently thrown error can be extremely difficult to resolve because the first thing you should do when you get an error is find reliable reproduction steps. If you can't find steps which cause the problem 100% of the time, you often cannot resolve the issue, or you can never be sure that your solution truly worked.

[...] This allows a programmer to write code such that it can respond in more ways than one to an action (or change), the responses can be reused in other contexts, and these responses can be added or removed at any time. The reflection approach you outlined suggests a one-to-one relationship, and if one wants a program to respond in multiple ways to a button action, one must jump through hoops (or write their own library) to do so.

I dont see why this should be impossible with the Reflection approach. Sure, the example Code that I have shown is not the most fitting, but when designing an API you could easily work around that.
One could create a little Wrapper class which remembers the source and the method to be invoked and have them in a list.

Quote:

Originally Posted by copeg

Another con of the reflection approach is that it can result in runtime errors (rather than compile time errors) that can deleteriously affect functionality.

Quote:

Originally Posted by aussiemcgr

[...] Reflection can lead to seemingly random and inconsistent runtime errors, which we all know is the most annoying things ever to debug. Notice the word "seemingly", because the exceptions thrown by Reflection are usually not immediately obvious that they are caused by code which uses Reflection.

There is only 2 Exceptions which can be thrown by the Reflection methods used in this code; the NoSuchMethodException which is a fairly obvious one, and the SecurityException which is unlikely to happen unless the method is not public.
The API says:

Quote:

SecurityException - If a security manager, s, is present and any of the following conditions is met:

invocation of s.checkMemberAccess(this, Member.PUBLIC) denies access to the method

the caller's class loader is not the same as or an ancestor of the class loader for the current class and invocation of s.checkPackageAccess() denies access to the package of this class

Furthermore these are checked exceptions and their appearance is not at all random; if they will be thrown at all they will be thrown right at the initialization of the GUI.
Maybe I am overlooking something, but from what I see I can not immediately agree with you there.

Maybe I am overlooking something, but from what I see I can not immediately agree with you there.

As Greg said - you asked for opinions and you got some. He's also correct in that I'm not going to argue the point - if you feel doing things through reflection is better then have at it - why not implement it by writing your own library doing so.

I dont see why this should be impossible with the Reflection approach.

It's not impossible, just a very bad idea. The most glaring problem is that you are substituting a trivial syntax error for run time exceptions. You are deliberately circumventing the compile time checks to save a few lines of code (which my IDE auto-generates anyway).

The more subtle issue is the nature of reflection. It's a very powerful tool but also a very specific one. It's slow, unpredictable and difficult to test. It breaks encapsulation and doesn't fit in well with the OO paradigm.

Don't get me wrong, Reflection can be awesome in the right places; error logging, serialization, plugins. It's just that I have attempted (and failed) to use it too many times to agree with you on any level. Learn to love Listeners.

There is only 2 Exceptions which can be thrown by the Reflection methods used in this code; the NoSuchMethodException which is a fairly obvious one, and the SecurityException which is unlikely to happen unless the method is not public.

Furthermore these are checked exceptions and their appearance is not at all random; if they will be thrown at all they will be thrown right at the initialization of the GUI.

Um, no, no, and no.
First, Class.getMethod() throws NoSuchMethodException, SecurityException, AND NullPointerException. And Method.invoke() throws IllegalAccessException, IllegalArgumentException, InvocationTargetException, NullPointerException, and ExceptionInInitializerError.
Second, what your quote of the SecurityExceptions did not mention explicitly is that there is no guarantee the level of security required by the SecurityManager will be available on all environments (meaning, it might work for some, but might not work for others. Have fun debugging that).
Third, the exceptions thrown by the invoke() method would happen when you call them which, according to your code, is when the user presses a button, not when the GUI starts up.