Why is SpringDecoder constructor marked as deprecated?

[djkeh]

Is your feature request related to a problem? Please describe.

spring-cloud-openfeign/spring-cloud-openfeign-core/src/main/java/org/springframework/cloud/openfeign/support/SpringDecoder.java

Lines 52 to 59 in 0828fff

	/**
	* @deprecated in favour of
	* {@link SpringDecoder#SpringDecoder(ObjectFactory, ObjectProvider)}
	*/
	@Deprecated
	public SpringDecoder(ObjectFactory<HttpMessageConverters> messageConverters) {
	this(messageConverters, new EmptyObjectProvider<>());
	}

This simple constructor requiring only messageConverters has been deprecated since #543.
I don't have specific customizers, so SpringDecoder(messageConverters) still works fine with me.
There must be some reason on 6218eeb even if it has no explanation in the commit message body, so I'd like to hear it.
If not, please bring it back.

Describe the solution you'd like

Remove @Depcrecated annotation.

Describe alternatives you've considered

spring-cloud-openfeign/spring-cloud-openfeign-core/src/main/java/org/springframework/cloud/openfeign/support/EmptyObjectProvider.java

Line 27 in 0828fff

class EmptyObjectProvider<T> implements ObjectProvider<T> {

Open EmptyObjectProvider public.

Additional context

• Use WebConverters for Hateoas. #543 (comment)
• 6218eeb

[al-anna]

I support the question / request
At the moment I can only see three options for a workaround:

• either use a deprecated constructor (and use of deprecated methods is highlighted as a potential vulnerability by some of the static code scanning tools)
• put a copy of EmptyObjectProvider into our own project and make use of it, which is also problematic as it is overrides @NonNullApi methods with a {return null;} implementation which is also an issue for code scanning tools
• invent your own version of EmptyObjectProvider which would pass through all static code checks but that's a waste of effort as in the end we don't want any customizers..

[georgeanderson]

I have just come across this problem. Removing @deprecated annotation seems the most sensible approach here. I can submit a merge request for that, but giving this issue hasn't been triaged since March makes me wonder if the change wouldn't be equally "ignored".

[al-anna]

One option we found is let Spring autowire the customizers by providing them in the Decoder constructing method, like

  @Bean(name = "feignDecoder")
  public Decoder myFeignDecoder(
      final @Qualifier("objectMapper") ObjectMapper objectMapper,
      final ObjectProvider<HttpMessageConverterCustomizer> customizers) {                                   // this
    final MappingJackson2HttpMessageConverter jacksonConverter =
        new MappingJackson2HttpMessageConverter(objectMapper);
    final ObjectFactory<HttpMessageConverters> objectFactory =
        () -> new HttpMessageConverters(jacksonConverter);
    return new ResponseEntityDecoder(new SpringDecoder(objectFactory, customizers));               // and then using those
  }

Unless there's something funny in your classpath Spring will autowire an empty list of customizers and this is what we were looking for in first place. This was a bit of a creative solution to avoid any static code scan tool issues raised.