And it'd be interesting to see a comparison of your tool to checkstyle and PMD, both fairly well-established and good tools for the same purpose...
On 2/25/06, Scott Deboy <[EMAIL PROTECTED]> wrote: > That is a very old version of log4j. Feel free to analyze a recent release > (or the current release), we'd be happy to hear your results. > > Thanks > > Scott Deboy > COMOTIV SYSTEMS > 111 SW Columbia Street Ste. 950 > Portland, OR 97201 > > Telephone: 503.224.7496 > Cell: 503.997.1367 > Fax: 503.222.0185 > > [EMAIL PROTECTED] > > www.comotivsystems.com > > > > -----Original Message----- > From: Yann-Gaël Guéhéneuc [mailto:[EMAIL PROTECTED] > Sent: Sat 2/25/2006 2:54 PM > To: log4j-dev@logging.apache.org; Naouel Moha > Subject: Detection of design defects > > > Dear log4j developers, > > We are a team of software engineers doing research on design > defects (antipatterns, codesmells...) in the Departement of Informatics > and Operations Research at University of Montreal. We develop a > framework to describe design defects synthetically and to detect these > in program source code automatically. We are currently performing > experiments to assess our detection algorithms. > > We selected log4j as an obvious case study because it is a > well-known, widely spread, and mature software. Also, we use log4j for > our own teaching and research projects. > > Would you be interested in helping us assessing our detection > algorithms? We would be very grateful if you could provide us with your > expertise on the development of log4j to help us in understanding why > certain classes are erroneously highlighted as design defects by our > algorithms. It is important for us to have your comments because we are > by no means experts in the implementation of log4j and we would be bias > by our own implementation of the detection algorithms. Also, you might > find our detection algorithms useful to improve the design and > implementation of certain classes and, thus, to ease the maintenance and > evolution of log4j. Of course, we will make our detection algorithms > available to you and your community when they are validated. > > We applied our algorithms on log4j v1.2.1 and generated potential > candidate classes for the follwing design defects (from the Brown's > AntiPatterns book): > - Blob, a large class doing all the work, only using small Data Class to > store/to retrieve data. > - Functional Decomposition, a class that does not conform fully to the > OO paradigm, such as not using inheritance and polymorphism. > - Spaghetti Code, a class with long methods and too many "global" variables. > - Swiss Army Knife, a class implementing too many functionnalities > and-or providing too many services. > > We attach to this message some results of our detection > algorithms. The classes named in these files are *candidate* design > defects and we already found manually many false positive cases (i.e., > class highlighted as design defects which are not). We cannot provide > you now with the complete results as your anti-spam filter rejects .zip > files, let us know if we can transfer you the results in another way. > Would it be possible that you kindly help us in improving our algorithms > or point us to someone > who could help us? > > If you have any questions or comments, please feel free to contact > either myself or Naouel Moha, Ph.D. student working full-time on this > project. > > Best regards, > Yann-Gaël > > -- > > # Results of the detection > > > ############################## Results of the detection of the Blob # > DataClass > 1.100.DataClass.1.Name = org.apache.log4j.chainsaw.ControlPanel > 1.100.DataClass.1.NAD = 2.0 > 1.100.DataClass.1.NMD = 2.0 > # ControllerClass > 1.100.ControllerClass.2.Name = org.apache.log4j.chainsaw.ControlPanel > > ############################## Results of the detection of the Blob # > DataClass > 2.100.DataClass.1.Name = org.apache.log4j.lf5.LogLevelFormatException > 2.100.DataClass.1.NAD = 0.0 > 2.100.DataClass.1.NMD = 1.0 > # LargeClass > 2.100.LargeClass.2.Name = org.apache.log4j.lf5.LogLevel > 2.100.LargeClass.2.NAD = 19.0 > 2.100.LargeClass.2.NMD = 18.0 > > ############################## Results of the detection of the Blob # > LargeClass > 3.100.LargeClass.1.Name = org.apache.log4j.lf5.viewer.LogBrokerMonitor > 3.100.LargeClass.1.NAD = 29.0 > 3.100.LargeClass.1.NMD = 105.0 > # DataClass > 3.100.DataClass.2.Name = org.apache.log4j.lf5.viewer.LogFactor5ErrorDialog > 3.100.DataClass.2.NAD = 0.0 > 3.100.DataClass.2.NMD = 1.0 > > -- > Yann-Gaël Guéhéneuc, Ph.D. > Professeur adjoint / Assistant professor > Ptidej Project Team Leader > GEODES - Group of Open and Distributed Systems, > Experimental Software Engineering > DIRO, Université de Montréal 1-514-343-6782 (Téléphone / Phone) > C.P. 6128, succursale Centre-Ville 1-514-343-5834 (Télécopie / Fax) > Montréal, QC, H3C 3J7, Canada www.ptidej.net > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
