posted 10 years ago
The problem is that when the classloader finds 2 classes with the same name in the classpath, it will decide to pick one. You don't have control over it. THe classloader is implemented in the JVM. So, in one JVM the classloader might pick one class, and it another one it might pick the other. If you reply on the classloader to load the class from your jar instead of abc.jar, your implementation will become platform dependent.
There are multiple ways you can make your implementation platform independent
a) Just inject TestImpl into your service class rather than trying to trick the classloader. Is there a reason why you can't do this?
b) Ask whoever has made abc.jar for you to add those methods to the interface. This is the least hackiest solution of all
c) Hack the jar and replace testinf.java with your own. If you have to hack, you have to hack. Atleast this hack doesn't break platform independence
d) This might be the most most complicated of all, but is also the cleanest hack. Deifine your own interface that extends TestInf and adds the 2 methods . Let's call it TestInf2 . Implement a "bridge" class that implements TestInf2, and wraps an instance of TestImpl. The wrapper class can just pass all the calls through to TestImpl. Now inject TestInf2 in your service classes.