I'd do this by having 'converter' bundles/plugins.
Your data structure reader/manager gets injected with these converters
and invokes the appropriate one(s) after reading a data structure.
This ofcourse requires the version to be stored with the data.
You can even use chains of converters when
The question seems to imply that your objects are stored in a database. It
might be more useful to do the conversion in the database? Usually a new
version detects an old serializable format and then updates the record.
Having different versions in a process for the same class is and will always
In OSGi R6 there is a new method that makes searching for capabilities more efficient (depending on how the framework is implemented)
https://osgi.org/javadoc/r6/core/org/osgi/framework/wiring/FrameworkWiring.html#findProviders(org.osgi.resource.Requirement)
I know in Equinox the capabilities a
I agree with Christian’s solution, and would add that the limitation of being
exposed to at-most-one version of each type per bundle is a restriction of the
underlying Java class loaders, not really OSGi at all.
Unless Java itself changes the way classes are loaded – highly unlikely since
it wo
You can not simply import different versions of the same package into
the same bundle. Inside one classloader each class name must be unique.
The classloaders are only involved when the object is created though.
So there is no problem to pass an A1.0.0 object into a method as Object.
You can th
