Funny thing Processing has a pre-processor already!
However, in devs' rationale there's no need to implement such basic C pre-processor commands
like #define, #ifdef and #endif.
In my opinion, if we have a pre-processor already, we should use its potential.
I can't see why not! 

What I can tell is:
Pre-processor's main purpose is to transform our Processing code into a Java valid one.
Even some syntax sugar like color data-type into int and #... web literal into 0xff... hexadecimal 1.
1 of its most important step is enclose our whole code into a Java class.
Plus adding a static main() entry-point as well.
And many other things as some necessary library import.

Maybe I should retitle this thread "HOT! Don't Touch!"

Why? I  don't get it!


The pre-processor of Processing is very different from what you are used to in C/C++. In fact the main purpose of Processing's pre-processor is to convert the sketch code into a correctly formed Java class so javac can compile it.

AFAIK there is no way to perform similar C pre-processor tasks within the Processing IDE. Certainly it is impossible to selectively choose which imports to use.

One technique available to developers is to use constant booleans e.g.

1. final boolean ANDROID_MODE = false;
2. 
   
3. public void setup(){
4.   if(ANDROID_MODE){
5.     println("Android mode");
6.   }
7.   else {
8.     println("Another mode");
9.   }
10. }

Here line 5 is unreachable because the conditional-statement in line 4 is always false, unless we change the value of ANDROID_MODE.

This technique cannot be used to select imports (as I said before)

... there is pedagogy that prevents such an obviously useful tool to be excluded from the language.

It's a hot topic! And I'd say there's some stubbornness at not including it in Processing language. 
Saying that it's anti-Java is senseless, since Processing itself is agnostic
to the underlying language in which it is compiled.

If we had some basic C pre-processing definitions we could write a unique source code
which would "compile" correctly in Java, JavaScript, Android and Arduino!

Addendum: Arduino got #define and I believe #ifdef & #endif. But it's C based anyways.
How jealous I am! 
http://arduino.cc/en/Reference/Define

"HOT Don't Touch" was an attempt at humor

Ah I get it now my brain must be tired.


You might explore Java annotations - not an area I have delved into so it might not help.

In the land of Java, you would have two sketches, one for the Java mode, another for the Android mode.
The Android-specific code should be isolated in some classes, with their specific code: methods using these imports cannot be used in the Java mode anyway.
General logic of the sketch, which would be system-agnostic, is isolated in classes without these Android imports.

It is a matter of code organization and separation of concerns.

I coded C a lot, and while the preprocessor is powerful, it can be easily abused, where you can have almost two distinct programs in various, intertwined preprocessor directives, resulting in something unreadable and hard to maintain.

On the other hand, the Java way can result in some redundant code, depending on how well this is handled.

Note: the Processing preprocessor is purely internal, dedicated only to change some Processing code into valid Java code (adding a class around your sketch, with a main() method, etc.), and is indeed absolutely not intended to be used by regular Processing coders.
You can try and hack it, but it is a quite advanced topic, you have to know how to build Processing (yes, it means you make your fork of Processing), how to change an Antlr grammar, etc.

I fear my advice was mostly usable in a classical Java environment, where you can exclude some packages from compiling depending on a profile. I don't know if it is usable in the Processing IDE, I haven't tried yet to use the Android mode.
In theory, if you make a .java tab in the PDE, its includes are limited to this file / class. An include in a .pde tab is shared by all the sketch!

Constants:
final int JOE = 1;
The final directive declares a variable as being actually a constant.
And, yes, they use storage, but it is negligible.
Ideally, an enum would be better suited for these declarations, but they must live in a dedicated .java tab, as Processing's preprocessor doesn't recognize them yet.

it seems that there is stuff that WANTS TO LIVE outside of a class definition- such as imports.  

In C++ #include and Java #import statements are ALL placed outside the class definitions. In C there are no classes so there is no comparison.

Try as I might, I could not move the android imports into the android class where they would not be "heard" by the java mode, and found myself running willy nilly through the code,

The Processing pre-processor will take your source code and wrap it up into a single class. Any classes inside the source code will become ' inner classes' and they all share the same imports.
The solution is to create the AndroidMode and JavaMode as ' top-level' classes. To do this in Processing create a new tab and when asked to name it - give the class-name you want to use with a .java extension. So if the class is to be called Foo then the tab would be called Foo.java (case sensitive). In this tab add only the import statements needed by the Foo class.

#define JOE 1

#define FRED 2

#define GEORGE 3

at the present, I am allocating storage for each of these values as Ints.

" Do you just use the java equivalent?"
Yes. Processing is just Java code, with some syntax sugar around it.

http://processing.org/reference/
I see a Bitwise Operators section, and exponentiation function is pow().

Note on Java mode vs. Android mode: perhaps you can use a trick explained in some threads here, putting the common code in a sketch, and making one sketch with classes specific to Android, and another for Java. Then you can hardlink the common code into these two sketches. Thus you can workaround the lack of compilation profiles in the PDE.

Just to add my penny-worth into this discussion ;)

For example, there is no exponentiation function listed in Processing.  Nor bitwise logical operators.  Do you just use the java equivalent?

Yes use the Java equivalent.

As to the exponential use the one in java.lang.Maths class (see here) like this

1. float x = (float) Math.exp(2); // calculates e squared

by default ALL classes in the java.lang package are imported so there is no need for another import to use the Maths class. Since the Math class uses the double type throughout you will have to cast the result to float for Processing. (All Processing functions use float for floating point numbers)

Bitwise operators & | >> <<  etc. are explained here.

BTW the last link takes you to the Java tutorials are a great place to find info about Java.

Processing has pow() in its "official" API. It's in the same Calculation section as the other Math 1s are.  
http://processing.org/reference/pow_.html

The only important 1 I've spotted lacking is Math.signum(). (There are some others of course.)
Perhaps that was ignored for the same reason Processing lacks support for nested enum type,
which was only introduced @ Java 5. Seems like Processing is internally still stuck @ ancient Java 4! 

And again I'm gonna repeat my opinion. Inclusion of C-like pre-processor directives in the Processing language
would surely make easier to write source codes which would seamlessly compile in different modes,
like Java, JavaScript, Android and even somewhat Arduino!

No need to have everything. Just basic #define, #ifdef and #endif is enough! This is a FACT!!!