>>> In my real program I have added lots of System.out.println's from
>>
[quoted text clipped - 6 lines]
> when not run from an IDE or command shell) - is there any major problem
> if they're left in?
Only the drag on performance - println() is invoked regardless of need.
Logging libraries are optimized for minimal impact on production performance.
>> There are many reasons not to use System.out for debug or trace purposes.
>
> I'd be interested in reading your list of those reasons.
The performance reason, ibid. Not having the output stream cluttered with
trace statements.
>> Why not using logging?
>
> I can't answer for the OP, but in my case it went like this:
>
> - System.out.println() works
> - it needs no special classes/jars bundled with your app.
Specious.
> - it needs no complex XML config files
Neither does log4j.
> - it needs no class instantiation/initialisation
Neither does log4j unless you need the flexibility.
> - it is just as easy to make conditional
No, it isn't. The conditions add complexity to your code, instead of being
hidden inside the logging aspect.
> - it is just as easy to comment-out or remove using search/replace
Which is a source code change, much harder than not changing source code.
Logging wins, since it doesn't need any code change, not commenting out nor
removal via search/replace.
> - Logging classes seem like they're oriented to making complex
> logging needs possible. Few of them make simple jobs simple.
I have no idea how you came up with this. Logging libraries are dog-simple to
use, about as complex as:
Logger logger = Logger.getLogger( getClass() );
...
logger.error( msg );
> - There's too many to choose from. Writing System.out.println()
> a few dozen times takes a lot less gumption than studying a
> half dozen logging classes and choosing one then using it.
I cannot believe you are touting ignorance as an excuse. Pathetic.
Logging takes all of five minutes to learn. Arguing that you are too lazy to
learn it is not an indictment of the logging library but of the practitioner.
> For my limited needs I preferred to reinvent the logging wheel myself,
> though I did feel properly guilty about it :-) I ended up with something
> I could control by environment variables or command line params, which
> could be used statically without configuration files or instantiation,
> which could have logging levels set programatically if needed, and which
> did the right thing in the absence of any configuration.
I don't see how any of that differs from, say, log4j.
> It goes without saying that it does a lot less than the more developed
> logging classes. But I like that it's as easy to use as
> System.out.println().
I like logging, which is as easy to use as "logger.error( msg )" and doesn't
require re-compilation to remove them,
> I still use System.out.println() for simple programs.
>
> I'm open to persuasion, so I'm interested to hear more details of the
> evils of System.out.println().
Go to, say, the Apache logging page for that. They lay the argument out
better than I can.
You should actually learn to use, say, log4j, before you pass judgment. By
admitting that you haven't learned either that nor java.util.logging, you
admit that you do not have a basis for your judgment.
Try it, you'll like it.

Signature
Lew
RedGrittyBrick - 28 May 2007 21:37 GMT
>> - System.out.println() works
>> - it needs no special classes/jars bundled with your app.
>
> Specious.
>> - it needs no class instantiation/initialisation
>
> Neither does log4j unless you need the flexibility.
All the examples I've seen seem to involve something like
`static Logger logger = Logger.getLogger(test.class);`
>> - Logging classes seem like they're oriented to making complex
>> logging needs possible. Few of them make simple jobs simple.
[quoted text clipped - 5 lines]
> ...
> logger.error( msg );
Can you just invoke methods statically like
Logger.error(msg);
>> - There's too many to choose from. Writing System.out.println()
>> a few dozen times takes a lot less gumption than studying a
>> half dozen logging classes and choosing one then using it.
>
> I cannot believe you are touting ignorance as an excuse.
I didn't think I was :-)
Actually its a problem I've encountered more than once with Java. A
recent example: I have a web-service written in Perl and wanted to test
access to the service from Perl, C# and Java. I'd a little experience of
Perl and Java but none of C#.
With Perl, THE way to do web services is to use SOAP::Lite. No need to
research lots of options. A SOAP::Lite test client can be written in
under a dozen lines of code.
With C#, I'd not written a line of C# before, but I downloaded Mono,
read http://www.mono-project.com/Web_Services, wrote a dozen lines of C#
and typed four commands and had a working client within an hour. I
didn't have to research several toolkits and choose one.
With Java I've spent hours Googling and reading reviews and tutorials
for what seemed like dozens of web-services toolkits. Most of it seemed
ten times as much work as Perl or C#. It was hard to work out what was
obsolete stuff and what was 'standard' for Java 6. I downloaded the
latest Eclipse Web-Tools Platform and tried to generate a stub class
from the WSDL but had problems. In the end I used the rather nasty
approach suggested in
http://www.ibm.com/developerworks/xml/library/x-soapcl/ which I
supplemented with a SAX parser, simply in order to avoid spending too
much time learning something which was somewhat peripheral to the project.
> Pathetic.
Cruel bastard ;-)
> Logging takes all of five minutes to learn.
I spent hours trying to find out what logging classes were available,
which were widely used and whether any were a standard part of JRE 1.5.
> You should actually learn to use, say, log4j, before you pass judgment.
> By admitting that you haven't learned either that nor java.util.logging,
> you admit that you do not have a basis for your judgment.
>
> Try it, you'll like it.
I will try it, but I suspect I'll probably still use
System.out.println() in small programs (one or two classes, < 200 LOC).
Appendix A:
Complete Perl web-services client
#!perl
use strict;
use warnings;
use SOAP::Lite;
print SOAP::Lite
->proxy('http://example.com/service')
->uri('Widgets')
->getWidgetDescription('Foo');
Complete C# web-services client (excluding stub generated from WSDL)
using System;
class GetWidgetDescription {
public static void Main(string [] args) {
WidgetService service = new WidgetService();
Console.WriteLine(service.getWidgetDescription("Foo"));
}
}
My real service returned arrays of objects but that didn't add
significantly to the time taken to produce working Perl or C# clients
with which to test the service.
Doubtless a Java client *can* be just as concise and easy to learn but
the above were almost straight from the first tutorials I found. I've
not found a simple Java tutorial that only uses classes that are part of
the standard JRE.
Lew - 29 May 2007 02:12 GMT
Lew wrote:
>> Pathetic.
> Cruel bastard ;-)
Sorry. Intended only for rhetorical effect. All feelings hurt in this
newsgroup are the sole responsibility of the reader, blah blah blah.
>> Logging takes all of five minutes to learn.
> I spent hours trying to find out what logging classes were available,
> which were widely used and whether any were a standard part of JRE 1.5.
Actually, this is a common problem with Java, all right. I found that log4j
was very simple, adapted well to learning a little at a time, and relieved me
of all worries about re-instrumenting for production. I therefore ignored all
the other choices.
>> You should actually learn to use, say, log4j, before you pass
>> judgment. Try it, you'll like it.
> I will try it, but I suspect I'll probably still use
> System.out.println() in small programs (one or two classes, < 200 LOC).
Or maybe you won't like it. It took me a few projects to even bother to set
up a log4j.properties for a project. Its simplest uses did enough for a
while, at least as much as println() and with much less footprint.
> Doubtless a Java client *can* be just as concise and easy to learn but
> the above were almost straight from the first tutorials I found. I've
> not found a simple Java tutorial that only uses classes that are part of
> the standard JRE.
It's a fair cop. Java can be a real beast.

Signature
Lew