Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let say you are building an app and you are using the latest library verion from a third party (say ver2.jar). Then you saw an example written 2 years ago, but that example uses the ver1.jar

Now in ver1.jar, there is web.method1(), but in ver2.jar there is no such method. Instead, in ver2.jar you have web.getOtherMethod.method1();

You ran your app with ver2.jar and found a lot of missing classes, and lots of errors. So what are you going to do to solve the incompatibility?

I think the version problem is really a nightmare because it is unstructured and you do not actually understand what is going on.

Also, why changed the location of the method in ver2.jar so differently like that?

share|improve this question

closed as too broad by gnat, MichaelT, gbjbaanb, Dynamic, Bart van Ingen Schenau May 17 '14 at 17:16

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

First, it may only appear unstructured to you. Next, I may be indeed unstructured regarding the particular change you are talking about, because of the people who did that one in an less cleverly manner. However, this is not the case in general. Compatibility requires doing one's homework, that's for sure, but it is not that hard either. In most cases, once you thought about it and established a few simple rules, it just works. – JensG May 17 '14 at 0:24
u seee this is Apache said "+) commons-codec-1.3 does not contain the DecoderException +) if it is not found you may have a look at earlier releases to fix the problem" (from a blog) Why we have to look for the eariler version to fix the problem? it is very nightmare actually – Tum May 17 '14 at 0:43
If we could anticipate all changes we make to our code, we would just write it perfect in the first place. Code gets maintained and the API changes between major versions, that's simply how it is. If you want to get with the new functionality, you'll have to learn how the new version works. All together it is very unclear what you're asking: do you want to know about the concept of the adapter pattern or is this just a rant? – Jeroen Vannevel May 17 '14 at 2:44

This isn't a question of versioning or verison control -- this is a question of amaturish interface design. In proper, professional utility code design, you never "make a new version" of the interface that's entirely incompatible with the old one, espcially without providing a compatability layer.

In the example you provided, the web interface contained in the ver1.jar file has a method like follows:

interface web {
   void method1()

Once this is published and provided for public use, it is amaturish to ever, ever, ever break it. Usually, the developers will define an additional interface, possibly with a back-reference to the old way of doing things

interface web2 {
    web getOtherMethod()
interface oldStuff {
   void method1()

It also wouldn't be improper to add additional methods to an existing interface:

interface web {
   void method1()
   void method2()

But if a simple version change breaks code you wrote against a library, it's either not a library worth using, or you were attemping to write directly to the internals instead of the interface.

For further reading on Java and interfaces, there are basic tutorials available for Java, and it's not to hard to find a seasoned programmer to extol the virtues of interfaces and encapsulation.

share|improve this answer

There are ways to protect yourself when using 3rd party libraries. One such method is to use the Adapter Pattern. This way you can use your class and keep it relatively the same in your code base and make any changes necessary with the library in your adapter class. It will also make unit testing much easier to verify version changes since you just need to test your adapter class rather than your entire code base to ensure that any changes in upgrading the library doesn't impact anything else.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.