[groovy] branch async-parse updated (7b5e997 -> 8c7f34a)

[em...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

emilles pushed a change to branch async-parse
in repository https://gitbox.apache.org/repos/asf/groovy.git.


 discard 7b5e997  The fork-join pool does not provide a good ClassLoader for Groovy types
     new 8c7f34a  The fork-join pool does not provide a good ClassLoader for Groovy types

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (7b5e997)
            \
             N -- N -- N   refs/heads/async-parse (8c7f34a)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 src/main/java/org/codehaus/groovy/control/ProcessingUnit.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[groovy] 01/01: The fork-join pool does not provide a good ClassLoader for Groovy types

[em...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

emilles pushed a commit to branch async-parse
in repository https://gitbox.apache.org/repos/asf/groovy.git

commit 8c7f34acd657d3f3e8c6fa4442dcbd34a9443813
Author: Eric Milles <er...@thomsonreuters.com>
AuthorDate: Thu Jul 30 13:03:47 2020 -0500

    The fork-join pool does not provide a good ClassLoader for Groovy types
    
     - Thread.currentThread().getContextClassLoader() was used starting with
    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
---
 src/main/java/org/codehaus/groovy/control/ProcessingUnit.java | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/main/java/org/codehaus/groovy/control/ProcessingUnit.java b/src/main/java/org/codehaus/groovy/control/ProcessingUnit.java
index 0b12ebf..a591f5e 100644
--- a/src/main/java/org/codehaus/groovy/control/ProcessingUnit.java
+++ b/src/main/java/org/codehaus/groovy/control/ProcessingUnit.java
@@ -101,8 +101,7 @@ public abstract class ProcessingUnit {
         // ClassLoaders should only be created inside a doPrivileged block in case
         // this method is invoked by code that does not have security permissions.
         this.classLoader = loader != null ? loader : AccessController.doPrivileged((PrivilegedAction<GroovyClassLoader>) () -> {
-            ClassLoader parent = Thread.currentThread().getContextClassLoader();
-            if (parent == null) parent = ProcessingUnit.class.getClassLoader();
+            ClassLoader parent = this.getClass().getClassLoader();
             return new GroovyClassLoader(parent, getConfiguration());
         });
     }