Why "synchronized" has no role in polymorphism

Question

synchronized is not part of method signature. But when we override a method, its not only the method signature which decides whether the overridden method will compile or not.

For example, we cannot add or widen a checked exception

Why does synchronized have no role in polymorphism. A synchronized method should not be overridden without putting synchronized. As the person who is using super class variable might think that all methods are thread safe.

But a non synchronized methods should be allowed to be overridden with synchronized as it is adding more functionality but on the other hand user will not face any error except time lag.

I am looking a logical explanation which can throw some light on "why is designed so".

Lifesaver

Answer 1

You can see JDK-4294756 for an explanation of it is OK for a method to override another without preserving the synchronized modifier. This bug report asked for a warning to be shown by the compiler when a method overrides a synchronized method but does not declare itself synchronized, and it was closed as "Won't Fix". The key reason is the following:

The use of the synchronized modifier, as well as other synchronization via explicit 'synchronized' statements, is a part of the implementation of an abstraction represented by a class, and an alternate implementation captured in a subclass may use a different synchronization strategy in order to implement equivalent semantics. As an example, consider the case in which a small critical section (protected by a 'synchronized' statement) within a larger unsynchronized method replaces a smaller method that was protected in its entirety by a synchronized method modifier.

So the absence of a synchronized modifier does not necessarily mean the method is not thread-safe. Thread-safety can be fine-grained inside the method.

Refractive

Answer 2

A "synchronized" method should not be overridden without putting "synchronized".

Wrong. A base class might not be thread-safe, but a subclass might have its own synchronization, such as a lock, lock-free thread-safe data structure, etc. Not all thread-safe methods are synchronized, and not all synchronized methods are thread-safe.

The same can go in the other direction (but may break other principles, depending on the case)

synchronized isn't an object-oriented thing, but rather a runtime/execution phenomenon, and an implementation detail. All it does is acquire a monitor the same way synchronized(this){ } (or synchronizing on the java.lang.Class object if static) would. As an implementation detail, it makes no sense to expose it to OOP considerations.

Note: This doesn't mean that a compile-time annotation such as @ThreadSafe doesn't make sense. It does, since it references the method's contract to be thread-safe. synchronized doesn't do this.

Indamine

A "synchronized" method should not be overridden without putting "synchronized". I am asking that why its not designed in such a way. I am not saying that it works this way. – Lifesaver

@user3610891 That's what you're saying in your original question. I'm explaining that it is not true, as that is a key part of answering your question. I – Indamine

so you are saying that a synchronized methods gets converted to synchronized block? – Lifesaver

@user3610891 Yes, a synchronized method is executed as if the body were in a synchronized block. As per JLS, " For a class (static) method, the monitor associated with the Class object for the method's class is used. For an instance method, the monitor associated with this (the object for which the method was invoked) is used. " – Indamine

Answer 3

Let me put it a different way:

Suppose we have two classes:

class Foo {
    public synchronized void doSomething(...) { ... }
}

class Bar extends Foo {
    public void doSomething(...) { ... }
}

Foo and Bar are different classes. foo.doSomething(...) and bar.doSomething(...) are different methods.

The synchronized keyword is not there for the benefit of the caller: It says nothing about what foo.doSomething(...) does. The synchronized keyword is just a detail of how that method is implemented.

The Foo class needs its doSomething(...) method to be synchronized in order to correctly fulfill its API contract in a multi-threaded environment. The bar.doSomething(...) method is implemented differently and it doesn't need synchronization.

So long as a Bar instance can be used wherever a Foo instance is wanted, everyone should be happy. There's no reason why the caller should want the method to be synchronized: The caller should just want the method to work.

Colonic