Question

I have a java project I want to create which will be built on top of some vendor APIs. The APIs connect to servers running said vendor’s software and perform various actions.

I have 2 different versions of the servers supported by 2 different API versions. Any changes to the API’s are in internal implementation only. I.E. The classes, interfaces, methods, etc. available to me in the older version exist in the newer version. Therefore the code I write should compile and run with either API version. There is a version number in the API presented to the servers when using the API to connect that prevents you from using a different version API on that particular server.

1. Is there a way to switch JAR files on the fly at runtime? (something like a c/c++ DLL??)

2. If switching API versions at runtime isn’t possible, what is the most elegant way to handle the problem. Build the code 2x (one for each api version)?

I hope I’m missing something but approach 2 doesn’t seem ideal. Here’s a more concrete example of why:

package org.myhypotheticalwrapper.analyzer;

import org.myhypothetical.worker;
import org.myhypothetical.comparator;

public class Analyzer {

    Worker w1 = new Worker();
    Worker w2 = new Worker();

    Comparator c = new Comparator(w1.connectAndDoStuff(),w2.connectAndDoStuff());
    c.generateReport();
}

This is my dilema. I want w1 to be built with the old API and w2 be built with the new API so they can connect to the appropriate servers. Other than the API’s they sit on top of, they are the same (identical code). Do I have to create two uniquely named Class types for W1 and W2 even though their code is identical, simply to accommodate different API versions? It seems like that could get unwieldy fast, if I had many API versions that I wanted to interact with.

Any suggestions and comments greatly appreciated.

-new guy

Answer 1

You can’t really change out a class file once it’s been loaded, so there’s really no way to replace a class at runtime. Note that projects like JavaRebel get around this with some clever use of instrumentation via the javaagent – but even what you can do with that is limited.

From the sounds of it you just need to have two parallel implementations in your environment at the same time, and don’t need to reload classes at runtime. This can be accomplished pretty easily. Assume your runtime consists of the following files:

• analyzer.jar – this contains the analyzer / test code from above
• api.jar – this is the common forward-facing api code, e.g. interfaces
• api-impl-v1.jar – this is the older version of the implementation
• api-impl-v2.jar – this is the newer version of the implementation

Assume your worker interface code looks like this:

package com.example.api;

public interface Worker {
  public Object connectAndDoStuff();
}

And that your implementations (both in v1 and v2) look like this:

package com.example.impl;

import com.example.api.Worker;

public class WorkerImpl implements Worker {
  public Object connectAndDoStuff() {
    // do stuff - this can be different in v1 and v2
  }
}

Then you can write the analyzer like this:

package com.example.analyzer;

import com.example.api.Worker;

public class Analyzer {
  // should narrow down exceptions as needed
  public void analyze() throws Exception {  
    // change these paths as need be
    File apiImplV1Jar = new File("api-impl-v1.jar"); 
    File apiImplV2Jar = new File("api-impl-v2.jar");

    ClassLoader apiImplV1Loader = 
      new URLClassLoader(new URL[] { apiImplV1Jar.toURL() });
    ClassLoader apiImplV2Loader = 
      new URLClassLoader(new URL[] { apiImplV2Jar.toURL() });

    Worker workerV1 = 
      (Worker) apiImplV1Loader.loadClass("com.example.impl.WorkerImpl")
                              .newInstance();
    Worker workerV2 = 
      (Worker) apiImplV2Loader.loadClass("com.example.impl.WorkerImpl").
                              .newInstance();

    Comparator c = new Comparator(workerV1.connectAndDoStuff(),
                                  workerV2.connectAndDoStuff());
    c.generateReport();
  }
}

To run the analyzer you would then include analyzer.jar and api.jar in the classpath, but leave out the api-impl-v1.jar and api-impl-v2.jar.