Deserializing to single-value Record from scalar values

Describe the bug I experience a potential regression since 2.12.0 when trying to deserialize a scalar value to a single-value Record. Consider this test case:

import static org.junit.jupiter.api.Assertions.assertEquals;
import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.junit.jupiter.api.Test;

class RecordStringDeserializationTest {

  private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper();

  @Test
  void deserializeMyValueRecordFromPrimitiveValue() throws Exception {
    assertEquals(new MyValueRecord("foo"), OBJECT_MAPPER.readValue("\"foo\"", MyValueRecord.class));
  }

  final record MyValueRecord(@JsonProperty String value) {}
}

This works as expected in 2.11.3, since 2.12.0 a MismatchedInputException is thrown:

com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance of `us.byteb.jackson.RecordStringDeserializationTest$MyValueRecord` (although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('foo')
 at [Source: (String)""foo""; line: 1, column: 1]

This still works as expected if an explicit factory method annotated with @JsonCreator is provided for the Record or for an equivalent Class without explicit @JsonCreator (see additional test cases). I would expect the behavior for Records to be the same as for Classes, it also seems contrary to the brevity of Records to have to define an additional factory method.

Version information 2.12.0

To Reproduce See test case above.

[cowtowncoder]

@bfncs Yeah, this wasn’t something I had thought of until you reported it; I did not realize Records were already used, although it was mentioned as something that sort of works (when discussing initially addition of explicit support for 2.12).

I will add a note on 2.12 release page: thank you for bringing this up.

[bfncs]

Thanks very much for answering this in great depth 💐 This makes sense and is still easy and consistent to use. I was only confused by the changed heuristic behavior between versions.