More testcases for overweaving and better handling of WeaverStateInfo
to avoid the dreaded problems deserialized the 'special key' used
to store diffs.
With these changes once a class is woven via overweaving we switch
the diff we store in the weaverstateinfo to 0 byte array (indicating
overweaving happened for later weavers that see it). We also stop
writing the special 'key' into the attribute and avoid looking-for
and attempting to replace it at the end of weaving.
Initial cut at bug 535086 - pertypewithin and non vis types
In this version unless you specify an aspect is privileged then the
pertypewithin clause will not match types not visible from the aspect
(private types or default vis types in another package)
Debating whether to change this to not require privileged.
Bug#531694: generate more optional thisJoinPoint construction code
This commit introduces some new methods into the
runtime Factory class and modifies code generation
to use them (and to use the form of the LDC bytecode
that loads class constants).
The version handling in LangUtil has been overhauled
to cope better with post 1.8 releases (JDK9 and JDK10 or 18.3
or whatever they call it). As part of this moved
to treating JDK9 as '9' rather than '1.9'. Also removed
duplicate version processing logic and had that defer to
the one place in LangUtil where we now deal with it.
Includes some generics tidyup in ajdoc. More ajdoc work
is necessary for Java10 because it removes the standard doclet
(old style). However trying to invoke the internal Javadoc
handler in Java10 is failing due to module visibility rules.
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.
If an anonymous class calls a method ITD'd onto one of its own
supertypes (e.g. new A() { xx(null); }) then it can be reported
as an ambiguous method invocation on Java8. There is different
handling for Java8 that is revealing an issue. The intertype
method declarations are recorded in a member finder attached to the
target type (A in this case). When the local type binding is
built it gets all the methods from supertypes added to it - this
unfortunately includes the ITD method. Then later when something
asks for all 'xx' methods on A, it finds the ITD method from when
A was constructed and an additional copy from the member finder.
The quick fix is for the member finder to use a set rather than
list when answering 'what are the xx methods'. If this proves
a problem down the line the deeper fix would be to avoid including
ITDs when the local type binding is built.