[odejava] why log4j?

[frdfsnlght]

Will, I assume you'll be reading this.

I seem to recall a post (but can't locate it now) about odejava using log4j. I never said anything then, but I am now. Why not just use the built in logging? It's yet another library I need to download and install now.

-Tab

[William Denniss]

I'm late on the logging scene - but I am of the understanding that log4j is superior.  It was created before the "inbuilt" logging and I believe was even offered to Sun to use.

The heirachical way log4j works, as well as being able to change settings in config files, code or java arguments is very nice.  To be honest I havn't compared it to Java's logging - I just used it as it seemed to be the industry standard, and I can say that I am a very happy log4j user and am using it in all my current projects now.

If you can present a really good reason to change I'll listen.  Just installing another .jar doesn't cut it for me, if the product is better

Will.

[frdfsnlght]

The built in Java logging can also be configured from a file and is also hierarchical. The API is very similar. Log4j's config file is xml, Java's is a properties file. As a result, Java's configs tend to be more compact.

I've used both systems professionally and made the decision that for all my own projects, I'll use the builtin stuff. The differences are so small for me, the fact that I have to have an extra jar file for log4j is a bother.

I'm not trying to start a huge debate here. You're free to use log4j on your own projects. My previous post probably came across as a little testy. It happened after a particlarly frustrating hour (early in the morning) of trying to get odejava to behave in a sensible manner (and failing), then getting the latest version from cvs (hoping maybe I was just hitting some bugs that had been fixed) and trying to build it, only to have the compile fail because I didn't have log4j.

-Tab

Games published by our own members! Check 'em out!

[William Denniss]

can you post a code snippet of what the logs statements look like?

I'll convert if Java's logging is as good, and if it's just a find/replace to change logging libraries.

I use .ini files for my log4j not xml anyway.

Will.

[William Denniss]

ok - two features I think are nice about log4j is that it can log stuff to syslog/MS Event log.  It appears Java Logging can't.  This would be very good for server stuff (think - odejava game engine server for eg.)

As I didn't compare the two libraries before using log4j - I did some reasearch.  From what I have read, it seems log4j is better.

reference:
http://www.ingrid.org/jajakarta/log4j/jakarta-log4j-1.1.3/docs/critique.html

Plus, you can use it for pre 1.4 (not an issue with Xith3D, but with other API's it may be).

It seems to me that log4j is the industry standard and for good reason.  I havn't really studied in depth however.

IMHO the small inconvenience of a wget on a .jar file into jre/ext is a pretty minor price to pay for a superior API if indeed it is superior.

Will.

[frdfsnlght]

Let me just say up front that I'm not making an argument to change the logging in odejava. I can't argue with log4j's extra features, though I've never used them.

But..., grabbing the log4j.jar file is just the beginning.

I prefer not to install libraries using Java's extension mechanism for the simple reason that it's too easy to forget they're not a standard part of the Java dist. I have my own lib directory I install this stuff into and that forces me to deal with the libs in my build.xml and startup scripts. That, in turn, better documents my app's dependencies. I've been bitten too many times to count by "publishing" an application only to have a user install it and not be able to run it because they don't have some component I've been taking for granted. Not only in Java, but Perl, C, etc. I prefer to force myself not to take third party libs for granted.

And even if I wasn't crazy as described in the previous paragraph, I'd have to remember to sign the log4j.jar and include it in the webstart config for my app since the average user will not have downloaded and installed, let alone even heard about, the extra library. Using my technique above doesn't change this, except that my ant build script now explicitly specifies the dependencies, and won't even compile my project without them, so I have a place to go to find them.

Of course, I also use Java3D, which is installed in Java's ext dir by default, which annoys me. That's another can of worms I won't get into now.

And of course all of this is getting dangerously close to the personal philosophies most programmers develop over time and like to defend to their deaths. I'm not trying to convince anyone my way's better. Take it or leave it.

-Tab

[dsellars]

I don't know if you saw when I asked about it in "Tools ..."

but just in case you are interested:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=tools;action=display;num=1084285958


Dan.

[frdfsnlght]

No, I hadn't seen that one. But now I have, and I even replied

As was discussed there, I don't think the built-in logging and log4j are interchangable. But the API's are very similar. And here, Will points out a couple of features that the built-in stuff doesn't have (since it violates platform independence, but frankly that's a stupid reason to keep it out in this case IMO).

I'll consider the issue dead. Except for the couple System.out.println's I found in Geom.java that should be replaced with logging statements, if not simply removed altogether. If you're going to do logging, then do logging.

-Tab

[William Denniss]

interesting other thread.

I agree that using /ext is risky - but that's why it's important to test on a totally untouched system.

I find no matter how hard you try to keep the dev machine clean it's hard.

As for the println's - I agree they need to be removed the only reason they havn't is time.

Will.