In particular, using the "all" package (which includes source) allows
IntelliJ IDEA to provide autocompletion and other nice features that
are unavailable when using the "bin" package.
Fixes#322
We add an option `createPhantomSuperclasses` to `ClassHierarchy`. When set, if a superclass is missing, we create a new `PhantomClass` in its place and allow the subclass to be added.
To use, you can create the `ClassHierarchy` with the new `ClassHierarchyFactory.makeWithPhantom` methods.
We already had some IntelliJ IDEA project metadata files in ".idea".
I've revisited and updated those now that I have more experience with
Gradle + IntelliJ IDEA + Git. I think this now represents a better
set of decisions regarding what does and does not belong in version
control.
This commit also extends "README-Gradle.md" with clear instructions on
how to bringup WALA as a top-level IntelliJ IDEA project. The
instructions are of a similar flavor to the Eclipse instructions that
were already present, though the details vary. Most notably, with
IntelliJ IDEA you should *open* WALA as an existing project,
not *import* it as a new Gradle project derived from "build.gradle".
This is exactly the reverse of what one should and shouldn't do for
WALA in Eclipse.
When IntelliJ IDEA imports WALA's Gradle configuration, it creates
what is calls a "module" for each sourceSet of each Gradle subproject.
In so doing, it automatically picks up the source and resource
directories used by each of these sourceSets. Unfortunately, IntelliJ
IDEA does not allow multiple modules to share a single root directory
as their source or resource directories, and that's exactly what was
going on with the "example-src" subdirectory under
"com.ibm.wala.cast.js.test.data".
This revised Gradle configuration still has is copying the necessary
"example-src" resources to the appropriate locations for use as test
resources. But IntelliJ IDEA no longer treats "example-src" as a root
directory for resources in the automatically-generated modules. So
now we get along nicer with IntelliJ IDEA while keeping everything
working with Gradle as well.
This task serves a similar role to the "afterEclipseBuildshipImport"
task used with Eclipse. It should only be necessary to build this
task once: in a freshly checked-out tree, just after opening it for
the first time in IntelliJ IDEA.
Ideally this extra setup task would be triggered automatically using
the "Tasks Activation" feature of IntelliJ IDEA's Gradle support.
Unfortunately, "Tasks Activation" settings are recorded in
".idea/workspace.xml", which is used for non-revision-tracked personal
settings.
If Gradle dependencies are set up correctly, then it should be
possible to build any subproject starting with a pristine tree.
These take too long to use for every commit, pull request, etc. But
running an extensive test like this periodically (e.g., weekly) seems
reasonable.
Boxing a primitive using the constructor ("new Integer(4)") always
creates a distinct new boxed instance. That's rarely what you need,
and in fact all of those constructors have been deprecated in Java 9.
Using the static "valueOf" method instead ("Integer.valueOf(4)") can
give better performance by reusing existing instances. You no longer
get a unique boxed object, but generally that's OK.
"javah" was deprecated in Java 9, and has been removed entirely in
Java 10. The right way to generate headers now is by using the "-h"
flag to "javac". When "javac" is run in this way, it still generates
bytecode too. So ideally, we'd run "javac" just once to generate
bytecode and headers simultaneously. Fortunately, the Gradle JNI
plugin at <https://github.com/wpilibsuite/gradle-jni> help us do this
cleanly. Nice!
Previously we were compiling and linking "smoke_main", but not
actually running it as part of automated testing. I simply overlooked
this in the process of recreating the Maven build logic in Gradle.
Now we run "smoke_main" when testing, which turns out to be a pretty
good test of our management of both Java search paths as well as
linker / shared library search paths.
We now use "-rpath" on both Linux and macOS. This linker flag sets
the ELF RPATH on Linux, and the "@rpath" attribute on macOS, but
effectively it's doing the same thing, and that same thing is exactly
what we want. I think.
On Linux, we also now look for the JVM shared library in three
different places. The library has moved between Java 8 and 9, and
even on Java 9 it goes in a different place on Fedora 28 versus Ubuntu
16.04.
According to
<https://docs.gradle.org/current/userguide/native_software.html>,
"When you assemble dependents of a component, the component and all of
its dependents are compiled and linked, including any test suite
binaries." So it's intentional that the "assemble" task causes
creation of the smoke_main executable and xlator_test shared library.
Nothing TODO here; the current behavior is as designed.
The existing code worked fine under Java 8, but Java 9 fails to
resolve type constraints unless it has more explicit information about
at least one of the arguments to anyOf. Weird.
WALA itself does not use any JUnit 4.12 features. However, I am
working on a WALA-based project that does require JUnit 4.12. Mixing
jar versions is a path to madness. So if the WALA maintainers don't
mind, it would make my life easier if WALA itself required JUnit 4.12.
Otherwise, I need to maintain that 4.11/4.12 difference indefinitely
as a divergence between official WALA and my WALA variant.
I suppose an alternative could be to let the JUnit version be
specified externally somehow. I have not explored this option in
depth, but could look into it if simply moving to JUnit 4.12 is
undesirable.
Ben Liblit
Manu Sridharan
Manu Sridharan
Julian Dolby