Java 中的 # ifdef # ifndef

Never used it, but this exists

JCPP is a complete, compliant, standalone, pure Java implementation of the C preprocessor. It is intended to be of use to people writing C-style compilers in Java using tools like sablecc, antlr, JLex, CUP and so forth. This project has has been used to successfully preprocess much of the source code of the GNU C library. As of version 1.2.5, it can also preprocess the Apple Objective C library.

http://www.anarres.org/projects/jcpp/

Use the Factory Pattern to switch between implementations of a class?

The object creation time can't be a concern now could it? When averaged over a long running time period, the biggest component of time spent should be in the main algorithm now wouldn't it?

Strictly speaking, you don't really need a preprocessor to do what you seek to achieve. There are most probably other ways of meeting your requirement than the one I have proposed of course.

javac will not output compiled code that is unreachable. Use a final variable set to a constant value for your #define and a normal if statement for the #ifdef.

You can use javap to prove that the unreachable code isn't included in the output class file. For example, consider the following code:

public class Test
{
private static final boolean debug = false;


public static void main(String[] args)
{
if (debug)
{
System.out.println("debug was enabled");
}
else
{
System.out.println("debug was not enabled");
}
}
}

javap -c Test gives the following output, indicating that only one of the two paths was compiled in (and the if statement wasn't):

public static void main(java.lang.String[]);
Code:
0:   getstatic       #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3:   ldc     #3; //String debug was not enabled
5:   invokevirtual   #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
8:   return

private static final boolean enableFast = false;


// ...
if (enableFast) {
// This is removed at compile time
}

Conditionals like that shown above are evaluated at compile time. If instead you use this

private static final boolean enableFast = "true".equals(System.getProperty("fast"));

Then any conditions dependent on enableFast will be evaluated by the JIT compiler. The overhead for this is negligible.

I think that I've found the solution, It's much simpler.
If I define the boolean variables with "final" modifier Java compiler itself solves the problem. Because it knows in advance what would be the result of testing this condition. For example this code:

    boolean flag1 = true;
boolean flag2 = false;
int j=0;
for(int i=0;i<1000000000;i++){
if(flag1)
if(flag2)
j++;
else
j++;
else
if(flag2)
j++;
else
j++;
}

runs about 3 seconds on my computer.
And this one

    final boolean flag1 = true;
final boolean flag2 = false;
int j=0;
for(int i=0;i<1000000000;i++){
if(flag1)
if(flag2)
j++;
else
j++;
else
if(flag2)
j++;
else
j++;
}

runs about 1 second. The same time this code takes

    int j=0;
for(int i=0;i<1000000000;i++){
j++;
}

If you really need conditional compilation and you use Ant, you might be able to filter your code and do a search-and-replace in it.

For example: http://weblogs.java.net/blog/schaefa/archive/2005/01/how_to_do_condi.html

In the same manner you can, for example, write a filter to replace LOG.debug(...); with /*LOG.debug(...);*/. This would still execute faster than if (LOG.isDebugEnabled()) { ... } stuff, not to mention being more concise at the same time.

If you use Maven, there is a similar feature described here.

final static int appFlags = context.getApplicationInfo().flags;
final static boolean isDebug = (appFlags & ApplicationInfo.FLAG_DEBUGGABLE) != 0

If you use IntelliJ there is a plugin called Manifold, that - along with many other features - allows one to use #ifdef and #define in Java.

Plugin url: https://manifold.systems/

Preprocessor information: https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-preprocessor

PS: I am not affiliated with them, we just happen to use it, and it helps a lot with out workflow (which is likely NOT typical for Java development)