logging for analysis

[Jeff Kish]

Hi.

I'm still relatively new to java.
I am trying to analyze and figure out on my own how a
proprietary frameworks 'works'.

It is event driven, and I tried putting a bunch of System.out.println
statements in, but:
1 - because (i come from c++ background) there are no destructors I
don't know for sure when things 'go away'
2 - everytime (it is still being developed) I get a bunch of debug in,
I use it for a day or two (yes it takes me that long to figure out
stuff .. my memory is kind of overloading) and then I have to get a
new version and put everything in all over again.

Does anyone have a suggestion on how to go about analyzing this?
I find there are a hand full of objects (session, etc) that have a
handful of important methods (handleTheEvent(...) etc) that are worth
logging.

I'd like to be able to output to a log file of some sort information
so I can play back a visualization of the events as they are fired and
handled by objects and their descendents.

I hope this isn't too much. I appreciate any thoughts.

thanks
Jeff

 

[Chase Preuninger]

Java tends to eliminate much of the junk that C++ has ie. memory
management. By that I don't mean do something like declare an array
for all 16 million colors (I did that once . Also by destructors I
think you might mean the finalise method in classes.

 

[Jeff Kish]

Java tends to eliminate much of the junk that C++ has ie. memory
management. By that I don't mean do something like declare an array
for all 16 million colors (I did that once . Also by destructors I
think you might mean the finalise method in classes.

Thanks. Any suggestions for an approach to logging event creation and
handling in a frameworks so I can go back later and visualize it?

I'd appreciate feedback in either the logging or visualization or
both.

regards
Jeff

 

[Lew]

Java tends to eliminate much of the junk that C++ has ie. memory
management. By that I don't mean do something like declare an array
for all 16 million colors (I did that once . Also by destructors I
think you might mean the finalise method in classes.

Aaaagh! Don't recommend finalizers! And they are most definitely *not* like
destructors - not even slightly.

Java neither has nor needs destructors. Nor anything similar.

Finalizers come with a *huge* penalty and *lots* of danger, and almost never
are needed.

There should be no problem declaring an array of 16M colors.

 

[Lew]

I'd appreciate feedback in either the logging or visualization or
both.

Logging:
log4j
<http://logging.apache.org/>

java.util.logging
<http://java.sun.com/javase/6/docs/api/java/util/logging/package-summary.html>

Both can be reconfigured at deployment time to give greater or lesser detail,
on a class-by-class basis even. I am more familiar with log4j myself.

At least with log4j, and I suspect with the Java package also, you can
configure outputs to go to a console, a file, wherever, even simultaneously.
log4j has hooks to handle multi-threaded programs, too.

The overhead of a logging call when the detail level isn't fine enough for it
to emit anything is quite small.

Make sure when you design your logging strategy that you think about what
operations will need when the program is deployed. Good logging will make
maintenance much easier, and downtime much rarer.

It is event driven, and I tried putting a bunch of System.out.println
statements in, but:

Why not System.err?

1 - because (i [sic] come from c++ background) there are no destructors I
don't know for sure when things 'go away'

They go away when the JVM decides they should. Only orphaned objects go away
- keeping a reference to an object will keep it from being garbage collected.

Kept references are Java's equivalent to memory leaks.

 

[Lew]

Also by destructors I
think you might mean the finalise [sic] method in classes.

There is no "finalise" method in the standard API.

<http://java.sun.com/javase/6/docs/api/java/lang/Object.html#finalize()>

 

[Jeff Kish]

I'd appreciate feedback in either the logging or visualization or
both.

Logging:
log4j
<http://logging.apache.org/>

java.util.logging
<http://java.sun.com/javase/6/docs/api/java/util/logging/package-summary.html>

Both can be reconfigured at deployment time to give greater or lesser detail,
on a class-by-class basis even. I am more familiar with log4j myself.

At least with log4j, and I suspect with the Java package also, you can
configure outputs to go to a console, a file, wherever, even simultaneously.
log4j has hooks to handle multi-threaded programs, too.

The overhead of a logging call when the detail level isn't fine enough for it
to emit anything is quite small.

Make sure when you design your logging strategy that you think about what
operations will need when the program is deployed. Good logging will make
maintenance much easier, and downtime much rarer.

It is event driven, and I tried putting a bunch of System.out.println
statements in, but:

Why not System.err?

1 - because (i [sic] come from c++ background) there are no destructors I
don't know for sure when things 'go away'

They go away when the JVM decides they should. Only orphaned objects go away
- keeping a reference to an object will keep it from being garbage collected.

Kept references are Java's equivalent to memory leaks.

mm I guess I didn't even think of System.err, is there a distinct
advantage to that?

Do you have any thoughts or recommendations to visualizing the
'captured' log records?

thanks
again