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".

Answer 1

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.

Answer 2

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.