Bug 42612 - accessing full signatures of local variables that contain generics
Summary: accessing full signatures of local variables that contain generics
Alias: None
Product: BCEL - Now in Jira
Classification: Unclassified
Component: Main (show other bugs)
Version: 5.2
Hardware: PC Windows XP
: P2 enhancement
Target Milestone: ---
Assignee: issues@commons.apache.org
Depends on:
Reported: 2007-06-06 22:16 UTC by D. Babich
Modified: 2008-02-02 11:33 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description D. Babich 2007-06-06 22:16:52 UTC
LocalVariable object not able to return full signature that contains generics.

Example: I have crated Foo class with the following method:
public void test(){
   ArrayList<Integer> localVar = new ArrayList<Integer>();
After creating JavaClass from Foo and accessing test() method and its local 
variable, signature reported for localVar is "java.util.ArrayList", where 
Integer generic part is truncated. However, after inspecting the ConstantPool 
for the Foo class, it does contain CONSTANT_Utf8[1]
("Ljava/util/ArrayList<Ljava/lang/Integer;>;"). Why not simply set the 
SignatureIndex of the localVar to the correct index within the ConstantPool 
that also includes the Integer part, or allow LocalVariable to also 
getAttributes(), where the Signature attribute is properly set to the full 
signature that includes Integer, as for methods.
Comment 1 Torsten Curdt 2007-06-06 23:43:04 UTC
please try BCEL trunk
Comment 2 D. Babich 2007-06-13 13:46:49 UTC
(In reply to comment #1)
> please try BCEL trunk

Could you please provide more information on BCEL trunk. If BCEL trunk relates 
to source repository (web access) @ 
http://svn.apache.org/repos/asf/jakarta/bcel/trunk, I found nothing that 
helped. Thanks. 

Comment 3 Charlie Nolan 2007-06-14 03:27:53 UTC
Torsten means that you should download & compile a copy of the current trunk
version (from the SVN) and see if the bug still appears there.
Comment 4 Torsten Curdt 2008-02-02 11:33:36 UTC
Charlie is correct. Do you need further help on this? What's the status?