'synchronized' interface methods

[Mike Duigou]

I completely agree that synchronized, along with strictfp and native, should be illegal for abstract methods.

For methods with a body then synchronized should still be allowed as it is a synonym for :

void foo() {
 synchronized(this() {
	...
 }
}

or

static void bar() {
 synchronized(Clazz.class) {
	...
 }
}

Since these would clearly be allowed in defaults, private and static methods then I believe they should have their normal meaning. I agree that #3 is a risk but I don't think taking away the synchronized keyword mitigates that. Not having synchronized will probably instead just lead to different errors. ie. "I can't add synchronized so I'll just write it without".

Mike

On Jan 8 2013, at 12:47 , 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