<< Back to previous view

[CLASSPATH-7] Do not assume that all classloaders in hierarchy implement URLClasspath Created: 22/Oct/15  Updated: 06/Nov/15  Resolved: 06/Nov/15

Status: Resolved
Project: java.classpath
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Colin Fleming Assignee: Stuart Sierra
Resolution: Completed Votes: 0
Labels: None


Currently, java.classpath assumes that all classloaders in the hierarchy implement URLClasspath. This is not always true, nor is it always possible to achieve this.

Cursive recently switched to running Leiningen inside an isolated classloader tree using ShimDandy. When someone tries to work with a project with cider-nrepl in their profiles, they receive the following error:

No implementation of method: :urls of protocol:
found for class: com.intellij.util.lang.UrlClassLoader, compiling:(track_state.clj:57:8) 
No implementation of method: :urls of protocol:
found for class: com.intellij.util.lang.UrlClassLoader

cider-nrepl uses java.classpath to introspect the classpath, and java.classpath walks the classloader hierarchy until it reaches the root classloader which is a com.intellij.util.lang.UrlClassLoader, which does not extend java.net.URLClassLoader. It is essential that this classloader not extend URLClassLoader because lein uses pomegranate to add jars to the classpath, and pomegranate will add those jars to the classpath using dynapath in the highest modifiable classloader it can find. It's important that that not be the root classloader since that would mean that lein plugins would be incorrectly loaded onto the classpath for different projects. Additionally, I cannot extend the URLClasspath protocol to the IntelliJ classloader because it's not available inside the shim.

I believe the solution is that java.classpath should check that the classloaders satisfy URLClasspath before calling urls on them.

Comment by Stuart Sierra [ 24/Oct/15 11:45 AM ]

I pushed a tentative fix to Git master as commit 39854b7f

Please test the SNAPSHOT release 0.2.3-20151024.163936-116, available from the Maven repository "https://oss.sonatype.org/content/groups/public/", and let me know if it resolves the problem.

Comment by Colin Fleming [ 24/Oct/15 4:49 PM ]

Thanks. I actually managed to work around the problem on the Cursive side by sealing all URLClassLoaders using dynapath, but this is still a good change to make. I'll reproduce the original problem and make sure this fixes it.

Comment by Stuart Sierra [ 06/Nov/15 2:12 PM ]

Fix included in 0.2.3 release.

Generated at Fri Nov 27 02:17:23 CST 2015 using JIRA 4.4#649-r158309.