Synchronized modifier not allowed in interface

Question

My understanding of an interface is that it defines a contract. The synchronized modifier can be an important part of the contract. So why doesn't Java allow for declaring some methods of an interface to be synchronized?
I just came across this again, let me try to illustrate:
public
interface IfcX
   void updateConsistently( double a, double b );
}As Java doesn't let me specify synchronized in the interface, I introduce an abstract class where I can make the method synchronized:
public
abstract
class someXBase
   public
   synchronized
   // Java does not let me make this an abstract method!
   void updateConsistently( double a, double b )
   { /* Java does not let me provide no body! */ }
}This class still has a problem: I provided an empty body, while actually I did want to keep that method abstract. The empty body produces a potential for bad surprises for naive extenders of someXBase. The empty body violates the principle of "minimum surprise". If I forget to redefine the method in an extension of someXBase, then I'm in trouble. And it will be easy to forget when there are many methods like this.
public
class someX
extends
   someXBase
   /* These attributes must not go into someXBase,
      as they belong to the concrete implementation only,
      not to the contract: */
   protected double _a ;
   protected double _b ;
   public
   synchronized
   void updateConsistently( double a, double b )
      synchronized (this)
         _a = a ;
         _b = b ;
}someX is how it should be. Only one client can be inside updateConsistently at any time, and the implementation of updateConsistently makes sure that method only updates a and b when nobody else is reading or writing any of them.

Answer 1

My understanding of an interface is that it defines a
contract. The synchronized modifier can be an
important part of the contract.
So why doesn't Java
allow for declaring some methods of an interface to be
synchronized?I disagree. Synchronization is an implementation detail only.
Thread safety however can be an important part of the contract, but the relevant part of the contract to specify that is in public documentation.
This class still has a problem: I provided an empty
body, while actually I did want to keep that method
abstract. I fail to see why you have done this - anybody can override the method anyway and not declare it synchronized. If you want to make sure somebody overrides the method, then it can help to throw an exception by default (the most appropriate in such a case would be an UnsupportedOperationException),
If you want client code to ensure thread safety, then document your code properly - If you provide an interface whose JavaDoc says "All methods are thread safe" or something similar, then anybody implementing the interface so that it is not thread safe has violated that contract. This is similar to providing documentation that says the draw method for a Shape, that takes a Canvas as a parameter, should draw the Shape on the Canvas - you have no way of forcing somebody to do that, so you rely on them conforming to the interface's contract (usually just its JavaDoc is enough).
If you were to force client code to synchronize a particular method, then you would be dictating the implementation. You need to bear in mind somebody may be able to write the code so that it is thread safe without declaring a particular method synchronized (in fact, this will always be the case), and in that situation you may be causing undue contention (and thus slowing down execution) by forcing the method to be synchronized; You might also make it difficult to avoid deadlock if the implementor wants to synchronize on different objects.