Ask HN: I have to analyze 100M lines of Java – where do I start?
31–40 of 126 posts
Re: Ask HN: I have to analyze 100M lines of Java – where do I start?
#32Re: Ask HN: I have to analyze 100M lines of Java – where do I start?
#33Source 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…
Re: Ask HN: I have to analyze 100M lines of Java – where do I start?
#34Re: Ask HN: I have to analyze 100M lines of Java – where do I start?
#35Callgraph. 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.
Re: Ask HN: I have to analyze 100M lines of Java – where do I start?
#36Just curious: what application needs 100M lines of anything?
It's not just one application. It's many of them.
Re: Ask HN: I have to analyze 100M lines of Java – where do I start?
#37Re: Ask HN: I have to analyze 100M lines of Java – where do I start?
#38Earlier 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?
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?
#39You 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.