[jira] [Comment Edited] (BCEL-187) Verification error when an invoke references a method defined in superclass

["Sarah Murray (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BCEL-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14351183#comment-14351183 ] 

Sarah Murray edited comment on BCEL-187 at 3/7/15 12:11 AM:
------------------------------------------------------------

[~jejecool], [Mark Thomas said on the mailing list that the following would help him commit this patch|http://markmail.org/search/?q=list%3Aorg.apache.commons.dev/#query:list%3Aorg.apache.commons.dev%2F+page:1+mid:lvm5vrr52mxgrikp+state:results]:

After looking at [BCEL-187] for a minute or two I can see a whole pile of work that needs to be done before I'd even think about committing anything. Just from that quick look:
1. Review the svn history to see if there are any pointers to which part of the JVM spec defines the restriction.
2. Review the JVM spec to see if I can see the restriction
3. Look at the byte code for the provided example to see which class the invoke opcode references. Better yet, write a disabled BCEL unit test to show this.
4. The structure of the test case looks odd. I suspect it aligns with other patches for other issues but nowhere is that explained.
5. The class files provided do not have any attached source. Without the source code, we have no idea (OK I could fire up a decompiler but that is another task) what is actually in those classes.

To put it another way, the current code asserts one behaviour. The bug report asserts another. No evidence is provided to support either position. Given that most (all?) the current committers likely to work on BCEL don't have a deep knowledge of the JVM specs some research is required to figure out which is correct. I've set out above how I'd do the research. I'm sure there are other, better approaches. 


was (Author: sarahkm1972):
[~jejecool] [Mark Thomas said on the mailing list that the following would help him commit this patch|http://markmail.org/search/?q=list%3Aorg.apache.commons.dev/#query:list%3Aorg.apache.commons.dev%2F+page:1+mid:lvm5vrr52mxgrikp+state:results]:

After looking at [BCEL-187] for a minute or two I can see a whole pile of work that needs to be done before I'd even think about committing anything. Just from that quick look:
1. Review the svn history to see if there are any pointers to which part of the JVM spec defines the restriction.
2. Review the JVM spec to see if I can see the restriction
3. Look at the byte code for the provided example to see which class the invoke opcode references. Better yet, write a disabled BCEL unit test to show this.
4. The structure of the test case looks odd. I suspect it aligns with other patches for other issues but nowhere is that explained.
5. The class files provided do not have any attached source. Without the source code, we have no idea (OK I could fire up a decompiler but that is another task) what is actually in those classes.

To put it another way, the current code asserts one behaviour. The bug report asserts another. No evidence is provided to support either position. Given that most (all?) the current committers likely to work on BCEL don't have a deep knowledge of the JVM specs some research is required to figure out which is correct. I've set out above how I'd do the research. I'm sure there are other, better approaches. 

> Verification error when an invoke references a method defined in superclass
> ---------------------------------------------------------------------------
>
>                 Key: BCEL-187
>                 URL: https://issues.apache.org/jira/browse/BCEL-187
>             Project: Commons BCEL
>          Issue Type: Bug
>          Components: Verifier
>    Affects Versions: 5.2
>            Reporter: Jérôme Leroux
>             Fix For: 6.0
>
>         Attachments: BCEL-187.patch, BCEL-187.zip
>
>
> Assuming a class A with a method foo() and a class B subclass of A. If an invoke opcode references the method B.foo() then the bytecode verifier raises an error with the following error message:
> {quote}
> Referenced method 'foo' with expected signature '()void' not found in class 'B'. The native verifier does allow the method to be declared in some superinterface, which the Java Virtual Machine Specification, Second Edition does not.
> {quote}
> I can't find where in the _Java Virtual Machine Specification, Second Edition_ this restriction is defined.
> The verification of the bytecode generated by the following code fails:
> {code:java}
> public class TestLegalInvokeInterface01{
>     public static void test1(Interface01 t){
>         t.run();
>     }
> }
> interface Interface01 extends Runnable {
>     
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)