no, not possible as far as i know. this question was asked several times before.

A little trick, brittle, and working only to distinguish 1.5.1 or earlier from 2.0+:

1. if (P3D == OPENGL) println("I am run on Processing 2.0");
2. else println("I am run on Processing < 2.0");

Would that information not be buried somewhere in a preferences or system resource file? If the path to the file is known, and the line containing the info is discoverable, could this not be utilized?

Granted, it would be hacky and painful to have to do this, and some built-in metadata would be far better. But shouldn't it at least be possible?

Knowing what version the sketch was created in is another matter entirely. But it seems to me that there should be a way, even if roundabout, to code a sketch to be able to determine what version of Processing it's currently running under.

I don't personally have an immediate need for this, but I can see us all wanting it as a feature in the very near future.

[Edit: Dang, I posted my comment before PhiLho's had appeared in my browser window.)

Note that there is a version.txt file in the lib folder of the Processing distribution.
The trick is to read the file without knowing where it is installed, in a portable way...

1. // http://sacharya.com/find-the-jar-file-given-a-class-name/
2. Class<?> context = processing.app.Base.class;
3. URL location = context.getResource('/' + context.getName().replace(".", "/") + ".class");
4. String jarPath = location.getPath();
5. println(jarPath);
6. String path = jarPath.substring("file:".length(), jarPath.lastIndexOf("!"));
7. if (path.substring(2, 3).equals(":")) // Windows
8. {
9.   path = path.substring(1);
10. }
11. println(path);
12. int pos = path.lastIndexOf("pde.jar");
13. if (pos == -1) { println("Not found"); exit(); }
14. String versionPath = path.substring(0, pos) + "version.txt";
15. String[] lines = loadStrings(versionPath);
16. println(lines[0]);
17. exit();

thats pretty cool PhiLho, 

Only works if Processing is installed in a publicly accessible area of the computer, otherwise you can't access the data (e.g. it is installed in Program Files), but that's awesome!

I never install Java programs in Program Files, at least because there is a space in the path, which can be problematic for some (poorly coded) programs, and also because of such restrictions (bothering me when I put stuff there, even if I am admin).
Beside, I thought there were restrictions on writing in Program Files, not on reading from there. Am I wrong?

v.k., I checked my collection of Processing archives, I found the first version.txt file in the revision 0182 (March 2010) and not in the 0154 (2008; I have no archives between them), so it is there since some time. So it has been around for some time.
See if the file is in the archive, perhaps.

/Applications/Processing.app/Contents/Resources/Java/revisions.txt

I filed an enhancement request here about making available the MODE and VERSION information.

//EDIT// All right, got a reply from Ben. For future reference, the outcome is...

• MODE information is covered by issue 281, but not yet implemented.
  

• VERSION information won't be added on principle with the following reasoning:

As for versioning inside PApplet, that's a really messy thing and encourages even more messiness in how people support newer/older code. If there's something that's breaking in 2.x that's causing a lot of trouble, please file a bug for it so that I know about it.

On some level, we /don't/ really want people using older code or supporting 1.x versions. I'm doing this in my spare time and I can't possibly build and debug 2.0 and also have to support 1.x versions.

we /don't/ really want people using older code or supporting 1.x versions.

Seems more like MS trying to make peeps abandon Win7 & WinXP for Metro Win8!  

I'm doing this in my spare time and I can't possibly build and debug 2.0 and also have to support 1.x versions.

Methinks nobody is asking for developers to work on previous versions!
And having a VERSION variable would be nice even for current beta versions!

Whether 3rd parties continue or not their support for previous Processing versions are their own call. 
It's sad that Processing developers are putting artificial impediments for it!