deadcode4j v1.5: Features

deadcode4j takes several approaches to analyze if a class is still in use or not:

• statical code analysis using Javassist, recognizing class dependencies¹
• parsing Spring XML files: files ending with .xml are examined
  • each bean element's class attribute is treated as live code
  • CXF endpoint definitions: each endpoint element's implementor/implementorClass attribute is treated as live code
  • Quartz job definitions: each property element's class attribute is treated as live code if it has an name attribute of jobClass
  • Spring View resolvers: each property element's class attribute is treated as live code if it has an name attribute of viewClass
  • recognizes Spring XML NamespaceHandlers as live code
• recognizing classes annotated with those Spring annotations as live code:
  • org.springframework.context.annotation.Configuration
  • org.springframework.jmx.export.annotation.ManagedResource
  • org.springframework.stereotype.Component
  • org.springframework.stereotype.Controller
  • org.springframework.stereotype.Service
  • org.springframework.stereotype.Repository
• parsing web.xml
  • recognizing listed listeners, filters & servlets (according to the XSD files)
  • look for the parameters defined by Spring's ContextLoader and FrameworkServlet: contextClass & contextInitializerClasses, treating the configured classes as live code
  • if the metadata-complete attribute isn't explicitly set to false:
    • implementations of javax.servlet.ServletContainerInitializer are treated as live code
    • implementations of org.springframework.web.WebApplicationInitializer are treated as live code
• parsing *.tld files: recognizing custom tags, tag extra infos, listeners, tag library validators & EL functions
• parsing faces-config.xml files: recognizing those element classes as live code: action-listener, application-factory, attribute-class, base-name, behavior-class, client-behavior-renderer-class, component-class, converter-class, converter-for-class, el-resolver, exception-handler-factory, external-context-factory, facelet-cache-factory, faces-config-value-classType, faces-context-factory, flash-factory, flow-handler-factory, key-class, lifecycle-factory, managed-bean-class, navigation-handler, partial-view-context-factory, phase-listener, property-class, property-resolver, referenced-bean-class, render-kit-class, render-kit-factory, renderer-class, resource-handler, source-class, state-manager, system-event-class, system-event-listener-class, tag-handler-delegate-factory, validator-class, value-class, variable-resolver, view-declaration-language-factory, view-handler, visit-context-factory
• recognizing classes annotated with JEE annotations as live code:
  • javax.annotation.ManagedBean
  • javax.inject.Named
  • javax.persistence.metamodel.StaticMetamodel
  • JAXB annotation javax.xml.bind.annotation.XmlRegistry
  • JAXB annotation javax.xml.bind.annotation.XmlSchema
  • JSF annotations javax.faces.component.behavior.FacesBehavior, javax.faces.convert.FacesConverter, javax.faces.event.ListenerFor, javax.faces.event.ListenersFor, javax.faces.event.NamedEvent, javax.faces.render.FacesBehaviorRenderer, javax.faces.render.FacesRenderer, javax.faces.validator.FacesValidator, javax.faces.view.facelets.FaceletsResourceResolver
• parsing Spring Web Flow XML: files ending with .xml are examined
  • each attribute element's type attribute is treated as live code
  • each evaluate element's result-type attribute is treated as live code
  • each input element's type attribute is treated as live code
  • each output element's type attribute is treated as live code
  • each set element's type attribute is treated as live code
  • each var element's class attribute is treated as live code
• parsing Apache Tiles XML definition files: files ending with .xml are examined
  • each definition element's preparer attribute is treated as live code
  • each bean element's classtype attribute is treated as live code
  • each item element's classtype attribute is treated as live code
• processing Hibernate Annotations
  • recognizing the strategy value of the org.hibernate.annotations.GenericGenerator annotation as live code
    • issue a warning if a @GenericGenerator is defined more than once with the same name
  • recognizing classes annotated with org.hibernate.annotations.GenericGenerator that are referenced by another class via javax.persistence.GeneratedValue annotation's generator value as live code
  • recognizing the type value of the org.hibernate.annotations.Type annotation as live code
  • recognizing classes annotated with a org.hibernate.annotations.TypeDef that are referenced by another class in the project as live code
    • issue a warning if a @TypeDef is defined more than once with the same name
• recognizing *Descriptor classes being generated by Castor as live code
• recognizing service classes defined within Axis .wsdd files as live code
• recognizing aspects defined within aop.xml as live code; supports both AspectJ and AspectWerkz

Customization

• recognizing classes annotated with custom specified annotations as live code
• recognizing classes directly² implementing custom specified interfaces as live code
• recognizing classes directly³ extending custom specified classes as live code
• custom XML file parsing: treating classes referenced in elements' text or attributes as live code

¹ Inner classes are always recognized as being referenced by the outer class and vice versa (even static inner classes). This is not only true for the currently used Javassist, but also for BCEL. This suggests that this is an aspect of the JVM spec.
² When examining class C extends B implements A, only B is recognized as implementing A; you can circumvent this by defining C extends B implements A
³ When examining class C extends B extends A, only B is recognized as subclass of A; no circumvention here - create an issue if you think this is absolutely required!