I cannot infer your intent, could you create a new DTO and make a new concise and clear test to reveal your intent?

It is not for common case.

You can not confirm that user uses the annotation @Repeatable , the name of property value .

I think it should be removed.

@seongahjo
Ah, I understand! Instead of defining a new findAnnotations in ArbitraryGeneratorContext, should I handle duplicate annotations within ArbitraryGeneratorContext?

Does this.getResolvedProperty().getAnnotations() not return the duplicate annotations?

Could you make a test to show when the duplicate annotation is an issue?

Does this.getResolvedProperty().getAnnotations() not return the duplicate annotations?

Yes.

@Getter
@Setter
public class TestSpec {
	@Max(value = 50)        // interface jakarta.validation.constraints.Max
	private BigDecimal a;

	@Max(value = 100)       // multiple @Max annotations - internally processed as container annotation
	@Max(value = 50)
	private BigDecimal b;     

	@Max.List({             // interface jakarta.validation.constraints.Max$List
		@Max(value = 100),
		@Max(value = 50)
	})
	private BigDecimal c;
}

Duplicate annotations appear to be automatically processed in the same way as the annotations in field c.

Therefore, I implemented findAnnotations to process the contents within Max$List in the same way as regular duplicate annotations, as shown above.

Without the Repeatable processing in findAnnotations, if we only use this.getResolvedProperty().getAnnotations(), we would need to search twice using getAnnotations(Max.class) and getAnnotations(Max.List.class). This is because we need to consider both cases where there is a single annotation and multiple annotations.
Since getAnnotationsByType cannot be used in the current implementation, I chose to implement findAnnotations to handle both single annotations and container annotations in a unified way.

It is not clear to me how it works when there are multiple constraints on the same property.

Does the JSR-303 support multiple annotations on the same property within the same group?

I only found the applying multiple constraints within the different group.
https://beanvalidation.org/1.0/spec/#constraintsdefinitionimplementation-multipleconstraints

Since the @Repeatable annotation allows multiple annotations to be applied, it was confirmed during testing that all validation annotations (including duplicates) are processed as expected.

However, JSR-303 does not define a specific approach for handling duplicate annotations, meaning implementations can vary.

Given this, rather than implementing complex logic to handle duplicates, it may be more practical to revert to the original approach of simply checking for the presence of annotations.

I don't understand why the JavaDecimalConstraint class needs to manage separate min/max values for negative and positive numbers. In the previous implementation with the @Digits annotation, this was necessary, but with the "3. Improved @Digits Annotation Processing," the method for enforcing maximum digit limits has changed. In this case, wouldn't it be sufficient to just manage the min/max values and their inclusiveness to generate random numbers? What do you think about changing this approach?

Is there a better idea for addressing both positive and negative values in the case of @Digits?

For example, in the case of @Digits(integer=3, fraction=2), it should be the value that satisfies the following constraints.

1. 0 <= value <= 999.99
2. -999.99 <= value <= 0

Looking at your example with @Digits(integer=3, fraction=2), I believe we could satisfy these constraints simply using a minimum (-999.99) and maximum (999.99) value. Is there any specific case where we need to manage positive and negative ranges separately in the current implementation?

Moreover, simplifying to a single range would actually help prevent potential distribution issues. For instance, with the current implementation, when we have constraints like:

@Digits(integer=3, fraction=2)
@Min(-2)
@Max(100)
private BigDecimal b;

The resolveArbitrary method in JqwikJavaArbitraryResolver splits the generation between negative and positive ranges with equal probability, leading to disproportionate distribution where values between -2 and 0 have the same total probability as values between 0 and 100. By using a single range approach, we could ensure truly uniform distribution across the entire valid range.
If I'm missing any important considerations, please let me know.