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)