Adjust how classpath entries manipulated for Java9 support
Prior to this AspectJ would discard ignore the ClasspathEntry
objects built by JDT and just work with the classpath as a string,
driving the JDT FileSystem to rebuild classpath entries again at
a later date using the string. This is more complex in Java9 because
the string representation was losing whether some entries came in
via modulepath. ClasspathEntry construction for modulepath entries
is non trivial (since the module-info must be processed).
The new version will cache some of the ClasspathEntry objects (those
built for modulepaths) and do more work on the AspectJ side building
classpath entries in general. It now passes these entries to a
different FileSystem entry point rather than the entry point that
takes a string path.
Multiple changes here:
- annotation unpacking is smarter and if it only needs runtime
retention annotations it uses reflection and doesn't unpack the
bytes to discover class level retention annotations.
- Reflection worlds are shared if for the same classloader.
Took the code from the patch submitted by Mario Ivankovits
in bug 520597 and made some improvements to make (hopefully)
better use of memory. Some basic tests added.
On Java9 cannot rely on URLClassLoader being found from which
to determine classpath so use the environment variable. This may
have issues if loaders are being constructed that specifically
deviate from the java.class.path.
Important to ensure we generate it of the right version as it may
end up containing code derived from a particular class that needs
a be run with a certain level of verifier. In this case if
inserting invokestatic targeting a interface method, we need to
be using something later than a java 1.2 level class file.
Issue it due to split packages (see comments in code). Don't want to
debug this further right now, possibly needs a command line flag passing
to the JVM that runs the test, so these tests need forking.