aspose file tools*
The moose likes Beginning Java and the fly likes Want to remove debug information Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Want to remove debug information " Watch "Want to remove debug information " New topic
Author

Want to remove debug information

George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Hello everyone,


I am wondering how to remove debug information (for example, System.out or System.err) automatically when I build/compile a Java project? Does Java compiler or build tool has such options when we build/compile a Java application?


Thanks in advance,
George
Lionel Badiou
Ranch Hand

Joined: Jan 06, 2005
Posts: 140
Hi George,

You can easily use conditionnal compilation with Java. Here's a sample :



Once your code is correct, set DEBUG constant to false. You may check your .class files to verify that no code relative to a "if (DEBUG)" clause is included.

Regards,


Lionel Badiou
CodeFutures Software
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Another alternative is to use a logging framework. Have a look at log4j or Java's own logging stuff in java.util.logging.*.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Lionel Badiou
Ranch Hand

Joined: Jan 06, 2005
Posts: 140
Hi again

I totally agree with Paul, you might consider using assertions or logging framework for professionnal projects.

Nevertheless, you should be aware that the only mean to remove (not just to ignore) debug code from .class file is the conditionnal compilation trick I have described.

Best regards to each of you,
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Which isn't conditional compilation at all as it require a sourcecode change to take effect!

It also depends on compiler implementation (another compiler may well decide not to inline the constant and may thus not even notice it can skip the code for example) which makes matters worse.

Another reason you're not going to want to remove debug information at all is that problems usually pop up only after you start deploying the application to customers at which point having the debugging logs available can be a big help.
Being able to enable and disable logging by simply changing a setting in a configuration file or a commandline option can save you a LOT of time.
[ January 17, 2005: Message edited by: Jeroen Wenting ]

42
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Lionel,


Originally posted by Lionel Badiou:
Hi George,

You can easily use conditionnal compilation with Java. Here's a sample :



Once your code is correct, set DEBUG constant to false. You may check your .class files to verify that no code relative to a "if (DEBUG)" clause is included.

Regards,


Your reply is very helpful. I am wondering why .class files do not include code relative to a "if (DEBUG)" clause if I set DEBUG to false. I think if and only if Java compiler can make sure that the value of variable DEBUG does not change, it can exlude code relative to a "if (DEBUG)" clause when compiling. Am I correct? Can you provide more detailed information?


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Paul,


Originally posted by Paul Sturrock:
Another alternative is to use a logging framework. Have a look at log4j or Java's own logging stuff in java.util.logging.*.


I can not use java.util.logging since I am using JDK 1.3 but java.util.logging can only be used with JDK version >= 1.4.

The resource you recommended is very helpful. If I can not use 3rd party libraries in my application, are there any other approaches to remove debug information?


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Lionel,


Originally posted by Lionel Badiou:
Hi again

I totally agree with Paul, you might consider using assertions or logging framework for professionnal projects.

Nevertheless, you should be aware that the only mean to remove (not just to ignore) debug code from .class file is the conditionnal compilation trick I have described.

Best regards to each of you,


I am very interested in the assertions technology you mentioned. Can you provide more resources on this topic? I am still very interested in the conditional compilation trick you have described, and it is highly appreciate if you could provide more detailed descriptions.


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Jeroen,


Originally posted by Jeroen Wenting:
Which isn't conditional compilation at all as it require a sourcecode change to take effect!

It also depends on compiler implementation (another compiler may well decide not to inline the constant and may thus not even notice it can skip the code for example) which makes matters worse.

Another reason you're not going to want to remove debug information at all is that problems usually pop up only after you start deploying the application to customers at which point having the debugging logs available can be a big help.
Being able to enable and disable logging by simply changing a setting in a configuration file or a commandline option can save you a LOT of time.

[ January 17, 2005: Message edited by: Jeroen Wenting ]


Your reply is very helpful and I agree with you. You are an expert.


regards,
George
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1824

Originally posted by George Java:
I am very interested in the assertions technology you mentioned. Can you provide more resources on this topic? I am still very interested in the conditional compilation trick you have described, and it is highly appreciate if you could provide more detailed descriptions.


Assertions is only avaliable JDK >= 1.4, so they will not be able to help you. You can still learn about them, of course, from this site

Conditional compiling is a little trick provided by SUN's javac compiler (and possibly by other compilers as well, but as Jeroen stated, that's not a given...) where any code enclosed in an if{false} block will not be included in the compile. Note that the false doesn't have to be th eliteral false, but it does have to be something that can be resolved at compile time, like static final boolean DEBUG.

Thus, if you have the code:


If you compare the compiled version of that to a compiled version where DEBUG = false, you would see that the entire if{DEBUG} block has been removed from the class -- not just the runtime logic.

Note that while(false) will throw a compile-time error, concerning unreachable code:


Anyway, if you can't use third-party software, it's really simple to write your own rudimentary logger:



Then you call Logger.logMessage("blah blah blah") instead of System.out.println("blah blah blah")


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1824

BTW, welcome to JavaRanch, George Java! I hope we've been helpful. I would like to point out, however, that your display name violates our Naming Policy (We are looking for names that are not obviously fake...) You can change your diplay name here
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by George Java:
...Your reply is very helpful. I am wondering why .class files do not include code relative to a "if (DEBUG)" clause if I set DEBUG to false. I think if and only if Java compiler can make sure that the value of variable DEBUG does not change, it can exlude code relative to a "if (DEBUG)" clause when compiling. Am I correct? Can you provide more detailed information?


regards,
George


Basically, that is correct. If the compiler is smart enough to see that the if statement will never be true, then it can remove it from the compiled .class file altogether. This is probably the primary reason that the "final" keyword is used when declaring the DEBUG variable. "final" tells the compiler that its value will never change.

Layne


Java API Documentation
The Java Tutorial
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Joel,


Originally posted by Joel McNary:
[QB]

If you compare the compiled version of that to a compiled version where DEBUG = false, you would see that the entire if{DEBUG} block has been removed from the class -- not just the runtime logic.


I think it is because the value of a final static variable can not be changed (like a constant variable), if it is set to false, the "if" block will not be included when the source codes are compiled. Am I correct?


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks for reminding, Joel.


Originally posted by Joel McNary:
BTW, welcome to JavaRanch, George Java! I hope we've been helpful. I would like to point out, however, that your display name violates our Naming Policy (We are looking for names that are not obviously fake...) You can change your diplay name here


I have changed my display name. Please check whether it is appropriate. If it is not, please feel free to contact me. I am a new user of JavaRanch, and I think I have many things to learn, both technical materials and how to use JavaRanch, how to communicate by JavaRanch, how to obey JavaRanch rules. I think you are a guru of this site, so if you think I need to improve something, please remind me.

Even if I am a newbie of this site, I can feel that there are so many experts here (including you). I hope I can learn more Java technical materials from them in the future.


regards,
George
George Lin
Ranch Hand

Joined: Jan 11, 2005
Posts: 125
Thanks Layne,


Originally posted by Layne Lund:


Basically, that is correct. If the compiler is smart enough to see that the if statement will never be true, then it can remove it from the compiled .class file altogether. This is probably the primary reason that the "final" keyword is used when declaring the DEBUG variable. "final" tells the compiler that its value will never change.

Layne


Your reply is just what I want.


regards,
George
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Want to remove debug information