TODO

Features

• support Java8
  • see matazoid/javaparser #27
    • help define appropriate javacc grammar file
  • use JDK's AST compiler
    • http://java.dzone.com/articles/using-java-compiler-tree-api
    • http://www.tutego.de/blog/javainsel/2012/07/mit-der-internen-compiler-api-auf-den-ast-einer-klasse-zugreifen/
    • https://today.java.net/pub/a/today/2008/04/10/source-code-analysis-using-java-6-compiler-apis.html
    • It seems that in order to use this compiler, I need JDK8:
      • When using the running JDK's compiler, I need deadcode4j to be compiled with JDK8 as well (or I try to extract this stuff into an own module and try to to compile this backward-compatible :/
      • Another problem is that I'm tied to a specific JDK (shipping the com.sun.tools stuff) then
      • When trying to use jsr308-compiler, I also need a java8 jdk to compile and run
  • Look at ANTLR
• recognize cyclic dependencies
  • actually, better to report which parts of the code are really used
  • "really used" means either marked as such manually or because the application breaks if the class (and its minions) is removed, i.e. the class is listed in sth. like web.xml
  • then we work on transitively from there
• Detection 2.0
  • check if a Spring bean is really used
  • check if JSF stuff is really used
  • generate a report
  • consider only listed Spring Web Flow XML files
• JBoss XML files (can be done using custom XML for the moment)
• JSP imports (with plain parsing, this means a huge effort; better look for a way to use Jspc and parse the bytecode?
• Class.forName (this would probably require to analyze the .java files; also, it is most likely that this is done in a dynamic matter)

Internals

• see if JDK's jdeps can be used instead of the custom dependency detection
  • this might be an inspiration: http://blog.codefx.org/tools/first-release-of-jdeps-maven-plugin/