Escape java hint fix String for html and fill in multi variables.

[mbien]

fixes a few small issues and one little performance improvement:

• The hint fix contains code segments which may contain angle brackets. This can break the formatting of the apply-fix dropdown.
• Multi variables are now replaced with their values in simple cases.
• Sort vars by length before replacement so that they don't replace each other. Multi-vars go first.
• can use String.replace() instead of replaceAll() since no regex is involved

before:

after:

hint:

$name = new java.util.Vector<$T$>();     =>
$name = new java.util.ArrayList<$T$>();  ;;

note:

• multi-variables like $T$ (zero-or-many) were not substituted before this change
• angle brackets were either ignored by the html renderer or caused undesired formatting

non-trivial case:

if ($b < $b1) {
    $body$;    
}
=>
if ($b1 < $b) {
    $body$;    
}
;;

note: some vars are prefixes of others

empty body:

single entry in multivar:

multiple entries in multivar:

[mbien]

@lahodaj do you think it is possible to compute the display name lazily in the getter of JavaFixRealImpl? I feel bad that this has so much string replacement and it runs during the hint matching phase and not during the apply phase.

Is it legal to call treepath.getLeaf().toString() without CompilationInfo or any other context? It would be fairly easy to move it into the getter if yes.

[mbien]

after testing a bit more I had to make some more adjustments

• the VariableTree -> identifier name conversion can't be done for multi vars, since those can have full statements in them
• improved the whitespace situation a bit so that it looks better as single-line-String
• cd18599 computes the display name of the fix lazily, so that it runs after the matching phase and does not affect editor performance

I noticed during testing that variables for method names are missing in the list, example:

java.util.Iterator<$T> $it = $col.iterator();
while ($it.hasNext()) {
    if ($it.next().$condition($params$)) {
        $it.remove();
    }
} :: $col instanceof java.util.Collection
=>
$col.removeIf(e -> e.$condition($params$));
;;

$condition would be missing, the refactoring works fine though.

[mbien]

rebasing/squashing for a fresh run and preparing for merge

[mbien]

I looked through com.sun.tools.javac.tree.Pretty which is called by JCTree#toString and I think it should be fine to call TreePath#toString lazily on EDT -> merging once green again