Question

I’m with some doubts how to implement dependency injection with guice when exists multiple implementations of same interface and this dependency is defined at runtime based on parameters, so I’ll give an example to easily explain my question:

Imagine the scenario where you have one module to load files of multiple formats, basically you have one interface defining the contract, and multiple implementations one for each format:

public interface FileLoader {
    void load(File file);
}

public class YMLFileLoader{
    void load(File file){
    System.out.println("Loading YML");
    }
}

public class XMLFileLoader{
     void load(File file){
         System.out.println("Loading XML");
     }
}

Now, in runtime guice have to define based on file extension the implementation that must be used to load it.
My idea to maintain the code clean is make use of annotations, for each implementation is specified what she loads through @FileLoaderType annotation.

@Singleton
@FileLoaderType("yml")
public class YMLFileLoader{
    void load(File file)
    {
        System.out.println("Loading YML");
    }
}

@Singleton
@FileLoaderType("xml")
public class XMLFileLoader{
    void load(File file)
    {
        System.out.println("Loading XML");
    }
}

My first question is if implementation is possible?

Being the first question is positive, there is any way to implement this solution where for each new implementation of FileLoader doesn’t require refactoring in implementation of AbstractModule that supports the solution?
In other words, is basically for each new implementation of FileLoader only be required the existence of the annotation @FileLoaderType to Guice know what is the dependency it should inject if the extention match with her.

Answer 1

One thing Guice can’t do is it can’t scan your classpath and find what classes you have, so you will need some way to tell guice what classes you have available. Therefore let’s split your question into two halves: getting a list of FileLoader implementation classes, and binding those classes into Guice.

Let me tackle the second half first. I’ll assume that you have in your AbstractModule subclass a method called getFileLoaderClasses with the signature:

private List<Class<? extends FileLoader>> getFileLoaderClasses() { ... }

In that case, what I would recommend for binding the FileLoader implementations is something like this:

private void bindFileLoaders() {
  MapBinder<String, FileLoader> mapBinder
      = MapBinder.newMapBinder(binder(), String.class, FileLoader.class);
  for (Class<? extends FileLoader> implClass : getFileLoaderClasses()) {
    FileLoaderType annotation = implClass.getAnnotation(FileLoaderType.class);
    if (annotation == null) {
      addError("Missing FileLoaderType annotation on " + implClass.getClass());
      continue;
    }
    mapBinder.addBinding(annotation.getValue()).to(implClass);
  }
}

This requires the guice-multibindings extension. Once you bind the implementations like that, you can use it as:

public class MyLoader {
  @Inject Map<String, FileLoader> fileLoaderMap;

  public void load(File file, String type) {
    FileLoader fileLoader = fileLoaderMap.get(type);
    if (fileLoader == null) {
      throw new IllegalArgumentException("No file loader for files of type " + type);
    }
    fileLoader.load(file);
  }
}

So now, how do we get that full list of implementation classes? There are a few ways to do this:

• Have one class with a static list of all the implementation classes:

  public class FileLoaderRegistry {
    public static final List<Class<? extends FileLoader>> impls =
        ImmutableList.of(
          YMLFileLoader.class,
          XMLFileLoader.class,
          JsonFileLoader.class
        );
  }
  

  This has the advantage that it’s probably the simplest solution to implement.
  It has a disadvantage that you’ll need to update this one file with each new implementation, and recompile it.

• Have a text file with all the class names in it and load the classes with Class.forName() after reading all the lines of the file.

• If you have the FileLoader implementations in different jar files, you can have a text file listing the names of the classes in each jar in a common location and then use System.getResources() to get an Enumeration of URLs pointing to each of the text files. Then read each file and load the class objects with Class.forName().

• The most complicated option is to use the annotation processing tool as part of your compilation process, and use that to generate either text files or the registry class. That’s a separate question.