In generic type lists, after a '*' in any type parameter list, sometimes
the '*' (which should be converted to '?') itself and always the
subsequent parameters would be missing from the signature:

  - '[Pjava/util/Collection<*>;' yielded
    'java.util.Collection<>[]', but should be
    'java.util.Collection<?>[]'

  - '[Pjava/util/Map<*Pjava/util/List<[Ljava/lang/Integer;>;>;' yielded
    'java.util.Map<?>[]', but should be
    'java.util.Map<?,java.util.List<java.lang.Integer[]>>[]'

This is now fixed.

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

Fixes #211. Previously, '?' was not converted to '*' in
UnresolvedType.nameToSignature, but kept as-is. That is why - falsely -
it was necessary to handle the '?' case in UnresolvedType.forSignature
at all, reading this kind of bogus signature and creating a type for it
in TypeFactory.createTypeFromSignature. This, ironically, led to correct
JVM generic type signatures containing '*' not being handled at all.

The conversion should now work correctly both ways.

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

Fixes https://github.com/eclipse/org.aspectj/issues/24, both the array
return type matching as such as well as matching dimensionality patterns
correctly. E.g., 'Foo*[]' is not the same as 'Foo*[][]'. This also works
correctly in combination with asterisks, even for primitive types, i.e.
'in*[][]' correctly matches a 2-dimensional array of 'int'.

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

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>

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>

In this version unless you specify an aspect is privileged then the
pertypewithin clause will not match types not visible from the aspect
(private types or default vis types in another package)

Debating whether to change this to not require privileged.