Conditional compiling

[Suma Shanbhog]

Hello,

In JAVA I had to implement something like conditional compiling.
I had earlier posted on this issue and got answers that it is not possible.

But now, a friend of mine suggested this:

class A{

public static final bool bDebug = true;

if(bDebug)
{
//do something
}
else
{
//do something else
}

}

But my argument was that the code in both if and else will be compiled.
But he says that as the bool variabel is "final"...., teh compiler know
whether it has to compile the if or the else.
So, does this serve the purpose of conditional compiling in the true sense?

Is that right?

Thanks in advance!

Suma

 

[Manish Pandit]

Not sure if this counts as conditional compiling. Internally, the code
that will be compiled will be :

public static final bool bDebug = true;

//do something <-- this is the if(bDebug) part.

Your if/else will not even make it to the bytecode, because the
condition evaluation is not tied to any *runtime value* - it is a
'constant'.

However, if you'd have something like

public static final SomeObject o = new SomeObject(a,b,c);

if (o.getA() == -1) {

//do something

} else {

//do something

}

This conditional statement will make it to the bytecode, as even though
the object reference is 'final', you can still modify the object. (vs.
basic java types).

Hope this helps!

-cheers,
Manish

 

[Suma Shanbhog]

Yeah I realised that the if/else part will not go into byte code...but the
contents of the if block will defenitely go....but my question was will else
part also be included in bytecode?
from your answer I deduced that it will not.

This is a workaround for the #ifdef in JAVA.
So, this may serve the purpose.

Thanks!
Suma

 

[Nick Vatamaniuc]

If you really need conditional compilation, you can try and use the C
preprocessor with Java. Just make sure to give it flag to not check any
syntax, just to expand the macros.

 

[Chris Uppal]

public static final bool bDebug = true;

if(bDebug)
{
//do something
}
else
{
//do something else
}

Since bDebug (horrible use of type-prefixes -- try to get out of that habit) is
declared final, and is initialised to a compile-time constant, the compiler is
/required/ by the language spec to treat the code as if you had written:

if (true)
{
//do something
}
else
{
//do something else
}

so your friend is right as far as that goes. However, the code in the else
branch still has to be syntactically and semantically valid (it can't refer to
not-yet-written classes for instance), or the compiler will reject it, so in
that sense it's not like conditional compilation in C. Also, as far as I know,
there is no formal specification for whether the compiler will eliminate the
unreachable code from its output. I believe that Sun's recent Java compilers
/do/ eliminate that code, but it's not something that's guaranteed. I,
personally, would be reluctant to depend on that behaviour unless either (a) it
didn't matter much, or (b) I had some way of checking the output as part of my
build/test procedures.

-- chris

 

[Peter Van Weert]

Manish Pandit schreef:

Not sure if this counts as conditional compiling. Internally, the code
that will be compiled will be :

public static final bool bDebug = true;

//do something <-- this is the if(bDebug) part.

Your if/else will not even make it to the bytecode, because the
condition evaluation is not tied to any *runtime value* - it is a
'constant'.

However, if you'd have something like

public static final SomeObject o = new SomeObject(a,b,c);

if (o.getA() == -1) {

//do something

} else {

//do something

}

This conditional statement will make it to the bytecode, as even though
the object reference is 'final', you can still modify the object. (vs.
basic java types).

Hope this helps!

-cheers,
Manish

http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html might be of
use here?

 

[Brandon McCombs]

Since bDebug (horrible use of type-prefixes -- try to get out of that habit) is

So you don't agree with Hungarian notation? What do you use then?

 

[Lew]

So you don't agree with Hungarian notation? What do you use then?

Hungarian notation runs counter to a basic tenet of object-oriented
programming, to hide implementation. What if a boolean became a wider
selector, e.g., the designer decided to add debug levels instead of a simple
switch? Hungarian notation forces once to choose between modifying the code to

public static final int bDebug = 1;
// 0 means not to debug, 2 means extra-verbose

in which case the 'b' is misleading, or to change the name of the public
variable to

public static final iDebug = 1;

then to modify all references to it accordingly.

The problem is that the name is tightly coupled to the implementation.

Better would be just to name the variable for its logical purpose, e.g,

public static final boolean debug = true;

This is similar to declaring variable by their interface type rather than by
their implementation type, as in

List <SomeType> list = new ArrayList <SomeType> ();

so that the usage is decoupled from the implementation specifics.

The real question is what benefit Hungarian notation even offered in the first
place. If you agree that it never really offered any benefit, then there is
no question of what to "use then". (To do what, increase coupling? Decrease
maintainability? Make the code harder to read? There are plenty of options
besides Hungarian notation to achieve those goals.)

- Lew

 

[Lew]

public static final iDebug = 1;

Oops,
public static final int iDebug = 1;

 

[Tor Iver Wilhelmsen]

So you don't agree with Hungarian notation? What do you use then?

Type information provided by the code-analyzing IDE - that, and
documentation. I reckon that I never will be in a situation where I
need to read or write changes to that code without access to an IDE.

 

[Chris Uppal]

Brandon McCombs wrote:

[me:]

So you don't agree with Hungarian notation? What do you use then?

If you are asking how I indicate the type of value to be held in a variable,
then -- beyond the fact that a well-named variable will normally indicate that
simply by virtue of having a good name -- I don't.

Broadening the question a little. I /strongly/ object to any kind of
decoration applied to local variable names -- they are the most used and the
most read, and anything which detracts from their readability is
counterproductive.

I /do/ like to use decoration to make instance and static fields stand out as
such (prefixes "s_" or "m_" for static and instance fields respectively); but
note several things:

1) Even that is fairly unpopular among Java programmers.

2) It is only a fix for a not-very-clear aspect of Java's syntax; and with
improving IDEs and with the use of those IDEs becoming more universal, the
value of that fix is reducing all the time.

3) It is /in no way/ acceptable to allow the decoration to be confused with the
name itself. The underscore is NOT an optional extra ! ;-)

-- chris

 

[Andy Dingley]

So you don't agree with Hungarian notation? What do you use then?

Hungarian is a bodge that's better than writing naked C++ without it
was 15-20 years ago. These days we have better options, such as IDEs
that are smart enough to _understand_ what they're editing, at least to
the level of types.