'synchronized' interface methods

[Remi Forax]

On 01/08/2013 09:47 PM, Dan Smith wrote:
> One of the changes in the 0.6.1 draft was to make 'synchronized' interface methods illegal.  (This applies to default methods and static/private methods in interfaces.)  Here are the main motivations for the restriction:
>
> 1) 'synchronized' is primarily for controlling access to fields.  Interfaces have no (instance) fields.
>
> 2) There's some risk that VMs won't be naturally equipped to handle these methods, and some extra work will be necessary.  Since we're not actively intending to support this combination of features, we'd really prefer that it not add to the VM implementation burden.
>
> 3) Interfaces allow multiple inheritance -- mixing behavior from different sources.  Since different code may use locking for different purposes, it's dangerous to allow two separate code bodies to be merged via inheritance and end up sharing a single lock object.
>
> 3) is the most compelling to me.  It makes sense to say that classes, among the many special privileges and responsibilities they have due to single inheritance, are tasked with managing locking on 'this'.  (Of course, this is only a soft guarantee, since the locking methods of all objects are public.)
>
> —Dan

0) 'synchronized' as a keyword is stupid because it's an implementation 
detail that leak outside, synchronizing on 'this' is stupid because 
'this' is too public, synchronizing on a Class (for static method) is worst.

Rémi