Tanctikon is an enclosing instance of the class this synchronized statement is called from.
Hmmm…
Hmm. I don’t get an error with this:
void draw(){
synchronized(this){
}
}
…and I don’t have your code to test / debug – can you try to break your screenshot down to a shareable MCVE that still exhibits the NullPointerException?
I don’t use synchronized in Processing – but one community member who I believe is a frequent user of synchronized is @quark.
The only reason for using the synchronized keyword is if you are using multiple threads. If you are not using multiple threads, and I can’t see anything in the images to suggest you are) then you should avoid using the synchronized keyword.
When you execute a Processing sketch the code is wrapped up in a class of the same name as the sketch. So in your sketch Tanctikon the code will be enclosed in a class called Tanctikon. So in your code
if(TakTanctikon.this == null) print("wtf");
is the same as
if(this == null) print("wtf");
It is impossible for the value of this to be null hence the error message in the left image.
As regard to the NPE if you look at your code you have two opening braces { following the synchronized(this) so I suspect you have included too much code in the scope of synchronised statement. This is born out the last post by @jeremydouglass.
Just to set the record straight I don’t use this keyword a lot 
. In the stackoverflow discussion it is used on secondary windows created with G4P. In early versions of Processing I used to get interference between the multiple draw() methods so made the G4P windows draw methods synchronized. It probably isn’t needed now.
2 Likes
Yes, the screenshots may not be very representative, but I just wanted to showcase the weirdness of the example.
It doesn’t make sense that a synchronized locked on this could produce a NullPointer. A possibility would be that it is a traceback bug in Processing that refers the NullPointer to the line of the synchronized statement when it is thrown inside it, but I doubt it, since the same error occured in different contexts.
I used the qualified name in the example because it was an inner class of Tanctikon, but enclosing instances can’t be null as well, thus the compile-time warning. I used this to demonstrate that it seemed absurd to me how synchronized(this) could throw a NP.
Even when it did show the NullPointerException in the right picture, the if statement didn’t evaluate to true and print “wtf”, thus pointing more into the direction that “this” is likely not the cause of this NPE.
I’ll try to reproduce this problem in a MCVE after finishing writing this.
Is there a way to see the full stacktrace within Processing? That would help a lot.
I found the culprit, it’s a similar cause to this SO post.
When I synchronize on a block and a NPE gets thrown inside it, it refers it to the synchronized statement itself.
Basically my synchronization didn’t cover all concurrent Thread accesses and one Thread would change a variable to null, which would cause a NPE inside the synchronized statement.
Edit:
I don’t know how I didn’t think of just catching the exception and printing the stack trace myself.
As I suspected, the NPE from a line of code within the brackets of the statement, but if I don’t catch it Processing refers the reason to the synchronized statement, which could be reasoned since it’s a statement on its own.
Considering someone else faced a similar problem as well, it likely has something to do with the implementation of synchronized and it’s stack tracing in various IDEs.