2) make instrumentor preserve the names of jar entries and classes as
they are input, rather than recomputing class names when writing the
output jar. This usually makes no difference, but can preserve broken
structures when the input jar file has mismatches between class names
and its entry names.
We put all the jar files (the testdata jar, JLex, etc.) in the root
directory now, and set up the build.properties so that these jars get
copied into the final plugin jar, making the tests work properly from
maven. We also still copy the jars into the bin/ directory, so the
Eclipse launchers still work.
These tests create FileModules for certain class / source files,
and hence assume those files are sitting in the filesystem. We
should come up with a better fix here.
- Annotation support
- Properly fix path-with-spaces bug.
- fix bug involving paths with spaces
- add a simple driver for building a call graph via a scope file
- Properly return null as default constructor of an array.
- organize imports
- better handling of missing bytecodes
- javadoc
- test fix
- small Javadoc fix
- added date-property.js
- 1) added InstanceKey.getCreation sites and its implementations 2) fixes for issues with keys representing dynamic properties i) all properties are converted to strings,
- publicize method makeClasspath(). deprecate quoteStringIfNeeded()
- organize imports
- javadoc
- renamed classes to make relationship to mod-ref analysis clearer
- add support for lexical writes
- Code to compute transitive lexical accesses of methods.
- extract some generally useful code from ModRef
- Generate proper InstanceFieldKeys for property accesses with Numbers.
- rewrite to make hardest test appear last
- fix test to properly check reachability
- add an array test that doesn't quite work
- add method to get a PointerKey for a global
- compare FieldValueDispatch objects based on CGNode as well
- Handle duplicate field names between subclass and superclass.
In some cases, class files will have non-abstract methods with no
bytecodes (e.g., stubs for compilation purposes). While such a class
file is invalid, we want to enable clients to handle such an error.
With these changes, Shrike will throw an InvalidClassFileException for
such cases, and WALA's IR construction code will throw a
WalaRuntimeException.