(regression) Factory method generic type resolution does not use Class-bound type parameter

[marcospassos]

Describe the bug
We're currently using Jackson 2.11.2, updating to the latest version has broken several tests. After some investigation, we discovered that the bug was introduced in version 2.11.3, as the reproduction test shows.

The bug is somewhat related to static factory methods (stamp method in the example) – the same does not happen to constructor methods.

Version information
Introduced in 2.11.3

To Reproduce
#3221

Expected behavior
No error

Additional context
Add any other context about the problem here.

[marcospassos]

@cowtowncoder, this issue is blocking our whole system from receiving updates. It also affects our Kafka applications (Avro serialization), and I believe there is nothing to do except report it here and track down the issue.
Is there anything else I can do?

[cowtowncoder]

@marcospassos This is literally on top of my to-evaluate list (https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson-Work-in-Progress) so I hope to look into it tonight or tomorrow.

[marcospassos]

Thank you for the feedback!

[cowtowncoder]

Looking at 2.11.3, guessing this might be related to #2795 or possibly #2846.
If it wasn't for something in a patch I would have guessed that there was some optimization going on that accidentally prevented application of mix-ins.

[cowtowncoder]

Hmmh. Some bad news here: I am not sure how this should ever have worked. A fundamental flaw is this:

    static class Timestamped<T> {
        public static <T> Timestamped<T> stamp(T value, int timestamp) {
            return new Timestamped<>(value, timestamp);
        }
   }

wherein it appears assumed that T declared for the factory method is somehow bound to class type variable T. This is not the case, as we might as well have:

    static class Timestamped<T> {
        public static <XYZ> Timestamped<XYZ> stamp(XYZ value, int timestamp) {
            return new Timestamped<>(value, timestamp);
        }
   }

which would show the problem -- the two type parameters T are completely unrelated in the first example.
They do not refer to the same type; and the one for factory method really is effectively declared like:

        public Timestamped<?> stamp(Object value, int timestamp) {
            return new Timestamped<>(value, timestamp);
        }

Static methods and fields are not really "part" of the class, and specifically they do not get bound type parameters -- if they did, there would be no need to add that <T> between static and Timestamped.

What I do not understand, tho, is how this would ever have worked. I don't think it really should.
And it is very unfortunate if it appeared too, simply due to naming.

[marcospassos]

So, if we rename the factory name generic parameter to anything other than T is it supposed to work?

[marcospassos]

Apparently not. Even renaming the generic parameter to avoid conflict, the issue persists. So I believe it should be something else.