The concept of extensible libraries is not new and is called by many different names depending on which context it is used in, like pluggable architecture or a factory finder pattern. You're already familiar with it if you ever needed to write a library allowing your users to extend its functionality at runtime.

One example of such a library is a quite popular SLF4J logging framework and its bindings. When you're writing a reusable library intended to be vended to others, SLF4J is a good bet. It provides an API you use in your own application code but allows your users to choose any logging implementation they wish to use, like System.out (slf4j-simple), Log4j (slf4j-log4j), or even lets them not to log anything (slf4j-noop). This is the major reason why libraries like Hibernate chose SLF4J over other logging systems.

If you ever wanted to write a library like SLF4J you would need such a pluggable system yourself. The good news is Java itself uses that kind of architecture internally and exposed its mechanism for you to use with the ServiceLoader system (since version 6). Even better, it's simple and easy to use. You're required to create an API and then load all implementations with Java provided classes. The whole concept is well documented in the following tutorial on Oracle's pages - Creating Extensible Applications. 

Here's how it looks in a nutshell.

You create an API:

public interface Dictionary {

     public String getDefinition(String word);

}

Then load all implementations:

public class DictionaryService {

    private ServiceLoader<Dictionary> loader;

    public DictionaryService() {
       loader = ServiceLoader.load(Dictionary.class);
    }

}

And finally use them:

for (Dictionary dictionary : this.loader) {

    String definition = dictionary.getDefinition(word);

    if (definition != null) {
        return definition;
    }

}

If you ever want to use a ServiceLoader with Spring you don't have to create ServiceLoader beans yourself.  In order to make the Oracle's example usable let's modify the DictionaryService to accept Dictionary loader implementations in the constructor instead:

public class DictionaryService {

    private ServiceLoader<Dictionary> loader;

    public DictionaryService(ServiceLoader<Dictionary> loader) {
        this.loader = loader;
    }

}

Now, let's modify the DictionaryDemo class to use Spring instead of instantiating DictionaryService ourselves:

public class DictionaryDemo {

    private static ApplicationContext ctx = 
        new AnnotationConfigApplicationContext(DictionaryAppConfiguration.class);

    public static void main(String[] args) {

        DictionaryService dictionary = ctx.getBean(DictionaryService.class);

        System.out.println("Book: " + dictionary.getDefinition("book"));

    }

} 

Finally, let's make Spring do its magic in the DictionaryAppConfiguration class:

@Configuration

public class DictionaryAppConfiguration {    

    @Bean
    public DictionaryService dictionaryService(ServiceLoader<Dictionary> loader) {
        return new DictionaryService(loader);
    }

    @Bean
    public ServiceLoaderFactoryBean dictionaryServiceLoaderFactory() {
        ServiceLoaderFactoryBean factoryBean = new ServiceLoaderFactoryBean();
        factoryBean.setServiceType(Dictionary.class);
        return factoryBean;
    }

}

There you go, nice and easy. 

Unfortunately, this creates a problem - as you might have guessed, the ServiceLoader requires your Dictionary implementation to have a no argument constructor. Nothing in the real world is that easy and this kind of design would force you to use static Service Locator patterns (and you know it's bad). Ideally, you would use a dependency injection framework (like Spring Framework) which allows you to inject your Dictionary classes with external collaborators. An example of such collaborator would be a database repository used to load your word definitions from a database. For that, we would need a different solution but that's a story for another time.