Am seeing that a typical addXXXListener() returns void !
I have seen this as a practice across the board whether it is UI frameworks (like Swing) or server-side frameworks.
For ex:
Class: AsyncContext
public void addAsyncListener(AsyncListener listener);
Class: AbstractButton
public void addActionListener(ActionListener l)
And numerous other examples...
Shouldnt we be interested to know if the add listener call completed successfully ?
What if the component was in a state where the listener could not be added ?
For ex: Consider the Guava library [ListenableFuture](http://guava-libraries.googlecode.com/svn/tags/release08/javadoc/com/google/common/util/concurrent/ListenableFuture.html#addListener(java.lang.Runnable, java.util.concurrent.Executor))
It has a
void addListener(Runnable listener, Executor exec);
Its behavior is that the listener is executed when the Future's computation is complete.
They took the approach that, if the Future is already complete then the listener would be called immediately. Even if the future was completed ages back.
There is no indication to the user that they are calling addListener() unnecessarily on an already completed future !
I would think the addListener() should be capable of returning a value(boolean?) that says if the listener could be successfully added and let the caller do the handling if the listener could not be added !
I know there must be some reason why all addListeners are written this way.
I just dont know why ?
These methods generally simply add your listener to a list. The circumstances in which it would not work are generally outside your control (think out of memory error for example) and would trigger an exception anyway.
The reason why Collection#add, for example, returns a boolean is that some implementations will only add the item if some conditions are met (e.g. Sets won't add an item if it is a duplicate). Note that this is the only situation when Collection#add will return false (other reasons will trigger an exception):
If a collection refuses to add a particular element for any reason other than that it already contains the element, it must throw an exception (rather than returning false). This preserves the invariant that a collection always contains the specified element after this call returns.
This was probably deemed not very useful for addListener.
The convention is to return information to the caller if the caller can be expected to act on the information.
The ListenableFuture is a very different use case to most addXXXListener() calls. These are expected to return immediately and be 100% successful in normal operation (e.g. just adding a listener to some internal list structure) and there is no actionable information to return to the caller. (However, in non-normal operation you would probably expect it to throw an unchecked Exception).
One possible variation is to treat this as a mutator operation and extend the usual Collection pattern to return a boolean if the internal data structure has been modified by the addXXXListener() call. Although this only returns useful information if the caller is not aware whether or not it has already added itself...
In all these cases, there's no possible way the listener could fail to be added.
Even if the future was completed ages back.
So what if the future was completed ages back? If you want to add a listener to the Future, you want to do something with that result whenever it's completed, whether that was ages ago or in the future.
I have a class currently called Promise that works as follows:
It holds a future value
It can always accept a subsequent action to take that uses the future value as the parameter
When the value is completed the function queue launches
Any functions added after the future is complete happen synchronously
So this seems to be a design pattern from functional programming that we're jamming into Java. The important thing is that we can daisy-chain on delayed events, which I understand is a feature more built into C# 3.0 language but you have to hack together with Java classes. Unfortunately, one, I don't know a better name for this than "promise" or "future," which seem misleading since the focus is more on the "DelayedCallStack" then the value at hand, and two, I don't know of any way to do this beyond writing our own fairly complicated Promise class. Ideally I'd like to lift this from the functional Java library but the concept eludes me thus far.
Note Java doesn't even give language/library support for an asynchronous callback that takes a parameter, which is one reason I'm so pessimistic about being able to find this.
So, what is this pattern, can it be done in libraries?
Take a look a ListenableFuture in Guava:
http://code.google.com/p/guava-libraries/wiki/ListenableFutureExplained
ListenableFuture allows you to add callbacks to be executed when the Future computation is completed. You can control what thread pool the callbacks get executed under, so they can be executed synchronously or asynchronously.
I can only say that we implemented pretty much exactly the same thing in Flex (ActionScript) and we also called it a Promise. In Clojure a promise is something quite a bit more lightweight: the get operation on it blocks until another thread delivers the promise. It's basically a one-element queue except that it retains its value forever, so subsequent gets always succeed.
What you have is a kind of a promise coupled with observers of its value. I'm not aware of any special term covering exactly that case.
EDIT
Now I notice that your "promise/future" might own the code that produces its future value (at least it's not entirely obvious whether it does). The ActionScript implementation I mentioned didn't do that -- it behaved like Clojure's, the value being supplied from the outside. I think this is the key distinction between a future and a promise.
I have multiple client handler threads, these threads need to pass received object to a server queue and the sever queue will pass another type of object back to the sending thread. The server queue is started and keeps running when the server starts.I am not sure which thread mechanism to use for the client handler threads notified an object is sent back. I don't intend to use socket or writing to a file.
If you wanted to do actual message passing take a look at SynchronusQueue. Each thread will have reference to the queue and would wait until one thread passed the reference through the queue.
This would be thread safe and address your requirements.
Though if you are simply looking to have threads read and write a shared variable you can use normalocity's suggestion though it's thread-safety depends on how you access it (via sychronized or volatile)
As far as making objects accessible in Java, there's no difference between multi-thread and single-thread. You just follow the scope rules (public, private, protected), and that's it. Multiple threads all run within the same process, so there isn't any special thread-only scope rules to know about.
For example, define a method where you pass the object in, and make that method accessible from the other thread. The object you want to pass around simply needs to be accessible from the other thread's scope.
As far as thread-safety, you can synchronize your writes, and for the most part, that will take care of things. Thread safety can get a bit hairy the more complicated your code, but I think this will get you started.
One method for processing objects, and producing result objects is to have a shared array or LinkedList that acts as a queue of objects, containing the objects to be processed, and the resulting objects from that processing. It's hard to go into much more detail than that without more specifics on what exactly you're trying to do, but most shared access to objects between threads comes down to either inter-thread method calls, or some shared collection/queue of objects.
Unless you are absolutely certain that it will always be only a single object at a time, use some sort of Queue.
If you are certain that it will always be only a single object at a time, use some sort of Queue anyway. :-)
Use a concurrent queue from the java.util.concurrent.*.
why? Almost guaranteed to provide better general performance than any thing hand rolled.
recommendation: use a bound queue and you will get back-pressure for free.
note: the depth of queue determines your general latency characteristics: shallower queues will have lower latencies at the cost of reduced bandwidth.
Use Future semantics
why? Futures provide a proven and standard means of getting asynchronous result.
recommendation: create a simple Request class and expose a method #getFutureResponse(). The implementation of this method can use a variety of signaling strategies, such as Lock, flag (using Atomic/CAS), etc.
note: use of timeout semantics in Future will allow you to link server behavior to your server SLA e.g. #getFutureResponse(sla_timeout_ms).
A book tip for if you want to dive a bit more into communication between threads (or processes, or systems): Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
Just use simple dependency injection.
MyFirstThread extends Thread{
public void setData(Object o){...}
}
MySecondThread extends Thread{
MyFirstThread callback;
MySecondThread(MyFirstThread callback){this.callback=callback)
}
MyFirstThread t1 = new MyFirstThread();
MySecondThread t2 = new MySecondThread(t1);
t1.start();
t2.start();
You can now do callback.setData(...) in your second thread.
I find this to be the safest way. Other solutions involve using volatile or some kind of shared object which I think is an overkill.
You may also want to use BlockingQueue and pass both of those to each thread. If you plan to have more than one thread then it is probably a better solution.
What are the pros and cons of keeping listeners as WeakReferences?
The big 'Pro' of course is that:
Adding a listener as a WeakReference means the listener doesn't need to bother 'removing' itself.
For those worried about the listener having the only reference to the object, why can't there be 2 methods, addListener() and addWeakRefListener()?
Those who don't care about removal can use the latter.
First of all, using WeakReference in listeners lists will give your object different semantic, then using hard references. In hard-reference case addListener(...) means "notify supplied object about specific event(s) until I stop it explicitly with removeListener(..)", in weak-reference case it means "notify supplied object about specific event(s) until this object will not be used by anybody else (or explicitly stop with removeListener)". Notice, it is perfectly legal in many situations to have object, listening for some events, and having no other references keeping it from GC. Logger can be an example.
As you can see, using WeakReference not just solve one problem ("I should keep in mind to not forget to remove added listener somewhere"), but also rise another -- "I should keep in mind that my listener can stop listen at any moment when there is no reference to it anymore". You not solve problem, you just trade one problem for another. Look, in any way you've forced to clearly define, design and trace livespan of you listener -- one way or another.
So, personally, I agree with mention what use WeakReference in listeners lists is more like a hack than a solution. It's pattern worth to know about, sometimes it can help you -- to make legacy code work well, for example. But it is not pattern of choice :)
P.S. Also it should be noted what WeakReference introduce additional level of indirection, which, in some cases with extremely high event rates, can reduce performance.
This is not a complete answer, but the very strength you cite can also be its principal weakness. Consider what would happen if action listeners were implemented weakly:
button.addActionListener(new ActionListener() {
// blah
});
That action listener is going to get garbage collected at any moment! It's not uncommon that the only reference to an anonymous class is the event to which you are adding it.
I have seen tons of code where listeners were not unregistered properly. This means they were still called unnecessarily to perform unnecessary tasks.
If only one class is relying on a listener, then it is easy to clean, but what happens when 25 classes rely on it? It becomes much trickier to unregister them properly. The fact is, your code can start with one object referencing your listener and end up in a future version with 25 objects referencing that same listener.
Not using WeakReference is equivalent to taking a big risk of consuming unnecessary memory and CPU. It is more complicated, trickier and requires more work with hard references in the complex code.
WeakReferences are full of pros, because they are cleaned up automatically. The only con is that you must not forget to keep a hard reference elsewhere in your code. Typically, that would in objects relying on this listener.
I hate code creating anonymous class instances of listeners (as mentioned by Kirk Woll), because once registered, you can't unregister these listeners anymore. You don't have a reference to them. It is really bad coding IMHO.
You can also null a reference to a listener when you don't need it anymore. You don't need to worry about it anymore.
There are really no pros. A weakrefrence is usually used for "optional" data, such as a cache where you don't want to prevent garbage collection. You don't want your listener garbage collected, you want it to keep listening.
Update:
Ok, I think I might have figured out what you are getting at. If you are adding short-lived listeners to long-lived objects there may be benefit in using a weakReference. So for example, if you were adding PropertyChangeListeners to your domain objects to update the state of the GUI that is constantly being recreated, the domain objects are going to hold on to the GUIs, which could build up. Think of a big popup dialog that is constantly being recreated, with a listener reference back to an Employee object via a PropertyChangeListener. Correct me if I'm wrong, but I don't think the whole PropertyChangeListener pattern is very popular anymore.
On the other hand, if you are talking about listeners between GUI elements or having domain objects listening to GUI elements, you won't be buying anything, since when the GUI goes away, so will the listeners.
Here are a couple interesting reads:
http://www.javalobby.org/java/forums/t19468.html
How to resolve swing listener memory leaks?
To be honest I don't really buy that idea and exactly what you expect to do with a addWeakListener. Maybe it is just me, but it appear to be a wrong good idea. At first it is seducing but the problems it might implies are not negligible.
With weakReference you are not sure that the listener will no longer be called when the listener itself is no longer referenced. The garbage collector can free up menmory a few ms later or never. This mean that it might continue to consume CPU and make strange this like throwing exception because the listener shall not be called.
An example with swing would be to try to do things you can only do if your UI component is actually attached to an active window. This could throw an exception, and affect the notifier making it to crash and preventing valid listeners to be notofied.
Second problem as already stated is anonymous listener, they could be freed too soon never notified at all or only a few times.
What you are trying to achieve is dangerous as you cannot control anymore when you stop receiving notifications. They may last for ever or stop too soon.
Because you are adding WeakReference listener, I'm assuming, you are using a custom Observable object.
It makes perfect sense to use a WeakReference to an object in the following situation.
- There is a list of listeners in Observable object.
- You already have a hard reference to the listeners somewhere else. (you'd have to be sure of this)
- You don't want the garbage collector to stop clearing the listeners just because there is a reference to it in the Observable.
- During garbage collection the listeners will be cleared up. In the method where you notify the listeners, you clear up the WeakReference objects from the notification list.
In my opinion it's a good idea in most cases. The code that is responsible for releasing the listener is at the same place where it gets registered.
In practice i see a lot of software which is keeping listeners forever. Often programmers are not even aware that they should unregister them.
It usually is possible to return a custom object with a reference to the listener that allows manipulation of when to unregister. For example:
listeners.on("change", new Runnable() {
public void run() {
System.out.println("hello!");
}
}).keepFor(someInstance).keepFor(otherInstance);
this code would register the listener, return an object that encapsulates the listener and has a method, keepFor that adds the listener to a static weakHashMap with the instance parameter as the key. That would guarantee that the listener is registered at least as long as someInstance and otherInstance are not garbage collected.
There can be other methods like keepForever() or keepUntilCalled(5) or keepUntil(DateTime.now().plusSeconds(5)) or unregisterNow().
Default can be keep forever (until unregistered).
This could also be implemented without weak references but phantom references that trigger the removal of the listener.
edit: created a small lib which implements a basic version of this aproach https://github.com/creichlin/struwwel
I can't think of any legitimate use case for using WeakReferences for listeners, unless somehow your use case involves listeners that explicitly shouldn't exist after the next GC cycle (that use case, of course, would be VM/platform specific).
It's possible to envision a slightly more legitimate use case for SoftReferences, where the listeners are optional, but take up a lot of heap and should be the first to go when free heap size starts getting dicey. Some sort of optional caching or other type of assisting listener, I suppose, could be a candidate. Even then it seems like you'd want the internals of the listeners to utilize the SoftReferences, not the link between the listener and listenee.
Generally if you're using a persistent listener pattern, though, the listeners are non-optional, so asking this question may be a symptom that you need to reconsider your architecture.
Is this an academic question, or do you have a practical situation you're trying to address? If it's a practical situation I'd love to hear what it is -- and you could probably get more, less abstract advice on how to solve it.
I have 3 suggestions for the original poster. Sorry for resurrecting an old thread but I think my solutions were not previously discussed in this thread.
First,
Consider following the example of javafx.beans.values.WeakChangeListener in the JavaFX libraries.
Second,
I one upped the JavaFX pattern by modifying the addListener methods of my Observable. The new addListener() method now creates instances of the corresponding WeakXxxListener classes for me.
The "fire event" method was easily modified to dereference the XxxWeakListeners and to remove them when the WeakReference.get() returned null.
The remove method was now a bit nastier since I need to iterate the entire list, and that means I need to do synchronization.
Third,
Prior to implementing this strategy I employed a different method which you may find useful. The (hard reference) listeners got a new event they did a reality check of whether or not they were still being used. If not, then they unsubscribed from the observer which allowed them to be GCed. For short lived Listeners subscribed to long lived Observables, detecting obsolescence was fairly easy.
In deference to the folks who stipulated that it was "good programming practice to always unsubscribe your listeners, whenever a Listener resorted to unsubscribing itself, I made sure to create a log entry and corrected the problem in my code later.
WeakListeners are useful in situations where you specifically want GC to control the lifetime of the listener.
As stated before, this really is different semantics, compared to the usual addListener/removeListener case, but it is valid in some scenarios.
For example, consider a very large tree, which is sparse - some levels of nodes are not explicitly defined, but can be inferred from parent nodes further up the hierarchy. The implicitly defined nodes listen to those parent nodes that are defined so they keep their implied/inherited value up to date. But, the tree is huge - we don't want implied nodes to be around forever - just as long as they are used by the calling code, plus perhaps a LRU cache of a few seconds to avoid churning the same values over and over.
Here, the weak listener makes it possible for child nodes to listen to parents while also having their lifetime decided by reachability/caching so the structure doesn't maintain all the implied nodes in memory.
You may also need to implement your listener with a WeakReference if you are unregistering it somewhere that isn't guaranteed to be called every time.
I seem to recall we had some problems with one of our custom PropertyChangeSupport listeners that was used inside row Views in our ListView. We couldn't find a nice and reliable way to unregister those listeners, so using a WeakReference listener seemed the cleanest solution.
It appears from a test program that anonymous ActionListeners will not prevent an object from being garbage collected:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JButton;
public class ListenerGC {
private static ActionListener al = new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
System.err.println("blah blah");
}
};
public static void main(String[] args) throws InterruptedException {
{
NoisyButton sec = new NoisyButton("second");
sec.addActionListener(al);
new NoisyButton("first");
//sec.removeActionListener(al);
sec = null;
}
System.out.println("start collect");
System.gc( );
System.out.println("end collect");
Thread.sleep(1000);
System.out.println("end program");
}
private static class NoisyButton extends JButton {
private static final long serialVersionUID = 1L;
private final String name;
public NoisyButton(String name) {
super();
this.name = name;
}
#Override
protected void finalize() throws Throwable {
System.out.println(name + " finalized");
super.finalize();
}
}
}
produces:
start collect
end collect
first finalized
second finalized
end program
It depends on what you want to do.
If you want to create a reactive value that depends on a specific value but where the callback is not supposed to have side effects, use a weak reference.
If you want to set up a callback which is run for its side effects, use a strong reference.
Imho, this is also why I strongly feel that the observer pattern should be encapsulated into a library most times, with something like Signal/ComputedSignal/Effect and the like.
Your register methods should be named based on what you want to do. The case where you want a reactive dependent value should be something like Subject.dependent_value( (args) => value) while the case with the Effect should be Subject.register_effect((args) => dostuff...).
Effects that depend on dependent values should walk their dependency graphs and register themselves as a strong child of the root observables.
i just have two questions about two methods used in many controllers/servlets in my app:
1-what is the difference between calling a static method in a util class or a non static method (like methods dealing with dates i.e getting current time,converting between timezones), which is better ?
2-what is the difference between calling a method(contain too many logic like sending emails) in the controller directly or running this method in a different thread ?
1)
Utils classes generally don't have any state associated with them. They just have behavior. Hence there really isn't much point in creating "instances" of them.
Even though compiler won't ever complain, instantiating a Util class would be a misleading coding.
Being Stateless Utils classes are completely thread safe. Class methods, whether static or not, get copied to every threads stack frame and cause no interference to each other. Java Utils classes are excellent examples of this.
2)
If your method is time consuming one, it makes sense to make it's call asynchronous.
There are advantages and disadvantages to using static methods:
Advantages:
You don't have to instantiate an object to use them.
Static variables defined in the class stay the same between calls.
Disadvantages:
You can only access static variables and static methods without creating an instance of an object to call them on.
Not inherently thread-safe... You must synchronize either the method or a section of code if you don't want other threads changing variables on you.
In my personal experience, static methods are great for things that don't require you to maintain state between calls. Like formatting dates.
Having said that, time operations are pretty easy.
Getting the current time is as easy as:
Date currentDate = new Date();
or
Calendar currentCal = Calendar.getInstance();
Calendar can also be used to roll Calendar.HOUR_OF_DAY (and Calendar.MINUTE if necessary) if you know the difference between the time zones.
1: So the static keyword only tells you about the accessibility of the method. If the method is static it can be accessed without instantiating an object. So it doesn't make sense to ask which is better: static or non-static.
2: Calling a method that has some time-consuming logic on a separate thread allows your main thread to continue working on some other things which are important. So if you have two time-consuming tasks that you need to execute for a client, then running those two tasks on separate thread can get the job done faster.
Note that all of this is said with the assumption that the programmer knows how to do proper threading... if the threading is not done correctly, then there could be a slew of problems: deadlocks, invalid object states, decreased performance, etc.
#1 Seems to have been answered well in other responses.
#2 Depends on the circumstance. If the controller is having to wait for the other thread to finish with the sending email task before it can continue then there is no speed improvement at all -- in fact there would be speed loss due to the context switch and synchronization. If the controller can service another request or if it can do something else in parallel with the email sending thread then there would be a gain.
Typically, if a controller needs to send email, it gives the job off to a worker thread and then continues on its way in parallel and handles the next request. This is faster but it means that there is no way to report back problems to the caller if the email sending failed.