Q:

How can I design for Java dependencies versioning

I've got a library defined by another team.  It has something like the following:
public class SingletonFoo {
  static {
    instance = new SingletonFoo();
  }

  private static final SingletonFoo instance;

  private SingletonFoo() {
  }

  public static SingletonFoo getInstance() {
    return instance;
  }

  public String getStuff() {
    // Stuff gets returned
  }
}

Now I need to use this library from my library.  However, the application that's using both libraries needs to be able to update them independently.
Option 1:
Use reflection to bind the two:
public String callLibrary() {
  Class fooClass = Class.forName("com.mycorp.SingletonFoo");
  Object fooInstance = fooClass.getMethod("getInstance", ...).invoke(null);
  String result = (String) fooInstance.getMethod("getStuff", ...).invoke(null);
  return result;
  // TODO: Add all sorts of error handling
}

But that's pretty fugly.
Option 2:
Directly bind to their library.
public String callLibrary() {
  return com.mycorp.SingletonFoo.getInstance().getStuff();
  // TODO: catch exception (ClassLoadError or something)
}

Obviously this is a lot cleaner.  However, the other team may release their library on a different schedule than mine.  If I bind V1 of my library to V1 of their code, they release V2, and the application uses my V1 with their V2, what happens?
Let's assume they've committed to keeping the package, class, and all method names constant.  Will the class loader be cool with a completely different instance of their jar, provided those integration points are constant?

A:

There are no such problems in java. Until other team does not change its interface, i.e. the class is still called SingletonFoo, still belongs to package com.mycorp and has static method getInstance() your code will work with it either it was built before or after current release of the other team's library. 

