This change affects both top-level subdirectory names as well as
Eclipse plug-in feature names. Perhaps it would have been possible to
change only the latter, but I don't like the idea of the two being
different.
These name changes fix three Eclipse plug-in warnings of the form:
Illegal value '...-feature' for attribute 'id'.
Legal token characters are "a-z", "A-Z", "0-9", "_". Tokens
must be separated by "."
I'll be the first to admit that I know nearly nothing about Eclipse
plug-in development. If changing these plug-in feature IDs has
broader implications that the automated regression tests won't detect,
then I probably overlooked them too. I would greatly appreciate
skeptical review of this change by someone who knows Eclipse plug-in
development well.
Note that personal Eclipse workspaces may need some manual adjustment
after this change. The three "...-feature" Eclipse projects should be
removed from the workspace, and the three corresponding "..._feature"
Eclipse projects should be added. If you do your git pull using
Eclipse's team features, perhaps it is smart enough to do this for
you? I don't know, but it wouldn't surprise me if fixing things
manually were still needed even in that case.
Specifically, this will run the "javadoc" goal of the
"maven-javadoc-plugin" and the "plugin-source" goal of the
"tycho-source-plugin" whenever Eclipse does a full build. It will not
run these on incremental builds, though. Maven plugins in general are
usually not designed with incremental execution in mind, so rerunning
them on every incremental build turns out to be too sluggish in
practice.
Previously, M2Eclipse would occasionally notice these two plugins,
realize it didn't know what to do with them, and produce Eclipse error
diagnostics that were difficult to resolve. With this change we are
telling Eclipse's Maven builder to just run the plugins in the natural
way even though M2Eclipse has no special handling built-in for them.
Fixes#198, much to my relief.
I would not bother to fix indentation by itself, but it makes sense to
fix this indentation now in advance of some larger changes coming to
this file soon.
In modern Java, we would not need to do this. Java 1.8 can infer the
generic type, which would allow us to write simply
"Collections.emptySet()" instead of
"Collections.<TypeReference>"emptySet()". Unfortunately, Android is
behind the times, so this specific project targets Java 1.5. That
older Java definition does not do the inference we would want here, so
we have to be explicit instead.
The former returns Set<T> for any T, whereas the latter merely returns
a raw Set. Using the former instead of the latter fixes four Eclipse
warnings about using raw generics.
Julian added this in a recent commit, but has told me that he does not
think it is necessary, and that I am free to remove it if it is
causing trouble. Removing this does indeed fix one Eclipse error
diagnostic: "Default encoding (UTF-8) for library '.' should be
removed as the workspace does not specify an explicit encoding."
In Eclipse projects that currently have no definite or potential
resource leaks, treat any such diagnostics as errors in the future.
In `com.ibm.wala.core`, enable warnings about definite or potential
resource leaks. Previously these diagnostics were turned off entirely
in this project. So we actually end up with more warnings now than we
had before, but they are all warnings we should eventually look into.
These are all problems that Eclipse can detect, but that it detects no
instances of right now. Treating these as warnings instead of errors
should help prevent us from slipping backward in the future.
This fixes an Eclipse Plug-In Development warning that reads "Source
folder 'dat/' does not have the output folder in corresponding output
entry 'output..'." It is not the default quick fix that Eclipse
suggests, and I am *definitely* not sure that this is the right way to
fix this problem. (I have nearly zero knowledge of Eclipse plug-in
development.)
That being said, this change does make the warning go away, and `mvn
clean install` without `-DskipTests` still succeeds.
In particular, per the corresponding Eclipse warning, "The
`javacProjectSettings` build entry should be set when there are
project specific compiler settings".
In particular, be quiet about being unable to resolve
"org.eclipse.jdt.launching.macosx", which was already marked as
`optional` anyway. I assume that I'm missing this because I'm not
developing on MacOS, and that it would be present if I were. Can
someone using MacOS confirm this?
Of course, doing nothing isn't always the right behavior. Sometimes a
previously-unhandled value is truly unexpected and one should fail by
throwing an exception. It may not always be clear whether an
exception or doing nothing is the right choice. For some `switch`
statements affected by this commit, I initially guessed that throwing
an exception was the right default behavior, but was proven wrong when
doing so caused WALA regression test failures. That's strong evidence
that the unmatched values were not really unexpected, but merely
should have been handled by doing nothing as before.
Previously each of these `switch` statements would implicitly do
nothing if an unanticipated `enum` value came along. My impression is
that each of these `switch` statements is supposed to be exhaustive,
such that an unexpected (unhandled) value should never appear. If one
does, we should recognize it and complain loudly.
Of course, sometimes the right behavior for previously-unhandled
values is to do nothing. It may not always be clear whether an
exception or doing nothing is the right choice. For this commit,
WALA's regression tests still pass even with the possibility of
throwing an exception for unexpected values. If we assume that the
test suite is thorough, that tells me that throwing an exception is
the right policy for each `switch` statement that I'm changing here.
This `switch` statement currently covers all possible values of the
`enum` it is testing. However, if a new value were introduced in the
future, the `switch` would have been silent about it instead of
printing a debug message as is done in all of the other cases. Better
to print *some* kind of debug in the default case too.
This `switch` statement currently covers all possible values of the
`enum` it is testing. However, if a new value were introduced in the
future, the `switch` would have allowed control-flow to fall through
by default instead of throwing an exception as is done in all of the
other cases. Better to throw *some* kind of exception in the default
case too.
Eclipse was warning that these `switch` statements had no `default`
cases. Each did have some default behavior, but implemented outside
the `switch`. By moving the default behavior into a `default` case
within the `switch`, we eliminate a static warning with no change
whatsoever to the run-time behavior.