Should the spec mandate an exception in case of @ExtractedValue non wildcards

Description

See https://github.com/beanvalidation/beanvalidation-spec/compare/2a9d0ce21856386a8bf9a1d9e963ebffc049604a...spec-full#diff-09dfff2a72d8d7a7663084247ccc6b32R13072

Reasons for raising ValueExtractorDefinitionException include:
[...]

  • A non-wildcard type parameter has been marked with `@ExtractedValue`

I wonder if mandating the exception in that case will make the experimentation by specific providers impossible. I'd rather have the window open with a "can" in the spec on that subject.

Thoughts?

Environment

None

Activity

Show:
Gunnar Morling
April 21, 2017, 1:11 PM

Couldn't an implementation enable such usage via an opt-in switch? That'd make apparent that relying on this functionality may result in portability issues.

Emmanuel Bernard
April 21, 2017, 2:40 PM

if you really want people not to use that feature because of too many hop to go through, then I guess yes that's possible. See where I'm going?

Gunnar Morling
July 11, 2017, 8:01 AM

The wording on this has been made more liberal towards extended support by specific providers, hence I'm going to close this one as "Out of Date".

Assignee

Unassigned

Reporter

Emmanuel Bernard

Labels

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Priority

Major
Configure