Re: java.util.logging

[Sascha Brawer]

> java.util.logging:
> - Lumberjack <http://javalogging.sourceforge.net>
> - my implementation, planned for Classpath

Thanks for the pointer! I've browsed a bit in the Lumberjack code and
would like to share my impressions.  Please be aware, though, that my
assessment might be biased.


Code Quality
------------
My impression was that there are places in each implementation where it
is cleaner, more elegant or more efficient than the other. In general,
they seem quite comparable in quality.


Documentation
-------------
Lumberjack was not intended as replacement for Sun's package, but as a
drop-in for JRE versions before 1.4.  Therefore, it is practically not
documented (especially no Javadocs) -- and does not need to be, since its
users can always look at Sun's Javadoc.  On the other hand, my code was
planned to become part of Classpath. Therefore, it is quite extensively
documented, trying to explain in detail what is going on.  The goal is to
be clearer than Sun's Javadoc (though I'm not sure whether I succeed in
this...)


Code Size
---------
My *source* code is twice as large as Lumberjack:  5 kLines/20 kWords for
my implementation, 2.6 kLines/11 kWords for Lumberjack [1].  The reason
is, again, documentation.  The *object* code size is currently 45 kB for
my implementation, 61 kB for Lumberjack [2].

[1] Measured with:
      wc java/util/logging/*.java
    so neither testsuites nor Lumberjack's installer are included in
these numbers.
 
[2] Measured with:
      javac java/util/logging/*.java -d /tmp/l ; \
      wc -c /tmp/l/java/util/logging/*.class
    where javac is from Sun JDK 1.3.1 (on MacOS X, but this should not
matter);
    again, this includes just the actual logging framework, without test/
installer.


Testing
-------
Lumberjack: 0.1 kLines/0.4 kWords (in net/sourceforge/javalogging/test).
My implementation: 4 kLines/11 kWords (Mauve, gnu/testlet/java/util/logging).

Lumberjack: Actively being used. Probably no obvious bugs.
My implementation: Barely finished, never has been used by anyone.
Obvious bugs likely (unless they are covered by Mauve testlets).


Completion
----------
Both implementations seem complete. Both were developed with the Sun JDK,
so both might require some effort for integration into Classpath.

However, I did not touch a JDK 1.4 so far, so running my Mauve additions
against the Sun reference implementation might reveal bugs in my
testlets, which in turn would require fixes to my implementation.  Also,
there's an occasional FIXME left in my code, and reviewing the
documentation wouldn't hurt either. These are the "final touches" for
which I did not want to release the code for 2-3 more weeks.


Copyright
---------
Lumberjack: LGPL, (C) Brian Gilstrap.
My implementation: GPL with exception, (C) FSF. The copyright assignment
letter
is on its way back to the FSF, but should arrive any day.



So, how do we proceed?

(a) Scrap my implementation, just use Lumberjack: In any case, Brian
could easily run my Mauve testlets against his implementation and fix a
couple of apparent bugs. He might want to do this in any case, totally
independent of an eventual integration into Classpath. I am not sure
whether there is a license conflict if he copies the Javadoc, but I
assume the only reason for doing this would be to use Lumberjack in
Classpath, in which case the license would have to change anyway.

(b) Merging: I definitely think it would be worth merging the two
implementations class by class, method by method.  Code quality will
improve from reviewing and comparing two independent implementations. So,
I am actually quite glad that this duplication of efforts has happened,
although it means more work in the short term. I see only one drawback,
namely that reviewing and discussing will take some more time.

Whatever the decision will be, I could check the testlets into Mauve
(assuming I'll be allowed to commit changes).  For some time, however,
bugs will be present -- the Sun reference implementation is unlikely to
pass all tests initially.  Do people know whether it is ok for Mauve to
check in broken tests?

For my implementation, I tried to create some temporary project on
subversions.gnu.org, but project creation in Savannah does not seem to
work currently.  My initial plan was to commit it directly into Classpath
(in java/util/logging) when I'm done with the "final touches", but I do
not know whether this is appropriate before a decision is made about
merging with Lumberjack.  Maybe it would be easiest if I could add it
into some special directory in the Classpath tree, e.g. projects/logging?
In that case, it would be very useful if I could be given permission to
commit changes to Classpath.

Thanks for reading all this. It's lengthy, but on the other hand, we are
talking about a substantial amount of code here.

Greetings,

-- Sascha