Question: Support type-use annotations for collection element validation (List<@Valid T>)

[mcruzdev]

Hi folks, thanks a lot for this great project!

I have a question regarding Bean Validation annotations on generic type arguments (Java 8+ type-use annotations).

Current behavior

Given a JSON Schema that represents an array of objects, jsonschema2pojo generates:

@Valid
private List<TaskItem> _do = new ArrayList<>();

This places @Valid on the container (List) instead of on the type argument.

Expected / desired output

Ideally, the generated code would use a type-use annotation on the generic argument:

@Valid
private List<@Valid TaskItem> _do = new ArrayList<>();

(or even just List<@Valid TaskItem> depending on configuration)

This style is supported since Java 8 and is the recommended approach in Jakarta Bean Validation for expressing cascaded validation on collection elements.

Question

Is it possible (or planned) to support generating type-use annotations on generic type arguments? If not currently supported, would it be feasible to extend the API (e.g. via SchemaRule, Annotator, or another extension point) to enable this?

[joelittlejohn]

This is a tough one because neither the official codemodel library or the popular fork by phax support this kind of annotation. You can read more at phax/jcodemodel#50.

There are some possible workarounds discussed on that issue, and to implement any of them you could just create a custom RuleFactory and extend/replace the ValidRule.

In the meantime I think we need to move to the phax library and start submitting PRs there.

[ricardozanini]

@joelittlejohn, thanks for your reply. How feasible is it to move to phax library?

[mcruzdev]

Thanks a lot for the quick answer and to the help 👍🏼

[ricardozanini]

@joelittlejohn so can we expect that you will replace the old dependency with phax?

jsonschema2pojo/pom.xml

Lines 445 to 449 in 32fb6a6

	<dependency>
	<groupId>com.sun.codemodel</groupId>
	<artifactId>codemodel</artifactId>
	<version>2.6</version>
	</dependency>

[joelittlejohn]

Yes, that's right

[joelittlejohn]

Okay, so I have good news and bad news.

The bad news is that I've investigated moving to the phax library and there are some things I don't like about this approach. I thought it was a drop-in replacement with minor breaking changes but there's more renaming and moving and things than I like. My bigger concern though is that there is a huge community for jsonschema2pojo with a lot of userspace extension points and customisation. If we change our underlying codegen library we break all of that. Yes, it's not great because arguably it's an implementation detail, but it has provided massive value for users to be able to customise in this way.

The good news is that a) I've helped the phax library with some use PRs for records and type use annotations and b) I now think there is a very viable way to achieve what we need here with only additive changes. It means I think we can add a couple of additional types that extend the sun codemodel rather than having to hack around in the core of it. So my plan is to implement this change directly in jsonschema2pojo and it's quite small.

[ricardozanini]

Thanks @joelittlejohn! Your concern is super valid, and we are one of your users who would (potentially) break :)

However, I think you will eventually have to move away from the outdated library (perhaps on a major release?). Aside, what about https://github.com/eclipse-ee4j/jaxb-ri/tree/master/jaxb-ri/codemodel? Just asking because @unkish pointed me there.

[joelittlejohn]

Right now, I don't actually see a compelling reason to make a breaking change there. I think we can achieve what we need by extending rather than replacing. This may not be the case forever, I agree, but let's see.

eclipse-ee4j/jaxb-ri is a much better target for upgrade as it's a continuation of the same project and a true drop-in replacement that will minimise disruption. I actually still don't think it is easy get PRs and changes merged there (e.g. for records, or other major language features) but at least it's alive.