• Post Reply Bookmark Topic Watch Topic
  • New Topic

preprocessor directives  RSS feed

 
Chandaka Fernando
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
It seems like java doesn't support pre-processor directives. Is there any other way of achieving the same thing.
eg. in C you migth include some debug code like this

can you do the same thing in java without any runtime overhead?
Thanks
Chandaka
[ August 06, 2003: Message edited by: Chandaka Fernando ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Code inside an if (b) where b is a constant "false" can be compiled out by the compiler, so yes, in a way.

Here's part of the disassembly. Note that main() contains nothing but a return statement:

Now, what you can't do is have a function like debugPrint() and call it and have the call compiled out, like you can do that with a debug macro in C. But if you don't mind writing the conditional right there in place, you're all set.
Java 1.4 now has an "assert" keyword; you can use it without any runtime overhead (except for space overhead, as they don't get compiled out, just switched on and off in the JVM) to do assertions.
 
Bhushan Jawle
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no direct way of doing that in Java. I remember reading an article on this, which mentiones that #IF stmts. were needed for portability purpose for most of the time. (between various OS) which I do agree with.
Most of the other requirements can be taken care by following different paradigms for s/w developemt.
I know the example you have given is just to make your dobu clear, but that issue (logging), can easily be addressed by using Log4j. Broader no. of issues can be sorted out by paradigms like AOP.
 
Richard Bailey
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you want a Java preprocessor for conditional compilation, check out http://www.rtbaileyphd.com/src/preprocessorwizard/PreprocessorWizard.html
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

Is that preprocessor the subject of your PhD?
 
Richard Bailey
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, I got my Phd in Aero/Astro at the time when keypunches & FORTRAN IV were still being used. I have written numerous code generators since then, including ones for FORTRAN, Ada, Perl, Java, and C. See also http://www.rtbaileyphd.com/perlwizard/ which is written in Java and generates Perl via a FreeMarker template. PreprocessorWizard http://www.rtbaileyphd.com/preprocessorwizard/ is written in Perl for generating Java (comments). I developed PreprocessorWizard to help with a current Java project which will result in two different applications being developed: one for instructors and one for students. The two apps will share a common set of features and I will be able to switch between building the two different jar files just by changing one line in a configuration file.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Long ago (last century, literally!) I was a C++ programmer. In 1998 my colleagues and I heard about this new cool thing called Java, so we started learning it. In the beginning we had lots of questions of the form "why does Java not have this or that feature from C++?". The question "why does Java not have a preprocessor like C++?" is one of those questions.

Nobody in Java-land uses a C++-style preprocessor, and nobody seems to really miss the C++ preprocessor (except maybe people who are C++ programmers and who are not used to program in Java).

I've never missed the C++ preprocessor when programming in Java and I would not like it at all if I would encounter a project where such a thing was used. It makes the source code very messy and hard to read and makes the build process so much more complicated (because you have to know exactly what to define etc.).

In C or C++, the preprocessor is often used to define platform-specific things. For example "#ifdef WIN32", or "#ifdef LINUX", etc. You don't need that in Java because Java is platform-independent.
Richard Bailey wrote:The two apps will share a common set of features and I will be able to switch between building the two different jar files just by changing one line in a configuration file.

It would be much better to extract the common functionality into a library and then write two separate applications that use the library, instead of having two different applications with their source code completely woven together.
 
Richard Bailey
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not really possible to extract the common functionality into a library. The reason is that much of the common functionality is the GUI and the GUI code is autogenerated by the Matisse GUI builder in NetBeans. One cannot touch that code. It really is very much easier just to change one line in a configuration file and thereby specify which version of the app is to be built.

When one uses the C preprocessor, it is true that the code can get very messy and hard to read. But a WYSIWYG preprocessor solves that problem. See the example at http://www.rtbaileyphd.com/preprocessorwizard/ It is very easy to spot what is active vs. inactive.

I always put debug code in my apps and wrap this code in instead of in In fact there is quite a bit of it. I don't want that code appearing in the production bytecode. It just bloats the code and reveals too much to a hacker who decompiles the jar file. I do not want to eliminate the debug code because I may want to reactivate it in the future.

If you have a freeware version and a Pro version, you would not want a hacker being able to activate the Pro features by decompiling and hacking the freeware version. A WYSIWYG preprocessor solves that problem because the deactivated Pro parts of the app become comments and the comments are not compiled into the bytecode.

The build process for me is greatly simplified. By changing one line in a config file, I can get the jar file to be produced in a different directory under a different name. That is because I run the preprocessor on my NetBeans project.properties file as well as on the *.java files. The preprocessor is called by the Ant build script, so the reconfiguring is completely automatic.

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!