Java language proposal #2
Java forces software designers to choose between synchronized and unsynchronized access when writing a class. Often, the most general-purpose design requires synchronization, while a number of important uses of the class do not. Synchronized wrapper classes are inconvenient to write and maintain; it doubles the number of classes. The designer is in a dilemma: whether to impose the performance penalty of synchronization, to write twice as many classes by providing wrappers, or to provide a less-general solution.
Java should release programmers from this dilemma by automatically creating synchronized versions of classes. The synchronized class should be a derived class of the original, containing an override for each non-final member function; the override is synchronized and forwards the invocation to the original class. Constructors of the synchronized class would be the same in signature as that of the original class, and would forward the construction to the original class's constructors. Since the synchronized version is derived from the original class, a synchronized object would be useable wherever the unsynchronized one was.
The implicit synchronized class should also be a public static nested class of the original class, with name "synchronized". Thus, to create a synchronized instance of the class HashMap, one would use "new HashMap.synchronized()" instead of "new HashMap()".
This would not break any existing code, because "synchronized" is not (and under this proposal still would not be) allowed as a programmer-defined class name. No syntax changes would be required in the language. Bytecode size need not increase significantly, as the synchronized class definition could be created on the fly.
I do not think automatically added synchronization is favorable as it oversimplifies synchronization. It might not be correct to generally synchronize all methods of a class as this might introduce dead-lock problems not anticipated by the programmer - for example due to unforeseen orderings of monitor acquisitions. So you must at least allow a programmer to specify if a certain class is suitable for generic synchronization - say by a tagging interface Synchronizable[\i].
Nonetheless, any such mechanism would probably just create the impression to programmers that proper synchronization can be achieved by implementing this interface or by instantiating your special subclass. This would draw the attention from concurrency issues, which it should not since every concurrent application must be carefully designed for its specific requirements.
It would be quite nice to be able to specify precise synchronisation constraints (e.g. only one thread can call method a() on any particular object at a time, only one thread can call method b() on any object of class C at a time, different threads can call different methods in different objects of class D, but can call the same method in different objects or different methods in the same object.) But that becomes ridiculous.
> [... snip ...] But that
> becomes ridiculous.
Specifying synchronisation constraints like the ones you have envisioned in your posting would impose a lot of problems for eg the JRE, so it may be viewed as "ridiculous".
But can't we look at this differently: Specifying synchronization constraints is not the task of the language, but something you configure when you deploy your code into an application server that will respect such constraints. You could then develop the unsynchronized version only, and get synchronization from configuration, not from writing more code for synchronized versions, or adding automatically generated code as suggested by the original poster.
Kind regards -- Claus
