I am looking into classloader isolation solution and it seems OSGi, especially the Classloader specification is wonderful. The whole OSGi spec is a 400+page boo

I am looking into classloader isolation solution and it seems OSGi, especially the Classloader specification is wonderful. The whole OSGi spec is a 400+page book if you are into services, security, etc... but the Classloading isolation spec is small and very useful. I am in need of a way to allow plugins/integration with other teams. If we use standard Java package sharing mechanism, sooner or later teams will run into dependency conflict hell. More often, microservices (IPC) is suggested, too. But, the nature of our application is sensitive to latency and require high throughput. That throws IPC out of the picture. Then, I remember the servlet API and how the servlet spec dictates classloading isolation at the container level. I rolled my own classloader to isolate the plugins/integrations but it is not as nice as OSGi implementation. At this point, I am very inclined into using OSGi just for the sole classloading purpose. One question that bother me is: since we are not that hardcore OSGi users, would it make sense for us to just bundle every plugins' into a fat jar and use bundle-classpath to resolve the plugin's owned dependencies? I know that by doing so, we are not strictly adhere to OSGi classes' sharing but it would lower the friction for independent teams to integrate with us.