Improve usage text, error and warning output in batch compiler
- 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>
Strip down compiler messages to AspectJ-specific ones
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>
Begin migration to 'aspectj' locale for compiler messages
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>
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.