Generally, overriding one means you should be overriding the other
too.
Also, configure Eclipse to treat any similar cases as errors, rather
than merely warnings.
In the `com.ibm.wala.util` project, configure Eclipse to treat any
future violations of this as errors, not merely warnings.
However, in `com.ibm.wala.cast.java.test.data`, configure Eclipse to
silently ignore missing @Override annotations. The JLex code in this
project is machine-generated, and we don't have a way to get the
generator to produce @Override annotations.
In general, test code may do all sorts of things that would be
considered poor style in production code. I assume that these
potentially-static methods are declared non-static by design.
These should mostly be things that we've already decided earlier that
we explicitly don't want to "fix" because they simply disagree with
the WALA project's coding style.
The additional diagnostics are ones that were previously being
ignored, but which we seem to have been ignoring by default rather
than as a conscious choice.
For diagnostics of which we currently have *zero* instances, treat
these as errors rather than merely warnings. The intent is to
permanently lock out future regressions of things we've completely
fixed. In the future, whenever we fix the last instance of a given
warning in a given Eclipse project, we should also promote that
diagnostic to an error to keep things clean into the future.
The Eclipse IDE shows no such diagnostics, so it would be nice to
treat them as errors if any appear in the future. However, the batch
Tycho-based build ("mvn clean install -DskipTests") does find and
report numerous such violations. This discrepancy is strange; Manu
and I currently don't know why it's happening. We suspect some
Maven-related weirdness may be creating slightly different
environments in the Eclipse GUI versus the command-line-driven build.
* Fix pom.xml to be like other projects
* Check for existence of nodejs download before re-downloading
* Fix Eclipse config files to be like other projects
This fixes one Eclipse "The JRE container on the classpath is not a
perfect match to the 'JavaSE-1.7' execution environment" warning in
the "Plug-in Development" category.
This fixes five Eclipse "Source folder '...' does not have the output
folder in corresponding output entry 'output..'" warnings in the
"Plug-in Development" category.
Previously some of these were accessing such fields through a subclass
of the declaring class. That creates an unnecessary extra inter-class
dependency lower in the type hierarchy than necessary.
Also, suppress this warning in an automated test input where the
indirect static accesses are explicitly intentional.
This test code is intentionally crafted to use instances to access
static methods. Eclipse's recommendation to access those methods
directly is, therefore, counterproductive.
These methods access only static members. They are methods of a final
class, which means no subclass can ever override these methods and use
dynamic dispatch to choose the implementation at run time. So
declaring these methods static is (statically) safe.
The method itself accesses only static members. The fact that it is
final means no subclass can ever override this method and use dynamic
dispatch to choose the implementation at run time. So declaring this
method static is (statically) safe.
Ben Liblit
Julian Dolby
Julian Dolby
Manu Sridharan