On 2015-10-16 23:54, Jonathan M Davis wrote:
Well, you probably will at some point, even if you don't know. According to TDPL, there's not supposed to be any such thing as a class with some functions which are synchronized and some not. The entire class is synchronized or none of it is, and if the class is synchronized then the member variables of the class are not accessible outside of the class. But that hasn't been implemented yet. Instead, we have synchronized functions like in Java. The PR that this thread is about makes it so that the member variables aren't accessible outside of the class, which probably won't cause DWT any problems, since public member variables are generally a bad idea. However, if this PR (or a future PR) actually finishes implementing synchronized classes (I don't know how far this PR actually goes), then any classes that DWT has which have any synchronized functions would then have to be synchronized classes. So, while the current PR may not break DWT, odds are that at some point in the future, synchronized classes will be finished, and DWT will probably break. It wouldn't surprise me if fixing it were fairly easy - particularly if DWT tends to synchronize all of the functions in a class when it synchronizes any of them - but at bare minimum, you're probably going to have to move the synchronized keyword from the function declarations to the class declaration, and it's possible that some of the implementation will have to change to cope with the fact that it's then not legal to have some functions in a class synchronized while others aren't.
Basically all of the usage of the "synchronized" keyword in DWT is actually the synchronized statement. I found a couple of more false positives where "synchronized" was part of a method name. There are cases where not all of the methods contain the synchronized statement.
-- /Jacob Carlborg
