You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Daniel Sun (Jira)" <ji...@apache.org> on 2020/08/09 03:41:00 UTC

[jira] [Resolved] (GROOVY-9679) The fork-join pool does not provide a good ClassLoader for Groovy types

     [ https://issues.apache.org/jira/browse/GROOVY-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Sun resolved GROOVY-9679.
--------------------------------
    Fix Version/s: 3.0.6
       Resolution: Fixed

> The fork-join pool does not provide a good ClassLoader for Groovy types
> -----------------------------------------------------------------------
>
>                 Key: GROOVY-9679
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9679
>             Project: Groovy
>          Issue Type: Improvement
>            Reporter: Eric Milles
>            Assignee: Eric Milles
>            Priority: Major
>              Labels: breaking
>             Fix For: 4.0.0-alpha-1, 3.0.6
>
>
> * {{Thread.currentThread().getContextClassLoader()}} was used starting with [{{46b1ffa}}|https://github.com/apache/groovy/commit/46b1fface0b17cf41f9681894bcb8d78fc831258] -- commit does not state that this parentage is required for any specific reason; fallback loader (the one that loaded {{ProcessingUnit}}) seems like a better option for Groovy.
>  * {{StaticTypeCheckingSupport.evaluateExpression(...)}} relies on loader created by this block; it does not transfer loader(s) from it's context.
> This came about for me because IDE is performing content assist asynchronously now and processing {{ClosureParams}}/{{DelegatesTo}} metadata relies on {{evaluateExpression}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)