Quoc Truong wrote:
> Hi-
>
> I am writing Java code that need to be compiled into two different
> byte code: one used native methods and the other normal.
>
> In C++, I can use #ifdef to solve this problem. But in Java, I
> can't seem to find any way except creating two separate codes.
Ha, ha, ha,....
The closest I can think is:
String env = System.getProperty("IFDEF");
if (env.equals("YES") {
// do this.
} else // "NO"
// do that.
}
When you compile your *.java do the same as cc or c++
javac -DIFDEF=YES yourCode.java
In *.c or *.C you may have:
cc -DIFDEF=YES -o yourCode yourCode.c
May someone out there can think a better way than I am!
--
Raymond Chui
Dept. of Commerce, NTIA
14 th & Constitution Ave., Rm 6888
Washington, DC 20230
202-482-2987
rc...@ntia.doc.gov
> Hi-
>
> I am writing Java code that need to be compiled into two different
> byte code: one used native methods and the other normal.
>
> In C++, I can use #ifdef to solve this problem. But in Java, I
> can't seem to find any way except creating two separate codes.
>
> Is there any equivalent to the #ifdef in C++?
>
> Thanks.
There is an equivalent. In order to define "ifdef" in java, you have
to define const
variable in one of your classes (i.e. an public final static int
variable). Note that the compiler don't treat this variable as class
members.
Now, in order to protect a code , define the flowing :
class Foo {
public final static boolean MY_IF_DEF = false;
public void myMethod () {
if (MY_IF_DEF ) {
.... // this is the ifdef code block
}
In the example above, if My_IF_DEF is false, the java compiler won't
generate any byte code for the code inside the block.
Bye
Tomer Meshorer
Comverse Israel
if can say
if (def)
{
...
}
if the value of def is known at compile time, the IF will disappear leaving
just the body or nothing but a Chesire smile. This optimisation is
guaranteed.
For the JAVA GLOSSARY and the CMP Utilities: http://oberon.ark.com/~roedy
--
Roedy Green Roedy rhymes with Cody ro...@bix.com ICQ:5144242
Canadian Mind Products contract programming (250) 285-2954
POB 707 Quathiaski Cove Quadra Island BC Canada V0P 1N0
-30-
> Is there any equivalent to the #ifdef in C++?
Use a constant expression:
private static final boolean NATIVE = true;
void method()
{
if(NATIVE)
{
...
}
else
{
...
}
}
The compiler recognizes that NATIVE is constant and creates only that
branch of the "if" statement which is actually executed.
--
Stefan Zeiger <szeiger{AT}usa{DOT}net> NEW: Novocode Toolkit Preview Release
http://home.pages.de/~szeiger/ http://pweb.uunet.de/novocode.ab/prod/tk/
=o= Java (and C++ for that matter) are designed so that you can
approach the problem differently, and reuse work. The way I'd
deal with the above problem is to create a superclass (or maybe
an interface), then create two subclasses, one using native
methods and the other normal.
<_Jym_>
> There is an equivalent. In order to define "ifdef" in java, you have
>
> to define const
> variable in one of your classes (i.e. an public final static int
> variable). Note that the compiler don't treat this variable as class
> members.
>
> Now, in order to protect a code , define the flowing :
>
> class Foo {
>
> public final static boolean MY_IF_DEF = false;
>
> public void myMethod () {
> if (MY_IF_DEF ) {
>
> .... // this is the ifdef code block
> }
>
I read 4 answers to the original question which sounded like this.
I'm affraid they are all "wrong" (sorry)
I don't think there's an equivalent to the #ifdef construction in Java.
All the solutions can't switch a whole method or class !
Also the code between #ifdef and #end may be complete garbage in C.
I'm not sure about Java, but I read somewhere on the net that Java tries
to compile everything, also after if (0).
Hans Pattenier
Wrong is perhaps too strong a word. The people answered with the nearest
equivalent in Java, which is the practical answer to the question. You are
quite right that Java does not not have an Ifdef suitable for turning off
entire methods or classes. You have to use /* */ comments and make sure
none are used in the method.
Hans Pattenier wrote in message
<34C33A23...@Medicine.LeidenUniv.nl>...
>Tomer sagie wrote:
>
>> There is an equivalent. In order to define "ifdef" in java, you have
....
>> public final static boolean MY_IF_DEF = false;
>>
>> public void myMethod () {
>> if (MY_IF_DEF ) {
>>
>> .... // this is the ifdef code block
>> }
>>
>
>I read 4 answers to the original question which sounded like this.
>I'm affraid they are all "wrong" (sorry)
1. Would you kindly be so eloquent as to provide substantial evidence in the
form of an example where a #ifdef could not be adequately handled by contant
'if' statements as per the above.
2. Could you please provide a compelling case for requiring garbage code
inside one of the #ifdef branches.
If you can't, your argument is no better than "You can't do printf("%d", x)
in Java, because the Java method is called 'println'", or something else
equally facile.
Regards
Roland
#if some condition is true,
Then define the return type of a function to be T, otherwise T'.
#if some condition
then import class X instead of class Y.
--
* Matthew B. Kennel/Institute for Nonlinear Science, UCSD
*
* Quoth the X Consortium: "Mechanism Not Policy"
*
* Translated: "Once ze windows go up, who cares why push MouseDown. That's
* not my department!" says Wehrner von Braun.
> 1. Would you kindly be so eloquent as to provide substantial evidence
> in the
> form of an example where a #ifdef could not be adequately handled by
> contant
> 'if' statements as per the above.
There's already a reply by s.o. else on this question. I agree
> 2. Could you please provide a compelling case for requiring garbage
> code
> inside one of the #ifdef branches.
1) Suppose you need functions in Java, and you allready have those
functions in C++
Copy those functions in your Java file and manually adapt them to
the Java syntax (and semantics)
During this process I might want to try out the partially converted
file, even when it's just to
see if the changes I made can be compiled. Then I'd want to be able
to ignore the code I
haven't changed yet.
2) Sometimes I make stupid mistakes. Sometimes the Java books contain
stupid mistakes.
Sometimes JDK contains bugs.
Anyhow, sometimes I would like to be able to disable a certain
method and enable a similar
method (same signature) just for debuggin purposes.
I don't know if these cases are compelling enough, but you might get the
idea.
And please don't misunderstand me. I'm not suggesting that Java sucks
because it has no #ifdef.
Actually I like Java a lot. Even more : I once had to debug 3rd party
software written in C
and I got sick of the enormous amounts of nested #ifdef constructions.
As #ifdef constructions
are not indented, it was a crime to find out if the part of code I was
looking at, would really be
executed at all.
Cheers,
Hans Pattenier
>Is there any equivalent to the #ifdef in C++?
Yes: #ifdef. :-)
(Noone prevents you from writing C pre-processor macros and statements
in your Java code, then run it through cpp or equivalent before
compiling the result. However, Java does not come with any
preprocessor, unlike C and C++ compilers, which depend on it.
However: Be aware that by introducing macros you effectively make your
code less maintainable - try as much as possible to avoid the stupid C
pre-processor. Look into alternative macro packages if possible.)
--
"In practical terms, borders are little more than lines on a map."
- FAO lady, "The X-Files"
to...@online.no http://www.pvv.org/%7etoriver/
Matt Kennel wrote in message ...
>:
>:1. Would you kindly be so eloquent as to provide substantial evidence in
the
>:form of an example where a #ifdef could not be adequately handled by
contant
>:'if' statements as per the above.
>
>#if some condition is true,
>
>Then define the return type of a function to be T, otherwise T'.
>
>#if some condition
>
>then import class X instead of class Y.
Have you heard of interfaces?
Not abstract superclasses, they're less mobile.
Write modular code, won't you.
>> 2. Could you please provide a compelling case for requiring garbage
>> code
>> inside one of the #ifdef branches.
>
>1) Suppose you need functions in Java, and you allready have those
>functions in C++
You're copying them already, so don't.
>2) Sometimes I make stupid mistakes. Sometimes the Java books contain
>stupid mistakes.
> Sometimes JDK contains bugs.
> I would like to be able to disable a certain method and enable a
similar
> method (same signature) just for debugging purposes.
This is all adequately covered by constant conditionals.
Regards
Roland
>Wrong is perhaps too strong a word. The people answered with the nearest
>equivalent in Java, which is the practical answer to the question. You are
>quite right that Java does not not have an Ifdef suitable for turning off
>entire methods or classes. You have to use /* */ comments and make sure
>none are used in the method.
This only works in certain contexts and I don't think it solves
the original poster's issue.
Well since #ifdef is a preprocessor directive and not part of the
C++ language, why not use the preprocessor?
public class X
{
#ifdef SUN
public String getName() { return "Krusty"; }
#endif
#ifdef MSWINDOWS
public native String getName();
#endif
}
You could then modify your makefile to preprocess your source
files before the java compiler is invoked.
Anytime you want conditional compilation. There
is no language support in Java (nor C++ or C, for
that matter) for this. Hence we use a pre-processor.
> 2. Could you please provide a compelling case for requiring garbage code
>inside one of the #ifdef branches.
>
>If you can't, your argument is no better than "You can't do printf("%d", x)
>in Java, because the Java method is called 'println'", or something else
>equally facile.
Is this some kind of perverse self-@deprecating humour?
Good grief... that makes no sense. Using interfaces
won't work for the signatures, because it will simply
make both requisite (which will be a compile-time
error if the signatures are the same except return
type). If I want to substitute a release class X
with a debug class X, what on earth do interfaces have
to do with it? We're talking about configuration
management of the executable.
Why are you getting into an argument when it seems
that you are misunderstanding the question?
>
>Not abstract superclasses, they're less mobile.
mobile?? Huh?
>Write modular code, won't you.
Um.... thanks for the tip.
>>> 2. Could you please provide a compelling case for requiring garbage
>>> code
>>> inside one of the #ifdef branches.
>>
>>1) Suppose you need functions in Java, and you allready have those
>>functions in C++
>
>You're copying them already, so don't.
Them? Copying? Is it just me or ....?
>
>Regards
>Roland
>
Mike regards Roland with a skeptical eye...
I think this is the best OO solution suggested yet.
Mike Whiten wrote in message ...
>>>#if some condition is true,
>>>
>>>Then define the return type of a function to be T, otherwise T'.
>>>
>>>#if some condition
>>>
>>>then import class X instead of class Y.
>>
>>
>>Have you heard of interfaces?
>
> Good grief... that makes no sense. Using interfaces
> won't work for the signatures, because it will simply
> make both requisite (which will be a compile-time
> error if the signatures are the same except return
> type). If I want to substitute a release class X
> with a debug class X, what on earth do interfaces have
> to do with it? We're talking about configuration
> management of the executable.
In my inimitable and deeply winning style:
1) Kindly explain why the release class and debug class won't export the
same interface. If they don't, you're going to have to change the rest of
your code, anyway, and you're f」%^」$%^'ed. Makes sense to me.
2) Your quibble about signatures is only valid for primitive types. It would
be better, in this special case, to wrap them in a class encapsulating
platform differences.
> Why are you getting into an argument when it seems
> that you are misunderstanding the question?
Keep this thread and revisit it in a few years' time.
>>Not abstract superclasses, they're less mobile.
> mobile?? Huh?
Yet another example of my keen sense of analogy.
>>>
>>>1) Suppose you need functions in Java, and you allready have those
>>>functions in C++
>>
>>You're copying them already, so don't.
>
> Them? Copying? Is it just me or ....?
Them relates to the subject of the immediately preceding sentence, i.e. the
functions (in C++). I failed to appreciate the subtleties of copying C++
code into a Java program, then attempting to disable it through #ifdef. My
startlingly insightful solution: don't copy the code if you're not going to
use it. I must admit, I didn't give the matter deep consideration.
Sceptical Roland
Actually I was just bored and this was the first usenet article that caught
my eye.
Mike Whiten wrote in message ...
>Roland PJ Pipex Account wrote:
>>
>>Hans Pattenier wrote in message
>><34C33A23...@Medicine.LeidenUniv.nl>...
>>>Tomer sagie wrote:
>>>
>>
>>1. Would you kindly be so eloquent as to provide substantial evidence in
the
>>form of an example where a #ifdef could not be adequately handled by
contant
>>'if' statements as per the above.
>
> Anytime you want conditional compilation. There
> is no language support in Java (nor C++ or C, for
> that matter) for this. Hence we use a pre-processor.
Would you kindly be so eloquent as to provide substantial evidence in the
form of an example where a #ifdef could not be adequately handled by contant
if' statements as per the above.
> Is this some kind of perverse self-@deprecating humour?
Only the truly deprecatory can be truly self-deprecating.
Roland
> >2) Sometimes I make stupid mistakes. Sometimes the Java books contain
>
> > stupid mistakes. Sometimes JDK contains bugs.
> > I would like to be able to disable a certain method and enable a
> > method (same signature) just for debugging purposes.
>
> This is all adequately covered by constant conditionals.
Not if the code contains syntax errors!
Hans Pattenier
this really is not equivalent. the parser (jdk 1.1.5) will attempt
to parse the code in your "ifdef block". this is not the way it
works in C. in C, ifdef, define, etc., are preprocessor directives--if
you ifdef out a piece of code it is removed by the preprocessor
before it ever gets to the compiler. i do not think there is a real
analog in java.
--steve
I would like it if Javac and Java used an SC.INI file rather than relying
on platform dependent SET statements.
One thing you could put in such a file is the list of preprocessors you
want run. That way the compiler can be smart enough to run the
preprocessor and compiler as needed using its make/dependency logic.
:>Would you kindly be so eloquent as to provide substantial evidence in the
:>form of an example where a #ifdef could not be adequately handled by contant
:>if' statements as per the above.
Constant if statements are only effective for removing code that would legally
compile if the if statement were true. Among other things, this means that
method prototypes and class declarations can't be included (other than inner
classes), and all { or } must be matched. This does somewhat limit the
flexibility of the construction...
--
Craig West Ph: (905) 821-8300 | It's not a bug,
Pulse Microsystems Fx: (905) 821-7331 | It's a feature...
2660 Meadowvale Blvd, Unit #10 | acw...@echo-on.net
Mississauga, Ont., Canada L5N-6M6 | cr...@pulsemicro.com
> Well since #ifdef is a preprocessor directive and not part of the
> C++ language, why not use the preprocessor?
>