Using constructor references apparently pulls in something involving
nullness annotations. However, we don't actually build with a jar
file that defines those annotations, so this leads to Eclipse build
failures. I don't know the right way to add such a jar file to our
current configuration mishmash of Ant, Maven, and Eclipse. So the
easier thing to do is just disable annotation-based nullness analysis.
I doubt we were getting any benefit from such an analysis anyway,
given that WALA itself doesn't use those annotations at all.
Eclipse's automated code clean-up tool did most of the heavy lifting
here: it specifically has a clean-up option for converting functional
interfaces to lambdas. I merely had to revert the automated changes
for a single enumeration class for which it produced invalid results,
and for a few test inputs that apparently aren't set up to be compiled
with Java 8.
Previously FilterIterator was very permissive regarding the type
relationships between the original iterator, the filtered iterator,
and the predicate used to prune the former down to the latter. Now we
enforce those relationships more strictly, including proper use of
covariant ("<? extends T>") and contravariant ("<? super T>")
polymorphic type parameters where appropriate.
This lets us get rid of seven suppressed warnings about generic types
and/or unchecked conversions. It also moves us toward being able to
use modern Java features like lambdas and streams more easily.
Julian Dolby assures me that WALA is now supposed to be using Java 8
everywhere. This covers nearly all remaining places that I can find
where an earlier Java version was still being used. (The few
exceptions are places where switching to Java 8 causes test failures.
I'll address those separately, probably by reaching out to the WALA
maintainers for help.)
E-mail exchanged with Julian Dolby suggests that this is the right
thing to do, and that it should have been done back when we converted
other parts of the build configuration to Java 8.
These two modules refer to "AST.JLS8". If you have Java 9 installed,
then "AST.JLS8" is marked as deprecated, and we can a warning unless
we suppress or disable the deprecation warning wherever "AST.JLS8" is
used. However, if you don't have Java 9 installed, then "AST.JLS8" is
not deprecated, and trying to suppress deprecation warnings where
"AST.JLS8" is used instead produces warnings about unnecessary warning
suppression. Aagh! Turning off the deprecation warnings entirely for
these two modules seems like the only sane compromise.
Removing fixes one Eclipse error diagnostic: "Default encoding (UTF-8)
for library '.' should be removed as the workspace does not specify an
explicit encoding."
This reapplies the fox from ecd1ff72fe,
which was reverted (apparently unintentionally) as part of a larger
group of changes in 8d65788aef.
Near as I can tell, the requests for deprecated versions here are
intentional. The non-deprecated version (AST.JLS9) is the latest and
greatest, but as far as I can tell we really do want the older version
here.
This is similar to 6caecce3e7, though in
that case JLS8 was the non-reprecated latest version and we were still
asking for JLS3.
currentSite should be ThreadLocal because not having this screws up a lot of the instrumentation-based dynamic call graphs we generate for the shootout benchmarks.
I have also conditionally changed how the string of the currentSite is created based on the output format that Julian came up with for the dynamic call graph. This support is necessary, because the Java std libraries are not instrumented. Therefore, they would appear as if calls from them show up from nowhere in the log that WALA generates for the dynamic call graph. This fix make those calls originate from a fake library BLOB node in the call graph.
- adding multi-flow AnalysisOption
- enable/disable special handling of zero-length arrays
Both are required to enable precise analysis of some Dacapo benchmarks when using the Averroes-generated summaries
This fixes two Eclipse Plug-in Development warnings of the form "Key
'...' is not found in localization properties file:
OSGI-INF/l10n/bundle.properties".
This fixes two Eclipse Plug-in Development warnings of the form "The
'javacProjectSettings' build entry should be set when there are
project specific compiler settings".
This removes three Eclipse Plug-in Development warnings of the form
"This plug-in does not export all of its packages"
I assume that omitting some exports is OK, because apparently nothing
else fails to build against these. If an omitted export were needed
elsewhere, something would fail to build.