Is there any algorithm that must use one of them in its implementation?
Almost certainly not. (Indeed, from the theoretical perspective, you should be able to simulate wait / notify using other java.util.concurrent.. classes. And synchronized could be replaced with explicit Lock operations ... though you would need to be careful to unlock in finally
clauses.)
However, there are probably algorithms where the best performing implementation in Java involves direct use of synchronized, with or without wait and notify.
Is it time to deprecate synchronized, wait and notify?
Irrespective of the answer to the previous question, the answer is definitely no.
The wait / notify can be (and often are) used correctly. In Java, deprecation is reserved for classes and methods that are broken; i.e. where continued use should be corrected as a matter of urgency. If Sun (and now Oracle) deprecated something as fundamental and as widely used as wait/notify, they would be creating a serious compatibility problem for huge amounts of legacy code. That is NOT in anyone's interest.
If you want to get rid of synchronized / wait / notify in your code, that is fine. But deprecation calls for the rewriting of large amounts of essentially correct multi-threaded code, and that would be a BAD IDEA. Corporate IT managers and software product managers would hate you for suggesting it ...
It is worth reading what "deprecated" means according to the Java documentation: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html
And also note that we are talking about deprecating stuff that is core to the Java language. Deprecating synchronized
has huge consequences.
The linked list isn't really helping you here. Replace it with a CueManager that
- Contains the list of Cues
- Maps the Cues to their respective Triggers
The CueManager should then control the life-cycle of the Cues--adding them and removing them from their respective triggers.
interface CueManager {
public addCueToTrigger(Cue, Trigger);
public removeCueFromTrigger(Cue, Trigger);
public deleteCue(Cue);
}
Best Answer
Is your API a public facing API? That dictates whether or not you should deprecate or remove. If the API is strictly for your benefit (i.e. only used within your company), then it is best to simply remove the offending code. It's much cleaner and will cause fewer maintenance headaches in the long run.
However, if the API is public facing simply removing a method can cause code that used to work with older versions of your library to stop working. That's where things get messy. The following are some guidelines: