+1 for OSGi providing the best solution to the class resolution problem,
though I think some work will have to be done around trust, as you say.
On 16/11/2016 02:23, Peter wrote:
>
> The conventional alternatives will remain; the existing ClassLoader
> isolation and the complexities surroundi
I agree with Dan, and I attempted this myself many, many years ago, but at
that time there were little consensus to go that route.
Although I don't like Maven, because it is very opinionated about
everything, I think it is a big, good step in the right direction.
Personally, I would go with Gradle
+1 to breaking up code into independently released modules. This would avoid
tricky builds that re-use the same source files to produce different jars
containing the same .class files, and it would ensure interdependencies are
validated by build tooling. This approach would also avoid a “boil th
The conventional alternatives will remain; the existing ClassLoader isolation
and the complexities surrounding multiple copies of the same or different
versions of the same classes interacting within the same jvm. Maven will
present a new alternative of maximum sharing, where different servi
While I also thought about out-of-process based mechanism for execution
of dynamically downloaded code, I came to the conclusion that in the
context of River/Java in-process mechanism is something that MUST be
done right. All other things can (and should) be built on that.
I think that the pro
I've been thinking about process isolation (instead of using
ClassLoader's for isolation). Typically, smart proxy's are isolated in
their own ClassLoader, with their own copies of classes, however with
Maven, a lot more class sharing occurs. Since River uses codebase
annotations for identity,
