Expose `translate()` method of standard `PropertyNamingStrategy` implementations

[toolforger]

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

I work on a REST server that uses PropertyNamingStrategies.SNAKE_CASE to translate Java property names to JSON field names.
The application code needs to report errors to the REST client, using the translated property names, but it has only the Java names.
PropertyNamingStrategies.SNAKE_CASE does have a translate function that does exactly what I need, but it is declared in NamingBase while SNAKE_CASE is declaredas PropertyNamingStrategy.

Describe the solution you'd like

• Declare public translate(String) in PropertyNamingStrategy, or
• Declare PropertyNamingStrategy SNAKE_CASE as NamingBase or SnakeCaseStrategy.

Usage example

Current application code:

import com.fasterxml.jackson.databind.PropertyNamingStrategies.SnakeCaseStrategy;
...
private static SnakeCaseStrategy toSnakeCaseConverter = new SnakeCaseStrategy();
...
propertyName = toSnakeCaseConverter.translate(propertyName);

Application code after change:

import static com.fasterxml.jackson.databind.PropertyNamingStrategies.SNAKE_CASE;
...
propertyName = toSnakeCaseConverter.translate(propertyName);

[cowtowncoder]

While I see how this might be convenient, from design perspective translate() method is an internal implementation detail for "simple" strategies. It is specifically not part of PropertyNamingStrategy because it may not work for all strategies: for example in some cases Field and Method names might require different handling. Or more likely translation is configurable with MapperConfig; that is not passed to translate().

So I will not make such a change, although I am not completely against improvements that would allow usage.
Another possibility would be to change type of SNAKE_CASE etc, but this would unfortunately be bytecode-incompatible change and as such cannot be done in a 2.x version.

[toolforger]

Oh. If translate being public makes the reader think it's official API.

Would changing public static final PropertyNamingStrategy SNAKE_CASE to a subclass indeed be binary-incompatible?
If that's the case, then I have a third suggestion:

• Have SnakeCaseStrategy declare public static final SnakeCaseStrategy INSTANCE = new SnakeCaseStrategy(), as there's no harm in that. (PropertyNamingStrategy.SNAKE_CASE could use that, without changing the declared type.)

[cowtowncoder]

Hmmh. The one downside is just that of sort of promoting use of translate(). You are right in that the method really should have been marked as protected, and yes, making it public makes it tempting thing to use.
My main concern would just be that going forward some of implementations may essentially drop use of translate().

However, given all of above, yes, I think I'll do what you suggest and create INSTANCE for all of types.

Thank you for suggestion!

[cowtowncoder]

Implemented; @toolforger if you can easily build 2.14.0-SNAPSHOT from 2.14 it'd be great if you could verify this is what works. It'll go in 2.14.0-rc3 (if I release one more RC), and in 2.14.0 regardless.