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>

This involves replacing references in weaver application code as well as
a few tests.

In order to make AspectJ weaver + tools contain a relocated ASM version,
I added a Maven Shade relocation step after Maven Assembly created the
uber JARs. Relocation works for both binaries and sources and also
encompasses Class::forName calls like in class AsmDetector.

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

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

The new string AjcTestCase.CLASSPATH_ASM_RENAMED dynamically determines
the 'asm-renamed' location from the classpath, system property
'java.class.path'.

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

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

After Ajc usage text output is filtered into its own category
IMessage.USAGE now - see commit @31b2d60b - some tests in module
'org.aspectj.ajdt.core' were failing. I fixed and also improved them a
bit.

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

Keep only ASM 2.0 binary because it is still used in UnweavableTest
which uses an old ASM API, e.g. with a ClassWriter constructor which no
longer exists.

Also add JarJar 1.3 library because it is needed by an Ant task in
lib/asm/build.xml.

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

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

This is the same for successful tests in class CompilationResult.

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

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 the copying of array contents to a collection where each element is added individually using a for loop. Such constructs may be replaced by a call to Collection.addAll(Arrays.asList()) or Collections.addAll().

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

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

Reports "unboxing", e.g. explicit unwrapping of wrapped primitive values. Unboxing is unnecessary under Java 5 and newer, and can be safely removed.

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>

- update to more recent JDT to pickup Nestmates fix
- bcel updated for NestMembers/NestHost attributes
- testcases for nestmates

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.