Registering Spring Converters via Extending Its Interface

This article is a step-by-step guide aimed at demonstrating an interface-based approach to using Spring's type conversion system.

Spring 3 introduced a core.convert package that provides a general type conversion system. The system defines an SPI to implement type conversion logic and an API to perform type conversions at runtime.

In the proposed implementation, the registration process of Converters by ConversionService happens via injecting dependencies through an interface default method. This results in a quite extensible and encapsulated solution when the process of onboarding new instances of Converter takes place during their initialization as Spring beans.

ConversionService Initialization

To get started, let us create an instance of ConversionService by extending its implementation of DefaultConversionService: 

package com.mycompany.converter;

import org.springframework.core.convert.support.DefaultConversionService;
import org.springframework.stereotype.Component;

@Component
class MyConversionService extends DefaultConversionService {

}

Extending Converter API

Next up is extending Converter interface by adding a default method which will be used for registration implemented instances of MyConverter by auto-wiring a ConversionService bean: 

package com.mycompany.converter;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.core.convert.converter.Converter;

interface MyConverter<S, T> extends Converter<S, T> {

    @Autowired
    default void onboardConverter(ConversionService myConversionService) {
        myConversionService.addConverter(this);
    }
}

Converter Implementation

The final step is adding a concrete implementation of MyConverter:

package com.mycompany.converter;

import org.springframework.stereotype.Component;

@Component
class SomeConverter implements MyConverter<String, Integer> {

    public Integer convert(String source) {
        return Integer.valueOf(source);
    }
}

Take notice that all mentioned classes, such as MyConversionService,  MyConverter, SomeConverter are placed in com.mycompany.converter package and have package-level access in the interest of encapsulation in order to expose the components created for the rest of a system only through Spring's interfaces.

Another point worth highlighting is that SomeConverter is a bean. This lets us for some converters if it is needed to have more complicated business logic implemented with some other dependencies which can be easily injected. And at the same time, at this level of abstraction, we are not bothered by the registration of our SomeConverter by MyConversionService which happens behind the scenes. What is beneficial from a maintenance standpoint is that other converters can be easily added or removed, and existing ones refactored without having any impact on registration business logic.

ConversionService Usage

The usage is the same as described in Spring documentation 3.4.6. Using a ConversionService Programmatically:

package com.mycompany.service;

import org.springframework.stereotype.Service;
import org.springframework.core.convert.ConversionService;

@Service
public class MyService {

    public MyService(ConversionService myConversionService) {
        this.myConversionService = myConversionService;
    }

    public void doIt() {
        this.myConversionService.convert(...)
    }
}

Where myConversionService bean should just be injected as a dependency to perform conversion operations through registered converters.

Final Word

That is basically what I wanted to cover here. Hopefully, someone will find it useful when they are dealing next time with Spring's type conversion system.

From my point of view, using default interface methods for dependency injection is a rather nonstandard approach that may not be obvious and even not known. I guess we should not always follow this direction. Still, I do believe that it can be useful to know about such a possibility, which in certain circumstances, can lead to quite an elegant solution. It is the same as with recursion, i.e., you should know about it and what alternatives are to be able to decide whether it suits well your concrete situation or not.