Making a variable 'final' is as much to do with safe programming as run-time efficiency. To understand why, you need to appreciate the difference between classes and objects.

Suppose  I have a class called MyCircle that contains within it a non-static variable defining a circle's radius.

You could create many instances from that class, each of which could have its own radius. The value of each object's radius is completely independent of any other object's radius value. ie. changing the value of one object's radius has no effect on the values stored by other objects that come from the same MyCircle class. This is the normal way of doing things in object-oriented programming.

If you were instead to define the radius variable as static, this would mean that the variable is associated with the class, not each of the objects created from it. As a consequence only one copy of it is stored, even if many objects are created. Change the value of radius in one object, and all the other objects' radius values change too. This is poor object-oriented practice and could lead to confusing bugs in complex programs. By making a static variable final, this ensures that once declared, its value can never be changed, thus reducing the chances of hard to trace bugs (you'd get an easy to spot compiler error if your code tried to change the value of a final variable).

In practice it therefore only makes sense to declare final static variables to represent constant values that never change at run-time (e.g. a program that contains a large collection of circles all of a constant radius). By convention, static final variables are given upper case values to distinguish them from true variables.

The story with final methods and classes is slightly more complicated, but is essentially the same principle of keeping behaviour fixed so that a class or object does not do unexpected things in your program.

Your first example is a perfectly reasonable approach to use in Processing. By declaring the variable radius at the beginning like that you have effectively made it 'global'. ie. its value can be changed both inside and outside your cercle^* class.

The second example is also fine (assuming you add a 'final' to the static declaration). This case is an example of encapsulation where, as you say, everything that relates to the properties of the circle are placed inside the class that represents it.

Which of the two approaches you take will depend on

(i) the complexity of the program. Simple programs can use the first 'global' approach without much problem. Processing is set up to make this approach really simple and easy to implement quickly. As programs become more complex, using global variables in this way can make debugging more complicated and difficult to trace though.

(ii) What parts of your program need access to 'radius'. If a circle's radius is something that only the circle class need ever have access to, then it makes sense to encapsulate it inside the class. That helps to keep the non-circle part of your code cleaner and easier to follow. If radius is something that is shared between many different parts of your code, then it may be better to  declare it elsewhere, such as in your first example.

---

* One minor point: Classes should always be named with an initial capital letter. This is a programming convention rather than a compiler issue, but it helps to differentiate classes from objects (that should always be named with an initial lower-case latter). Doing so will help to embed these ideas of classes, objects, static and instance variables etc.

Yup, that's me. In fact I was working on text for the second edition of that book today before getting distracted by Processing...

That was amazingly well explained Here are my thoughts on statics and finals..

- making something static, and especially static final will speed up things, I have proven this (in J2ME atleast) - due to the less checking required during run time, ie, no checking at all if its final - I guess the compiler does some nice jiggery pokery also since its a "constant" effectively if its final. Even though I could get burned at the steak for suggesting this, when I need to optimise, I make everything static and static final if I can - SO LONG AS THIS WILL NOT AFFECT anything in my run time - ie, you know that there is only ever once instance of a class.

- the same approach can save jar size and make life easier, again heretic speak but I often cant be bothered to code a getVal() setVal() so I just make it public static and get it by doing ClassName.myStaticVar - it is a hell of a lot quicker than making get/set methods or even trying to find the instance name and doing instance.myVar. Again ONLY IF THIS WONT AFFECT the runtime of my code. You may argue this is bad practise for later when I upgrade my code, yep thats fair enough.

- As Jo mentioned statics should be done in capital letters, mainly so your brain goes ohh CAPS must be static (im learning all these conventions are really clever because you save so much time not checking what stuff is - similarly if you keep all your variables named the same sort of thign throughout your career in the end youll be able to "guess" what you called it without going looking) - using these finals in things that get called a lot can speed things up, like in a constantly called draw method:

getWidth()/3.142

is blatently going to be slower than:

WIDTH/PI

or even:

WIDTH_OVER_PI (fastest)

in switch statements its nice do use finals, as the states will enver change, ie:

switch(gameMode)
{
case INTRO:
break
case CREDITS:
}

which helps code readability..

Anyway just thought id stick my 2 cents in there in case it helps.. I have a tendency to tell people stuff how it is, rather than the academic way and sometimes I feel "human beings" prefer it that way

Thats not to say Jo is not a human being, I loved the explanations, Im just talking about these Java purists who would have me hanged for saying yeh I make stuff static final for speed and ease... (mostly theyre hiding on IRC

Cheers,
Gaz.