Cramming all the jars together

I had an interesting conversation with a coworker about solving a particular problem.  We have a JVM that connects to a vendor product.  The vendor provides a client library in the form of jar files.  The client library implements the proprietary communication protocol that the vendor created.  This client library also makes use of some open source jars.

We are in the middle of an upgrade for that vendor product.  This product is not really upgradable.  The upgrade process usually takes a few days, with the product being down during the entire upgrade.  Because of this, we decided to set up a second instance of the product in parallel with the first.  The idea is we can migrate processes to use the new system over time.  This poses an interesting problem: how do you support two different versions of the client api in the same JVM?

This is a major version upgrade, so there are some differences.  The main difference on the surface is the fact the client api changed to a different java package.  This leads my coworker to believe that we should just be able to throw all the jars in the same classpath.  This is a simple JVM.  There is no custom classloader and it does not use OSGI.  For me, I don't care that the api changed to a different java package.  We have no clue how the internals of the api work.  That is the point of having an api to begin with.  We shouldn't need to know how it works.  Trying to get two versions of the client api into the same classloader is like putting two different versions of Spring into the same classloader.  It just doesn't make sense.

I recommended that we offload the vendor call to another JVM.  The vendor call we make is a batch call returns data from inside of the system.  It takes about 2 minutes.  There is already infrastructure in place to have multiple versions of the jars on the filesystem.  We have a config file that specifies which version we use.  You just read the config, invoke the correct child JVM to make the call, and process the result.  In fact, this was the architecture we used to have, until one of the developers decided to disable that functionality.