I work on enterprise Java projects that do not have a single entry point from where I can trace the flow of execution. Some of the projects have hundreds of classes, and when I'm asked to add a feature to a project, I often find myself at a loss as to where to start looking at code.

What's the best way to dive into such projects so that I can implement the feature quickly without wasting time.

  • Do your projects pull from a data access layer? Mar 15, 2012 at 23:10
  • Give more details. Does it use any frameworks like struts / EJB etc?
    – java_mouse
    Mar 15, 2012 at 23:13
  • @PhillipKregg Yes, it has a data access layer.
    – rdasxy
    Mar 15, 2012 at 23:21
  • @java_mouse it's a Spring project.
    – rdasxy
    Mar 15, 2012 at 23:22
  • Ask one of developers who wrote the code or bigger parts of it. No one of them still there in your company? Then you most probably have to spend some weeks or months to understand the system.
    – Doc Brown
    Mar 16, 2012 at 18:00

7 Answers 7


Does the project have a suite of well-maintained unit tests? The unit tests are programmatic documentation for what the code does.

In addition, you need to learn enough about the architecture of the application to identify the places where you need to insert code for your new features, and more or less ignore the rest. You don't need to know the whole code base to do this; if the projects are well-architected, the functionality is already sufficiently encapsulated and decoupled that you can focus on the relevant parts. If you're lucky, the projects already follow a well-known architecture which will serve as a map for you to follow.

Code always has one or more entry points. For MVC projects, the entry point is a controller method based on an URL; the method will almost certainly access a data repository, and return a view. Start there.


Start with the middle tier( business logic layer).

That is one of the places the control comes for any user actions or trigger events if it is a non UI based application. If you are in debug mode, You can trace it to the top and bottom ( most likely data access layer).

It will take sometime but this is the efficient way to jump into undocumented projects.

If the project uses any framework ( struts-config.xml , ejb config xmls , spring config xmls) will have a defined interfaces and you can start from there as well.


There's always an entry point. For Java enterprise apps: servlets, filters, and context listeners are at the top, they normally lead into application bootstrapping e.g spring context loader, which then leads into controllers, then into entities and views. It's actually pretty straightforward, particularly if a framework such as spring, tapestry, or wicket is used. Once you know how the framework processes a request, you should be able to identify the extension points you need.


I would start with a class hierarchy. If you have one great, if not, find a tool that can reverse engineer your code and create one for you. From that you can start to see how things may be related. Once you can see how things may be related you can at least target areas instead of having a large "hodgepodge" of classes. You can target an area you can see how they are associated with each other (is this class an association of this one, is this set of classes a design pattern, etc). Attempt to add some order and structure around what you're looking at and then break down each section.


Here are some posts from stack overflow outlining the tools you could use in eclipse (or as standalone applications) to reverse engineer and generate a model:

"How do you eat an elephant". "One bite at a time".

  • 2
    How do you code an elephant? One byte at a time. Mar 16, 2012 at 13:31

This is almost impossible to extend your java project if you don't get the entry points and a clear documentation of what has been done and why.

FYI: When we deliver a project to our customers we now systematically join an UML model as well as java doc and a printed documentation. We create hundreds of views from the model displayed as class diagrams. We add plenty of comments and explain the static architecture as well as business rules and methods flow. If our customers want to take his code and give it to another company it will be easy for them to modify the existing software not only at deployment level but also at architecture level. Powerful, simple and brilliant use of dynamic UML views from a single model.

Having said that I know very few integrators interested to provide all this information because once the customer is trapped it is better not to let him go. Giving full model and dynamic UML navigation will allow customers to be independent and therefore this is not good for business revenue. I still don't understand why big banks, or telecom companies are so naive to get trapped by integrators and don't ask the full model at the project delivery ? The java code or a printed documentation is not enough. The printed documentation is usually an automatic process. It has no real value to extract information from the code in order to print it or provide a PDF.


There are ALWAYS entry-points, you just have to find them. If it's a schedule-driven batch application, there are tasks configured somewhere. If it's a web-application (using Spring) there are mappings and Controllers. If it's a web services application, there are service endpoints. If it's a Swing application, there are event handlers or somesuch. And if it's a big ol hairy command line application, there is a main() method.

Regarding "diving in quickly" - well, how long it takes to find the entry-points is really individual. If the system is written according to established patterns and you are familiar with the frameworks and the underlying business rules and processes - then you should be able to figure them out very fast indeed. If not, it may take longer. But there is no universal "trick". You accumulate experience, you learn to recognize patterns and understand how the frameworks are built up and organized and you get better.


Regarding dealing with legacy code:

  • The book from Michael Feathers gives some good practices on how to approach legacy software.

Regarding flow of execution:

  • It's a Spring project, so expect the control flow to do magic tricks. It might do lots of calling methods by reflection, or even AOP. Trying to understand the "flow of execution" using a debugger may cause frustration.
  • It's a Spring project, so the structure of the project is rather homogeneous. Learn Spring (if you haven't already) so you understand the concepts of beans and wiring. This tells you what classes work together.

Regarding entry point:

  • Let me guess: it's a web application. Let me guess again: it's using Spring MVC. Learn this one, too, so you know how to find the controller classes for the pages. These are the entry points into your application. There are called by reflection, so you won't find them using static analysis of the source code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.