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.
In general, my approach was to try to eliminate each unused parameter
using Eclipse's "Change Method Signature" refactoring. That did not
always succeed: a parameter may be unused in some base class method,
but then be used in subclass's override of that method. In cases
where refactoring to eliminate a parameter failed, I instead annotated
the parameter with '@SuppressWarnings("unused")' to silence the
warning.
Note: this group of changes creates a significant risk of
incompatibility for third-party WALA code. Some removed parameters
change externally-visible APIs. Furthermore, these changes do not
necessarily lead to Java compilation errors. For example, suppose
third-party code subclasses a WALA class or interface, overrides a
method, but does not annotate that method as @Override. Removing a
parameter means that the third-party method no longer overrides. This
can quietly change code behavior without compile-time errors or
warnings. This is exactly why one should use @Override wherever
possible, but we cannot guarantee that third-party WALA users have
done that.
The fix is to add "static" where appropriate, of course. I've also
simplified calls to such methods to reflect the fact that they no
longer need a specific object to call the method on.
In projects that contain test inputs, I've left the non-static
declarations unchanged, and instead downgraded the warning to be
ignored. In all other projects, this warning has been upgraded to an
error.
Access is provided via corresponding methods in FieldImpl, ShrikeCTMethod and ShrikeClass.
Since we do not currently have implementation of these methods for front-ends other than Shrike, these new methods are not yet made available in the corresponding interfaces.
tentative beginnings of refactoring to separate Java-specifics: so far IClass.getModifiers() and IMethod.getDeclaredExceptions() are declared to throw UnsupportedOperationException
git-svn-id: https://wala.svn.sourceforge.net/svnroot/wala/trunk@3200 f5eafffb-2e1d-0410-98e4-8ec43c5233c4
1) The visitors nested in the SSAPropagationCallGraph have become static classes so that they can be reused in a delegation pattern for the cross-language call graph builder.
2) The ClassHierarchy is now encapsulated behind an IClassHierarchy interface to allow for a CrossLanguageClassHierarchy that delegates to a set of child hierarchies, one for each language. The internals of the ClassHierarchy are almost entirely unchanged
3) There is now a new Language interface in com.ibm.wala.classLoader, and all IClassLoader objects have to know what language they load for. This language object now encapsulates a few language-specific options that were previously hacked into the AnalysisOptions object.
git-svn-id: https://wala.svn.sourceforge.net/svnroot/wala/trunk@1212 f5eafffb-2e1d-0410-98e4-8ec43c5233c4