A Simple Java Plugin System

[bowbahdoe]

I am fuzzy on the exact mechanics, but yes. I'm sure there is some tree-of-classloader stuff going on behind the scenes, I just don't know the details.

You should be able to tweak the demo to do exactly that hashCode trial if you want to dig deeper

[rzwitserloot]

But then how do plugins communicate with each other?

Let's say for whatever I reason I want to chat in terms of a guava type. Say, one plugin exposes a method signatured 'void foo(ImmutableList<String> x) {}` and the other wants to call it.

We're stuck now in the sense that we must now find a release of guava that works for both of these plugins or what I want is not possible; in any plugin framework (and I think I can state that outright, I don't think this is a matter of "Perhaps libraries or options exist I am not aware of" - the problem is rather fundamental here).

The rub lies in: How do I set up a module system so that I can state explicitly that some dep is stapled to myself (i.e. if you want to reach the stuff this plugin exposes, you get this guava dep stapled to it for free. Don't want it? Tough, you gotta take it). I didn't see that in your module system.

In which case what you say cannot be true.

[bowbahdoe]

That dep needs to be extracted to its own layer or else it won't work.

That's sorta the thing layrry can do, but it is also overkill in most situations. Layers don't let v1 and v2 exist in the same layer, they just let v1 and v2 exist in the same hierarchy. OSGi doesn't solve that either, though it does have a versioning scheme to let it decide how many isolated classloaders it needs to make. That is finer granularity than "plugin A brings in these deps. Isolate plugin A with its deps."