Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Thu, 24 Apr 2014 12:11:17 +0000 (UTC)
From: "Emmanuel Bourg (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12619179.1047778976000.171515.1398341477783@arcas>
In-Reply-To: <JIRA.12619179.1047778976000@arcas>
References: <JIRA.12619179.1047778976000@arcas>
Subject: [jira] [Updated] (BCEL-13) ConstantPoolGen.lookupClass(String)
 finds LAST entry rather than first
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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)