[jboss-jira] [JBoss JIRA] (JASSIST-188) CtClass detach does not completely clean class from pool.

[Shigeru Chiba (JIRA)]

    [ https://issues.jboss.org/browse/JASSIST-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778380#comment-12778380 ] 

Shigeru Chiba commented on JASSIST-188:
---------------------------------------

I will release within a few days.
                
> CtClass detach does not completely clean class from pool.
> ---------------------------------------------------------
>
>                 Key: JASSIST-188
>                 URL: https://issues.jboss.org/browse/JASSIST-188
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.17.0-GA
>         Environment: Ubuntu, Windows, JDK 1.6/1.7
>            Reporter: J D
>            Assignee: Shigeru Chiba
>            Priority: Critical
>             Fix For: 3.18.0-GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Description:
> Class with same qualified name cannot be recreated even if previous class was detached  successfully from pool. 
> Creation#1: Consider class eg.foo.MyClass is created using default pool and private int myArg1 private member along with some getter/setter methods. After its creation, the CtClass.detach is invoked successfully.
> Creation#2: Subsequently, create eg.foo.MyClass using same default pool succeeds but any attempt to add members e.g. private int myArg1 fails with error: 
> Field myArg1 in eg.foo.MyClass is private. 
> Bug Analysis:
> MemberCodeGen.isAccessibleField has f.getDeclaringClass from Creation#1 but thisClass is from Creation#2. This  was traced to MemberResolver.invalidNamesMap. When Creation#1 detached the CtClass, it got removed from pool but not from the invalidNamesMap for default pool.  Subsequently when MemberResolver.lookupClass looks for "eg.foo.MyClass", the Creation#1's CtClass gets returned. This is a bug because that class was detached earlier and must not be reused for any processing - we are creating another instance because a new definition is needed for that class.
> The bug is critical as erroneous unintended cached class definitions could be used even when not intended leading to potentially very severe runtime problems. Remember that cache is a good only if it accurately provided cached results. In this case, stale/incorrect results will be returned. 
> Proposed Fix:
> Add a static method detachInvalidNames in MemberResolver that removes a qualified class-name from invalidNamesMap for that class's pool. CtClass.detach must invoke this detachInvalidNames.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira