Summary: | static method call from subclass signature is wrong | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Alexandre Vasseur <avasseur> |
Component: | Compiler | Assignee: | Alexandre Vasseur <avasseur> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | blocker | ||
Priority: | P1 | ||
Version: | DEVELOPMENT | ||
Target Milestone: | 1.5.0 M3 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Alexandre Vasseur
2005-07-18 09:25:01 EDT
don't know why but javap says: invoke static #2 const #2 = Method #3.#19; // alex/sam/AspectJBugMain.test:()V why is that AspectJBugMain there ? (1.5_3, both Sun and Jrockit ) javap shows the same thing under jdk 1.4 too. There was a change from 1.3 to 1.4 in the bytecodes generated for invoke calls. In the 1.3 spec, the spec. said you generate a call to the root defining type of the method. In 1.4 compilers were required to preserve the target type of the call. It looks very odd to see this for static methods too, but that seems to be what is happening. The getMethod() method was added to MethodSignature only as part of the annotation work done in M2 (so comparatively recent for the aspectj runtime library). Without looking, my guess is that it is not walking up the hierarchy correctly to find the method in this case. I don't think MethodSignature.getMethod() should ever return null so that's definitely a bug! note that also means toShort/LongString provides a wrong information as well (this even in old version) given what you describe, should the toShort/LongString give the name of the base class or not (currently: not, it has the name of the class that is in the bytecode from the compiler)? I think we need to correct class name instead, ie that the issue is not in runtime/ but in the shadow signature creation down in the weaver/ thoughts ? i have changed the bcelshadow when it gets created odd that we were having a match - there might be duplicate logic now somewhere fixed close when ship was M3 remind was M3 remind |