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

Work in progress, relates to #70

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

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

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

- Usage texts are now printed to stdOut, no longer stdErr.
- 'java ...Main -?' no longer prints usage text twice (once to stdOut
  and then again to stdErr).
- AjdtCommand.inferKind: Usage texts are no longer mis-identified as
  warnings or errors just because they contain substrings "warning" or
  "error". Matching is now more precise, looking for "[warning]" and
  "[error]". But in that case the method would not be called anyway
  because errors and warnings are identified in other ways already. As a
  fall-back, the categories IMessage.ERROR and IMessage.WARNING still
  exist in the method.
- In case of compile errors, no usage message is printed anymore,
  because previously the user had to scroll up a lot in order to see the
  actual messages. This is also in line with ECJ. The same is true for
  warnings, but it was like this in Ajc already.
- AjdtCommand.inferKind: There is a new category IMessage.USAGE
  especially for AspectJ usage texts, which will be identified by string
  matching and then correctly handled (i.e. printed to stdOut, not
  stdErr).
- Usage text printing is no longer done in AspectJ but in the AspectJ
  "shadows" fork of JDT. This helps to get rid of some now obsolete code
  here.

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

Delete all properties from messages_aspectj.properties which were just
copied from Eclipse and basically the same. This not only gets rid of
duplicates but also eliminates differences found between upstream and
AspectJ strings which were just cause by errors or oversights during
manual upgrade.

TODO:
  - Find a way to print the '-X' options as info instead of yielding
    'abort', making it seem as if compilation failed and print the usage
    message to stdErr instead of stdOut.
  - Eclipse also has misc.usage.warn, not just misc.usage, i.e. usage
    info specifically for warning options. Make sure that AspectJ uses
    it consistently.
  - Find a way to merge AspectJ-specific options into the standard
    Eclipse usage text instead of completely replacing it, further
    reducing the need to merge and copy upstream content.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Renamed messages.properties to messages_aspectj.properties and moved to
a path identical with the Eclipse original resource file. Therefore, it
is now just treated as a localised version of it.

The new jdtcore-for-aspectj.jar already contains logic to use the new
locale. Hence, BuildArgParser no longer needs the static block to
initialise its own resource bundle, Eclipse JDT will automatically pick
it up.

The version string was also updated to the new Eclipse merge commit
hash + date + "Java16".

TODO: Strip down properties file in order to only contain delta to
Eclipse.

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

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

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

Reports on declarations of Collection variables made by using the collection class as the type, rather than an appropriate interface.

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

Reports Collection.addAll() and Map.putAll() calls after instantiation of a collection using a constructor call without arguments. Such constructs can be replaced with a single call to a parametrized constructor which simplifies code. Also for some collections the replacement might be more performant.

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

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 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>

This commit introduces some new methods into the
runtime Factory class and modifies code generation
to use them (and to use the form of the LDC bytecode
that loads class constants).

Prior to this AspectJ would discard ignore the ClasspathEntry
objects built by JDT and just work with the classpath as a string,
driving the JDT FileSystem to rebuild classpath entries again at
a later date using the string. This is more complex in Java9 because
the string representation was losing whether some entries came in
via modulepath.  ClasspathEntry construction for modulepath entries
is non trivial (since the module-info must be processed).

The new version will cache some of the ClasspathEntry objects (those
built for modulepaths) and do more work on the AspectJ side building
classpath entries in general. It now passes these entries to a
different FileSystem entry point rather than the entry point that
takes a string path.

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.

Signed-off-by: hsestupin <stupin.sergey@gmail.com>

Signed-off-by: hsestupin <stupin.sergey@gmail.com>