=== on 4 Feb 2015, 13:58:18 Ann Campbell wrote:
Gendarme DoNotLockOnThisOrTypesRule

=== on 13 Apr 2015, 10:50:21 Freddy Mallet wrote:
@Tamas, does this rule makes sense to you ? Thanks

=== on 22 May 2015, 11:20:42 Tamas Vajk wrote:
\[~ann.campbell.2] Looks good, I've updated the wording around the ``++Type++`` object

=== on 22 May 2015, 12:08:56 Ann Campbell wrote:
Thanks [~tamas.vajk]. Looks good.

=== on 11 Jun 2015, 12:45:11 Tamas Vajk wrote:
\[~ann.campbell.2]: Could you rephrase it according to the following?

\[~dinesh.bolkensteyn] made the following remark on this rule in GitHub: "...IMO ideally we'll want to show an instance of a real issue.


my understanding of the current description is that, as soon as another thread will also lock "this" or the same type, then you will have a deadlock"


The problem he raises is that we shouldn't lock on ``++this++`` or an instance of ``++Type++`` because it *increases* the chance of running into a synchronization issue.


I don't thing that we should add a code sample which has a deadlock as the example would be too complex and long.

=== on 11 Jun 2015, 15:22:39 Ann Campbell wrote:
wording massaged. See what you think.

=== on 11 Jun 2015, 15:23:33 Ann Campbell wrote:
FYI [~nicolas.peru]. This was originally written for C# but I've just mapped it to a FB rule.

=== on 11 Jun 2015, 15:29:03 Tamas Vajk wrote:
\[~ann.campbell.2] Looks good

=== on 15 Jun 2015, 09:24:06 Nicolas Peru wrote:
\[~ann.campbell.2] I have doubt about how this one actually maps to the findbugs rule mentionned. AFAIU this one is about synchronizing on ``++this++`` whereas the FB rule is about synchronizing on ``++this.getClass()++`` that should be avoided so I think this mapping is not correct. 




=== on 15 Jun 2015, 13:59:21 Ann Campbell wrote:
\[~nicolas.peru], C#'s ``++this.GetType()++`` is analogous to Java's ``++this.getClass()++``.


Does that sway your opinion?

=== on 15 Jun 2015, 14:32:47 Nicolas Peru wrote:
\[~ann.campbell.2] Not really, as the fix for the findbugs rule suggest to use the static ``++.class++`` accessor instead of ``++this.getClass()++`` which is synchronized on a type, hence the spirit of the rule is not the same and then mapping is not suitable.

=== on 15 Jun 2015, 15:07:34 Ann Campbell wrote:
Okay [~nicolas.peru]. Mapping removed.

=== on 8 Jun 2023, 11:07:34 Greg Paidis wrote:
During a LAYC sprint, I removed java, since it is neither implemented nor are there any implementation tickets.