Re: java.util.logging

[Brian Gilstrap]

Sascha,

Thanks for the long assessment. In general, it seems like it is quite 
even handed.

I had already responded to Anthony Green letting him know I'm not 
interested in assigning copyright to the FSF at this time.

I would definitely be interested in exchanging thoughts on the API, and 
appreciate the offer to try your test suite on Lumberjack. Regression 
testing is definitely a weak area of Lumberjack. Also, in my opinion 
there are areas of the spec which are quite ambiguous. I think it would 
be enlightening (hopefully for both of us :-) to talk about some of 
these issues.


> [...] The *object* code size is currently 45 kB for
> my implementation, 61 kB for Lumberjack [2].
[...]
> [2] Measured with:
>       javac java/util/logging/*.java -d /tmp/l ; \
>       wc -c /tmp/l/java/util/logging/*.class


This is interesting. While neither size is terribly huge, it does make 
me wonder why there is such a large percentage difference. The first 
thing that pops into my mind is this: how long are your variable/field 
names typically? :-)


> 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'd like to do this. It could also help facilitate a discussion about 
ambiguities in the spec, since the test framework might touch on some of 
those ambiguities.


> (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.


I would be interested in pursuing a comparison of the implementations, 
even without a true merging of the code. I see this as having several 
benefits:

1) Peer review - we both get peer review of our code
2) Compatibility - we both achieve greater (complete?) compatibility 
with each other. This will make it easier for users of the libraries to 
work with either.
3) Spec clarification - we may be able to convince Sun to clarify fuzzy 
parts of the specification. Even if that doesn't happen, we could 
produce our own document detailing the areas we feel are ambiguous and 
our interpretations of those sections.

There are probably other good consequences I haven't thought about... :-)

Please let me know if you're interested in pursuing a mutual code/design 
review.

Thanks,
Brian

--
Brian R. Gilstrap
address@hidden
Husband and father, Tai Chi practitioner, Software architect
Java developer, Macintosh User

"Doubtless, like all of us, he was many men, turned on one or another of 
his selves as occasion required, and kept his real self a frightened 
secret from the world."  --Will Durant