jhunter at acm.org
Wed Apr 25 13:47:16 PDT 2001
I think Frank makes an interesting suggestion below. I tried his
suggestion for Element (using a private variable instead of public), and
it seems to work well. Any reason not to add this to our core classes,
as a private variable?
Jools suggested (after seeing my CVS commit) having our EasterEgg class
print CVS versions of all the classes, something possible if with JDK
1.2 where you can peek at private variables in a low-security
environment. The behavior would be like ident(1).
P.S. Resent with permission.
Subject: jdom cvs_id suggestion
Date: Tue, 24 Apr 2001 15:28:46 -0700
From: Frederick Roeber <roeber at xigo.com>
To: brett at jdom.org, jhunter at jdom.org
First, I wanted to thank you for writing jdom; I'm finding it incredibly
I would like to make one suggestion. I'm trying to debug a problem in
someone else's program; a program in which he used some version of
jdom. Unfortunately, I'm not sure just when he grabbed the source, and
the line numbers in the exception stack don't correspond to the current
It would have been really useful if CVS version info were built into the
classes; then I could e.g. strings the jar to figure out at what version
I need to look.
Personally, I always include the following as the first thing in every
(primary) java class I write:
public static final String CVS_ID =
"@(#) $RCSfile: $ $Revision: $ $Date: $ $Name: $";
(all one line, obviously).
I found that information -- particularly the Name, which is *not*
included in the widely-used $Id: $ cvs tag -- to be the most useful
information. (Name is filled in with the name of the tag (static or
branch) with which the code was pulled.)
In addition to being useful for debugging, this has saved me in the past
when someone's (re)opening a bug against me, and I've been able to point
to these strings in the binary to prove that no, they really didn't
update like they said they did.
Hope this is a useful idea.
Thanks again for writing jdom.
More information about the jdom-interest