aspose file tools
The moose likes Threads and Synchronization and the fly likes Synchronization and interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Reply Bookmark "Synchronization and interfaces" Watch "Synchronization and interfaces" New topic
Author

Synchronization and interfaces

WarnerJan Veldhuis
Greenhorn

Joined: Sep 27, 2002
Posts: 9
If my interface says:

does my class comply to the interface's method if I say:

I've tried it, and it *does* compile, but does my class really implement the right interface-method?
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
Interfaces cannot require or disallow use of the synchronized modifier in implementing methods. There are many ways to manage synchronization, and that should be (must be) an implementation detail.
The only place synchronization belongs in an interface is when your Javadocs describe the thread safety properties of a class or method, which is obviously not machine enforcable*.

* (Footnote) Not enforcable in Java and probably every other language with current technology, that is.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by David Weitzman:

The only place synchronization belongs in an interface is when your Javadocs describe the thread safety properties of a class or method, which is obviously not machine enforcable*.

* (Footnote) Not enforcable in Java and probably every other language with current technology, that is.

Java does not allow the synchronized modifier in an interface. And what do you mean not machine enforceable!? Java's behavior is defined by the JLS, not the machine it is running on.
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
And what do you mean not machine enforceable!? Java's behavior is defined by the JLS, not the machine it is running on.
I'm not appealing to the specs here, but rather common sense. The bytecode verifier machine-enforces many rules related to interfaces (ensuring that return types are correct, all methods are there, etc.). Code that doesn't meet those specs won't be loaded and run. There is no reason why a language can't also have interfaces that specify, say, "This method takes a list of integers and returns a list of those integers sorted" in bytecode such that the bytecode verifiers for those languages won't load code that doesn't properly sort and terminate (if you're interested in stuff like that, look up Proof Carrying Code). Java is not such a language and surely never will be for very practical reasons, but not necessarily because of technical reasons.
But since Java obviously lacks those capabilities, it becomes clear that nothing one puts in an interface relating to synchronization can have the same useful and enforced meaning that "returnType methodName(params)" does. It would be like having a modifier "srt" which specifies that any data returned by the function must be sorted. Putting things like that in an interface which aren't meant to be enforced and will add no new capabilities to a language while requiring the programmer to type more are simply a waste of space.
This was the more general reasoning behind my statement above. In this case it would also be sufficient to show that in particular, having a "synchronized" modifier in interfaces would impose arbitrary restrictions that interfere with implementors instead of helping. That becomes apparent when you're familiar with the different levels of synchronization used in the wild, but I don't know how well I can explain it here. I'll just point to LinkedQueue from Doug Lea as an example of a class which would be harmed by method-level synchronization and call it a day.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I agree. Don't know why I took maching to mean computer as opposed to JVM which is what you seem to have meant. Either way the neither investigates ones claims about his code.
[ March 09, 2004: Message edited by: CL Gilbert ]
Avi Abrami
Ranch Hand

Joined: Oct 11, 2000
Posts: 1112

Jan,
As far as I know, the synchronized keyword is not part of the method declaration, therefore the compiler considers the implementation method declaration (with the "synchronized" keyword) to match the interface declaration (without the "synchronized" keyword).
I understand from this, that it is not required to use "synchronized" in interface method declarations -- in fact, I would suggest that it is better not to use "synchronized" at all in any interface method declarations.
Good Luck,
Avi.
WarnerJan Veldhuis
Greenhorn

Joined: Sep 27, 2002
Posts: 9
Thanks all for your answers... Conclusion: having synchronized in the method declaration does not break the interface contract. That's what I wanted to know... Thanks
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

yes that is correct. thread safety is not part of the contract. and synchronize does not tell you much at all about a method.
Also you can throw exceptions in an interface, but the method does not have to throw the exception if it does not really throw it.
 
I agree. Here's the link: http://jrebel.com/download
 
subject: Synchronization and interfaces
 
Similar Threads
Can't declare methods to throw java.rmi.RemoteException
B&S : Couple of questions
RMI Interface
Problems for implementing readRecord & findByCriteria
NX: Is it OK to wrap readRecord in a new method?