Parsers (and therefore the machinery provided by parser generators) must have some mean to handle invalid source files. Thus each parser (and parser generator) has chosen some method to manage syntax errors.
An easy solution provided by most is simply to throw an exception when such an error is encounterd. The user code invoking the parser has to catch this exception and live with an aborted parse. A more sophisticated solution to have the parser report a syntax error, but recover from the error and continue parsing; any such recovery must handle AST building with some kind of marker on the nodes at the point of error if you also hope to get a usable tree. Most parser generators will offer some kind of syntax recovery, but leave you on your own to handle AST building the face of such errors. Such parser recovery logic is relatively hard to build, and you likely can't do it yourself without becoming an expert in parser error recovery, and making custom changes to the particular parser generators support code.
I'm not specifically familiar with JavaCC (or most of the other parser generators out there), so I don't know if it does this. Obviously, check the docs. If the error handling support you want isn't there, move on to another generator that has it.
I suspect your real problem will actually be getting grammars appropriate for your task. Nobody has "Java" or "COBOL"; they have a specific dialect, e.g., Java 1.5 or IBM Enterprise COBOL or VB6. These are more different from the imagined base language that you expect based on my long experience. You can hope that such grammars as you can obtain will work (including error recovery) to enable you to parse the various dialects of each ins spite of such differences, but generally you'll get large numbers of errors from code in one dialect that doesn't match the grammer you want. (What will you do with the card numbers out past column 72, in your IBM Enterprise COBOL code that has EBCDIC source files?) So you really want a tool that has lots of parsers that handle the various dialects, and that should drive your choice IMHO.
I think ANTLR has a lot of language definitions (more than JavaCC) so it kind of qualifies. However, many the grammars at that site are experimental or unfinished (some are pretty good) so you get kind of pot luck.
Our DMS Software Reenginering Toolkit has a lot of grammars, and we think it our task to make these production quality. We aren't perfect either but our grammers tend to have been tested on large bodies of code, and have support for various dialects. Error recovery is built in, and you do get a tree back (with error nodes in the AST) if the number of errors is less than a specified threshold. DMS also handles nasty issues such as character encodings (we do a wide variety including 80 column EBCDIC with card numbers in column 72 for IBM COBOL and JCL). DMS may not be what you want; for instance, it is not Java based. But we try to make up for that by providing a huge amount of machinery to support post-parsing tasks, such as what you want to do. This machinery includes support for building symbol tables, extracting control and data flows, matching patterns and applying source-to-source transformations, etc. But that's a tradeoff for you to make.