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

Renny Barrett edited comment on LANG-1702 at 7/11/23 9:28 PM:
--------------------------------------------------------------

LANG-1524 might be {_}related{_}, but I don't think it's necessarily the same.  
LANG-1524 refers to TypeUtils.classToString, whereas this ticket refers to 
TypeUtils.unrollVariables.

 

It could well turn out that LANG-1524 and this ticket both spring from the same 
erroneous assumptions about how type variables work with inner classes, but 
looking at the commons-lang implementation code, it looks like LANG-1524 could 
be fixed without fixing this ticket, and vice versa.

Probably best to fix LANG-1524 and this ticket at the same time (and also test 
other methods on TypeUtils operating on parameterised inner classes), but 
that's not to say that this ticket _duplicates_ LANG-1524.

 


was (Author: JIRAUSER301302):
LANG-1524 might be {_}related{_}, but I don't think it's necessarily the same.  
LANG-1524 refers to TypeUtils.classToString, whereas this ticket refers to 
TypeUtils.unrollVariables.

 

> TypeUtils.unrollVariables can cause a StackException for parameterized inner 
> class
> ----------------------------------------------------------------------------------
>
>                 Key: LANG-1702
>                 URL: https://issues.apache.org/jira/browse/LANG-1702
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.reflect.*
>    Affects Versions: 3.12.0
>            Reporter: Renny Barrett
>            Priority: Major
>         Attachments: TestTypeUtilsUnwrap.java
>
>
> If TypeUtils.unrollVariables is called for a type which is a non-static inner 
> class where the inner class and its enclosing class both have type 
> parameters, then there's an infinite recursion which results in a 
> StackOverflow error.
>  
> Simple test code that recreates the issue is attached.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to