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>
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>
Bug#531694: generate more optional thisJoinPoint construction code
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).
Adjust how classpath entries manipulated for Java9 support
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.
Fix 436653: conditional aspect activation plus various polish
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.
fixes for 137235 (contributed by Ron): more intelligent logic for determining if a path entry is a jar/zip (don't just rely on suffix, some new .bndl files seem to be becoming popular...)
Support for "-Xset:name=value,name=value,name=value". The name/value data is stored in a properties object in the world and is accessible through getExtraConfiguration(). This will enable easier tailoring of weaver/world behaviour since you wont need to add new X option processing for every little thing. Should possibly only be used for tuning parameters.