MaintainJ generates runtime sequence and class diagrams for a single user action. This helps to trace the runtime objects called for that action. Only the calls between application classes are shown. The diagrams are simple and easy to read. Application code is not touched. In MaintainJ 2.8, the diagrams can be generated for Tomcat/JBoss applications without leaving Eclipse. Check the video demo. Similarly, diagrams are generated for each JUnit test when tests are run in Eclipse. Check the video demo. J2EE/J2SE/Swing/Applets/Eclipse Plugin applications are also supported seamlessly. The basic premise of MaintainJ is, a) It is difficult to understand Java applications by reading code. Debuggers don't help to trace call flow b) Too many frameworks, their configurations and interface based designs make it difficult to track down a problem c) But, most of the business logic exists in our Java components and not in frameworks or their configurations d) So, if we can quickly identify those components at play for a user action, we can easily identify the root cause of a problem Read the complete premise and future plans for MaintainJ. A few questions to the community: a) Do you agree with the premise? b) How do you perform the change impact analysis currently? How often is a possible impact point missed causing production issues? How do you scope the regression tests? c) Will you consider using a tool that may not perform a foolproof impact analysis, but uncovers many possible impact points?