If we didn't have to worry about being backwards compatible, I'd definitely argue for the second solution. Java compatibility is not a very strong argument in my opinion. First, porting a Java application 1:1 is asking for performance hazards (w.r.t. GC, ...) anyway. Second, the no-synchronized-by-default design allows for clear error messages that immediately suggest the correct fix (add an attribute to the class declaration), and for mechanical porting, Java classes could just be translated to "@synchronizable class" or whatever.

I think deprecating the old behavior is the right choice here.

Reply via email to