next »

[Jamie W]

One for the Java experts here:

Is there any kind of conditional compilation in Java? Like there is #ifdef / #endif in C - anything like that in Java?

Cheers,
Jamie

[kamac]

You might aswell google such simple questions :S

http://stackoverflow.com/questions/14208524/if-in-java-like-in-c-preprocessors

[Jamie W]

You might aswell google such simple questions :S

http://stackoverflow.com/questions/14208524/if-in-java-like-in-c-preprocessors

Thanks.

I don't think I worded my question very well, it certainly doesn't do justice to the complexity of the problem I'm faced with. The solutions presented in the link, don't seem all that elegant to me. The idea of commenting out code? Please!

[jgrams]

Would you like to try re-wording it? Because they do answer the question which you asked. Several of them say very clearly that there is no preprocessor in Java.

One of them even says:

Depending on your build system, you may be able to use a third-party preprocessor (you can find lots of them by searching for "java preprocessor"). Some examples are

...

[MorleyDev]

There are external 3rd party tools, but I've never been a fan of them in any language (it just never has felt like a clean solution to me). The more fundamental question is what are you actually trying to do with this, as there may be a cleaner and more elegant solution.

[Average Software]

There's no reason why you can't just use a C preprocessor on your Java files.

[kolrabi]

Just use normal ifs. If the compiler knows the condition can never be true, no bytecode will be generated.

[Jamie W]

There are external 3rd party tools, but I've never been a fan of them in any language (it just never has felt like a clean solution to me). The more fundamental question is what are you actually trying to do with this, as there may be a cleaner and more elegant solution.

I should have been more clear; you know you're in trouble when you can't clearly define the problem (or question) ... which to be honest, is probably winder in scope that simple 'what is a substitute Java mechanic for #define).

Previously, I had a class, called Vars. With members for each conditional requirement for Java code to be compiled (or executed). For example, Vars.condition1 or Vars.condition2

This solution just seemed really messy and ugly. I've only been using Java for maybe a year (been using C and C++ much longer), so am quite unfamiliar with good programming practices available in Java.

Someone mentioned the use of the keyword 'final'. I'm guessing that's used to show a value won't be changed; like a const? Maybe?

So anyway, the conditional compilation issue is just one of the problems I'm having. But there's more....

I'm having to maintain an Android project with multiple targets, using different store IAP code, and also Google Play Services or Amazon Game Circle or whatever, for leaderboards. How best to handle that? At the moment, I'm thinking some kind of class heirachy malarky.

Apologies if my original question was a bit vague.

[InfiniteStateMachine]

yeah java kind of lends itself to a lot of design pattern malarky.

Your vars solution is probably as close are you are gonna get. Off the top of my head I'd probably do that as well then for something like IAP just make a common interface and do something like the following :


IIAP thing;
if (vars.apple)
{
 thing = new AppleIAP()
}
if (vars.android)
{
 thing = new AndroidIAP()
}


etc etc..

It sucks, if it was c/c++ I'd just do something with the buildscript to inject defines for each platform but I'm not sure that's possible with java. I havent used ant/maven more than absolutely necessary.

[MorleyDev]

Well even on C++ I'd typically find it more desirable to have multiple implementations that implement a base abstract class, and then have some factory that creates the desired implementation. Conditional compilation is just to remove ones that won't compile on certain platforms.

So it could look closer to:

Code:

class IAPFactory {
    IAP create(AppType type) {
        switch(type) {
            case AppType.Apple: return new AppleIAP();
            case AppType.Android: return new AndroidIAP();
            case ...
        }
    }
}

Splitting such things into multiple discrete implementations of a common interface winds up making the code less dense overall as code density is a bigger source of difficult-to-follow code and therefore bugs than LOC, and so (insert usual ramblings about the advantages of SOLID principles here).