StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

This was required by the Eclipse team as one precondition for the next
release.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

The Java 16 Javadoc generator has changed the HTML structure once again
even compared to Java 15. I adjusted the matching in HtmlDecorator and
also fixed CoverageTestCase. Most methods there I just made to work
quickly, but method 'testInnerAspect()' I actually refactored. Some
other methods could (probably should) be restructured in a similar
fashion, but for now I just wanted to understand what the test does and
see how much work it would be to refactor it. But finally, I just want
to get the GitHub CI build running on Java 16.

TODO: I did not check if the decorated HTML actually looks OK and am
unsure if the tests cover that sufficiently, I never reviewed the tests.
It would also be better to do regex matches instead of looking for
variants of fixed strings or maybe even to operate on a DOM. But I am
not in a mood to refactor that tonight.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

HtmlDecorator.decorateHTMLFile is where after Java version upgrades
(i.e. also new Javadoc generator version) usually tests fail for the
first time during builds because strings no longer match as expected.

There now is this log message on stdOut: "Something unexpected went
wrong in HtmlDecorator. Here is the full file causing the problem:"
After that, a full HTML page is logged. I hope this helps me identify
the new error on GitHub Linux Java 16, because the same test works on
Windows and I have no idea how to remote-debug a GitHub CI build.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Mini refactoring, making the code a bit less verbose

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

There are two styles to convert a collection to an array: either using a pre-sized array (like c.toArray(new String[c.size()])) or using an empty array (like c.toArray(new String[0]).
In older Java versions using pre-sized array was recommended, as the reflection call which is necessary to create an array of proper size was quite slow. However since late updates of OpenJDK 6 this call was intrinsified, making the performance of the empty array version the same and sometimes even better, compared to the pre-sized version. Also passing pre-sized array is dangerous for a concurrent or synchronized collection as a data race is possible between the size and toArray call which may result in extra nulls at the end of the array, if the collection was concurrently shrunk during the operation.

Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>

Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>

Reports any String.indexOf() expressions which can be replaced with a call to the String.contains() method available in Java 5 and newer.

Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>

Reports for loops which iterate over collections or arrays, and can be replaced with an enhanced for loop (i.e. the foreach iteration syntax).

Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>

The version handling in LangUtil has been overhauled
to cope better with post 1.8 releases (JDK9 and JDK10 or 18.3
or whatever they call it). As part of this moved
to treating JDK9 as '9' rather than '1.9'. Also removed
duplicate version processing logic and had that defer to
the one place in LangUtil where we now deal with it.

Includes some generics tidyup in ajdoc. More ajdoc work
is necessary for Java10 because it removes the standard doclet
(old style). However trying to invoke the internal Javadoc
handler in Java10 is failing due to module visibility rules.

Modified test expectation system so it is possible to say
the test cares about one particular message and the rest
do not matter (prefix message string with '*') - crude but
quick.

Polished many places to exploit generics

Upgraded all the tests to work on Java8 - some serious changes
regarding ajdoc on Java8. Hopefully it has stayed backwards
compatible with earlier JDK versions (e.g. if using AspectJ 1.8.3+
with a JDK less than 8) but no explicit testing done for this.

Also fixed ajdoc tests to run correctly when executed via RunTheseBeforeYouCommit tests (previously they were not being run and silently failing).

57780: ajdoc package summary should not show synthetic information;  
57773: ajdoc crash;  
Cleaned up link generation, added support for arbitrary levels of type nesting.

57780: ajdoc package summary should not show synthetic information
57773: ajdoc crash

in other packages (again). Also, fix for nested types. Covers more than one
level of nesting. NOTE: the tool is currently not capable of producing
output for more than one level of nesting. Bug will be raised if Ron has
not already opened it.

in other packages (again). Also, fix for nested types.

- AJDT integration works
- generates documentation for all the AspectJ modules
- works on 1.3 and 1.4
- comments and Javadoc tags are properly preserved and resolved
 
Note that the hope is still for "declare" documentation to come in the form of a contribution.  

Getting it to work for our tree involved a bunch of bug fixes to deal with things like anonymous types.  To run from our tree in bootstrap mode use something like the attached batch script.  

I had to roll back some of Andy's fix to broken links: getRelativeComponent didn't work properly for internal anchor links (..html#<mumble>).  Andy, could you check this against the current thing against whatever was breaking for you, and ideally add that code patter to CoverageTestCase?

I added -XjavadocsInModel to make the addition of Javadoc strings to the ASM only happen when request it (prevent bloat of the model with strings.  The running time of ajdoc is now dominated by the compilation time.

for generating spacewar documentation.