[
https://issues.apache.org/jira/browse/GROOVY-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416720#comment-17416720
]
Eric Milles commented on GROOVY-10224:
--------------------------------------
Yes, there will likely be issues for type parameter namespace confusion since
the generics methods are very low-level. Do you have a specific test case that
is not working properly? I don't think a general solution is close at hand
without replacing basically all of the generics public API with some new
service that is much more aware of context/scoping.
The solution for groovy-eclipse was to have a separate map for each
layer/level:
https://github.com/groovy/groovy-eclipse/blob/master/base/org.eclipse.jdt.groovy.core/src/org/eclipse/jdt/groovy/search/GenericsMapper.java#L44
> No owner type of `ParameterizedType` of Java could be represented in
> `ClassNode`
> --------------------------------------------------------------------------------
>
> Key: GROOVY-10224
> URL: https://issues.apache.org/jira/browse/GROOVY-10224
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
> Reporter: Daniel Sun
> Priority: Major
>
> {quote}
> Java5 treatment of ParameterizedType is incorrect: it doesn't take into
> account getOwnerType(). I've made ASM decompiler behave the same way for now.
> I don't know how to represent such types in ClassNode API.
> {quote}
>
> See https://github.com/groovy/groovy-core/pull/552
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
