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 [EMAIL PROTECTED] 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
