Add Java Stack Trace highlight support.

[wesalvaro]

Highlights Java stack traces.

[zeitgeist87]

Hi @wesalvaro

Thanks for contributing. I like your idea. This could be quite useful.

I'll try to do a proper review until tomorrow.

[wesalvaro]

Sounds great. I look forward to hearing your suggestions.

[zeitgeist87]

Your solution is very precise. It is almost a complete semantically correct parser for Java stack traces. It must have taken you a lot of effort to get it there.

However I think in its current version it is unnecessarily complex. Prism is not a parser and it strives to be as simple and fast as possible. I can get almost the same result with the following simple language definition:

Prism.languages.stackjava = {
    'function': /[a-z0-9_$<>-]+(?=\()/i,
    'path': {
        pattern: /[a-z0-9_]+\.java(?=:\d+)/i,
        alias: 'entity',
    },
    'package': {
        pattern: /\b[a-z0-9_]+(?:\.[a-z0-9_$]+)+/i,
        inside: {
            'class-name': {
                pattern: /(\.)[^.]+$/,
                lookbehind: true,
                alias: 'entity'
            }
        }
    },
    'keyword': /\b(?:Caused by|at|more)\b/,
    'number': /\d+/,
    'punctuation': /[:.()]/,
};

The above definition exploits the fact that Prism executes every pattern in order and that later patterns cannot overwrite existing matches. The above definition is of course just a quick draft to show you what I mean. It is not tested very well and only intended as a rough guide.

I like how you constructed the IDENTIFIER_CLS variable.

Another minor thing Prism generally uses tabs instead of spaces.

I hope you are not discouraged by my critique. I think adding a language for Java stack traces is a good idea.

EDIT:

On second thought, do we really need all those obscure unicode characters in JAVA_IDENTIFIERS? I know they are theoretically possible, but I have never seen any of them used in practice. Prism doesn't have to be a compliant parser.

[wesalvaro]

Thanks for the review! I admit that I struggled a bit getting to the point where things were recognized in a coherent way. Our project also includes a plugin to link classes and things in the stack traces to the actual code files, so that's part of the rationale for detecting things the way I did. However, I'm sure it's a little overboard.

I will try out your suggestions and see how they go with the test cases that I amassed from our stack trace investigations.

As for the JAVA_IDENTIFIERS, we were seeing some weird identifiers in the stack traces and so I felt that completeness there was a fine approach. I would say it's definitely (hopefully) unnecessary, though.

Glad to know that you like the idea. I'll work on it some more this week and update you on the result.

Thanks again,
-Wes

[mAAdhaTTah]

@Golmote You think this would be useful to include?

[Golmote]

@mAAdhaTTah I'm ok with it. I wasn't sure it was a finished PR, since @wesalvaro never commented after his last commit, and some on the stuff @zeitgeist87 pointed out have not been addressed at all (like usings tabs).
An example file would also be needed, and maybe more atomic tests.

I don't think we have write access on this one, so we'll need to make a new PR if @wesalvaro does not update it himself.

[mAAdhaTTah]

Superceded by #1520.