Java Signals

Question

I'm posting this here because I do not know of a better way to address the Java development team directly.
Requests for a signal handling facility have been made since the earliest releases of Java. The response from the Java development team seems to be that signals are platform dependent and therefore does not meet the demands of WORA. However, what about adding Java's own signal handling facility instead of trying to interface with the platform's?
I was recently working on a project where I needed two threads to be able to notify each. Instead of using signals, I had them routinely stop and check some shared variable. However, that is more expensive than necessary and it would have been preferred if thread 1 could have thrown a singal to thread 2.
Note that what I needed was not a way for the operating system to signal Java, but instead a way for Java to signal Java.
I would propose some Signal object, much like the Exception object. Signals in Java would, of course, be implemented as objects and be capable of carrying more information than their C-like counterparts. It would also be subclassable so that even more information could potentially be passed between threads. A thread would then register some method as signal handler for a particular kind of Signal object (similar to the way that current Java code catches different kinds of Exception objects). If the signal is thrown, execution of the catching thread halts, jumps to the signal handler method, clears the handler registration, and returns to the point of discontinuation. This can be done without need for implementing platform-specific signal handling.
Even though the above description does not include platform specific signals. It would also be possible to subclass Signal and create a generic SystemSignal object. This SystemSignal object would incur the signal handler for any thread that is listening for a SystemSignal object. The object would contain some getName() method to fetch the platform name of the object (i.e. SIGTERM). If a SystemSignal handler had been registered, the JVM would construct a SystemSignal object and set the name. It would then invoke the signal handler and it would be up to the handler to analyze the signal with getName() and determine if it wants to perform an action for this signal. This would encourage more developers to use platform specific signals in their Java code. However, those developers that needs this functionality are not working around it in Java, they are instead turning to C or C++ for the functionality they require for the entire project or for JNI calls. I don't believe it would be in the best interest of the language to try to discourage the practice of using platform specific signals.
Thanks,
Jonathan A. Kennedy
Programmer/Analyst

Answer 1

Seems to me there are plenty of ways in Java to handle this issue without trying to get the language changed. Here's a simple one to get you started; I don't know if this is exactly what you meant but it sounds like it.
You need a way for a Thread to be "notified" of some event by another thread. So, write a subclass of Thread (call it NotifiableThread) that has a notify() method. Then NotifiableThread A, or any code for that matter, can call NotifiableThread B's notify() method at any time. NotifiableThread B's notify() method would be coded to do whatever is supposed to happen when the event is signalled. This is just a rough outline, you would have to deal with synchronization issues and so on.
Another common Java design pattern you could use is the Listener pattern, where one object registers itself as a Listener with another object that is generating events.