You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Emmanuel Bourg (JIRA)" <ji...@apache.org> on 2014/04/24 14:11:17 UTC

[jira] [Updated] (BCEL-13) ConstantPoolGen.lookupClass(String) finds LAST entry rather than first

     [ https://issues.apache.org/jira/browse/BCEL-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Bourg updated BCEL-13:
-------------------------------

      Description: 
I have discovered a class file that has multiple CONSTANT_Class entries in the ConstantPool that point to the same CONSTANT_Utf8 class name string.  The ConstantPoolGen.lookupClass(String) method seems to return the index for the LAST of the two CONSTANT_Class entries instead of the first.  Details are available from:
http://www.markcrocker.com/~mcrocker/Computer/Purifier/wrongClassrefIssue.shtml

This is a problem because I am attempting to create pure Java J2ME preverifier (The Purifier: http://www.markcrocker.com/~mcrocker/Computer/Purifier/). 
Ideally, it should produce the same StackMaps as SUN's preverifier.  However, in the case of this unusual class, it cannot because it uses BCEL and BCEL's lookupClass produces a different index than SUN's preverifier for the particular class that happens to have two possible indecies.

  was:
I have discovered a class file that has multiple CONSTANT_Class entries in the
ConstantPool that point to the same CONSTANT_Utf8 class name string.  The
ConstantPoolGen.lookupClass(String) method seems to return the index for the
LAST of the two CONSTANT_Class entries instead of the first.  Details are
available from:
http://www.markcrocker.com/~mcrocker/Computer/Purifier/wrongClassrefIssue.shtml

This is a problem because I am attempting to create pure Java J2ME preverifier
(The Purifier: http://www.markcrocker.com/~mcrocker/Computer/Purifier/). 
Ideally, it should produce the same StackMaps as SUN's preverifier.  However, in
the case of this unusual class, it cannot because it uses BCEL and BCEL's
lookupClass produces a different index than SUN's preverifier for the particular
class that happens to have two possible indecies.

         Priority: Minor
      Environment: URL: http://www.markcrocker.com/~mcrocker/Computer/Purifier/wrongClassrefIssue.shtml  (was: Operating System: All
Platform: All
URL: http://www.markcrocker.com/~mcrocker/Computer/Purifier/wrongClassrefIssue.shtml)
    Fix Version/s: 5.2
         Priority:   (was: P3)
         Severity:   (was: normal)

> ConstantPoolGen.lookupClass(String) finds LAST entry rather than first
> ----------------------------------------------------------------------
>
>                 Key: BCEL-13
>                 URL: https://issues.apache.org/jira/browse/BCEL-13
>             Project: Commons BCEL
>          Issue Type: Bug
>          Components: Main
>    Affects Versions: 5.0
>         Environment: URL: http://www.markcrocker.com/~mcrocker/Computer/Purifier/wrongClassrefIssue.shtml
>            Reporter: Mark Crocker
>            Assignee: Apache Commons Developers
>            Priority: Minor
>             Fix For: 5.2
>
>
> I have discovered a class file that has multiple CONSTANT_Class entries in the ConstantPool that point to the same CONSTANT_Utf8 class name string.  The ConstantPoolGen.lookupClass(String) method seems to return the index for the LAST of the two CONSTANT_Class entries instead of the first.  Details are available from:
> http://www.markcrocker.com/~mcrocker/Computer/Purifier/wrongClassrefIssue.shtml
> This is a problem because I am attempting to create pure Java J2ME preverifier (The Purifier: http://www.markcrocker.com/~mcrocker/Computer/Purifier/). 
> Ideally, it should produce the same StackMaps as SUN's preverifier.  However, in the case of this unusual class, it cannot because it uses BCEL and BCEL's lookupClass produces a different index than SUN's preverifier for the particular class that happens to have two possible indecies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)