@JsonValue fails for Java Record

[cowwoc]

Version information
2.12.1
OpenJDK 15.0.1

To Reproduce

Given:

public final record GetLocations(@JsonValue Map<String, URI> nameToLocation)
{
	@JsonCreator
	public GetLocations(Map<String, URI> nameToLocation)
	{
		assertThat(nameToLocation, "nameToLocation").isNotNull();
		this.nameToLocation = new HashMap<>(nameToLocation);
	}
}

I am expecting Jackson to serialize the Map to JSON but instead I get the following exception:

Problem with definition of [AnnotedClass GetLocations]: Multiple 'as-value' properties defined ([field GetLocations#nameToLocation] vs [method GetLocations#nameToLocation()])

[cowwoc]

Adding the following code works around the problem (though ideologically, I'd prefer to serialize the return value of the getter than the field):

@JsonValue(false)
@Override
public Map<String, URI> nameToLocation()
{
	return nameToLocation;
}

[cowtowncoder]

Very likely related to the general issue (hoped to be tackled in 2.13) of matching @JsonCreator (constructor) parameters to fields, so that effectively @JsonValue would be invisible to property handling logic.

On plus side, if so, would get solved along with quite a few other problems.

[pjfanning]

@cowtowncoder if I read this issue correctly, then this appears to be similar to an issue in Scala. Java Records are similar to Scala Case Classes. In a Case Class, the constructor params are automatically accessible publicly - essentially Scala compiler creates a scala class with a field and a method with the name of the field. Annotations are added to the field unless you use a special form of the annotation (@(JsonValue @getter) is an annotation that is added to the derived getter method instead of the field). Scala 3 has a bug where the @getter is ignored so the annotation is not treated correctly.

So the ask on my part, is would it be possible to have jackson-databind PojoPropertiesCollector look for @JsonValue annotations on methods and fields?

[cowtowncoder]

@pjfanning I think this would be part of the big rewrite of Creator-vs-Properties introspection that I was hoping to do for 2.13 but did not have time for. So got pushed forward.

Handling of @JsonValue should be synchronized in a way that avoids any issues with property detection, in case of serialization, yes. Where exactly that should be rectified I am not sure.

One thing that might be help would be reproducing this with regular @JsonCreator-using POJO instead of Record (assuming this is possible). Records have some special handling but this might not be due to that but more general issue.

[pjfanning]

@cowtowncoder thanks for the update.

My comment above was really an enhancement request so that @JsonValue annotations could be supported on fields - would this be feasible?

[cowtowncoder]

They are already, since Jackson 2.9 (see #1428).

[pjfanning]

thanks @cowtowncoder - must be something else going on that is causing the scala 3 stuff not to work

[yihtserns]

...though ideologically, I'd prefer to serialize the return value of the getter than the field...

@cowwoc you can remove the @JsonValue annotation from the Record header, and annotate the accessor instead:

public final record GetLocations(Map<String, URI> nameToLocation)
{
	@JsonCreator
	public GetLocations(Map<String, URI> nameToLocation)
	{
		assertThat(nameToLocation, "nameToLocation").isNotNull();
		this.nameToLocation = new HashMap<>(nameToLocation);
	}

	@JsonValue
	@Override
	public Map<String, URI> nameToLocation()
	{
		return nameToLocation;
        }
}

A Trick

Since this issue is caused by (auto-)propagation of annotation on Records components, we learn that the decision to propagate the annotation to either field and/or accessor method is decided by the @Target supported by the annotation itself.

Since @JsonValue can be annotated on ElementType.FIELD & ElementType.METHOD, it gets propagated to both. Knowing this, you can create a custom meta-annotation for @JsonValue that targets only ElementType.METHOD:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@JacksonAnnotationsInside
@JsonValue
public @interface JsonValueAccessor {
}

Then this will then work:

public final record GetLocations(@JsonValueAccessor Map<String, URI> nameToLocation) // Your custom annotation
{
	@JsonCreator
	public GetLocations(Map<String, URI> nameToLocation)
	{
		assertThat(nameToLocation, "nameToLocation").isNotNull();
		this.nameToLocation = new HashMap<>(nameToLocation);
	}
}

[cowtowncoder]

Ok I think I know how this can be fixed quite easily: Method should have precedence over Fieldso let's use that as tie-breaker.

[cowtowncoder]

Fixed in 2.14 for 2.14.2.

[yihtserns]

@cowwoc please take note of the following gotcha for the workaround you used i.e.:

@JsonValue(false)
@Override
public Map<String, URI> nameToLocation()
{
	return nameToLocation;
}

The fix c23f772 for 2.14.2 can cope with that workaround, so you'll still get the same resulting JSON of {"first":"http://example.com","second":"http://google.com"} even if you don't remove it.

⚠️ BUT if and when you upgrade to 2.15.0, that workaround + the fix for #3352 (specifically #3737) will result in JSON of {"nameToLocation":{"first":"http://example.com","second":"http://google.com"}}, so you must remove it.

[cowwoc]

@yihtserns Got it. Thanks for the head's up.

[cowtowncoder]

Hmmh. Ok that is bit unfortunate wrt compatibility, although not sure if anything can be done about it.
@JsonValue(false) means "do NOT use this method as 'JSON value' accessor.
But I guess had I realized there was a work-around that gets invalidated, I'd probably not have added this fix in 2.14 but only 2.15

[yihtserns]

But I guess had I realized there was a work-around that gets invalidated, I'd probably not have added this fix in 2.14 but only 2.15

@cowtowncoder Eh your fix for 2.14.2 won't cause any problem with the workaround. Let me rephrase:

1. The fix committed for this issue in 2.14.2 will NOT break the workaround.
   • Keeping/removing the workaround won't cause any problem.
2. The fix committed for Do not require the usage of opens in a modular app when using records. #3352 in 2.15 WILL break the workaround.
   • Keeping the workaround will result in incorrect JSON so it must be removed.

Sorry for any confusion.

[cowtowncoder]

@yihtserns ah yes. My bad; I did realize it after writing. Thank you for confirming.
That's a bit better, at least patch would not cause behavioral change.