Two libraries needing different versions of a common library
I am currently writing an application that utilizes two libraries that depend on a third common library. However, each of the two libraries requires a different version of the third library. Is there any way this can be done?
I have done some research into writing custom class loaders but I haven't been able to find anything useful in this instance. Any help would be appreciated. Thanks.
[404 byte] By [
CSBriana] at [2007-11-27 6:46:02]
It may be easier to change one of the first two libraries, so they can both use the same version of the third one.
I need the versions of each that I am using. So, that doesn't seem to be a solution.
I don't see why needing different versions would keep you from modifying them.
Yes, in theory I could go through one of the libraries and change the namespace of the required library to something else. That is certainly not ideal though. I guess this is JAR hell after all....
No, that's not what I mean.
Why is it that these two libraries need different versions of the third library?
Is it a matter of a missing feature? Could you just update one of the first two libraries to use or to avoid that particular feature?
It might end up being only a few lines of code. And if it's open-source, maybe you could submit the changes you make back to the maintainers. Presto: problem solved, and the code is better as a result.
I suppose you could do some hackery with class loaders, but a hack like that doesn't seem like it should be the first choice.
Most likely something like jakarta-commons. They changed their entire package structure and naming at some point in between 2 minor versions, causing everything that used it before that point to be either stuck with using old versions or having to be completely rewritten.
It's not just a feature missing that's the problem. If I use one version of the library, one part of the program simply doesn't work. If I use the other, then the other part of the program refuses to work.
One of the librarys is open source so I guess I am going to go though and change the imports in there and then change the package structure of the common library.
> It's not just a feature missing that's the problem.
> If I use one version of the library, one part of the
> program simply doesn't work. If I use the other,
> then the other part of the program refuses to work.
The problem you should be trying to solve is why the two libraries won't work with the same (latest) version of the shared library. It indicates that one of them is relying on buggy behavior, and should be fixed.
Do you have any access to the libraries' source code? You'd be far better off trying to figure out what changed, and how to fix the piece that relied on its old behavior, rather than any sort of hack (and changing package structure to work around a bug is definitely a hack, perhaps moreso than using a custom classloader).
Finally, what does "doesn't work" mean? Are you unable to compile? Are you able to compile but get incorrect results? Does the program crash?
Yes, I agree. It should be fixed. However, I need to use the version that each library supports. We don't have enough resources to fix problems in tens of thousands of lines of code in the library. I guess this is impossible in Java. I can't figure out how I could make a classloader load the classes without modifying one of the two library's. It seems that the best thing to do is just repackage one version of the common library.
Actually you can probably do it with a classloader, but again, it seems like a real hack that should be your last resort.
Trying to debug a problem in an open-source library shouldn't be as insurmountable a problem as you seem to feel it is. I mean, most of the two libraries work, or you wouldn't be using them, right?You should be trying to fix things, not coming up with increasingly fragile and complicated band-aids.
sigh but as you insist to do this only as a hack, then perhaps creating a hacked classloader is the least offensive hack you can use. I'd suggest looking at URLClassLoader to see if you can make a subclass that will check the URL its given, and if it matches the library you're looking for, it'll look for a particular version. Then use two instances of this class loader, one for each of the two other libraries.
> I can't figure out> how I could make a classloader load the classes> without modifying one of the two library's.Why not?You must load both via a class loader of course.
