PropertyNamingStrategy is an upside-down solution to a common problem

The problem that I "solved" using a PropertyNamingStrategy is one
that has been frequently raised on the Web: attributes coming down
in JSON format with an "@" prefixed to the the attribute name.
Jackson does not create JSON with the "@" prefix, but it is quite
desirable that it be able to deal with JSON that has this
idiosyncracy, as client side developers do not always have control
over what the server side is sending.

The problem with the PropertyNamingStrategy solution is this: what
one receives is a property name as determined by Jackson when it
introspects the class. SFAICT, there is no way to know within the
PropertyNamingStrategy implementation that the property name is an
attribute name versus an element name. Even if there were, the
problem to be solved is not "what name will incoming JSON use for
this property?" Rather the problem is, "here is the name that
incoming JSON is using, what should it be to make Jackson happy?"
So for example, if the data class has the property

@XmlAttribute(name = "id")
void setId(int id) ...

the question should not be "what name does the 'id' property have
in the received JSON" but rather "kindly rename '@id' name found
in incoming JSON to the name that Jackson would expect, based on
your class properties and annotations." A plugin solution that
addresses the second question will be much more resilient than a
solution that that addresses the first question.