I don't think they were ever truly abstract. It just indicates that they are there as a default impl, which you can easily override if in need of something more. I agree with you that it's probably not the best name choice, it could be Base or really Default, but I think you should ping Adrian to explain you the real motivation behind the name. David M. Lloyd wrote:

The only problem is that names are meaningless unless they communicate something to someone besides the person assigning the name. Dimitris Andreadis wrote: -- Jason T. Greene JBoss, a division of Red Hat

Adrian Brock wrote: Then there should be no reason to instantiate it. The humpty dumpty argument is very weak. Following this argument, I could call every class StringXXX, since the code making up the class itself is a String. This, however, does not make it a good name. Names are completely meaningless if they do not convey a meaning to someone besides the author. That is unless you intend on being the only person to use it. -- Jason T. Greene JBoss, a division of Red Hat

On Wed, 2009-06-03 at 08:33 -0500, Jason T. Greene wrote: If you want a serious discussion then cool the ad-homeniem attacks. Frankly, I've got better things to do than worry about whether somebody can understand what a class does from its name without reading the javadoc or even the code (it is open source). The same goes for all the other "feeble" topics that have been drowning the dev-list recently. If I see another topic on logging I might even unsubscribe from the list. ;-) "Rearranging the deck chairs on the titanic" is a phrase that springs to mind. -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Thu, 2009-06-04 at 10:17 -0500, Jason T. Greene wrote: What developers should really concentrate on is what's tested. I don't care what the javadoc says or what an author thinks their software does. If its not tested it could do anything. The tests also give some idea about how the thing should be used, (something that's a lot more useful than the usually perpetually out-of-date docs). Testing is a much higher priority than whether a class should be AbstractThingyBuilderFactory or other "aesthetic" arguments. Stick your e-mail client in threaded mode and you can see examples of (without naming names): * "design by committee" - JFDI and we can discuss it when you have a working prototype that gives us something more concrete to talk about and develop. If you need to collect anything beyond peripheral requirements then maybe you're not the best person to lead the project? * any post that begins +N usually has very little to add to the discussion, the -1 posts have much more relevance (if you can see them for "trees") - good software design is not done via elections its done by vetoing (fixing) bad design * further reduxes of "wouldn't it be good if ...", usually by people who aren't going to do (or resource) the ... - You want it, you do it I could go on, but ... -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

On 06/04/2009 07:10 AM, Adrian Brock wrote: Figuring out what code does is useless without knowing what it's supposed to do. The Javadoc is a critical part of this, and frankly there isn't much on most of our codebase. That's pretty derisive, and I for one don't appreciate it. That reminds me... ;-) I'm not following your metaphor. What exactly is the titanic here? The AS? Does that make you William Pirrie? ;-) Seriously we all want to make things better here, and frankly we could really use your help, not your insults. - DML

On 06/04/2009 11:30 AM, Adrian Brock wrote: I think you'll find that you are incorrect, if you're referring to this thread: http://lists.jboss.org/pipermail/jboss-development/2007-December/011166.html I argued the following: 1) All popular logging APIs should be supported 2) Everyone should switch to JUL 3) App developers should be able to use whatever API they like without blowing things up or getting other unexpected results. I still stick by my #1 and #3, though I conceded #2 a rather long time ago (there are a lot of features present in other logging APIs that are missing in the j.u.l.Logger API, and my current opinion based on user feedback is that slf4j is least likely to introduce dependencies that aren't already present in a given project). As I recall, your response was: 1) Everyone should use jboss logger 2) We will always have to deal with many logging frameworks 3) JUL is broken and can never be used safely, period I still disagree with #1, but that's one of those things that nobody will ever really agree on. I agree totally with #2, and in fact that ties directly with my #1 and #3. I have since refuted your #3 by producing a JDK logmanager (with javadocs btw) that isn't broken, which allows us in 5.1.x to trap JUL messages and forward them into our log without risking performance/deadlock/memory leak/etc issues. I have since come to the conclusion that there are two separate arguments: what logging APIs to support, and what logging backend to use. The answer to the first is "all of them", and the answer to the second is "it doesn't matter, so long as it works". Thus it doesn't matter what logging APIs each project chooses to use because all the major APIs should be supported. So when working on the new logging POJO service, I've stuck to that philosophy. Since that time the vast majority of my posts on the topic of logging have gone unanswered. Do you have anything to add? If so, how about posting constructive criticism here: http://www.jboss.org/community/wiki/LoggingPOJOServiceRequirements So my question for you in this thread is, are we still in disagreement about something that is relevant here? - DML

Adrian Brock wrote: There was no javadocs and i did read the source code - but honestly it's too complex for me to understand the usage of the classes and hence this thread. The only reason i brought up this thread was to understand the usage of such classes better and if there was more to it than just: That's all i wanted to know. I respect the freedom each developer has, to name the classes as per his choice. regards, -Jaikiran