interference between user and kernel code

[scottdraves]

we have problems like #6771 because our class loader calls ClassLoader.getSystemClassLoader()

this also means you can break the kernel if you %classpath add the wrong jar.

[jpallas]

"No question that includes the word ClassLoader has a happy answer." -- Rob Norris

Thinking off the top of my head, it seems like a bunch of problems are caused by exposing all of the kernel classes and their dependencies to the user environment. Naively, it seems like the widgets and such that are intended to be visible to user code should be isolated and self-contained (shading their transitive dependencies). But is separate class loaders needed to do that? I'm not sure just how big a hell-mouth is opened by having separate class loaders. Some things are meant to be shared between the user and kernel code (like jvm-repr's Displayers), and I guess(?) that breaks if the class is loaded by two different class loaders?

[scottdraves]

yea one of my least favorite topics :}
maybe someone who knows better can give us some tips.

[scottdraves]

Proper solution would be separate classloaders for kernel and user code.
Would involve #6836 too.

[scottdraves]

workaround might be to shade all kernel classes so they don't conflict with whatever the user loads.
just have to be sure not to shade the user-visible APIs.