How to avoid classloading conflicts for a java library
<p>We have a java library (more like a framework) which can be used to build JDBC drivers. The framework implements the JDBC interface, and you implement some interfaces which are consumed by the framework to realize the driver.</p>

<p>One issue which has come up is that if you create two drivers with this framework, and try to use them simultaneously in a single JVM, only a single set of the framework classes will be loaded.</p>

<p>This is bad for at least two reasons:</p>

<ol>
<li>The framework contains singletons, so only the first driver loaded
actually works correctly.</li>
<li>Even if we removed all singletons, things
could break if the 'wrong version' of the framework is loaded at
runtime for one of the drivers.</li>
</ol>

<p>The solution used was to rename the framework class packages for each driver, so that they would no longer conflict. While this works, there is a concern about the bytecode manipulation, as it happens after our testing.</p>

<p>My question: Is there a better way? This needs to be handled from our side, not the application's, as an application uses the driver simply as a JDBC driver, so it needs to be transparent.</p>

<p>One idea I had was to serialize all the classes of the driver (other than the 'entrypoint' classes which implement Driver/DataSource) into some sort of resource which is packaged in the driver jar (with the FQN of the resource and entrypoint classes being unique to the driver), then have the entrypoint classes, in a static initialization block, read out the classes and load them with a private classloader. Are there any glaring problems I'm missing with this approach? </p>