Community
Participate
Working Groups
In some environments, a developer wants to exploit AspectJ by parsing pointcuts of their own construction (pointcuts not necessarily coming from a source file or aop.xml). In these situations there is a need to conjure up a pointcut parser and use it. This needs the following pieces of AspectJ to be performant: - construction of a pointcut parser - parsing of a pointcut expression string Under Spring IDE we are seeing some situations where construction is expensive (500ms>1000ms). This appears to be due to the setClassLoader call that happens internally whilst building the parser and the ReflectionWorld that causes to come into existence. My own tests show no such problem (using the context classloader in a JUnit test) but under Spring IDE the context classloader is a little more 'full' of stuff. The messyness of the classloader ought to be irrelevant when constructing a world, but it appears to have an impact.
for now it is being tackled in a different way by partially caching the types loaded. the speed up with that change means this isn't as urgent as it was.