Question: I am asked to develop a software which should be able to create Flow chart/ Control Flow of the input Java source code. So I started researching on it and arrived at following solutions:

To create flow chart/control flow I have to recognize controlling statements and function calls made in the given source code Now I have two ways of recognizing:

1. Parse the Source code by writing my own grammars (A complex solution I think). I am thinking to use Antlr for this.
2. Read input source code files as text and search for the specific patterns (May become inefficient)

Am I right here? Or I am missing something very fundamental and simple? Which approach would take less time and do the work efficiently? Any other suggestions in this regard will be welcome too. Any other efficient approach would help because the input source code may span multiple files and can be fairly complex.

I am good in .NET languages but this is my first big project in Java. I have basic knowledge of Compiler Design so writing grammars should not be impossible for me.

Sorry If I am being unclear. Please ask for any clarifications.

Answer: 
All tools handling Java code usually decide first whether they want to process the language Java or Java byte code files. That is a strategic decision and depends on your use case. I could image both for flow chart generation. When you have decided that question. There are already several frameworks or libraries, which could help you on that. For byte code engineering there are: [ASM](http:///asm.ow2.org/), [JavaAssist](http://www.csg.is.titech.ac.jp/~chiba/javassist/), [Soot](http://www.sable.mcgill.ca/soot/), and [BCEL](http://jakarta.apache.org/bcel/), which seems to be dead. For Java language parsing and analyzing, there are: [Polyglot](http://www.cs.cornell.edu/projects/polyglot/), the eclipse compiler, and javac. All of these include a complete compiler frontend for Java and are open source. 

I would try to avoid writing my own parser for Java. I did that once. Java has a rather complex grammar, but which can be found elsewhere. The real work begins with name and type resolution. And you would need both, if you want to generate graphs which cover more than one method body.
> 
> Now I have two ways of recognizing:
> 
> 
> 

You have many more ways than that. JavaCC ships with a Java 1.5 grammar already built. I'm sure other parser generators ditto. There is no reason for you to either have to write your own grammar or construct your own parser.

And specifically 'read[ing] input source code files as text and search for the specific patterns' isn't a viable choice at all, as it isn't parsing, and therefore cannot possibly recognize Java programs correctly.