That's not a question, because I have solved the issue, but it is syntax related and I thought I should share the problem and found solutions.

I was bitten by a strange limitation in Processing.

I has to write several different but similar classes with various parameters, or even algorithms. So I made an interface, so the classes could implement the interface and I can pass them as method parameters with interface (generic) type.
I first made a plain interface with parameterless methods and a dummy implementation with nearly empty methods. It worked fine.
Later I found I should pass one of my classes as parameter type.
Example:
Code:

interface Foo
{
    int Bar(Heart h);
}
class FooC implements Foo
{
    int Bar(Heart h) { /* Use h; */ return 1; }
} 

where Heart is one of my classes.
Ouch! I got an error:
Quote:

Apparently, a interface is a static type. It is fine if it uses a type external to the PApplet (eg. color, PImage, or some external class) but doesn't like using an internal class.
Problem: I can't use a "qualified name" to access the class, as the name is dynamically generated. Perhaps we could use a special notation that would be substitued by the pre-processor...

A possible workaround is to put the interface in a .java file, but then I must also externalize the Heart class, thus pass the PApplet instance around, etc. Not very elegant in my mind, even if all I do there is to use the color type (replacing by long seems to work), and a little drawing code. And using some auto cast, apparently.
Here again, the pre-processor could do this automatically (adding a PApplet reference, passing it around, etc.) but it is far from obvious, I fear...

Perhaps the issue is already somewhere in the depths of Discourse, I admit I haven't searched.
OK, I just searched and found the same case: http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Syntax;action=display;num=1150747743;start=0#0

fry says the same thing as above, that the interface must go outside of the PApplet. But I am reluctant to write semi-Processing code in my class.

I used another workaround, that I thought interesting to share. Not very elegant (purists will puke) but it works:
Code:

interface Foo
{
    int Bar(Object oh);
}
class FooC implements Foo
{
    int Bar(Object oh) { Heart h = (Heart)oh; /* Use h; */ return 1; }
} 

Indeed, fundamentally, it is a Java issue, but within the precise context on Processing and its way of handling declarations.
In a real Java project, I suppose nobody would make an internal interface.
I just wanted to point out this limitation and highlight some possible solutions.

It is not really a defect of the design of Processing. As fry points out, this sub-language aims mostly at beginners or simple projects. So stuff like interfaces and abstract classes might be a bit stretched.

Yet, people use Processing as a learning tool toward programming in general, and Java in particular.
And being able to promote code reuse and good OO ideas would be nice. But of course, there is no simple solution for this, as I point out.

I have a similar issue with the Processing classes I make, which I want to reuse in various sketches. But I will develop that in another thread.