Can javac do macro (conditional) compilation?  
Author Message
RC





PostPosted: 2007-6-13 23:14:00 Top

java-programmer, Can javac do macro (conditional) compilation? In C/C++ we can do

for example:

#ifdef VERSION_1
// write version 1 codes here
...
#else
// write version 2 codes here
...
#endif



Then when we compile the code with -D option

gcc -DVERSION_1 input_filename.c -o output_filename
This will compile the codes in version 1

gcc input_filename.c -o output_filename
This will compile the codes in version 2

I am just wonder can I use -J option in javac?
If I can, then how do I write the syntax in java codes?
 
Owen Jacobson





PostPosted: 2007-6-14 0:12:00 Top

java-programmer >> Can javac do macro (conditional) compilation? On Jun 13, 8:13 am, RC <email***@***.com> wrote:
> In C/C++ we can do
>
> for example:
>
> #ifdef VERSION_1
> // write version 1 codes here
> ...
> #else
> // write version 2 codes here
> ...
> #endif
>
> Then when we compile the code with -D option
>
> gcc -DVERSION_1 input_filename.c -o output_filename
> This will compile the codes in version 1
>
> gcc input_filename.c -o output_filename
> This will compile the codes in version 2
>
> I am just wonder can I use -J option in javac?
> If I can, then how do I write the syntax in java codes?

No. However, as I understand it, final static constant-expression
booleans can be used to eliminate code inside if statements at compile
time.

If you absolutely need a macro preprocessor you have to invoke it
yourself as part of your build, and then feed its output to javac.
Think very hard before doing this.

 
Lew





PostPosted: 2007-6-14 0:28:00 Top

java-programmer >> Can javac do macro (conditional) compilation? RC wrote:
>> In C/C++ we can do

Java is neither.

>> #ifdef VERSION_1
>> // write version 1 codes here
>> ...
>> #else
>> // write version 2 codes here
>> ...
>> #endif
>>
>> Then when we compile the code with -D option
>> I am just wonder can I use -J option in javac?

Owen Jacobson wrote:
> No. However, as I understand it, final static constant-expression
> booleans can be used to eliminate code inside if statements at compile
> time.

Why would one need to? Why not just use regular "if" constructs?

> If you absolutely need a macro preprocessor you have to invoke it
> yourself as part of your build, and then feed its output to javac.
> Think very hard before doing this ...

then don't.

What would be the point? The primary use of conditional processing is to
account for different environments, a moot point with Java. Everything else
it's used for is more naturally expressed in Javaworld with properties.

This is the point of saying that Java is neither C nor C++. The whole idea of
conditional processing is irrelevant to Java.

--
Lew
 
 
Robert Klemme





PostPosted: 2007-6-14 0:59:00 Top

java-programmer >> Can javac do macro (conditional) compilation? On 13.06.2007 18:27, Lew wrote:
> RC wrote:
>>> In C/C++ we can do
>
> Java is neither.
>
>>> #ifdef VERSION_1
>>> // write version 1 codes here
>>> ...
>>> #else
>>> // write version 2 codes here
>>> ...
>>> #endif
>>>
>>> Then when we compile the code with -D option
>>> I am just wonder can I use -J option in javac?
>
> Owen Jacobson wrote:
>> No. However, as I understand it, final static constant-expression
>> booleans can be used to eliminate code inside if statements at compile
>> time.
>
> Why would one need to? Why not just use regular "if" constructs?

Or rather use interfaces with different implementations and make use of
polymorphism. I think that's the most used idiom in Java land.

>> If you absolutely need a macro preprocessor you have to invoke it
>> yourself as part of your build, and then feed its output to javac.
>> Think very hard before doing this ...
>
> then don't.
>
> What would be the point? The primary use of conditional processing is
> to account for different environments, a moot point with Java.
> Everything else it's used for is more naturally expressed in Javaworld
> with properties.

Another path that's often chosen in Java is using interfaces with
different implementations depending either on environment, configuration
(properties etc.) or runtime conditions.

> This is the point of saying that Java is neither C nor C++. The whole
> idea of conditional processing is irrelevant to Java.

Yeah, stop thinking in C(++).

Kind regards

robert
 
 
Owen Jacobson





PostPosted: 2007-6-14 4:14:00 Top

java-programmer >> Can javac do macro (conditional) compilation? On Jun 13, 8:13 am, RC <email***@***.com> wrote:
> In C/C++ we can do
>
> for example:
>
> #ifdef VERSION_1
> // write version 1 codes here
> ...
> #else
> // write version 2 codes here
> ...
> #endif

<offtopic>
To add to my earlier comments, you can do that in C and C++, but you
shouldn't. It misleads most programmers into thinking they can still
build "VERSION 1" of their software when, in fact, they can't. Not
from source code that is not what was originally released as version
1.

If behaviour has to change between versions, *remove the old
behaviour* and replace it with the new one. If you discover a need to
provide both behaviours, it will either be in the same build (in which
case that preprocessor trick won't work) or it won't (in which case
you can check out the version 1 source code and build that).
</offtopic>

 
 
RC





PostPosted: 2007-6-14 20:17:00 Top

java-programmer >> Can javac do macro (conditional) compilation? I agree with you. The reason I came up this idea is
I have two versions of code. I want to do a demo to the
users. An user can open a window to run two programs.
I want to see which version they prefer/like. Then in
the final build, only one version will be check in.
 
 
Lew





PostPosted: 2007-6-14 21:51:00 Top

java-programmer >> Can javac do macro (conditional) compilation? RC wrote:
> I agree with you. The reason I came up this idea is
> I have two versions of code. I want to do a demo to the
> users. An user can open a window to run two programs.
> I want to see which version they prefer/like. Then in
> the final build, only one version will be check in.

Use what Robert Klemme suggested:
> Another path that's often chosen in Java is using interfaces with different implementations depending either on environment, configuration (properties etc.) or runtime conditions.

Polymorphism rules.

--
Lew