Is there a single scenario (other than compatibility with ancient JVMs) where using synchronized is preferable to using a Lock? Can anyone justify using wait or notify over the newer systems?

Is there any algorithm that must use one of them in its implementation?

I see a previous questions that touched on this matter but I would like to take this a little further and actually deprecate them. There are far too many traps and pitfalls and caveats with them that have been ironed out with the new facilities. I just feel it may soon be time to mark them obsolete.

  • 4
    Have you read Brian Goetz's Java Concurrency in Practice? He covers the implicit vs explicit lock debate nicely there. – Martijn Verburg Nov 21 '12 at 23:49
  • @MartijnVerburg - Sadly no but I have huge respect for his work. – OldCurmudgeon Nov 22 '12 at 0:29
  • 1
    synchronized keyword may be usefull with simple static methods that should be thread safe, for anything else i would use concurrent. But this is my opinion – Kemoda Nov 22 '12 at 10:21

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.

  • Actually, as far I recall, according to the excellent “Java concurrency in practice” book, the java.util.concurrent util classes are actually faster. Behind the scenes these classes directly talk to the VM, where as synchronized installs a blunt lock on object in the object graph and thus impacts global performance. – akuhn Nov 24 '12 at 4:37
  • Forgive me @Stephen if I came across as suggesting that we actually remove synchronized et. al. I am merely suggesting deprecation, which really only says don't use this for new code. I wouldn't dream of suggesting damaging tried and tested legacy code my demanding their removal. – OldCurmudgeon Nov 24 '12 at 20:09
  • @OldCurmudgeon - rather a late response, but I think deprecation is too extreme. 1) It means that the feature could be removed. 2) It implies that the feature is broken, as distinct from merely being old-fashioned. 3) A lot of people are still happy to write new code that way ... and there's no strong reason that they shouldn't. 4) There are other, less "in your face" ways to discourage it; e.g. writing PMD rules ... – Stephen C Feb 1 '13 at 12:28
  • @StephenC - Is there then a slightly less dramatic action we can take that will eventually result in them not being used or taught in college. They clearly should be avoided. I suspect PMD rules - although a good idea - would not reach the teachers very quickly. – OldCurmudgeon Feb 1 '13 at 13:19
  • 1
    @StephenC A nitpick: going by the Java docs you linked to, I don't think deprecation means the deprecated code is broken. That's one reason, but as the docs says, an API can be deprecated when it's superseded by a newer, better API (as, the OP argues, is the case with concurrency). And low-level concurrency, if not actually encouraging bad practices, is certainly very error prone. – Andres F. Feb 1 '13 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.