Conditional Compile

[Brian Edginton]

What is the best way (or what are the available ways <G>) to
do a conditional compile in java? I'm looking for the equivilant
of a preprocessor command like #ifdef

Thanks,
edge

 

[Tim Tyler]

: What is the best way (or what are the available ways <G>) to
: do a conditional compile in java? I'm looking for the equivilant
: of a preprocessor command like #ifdef

There's this:

final static boolean debug = false;
....
if (debug) {
// any code here is completely removed if !debug...
}

The code in the middle must still compile, though.

 

[Miguel De Anda]

: What is the best way (or what are the available ways <G>) to
: do a conditional compile in java? I'm looking for the equivilant
: of a preprocessor command like #ifdef

There's this:

final static boolean debug = false;
...
if (debug) {
// any code here is completely removed if !debug...
}

The code in the middle must still compile, though.

Hmm... maybe somebody can make another java program to go through any code
inside that 'if' and remove it. It shouldn't be too hard. Any volunteers?

 

[John C. Bollinger]

Hmm... maybe somebody can make another java program to go through any code
inside that 'if' and remove it. It shouldn't be too hard. Any volunteers?

That's effectively what the compiler does. What a good compiler does,
at any rate -- I'm not aware of compilers being _required_ to do this.
I believe Sun's does though, and probably IBM's too.

If you really want to use a preprocessor on Java code then why not just
use C preprocessor syntax and run it through a C preprocessor? Except
for debug code, however, I don't really see much use for conditional
compilation in Java.


John Bollinger
(e-mail address removed)

 

[Tim Tyler]

: Miguel De Anda wrote:

:> Hmm... maybe somebody can make another java program to go through any code
:> inside that 'if' and remove it. It shouldn't be too hard. Any volunteers?

: That's effectively what the compiler does. What a good compiler does,
: at any rate -- I'm not aware of compilers being _required_ to do this.

JLS 14.20 seems to be the word on this:

``An optimizing compiler may realize that the statement x=3; will never be
executed and may choose to omit the code for that statement from the
generated class file''

I.e. it's explictly permitted - but is not required.

I believe all the main Java compilers perform this optimisation, though.

 

[Roedy Green]

Except
for debug code, however, I don't really see much use for conditional
compilation in Java.

The place I have run into where a preprocessor would be nice was when
where you had two libraries that implemented a class. You wanted
variable import statements.

 

[Roedy Green]

The compiler has removed the whole if statement from the compiled
bytecode

And if you use an optimising compiler, like Jet, even more of your
code disappears. I discovered, for example, that I always called a
method with a boolean parameter true. Jet then decided the parameter
was not necessary and removed it, and took out all code that would be
invoked if it were ever false, noting of course that I never used
Class.forName which could break that optimisation.

see http://mindprod.com/jgloss/jet.html

 

[Tim Tyler]

: Java gurus frown on using preprocessors. Often with a bit of ingenuity
: you can bypass the need.

A preprocessor would be a great thing - if it mapped from a great,
fantastic language to Java source code.

Most preprocessors only try to improve on Java a little bit.

Java is too well established for any /slight/ variants on it to
invade its turf - even if they are improvements on it to some extent -
that just stops other people from using your code - and prevents you
from using their tools.

 

[Carsten Zerbst]

if(running_Mac_OS_X)
{
use_an_apple_extension_jar
}
}
This code is now no longer portable to platforms which dont have the
apple extension jar, EVEN if the running_Mac_OS_X flag is false.

It is not portable in the sense of compiling, running should be no
problem. And all you need are the MOX jars on you developping machine.
I have jmx-libraries for linux, sunos and windows
on my machine which are referenced in my setup code, its no problem to
compile again them on linux. So where is the problem ?

Bye, Carsten

 

[Dale King]

: Miguel De Anda wrote:

:> Hmm... maybe somebody can make another java program to go through any code
:> inside that 'if' and remove it. It shouldn't be too hard. Any volunteers?

: That's effectively what the compiler does. What a good compiler does,
: at any rate -- I'm not aware of compilers being _required_ to do this.

JLS 14.20 seems to be the word on this:

``An optimizing compiler may realize that the statement x=3; will never be
executed and may choose to omit the code for that statement from the
generated class file''

I.e. it's explictly permitted - but is not required.

I believe all the main Java compilers perform this optimisation, though.

And most are likely to optimize it out. While they are not required to
remove the code, they are required to ifs with constant conditions because
it is a special case for the code reachability analysis. They are required
to not generate a warning about unreachable code in this case. Since they
already have to detect the condition it is trivial to do the optimization.

 

[John C. Bollinger]

The place I have run into where a preprocessor would be nice was when
where you had two libraries that implemented a class. You wanted
variable import statements.

I can see why you would want conditional compilation in this case, but I
dislike the general approach. If implementations are provided in
different libraries then, IMO, they should implement a common interface,
be typed with that interface inside any program that cared to use them
interchangeably, and in such programs be instantiated reflectively. The
specific class name to use need not appear in the source at all -- the
most flexible approach would put it in a configuration file for the
application, or possibly read it from a system property defined at JVM
startup. There is then no need for conditional compilation and, IMO,
the situation is rather clearer (if a bit more complex).


John Bollinger
(e-mail address removed)

 

[Graham Matthews]

It is not portable in the sense of compiling, running should be no
problem. And all you need are the MOX jars on you developping machine.
I have jmx-libraries for linux, sunos and windows
on my machine which are referenced in my setup code, its no problem to
compile again them on linux. So where is the problem ?

Try compiling the above code on a non OS-X platform. It will complain
that it can't find classes referenced in the "use_an_apple_extension"
bit.

Now if I could copy the Apple extension jars to my other platforms
then I could compile, but I can't.

graham

 

[Graham Matthews]

I can see why you would want conditional compilation in this case, but I
dislike the general approach. If implementations are provided in
different libraries then, IMO, they should implement a common interface,

That's all good and well if you own the libraries in question and have
source for them. If not this interfce approach doesnt work.

graham

 

[Graham Matthews]

: Having this code compile is only 1/2 the problem. The real
: problem is that this code may reference libraries that only
: exist on certain platforms. An example,

: if(running_Mac_OS_X)
: {
: use_an_apple_extension_jar
: }

: This code is now no longer portable to platforms which
: dont have the apple extension jar, EVEN if the running_Mac_OS_X
: flag is false.

If you do that in Java you're well advised to put the platform-specific
code in entire separate classes.

That doesn't help. I still can't compile the given class on any platform
that doesn't have the apple jar file (and as far as I know I am not
allowed to go copying this apple jar file around to other platforms).

graham

 

[Graham Matthews]

The proper solution would be to design an interface
that abstracts from the apple specific stuff and program
to that interface. You would then have completely portable
code.

The interface implementation for the different OS's would
still have to be provided - as a separate product.

Isn't this how it works with other pluggable things,
like XML parsers etc.?

What happens if I don't have the source for this library.
I just have the jar file, so I can't change the code in it to
implement some new fangled interface.

graham

 

[P A Hill]

That's all good and well if you own the libraries in question and have
source for them. If not this interfce approach doesnt work.

Facade Pattern

-Paul

 

[brougham3]

That's all good and well if you own the libraries in question and have
source for them. If not this interfce approach doesnt work.

If you don't own the libraries, I'd suggest using an adapter class that you
do own. Then, you're not quite so dependent on 3rd party libraries.

 

[Jon A. Cruz]

What happens if I don't have the source for this library.
I just have the jar file, so I can't change the code in it to
implement some new fangled interface.

No,
but as others have pointed out, you can make a thin wrapper class that
implements your interface. And you can use reflection to load it so as
to prevent class-loading problems.

 

[Jon A. Cruz]

Try compiling the above code on a non OS-X platform. It will complain
that it can't find classes referenced in the "use_an_apple_extension"
bit.

Which is why I prefer conditional *loading*.

And the aforementioned stub library solves your compilation problem.

I do it all the time.

 

[Tor Iver Wilhelmsen]

Try compiling the above code on a non OS-X platform. It will complain
that it can't find classes referenced in the "use_an_apple_extension"
bit.

Unless it's a lot of code, use reflection (though you lose the
compile-time checks). Or invoke a class you compile once on the Mac
and ship as a .class for inclusion when building later.