What you are looking for is active detection of a window resize event. I have done this in the past, but the look isn't all that pleasing and it is quite difficult to get done.

Before you can do this, you have to understand that Processing (by default) uses the AWT Frame object for the frame. The AWT is a bit out-of-date and doesn't include the ability to detect active window resizing (when it was released, most windows would blank out during resizing. Obviously that has changed...). There is a new package, Swing, which provides the JFrame which does have this ability. However, in order to get a JFrame object instead of a Frame, you need to meddle with the initialization of the sketch and change the declaration of frame. It isn't impossible, but it is quite messy.

I appear to have lost the example that demonstrated active resize detection, but it possible. Keep in mind that it was messy and not at all pleasing to the eye. If you still want to pursue it, then I can whip something up...

I guess he meant that it's gonna be laborious. And you'll have to hack the generated .java source me guess!
Maybe, even some internal files from processing installation! 

Not at all, GoToLoop.
He meant when such redrawing happens during resizing, it is generally not synchronized with screen refreshing, so you get tearing, visual artifacts, etc.

Short answer: No.

What exactly is the purpose for getting this to work? Perhaps you can find an alternative solution to the problem. This is really one of the limitations that I have found with Processing and I really hope that someone can find a solution at some point while maintaining the drawing canvas that Processing provides.

Okay. If you still want to do it, then you can pursue that. I had tried in the past and abandoned the idea because it looked so awful. I might be able to get back to you later with how I did it.

When I say that Processing has this limitation, that doesn't necessarily mean that Java lacks it, but rather that most Java programs run strictly with a GUI, built from Swing, which runs at the same level as the resizing window. In Processing's case, there is another whole level on top of Swing for Processing's drawing canvas, the disparity between these layers causing most of the problems. So if your program relies on Processing's drawing functions, then you encounter this issue. But if you need only a GUI (such as provided by Swing), then it is feasible to implement resize detection.

Processing is Java, with some syntactic sugar poured on it.
But Processing doesn't mix well with Swing: people use Processing inside Swing applications with success, but it is hard to use Swing inside Processing.