Live data from Hacker News

Ask HN: I have to analyze 100M lines of Java – where do I start?

news.ycombinator.com

31–40 of 126 posts

Re: Ask HN: I have to analyze 100M lines of Java – where do I start?

#33
post #30

Source to UML: http://www.architexa.com/ Getting call paths: https://github.com/gousiosg/java-callgraph Line coverage from instrumented jars: http://emma.sourceforge.net/ For this type of request, I'd push back and say, let's identify very small parts of this and begin rewriting those one at a time in an isolated project. Kind of an agile rewrite that will combine the legacy project with the slowly rewritten one. Use…

nice links! :)

Re: Ask HN: I have to analyze 100M lines of Java – where do I start?

#35
post #5

Callgraph. Then document the larger chunks, working your way down. It's like having a map versus having no map at all. And 100M lines? Are you sure there is no code generator at work here?

It's code that's been developed and it's been running for decades, I'm afraid.

developed in java and running for decades? how long has the language been around?

Re: Ask HN: I have to analyze 100M lines of Java – where do I start?

#36

Just curious: what application needs 100M lines of anything?

It's not just one application. It's many of them.

Why not (sounds easy eh?) go one application at a time? Are there interactions between apps? Maybe you can start with documenting all the interaction (~ api). Then you'd go deeper in each app.

Re: Ask HN: I have to analyze 100M lines of Java – where do I start?

#38
post #35

Earlier quoted context omitted.

It's code that's been developed and it's been running for decades, I'm afraid.

developed in java and running for decades? how long has the language been around?

19 years. But sun was pushing it quite aggressively at enterprises so it is not rare to see big java installations that are now 15+ years old.

And those are not the most fun to work on.

Re: Ask HN: I have to analyze 100M lines of Java – where do I start?

#39
With a codebase like that, it's better to look at it through the users' eyes, rather than trying to reverse engineer the business from the code. Things that look like bugs in the code may actually be features for the users, or may have been absorbed so long ago that they've fundamentally changed the nature of the business.

You don't need to understand the whole codebase. It will take years. Best to focus on what the users need and analyze small chunks. If it's truly 100M lines, there's not going to be any semblance of consistency in the code.

You can also slap New Relic on it and you may be amazed at what you learn, right away.

Don't waste too much time trying to understand all the code. Focus on a couple issues first, make some hypothesis, and then see how well your understanding of the code fits the bigger picture. Refactor and repeat.

Post reply on HN