For something as simple as an integer, there's no reason to define things as constant, you'll get no benefit at all.

It is possible to do it (I think) by saying:
static final int xMinus=0;
but it's of no benefit really.

They don't need to be constant to do that though is what I'm saying. Making them constant instead of variable gives almost no benefit in most cases.

OK, Thank you. I just tried it and it work.

I put <static final int kk=55;> in the main tab,
and I can <print(kk);> in this and the other tabs,
and it wont let <kk+=1;> work, which is what I want for a constant.

I guess <final> means it can not be changed. What about <static>?

I did found this reference about <final>,
http://renaud.waldura.com/doc/java/final-keyword.shtml#fields
but its a bit too much for me.

(I'm learning Processing but I don't know Java, and yet I already did some cool things..., but the whole scope of Processing and Java is just overwhelming!)
http://leepoint.net/notes-java/index.html

not that I do much of this (thankfully!) or really care too much about it... but my understanding of the value of modifiers such as static and final is for semantic and best practice standards–usually applicable in large scale dev, not seat of your pants creative coding (my preference of course;-)

For example, a system that utilized a bunch of shared widget-type parameters might create a Widget class with a slew of constants (that must never change or stuff could break). You wouldn't want to force users to memorize a bunch of integer values, so you'd do something like:

static final int SEXY_EYECANDY_DETAIL = 23;
static final int MILDLYFETCHINNG_EYECANDY_DETAIL = 24;
static final int BUTTUGLY_EYECANDY_DETAIL = 25;
etc.

This would also, as was said by others, allow the constants to be used without the need to instantiate the Widget class.
(You'd access them using the class directly, like: Widget.SEXY_EYECANDY_DETAIL).

In a library composed of many related classes, in which it could make sense semantically to use an eyecandy detail, there is an efficiency of both not having to instantiate another class, along with the benefit of a common logical naming system. And the final keyword provides some security to things not unexpectedly breaking.

One last point (if anyone really cares), Java's Interface structure allows the inclusion of constants, which is a good place to create them. Of course, interfaces become most useful as you begin to work with more advanced OOP patterns, which rely on the benefits of polymorphism.

(warning-digression follows) For example, a common interface type can be composed within a class that needs to be able to communicate with many other classes (say a game engine that keeps track of lots of stuff). Rather than composing objects of all of the possible classes within the engine class, you could compose only the single interface type, which each of the other classes would implement (meaning each of those classes now has a 2nd identity of the interface type). This allows an interface parameter to successfully catch any object argument passed in, as long as it's also of the 2nd interface type. Java then can miraculously figure out which class type you passed in to the engine and ultimately invoke a commonly named method, which will use the implementation defined within the calling object's class. This would allow you to, as an example, expand the game's characters, without needing to mess with the Engine class itself.

* modified *
I'm  not using J2SE 5.0, so I haven't been using typesafe enums and static imports, but apparently that's the way its now recommended to include lists of constants, rather than embedding them in interfaces. Of course all of this has pretty much nothing to do with using Processing.