Versioning information in classpath

Question

I am creating an API library that will be deployed to customer's on-premise applications. This on-premise application contains independent plugin modules that contain the API library as a dependency. Each application may have several of the plugins, therefore many copies of the API library.

I would like to have the flexibility to evolve the API library, while avoiding classloader conflicts. An OSGI implementation is not an option at this time. I am wondering if anyone has placing versioning information in the classpath, as to create different instantiations of the classes, as a way to avoid conflicts.

e.g.

User.java in package com.product.v2014_04 (1st version)

User.java in package com.product.v2014_05 (2nd version)

Does anyone have experience doing this, or know of any popular implementations that use this method to avoid classpath collisions? Pros/cons?

Much appreciated

Answer 1

Apache does this with some of their libraries. If you look at an older version of commons-lang (such as 2.6), the packages all live in org.apache.commons.lang. Go grab a current version of it (such as 3.3) though, and you'll notice that all the packages have been renamed to org.apache.commons.lang3.

When I recently migrated an app from 2.6 to 3.3, it was a bit of a pain to go through and fix all my import statements, but it certainly got the point through that this was a major version change and I needed to pay attention to how I was using the code.