Combined with a version-control system like CVS or Subversion (for which there
are Java clients), and the version-control systems themselves include or wrap
the 'diff' command, you can get very sophisticated tracking of changes to text
files.

BTW, if this is to serve some sort of human-factor performance metric for,
say, source-code development, I recommend:

Add the absolute value of lines added to the absolute value of lines removed
to the absolute value of lines altered each day to get a programmer's
productivity for that day.  Count comment lines at 125-150%.  Count one line
of whitespace as one line, two consecutive lines or more of whitespace as 1.5
lines.  Count lines only for source files that have been formatted (indented)
to the organizational standard.  Credit the negative of a programmer's total
for the day if that day's build won't build because of the developer's check-in.

Even all that won't measure certain important things, but it would give a
rough estimate of raw productivity.

If you want a less valuable metric, count all lines equally, but do
standardize the whitespace first.  This should make it easier to use the raw
diff numbers of added, deleted and altered in a scripted way.

There is a definition of open source by OSI - I would
say that the last two of your characteristics are included
in the open source definition.

(http://www.opensource.org/docs/osd item 1 and 3)

Arne

If you use that as a performance metric for team members, it won't encourage
them to write comments or use whitespace to make their code more readable.

Comment lines should be counted.  Maybe count them double when they're revised.