Refactor and improve error matching

[kriegaex]

This PR supersedes the remaining part of #342 which was not part of #343, because the original description does not fit the content of that PR anymore.

Refactor javac output parsing code for better readability

Add a few more helper methods, factor out error message constants into an inner class, get rid of some deprecated API usage, add or improve comments, remove excessive blank line usage. The scope of these changes is not the whole JavacCompiler class, but just the parseModern* methods I am about to improve some more in subsequent commits.

The functionality is unchanged for now, it really is a classical refactoring. But the next commit depends on and builds on top of it:

Improve forked javac error matching accuracy and flexibility

• Add more error message prefixes to class JavacCompiler.Messages
• New method JavacCompiler.getTextStartingWithPrefix handles multi-line Java properties with placeholders and match them correctly in javac log output
• Add test verifying that for slightly modified, non-matching error headers at least the stack traces are still recognised and added as error messages, despite the headers missing in those cases

Recognise new javac error header types

• javac.msg.resource - "The system is out of resources."
• javac.msg.io - "An input/output error occurred."
• javac.msg.plugin.uncaught.exception - "A plugin threw an uncaught exception."

@olamy, as you have seen at least one commit before, maybe at your convenience after the holidays you want to review this PR. Until then, I wish you some happy relaxing time off. 🙂

[kriegaex]

@olamy, I have split some and squashed other commits for the diffs per commit to be more focused and more easily digestable. Now, I am actually quite happy with the succession of commits and the PR overall.

[slawekjaranowski]

I afraid that it can depend on JDK version ... and maybe on vendor Can we prepare a simple IT even for a few cases?

[kriegaex]

@slawekjaranowski, of course it depends on JDK version, which is why I have properties for multiple JDK versions (e.g. 8, 21 or 8, 9, 21), where I found differences. The parametrised tests check all variants already.

Feel free to write as many ITs as you wish. I will not. Reminding you again, however, for the third time or so, that it is difficult to reproduce most errors on all JDK versions in an IT, because as they get fixed, this can change, even between two separate update versions of the same JDK major.

I can assure you that I reproduced each single error, which is how I managed to get sample stack traces for the tests in the first place. That was more tedious than to actually write the code, because I had to juggle many JDK versions and locales and in some cases even install specific, outdated JDK update versions just to reproduce an error in real life, because later it was already fixed in the same JDK.

Compare the before vs. after situations: Before, there were

• no ITs for these types of errors either,
• way fewer UTs,
• hard-coded text matches in English only for all error headers,
• fewer error types recognised at all and
• code less readable and comprehensible than now after my refactoring and additional comments.

If you are afraid, that this PR makes anything worse, just do not merge it. But stop trying to burden me with work that should have been done by others in the past already. Much of that work I did in this PR, but new ITs are out of scope for me, because the existing ITs are so minimal, we could add at least two dozen new ones for everything that currently only has UT coverage. How about some Mojohaus developers getting active there? Not everything can be done by waiting for external contributors doing it. I want to give you my little finger, not the whole hand or arm. So try not to be too greedy.

[slawekjaranowski]

Can anybody else look at it? @kriegaex did a huge work on it, so it should not be postponed forever ...