I agree with comments and answers. There must be only one version of a library, suggested approach is to use of latest one.
Normally, libraries should support backward competibility (if no major release difference) with deprected annotation for warnings.
If you add both, it's not guaranteed which version your classloader will pick.
As a very forcefull way to solve this is to manually implement a multi classloader approach.
Warning: This will work only if your relationship to this library is more like a service invocation based approach.
- Create another project which has dependencies to old jar user library and also old jar.
- Export all dependant jars to different folder.
- Within your application, manually create a new classloader and load all jars within that directory.
- When time comes switch to new classloader (overwrite current thread's classloader) then call required class create/call method operations by reflection. A wrapper class will be easier.
- After usage is done finally revert threads classloder then go on.
Note: Not sure, but probably default Java classloaders have parent&child relationship (OSGI classloders has it for sure).
If so, you dont need to seperate common jars. When your parent project loads it, it should be accessible via child classloader as well. That's how you can pass a parameter object created by parent classloader to a object method loaded by child classloder.