[bv-dev] BVAL-221 Constraint violation builder cannot put constraint on a top level map key

[Gunnar Morling]

> - relaxing NodeBuilderDefinedContext and adding the new contract on it

I wouldn't really like that as it reduces safety of the API.

> - an explicit new method deprecating addNode

Related to this is BVAL-336 [1]. We've added Node#getDescriptor(), so the
question is what should that return for nodes created by the user via the
node builder API?

We could have a new method

addNode(String name, ElementDescriptor descriptor) or even
addNode(ElementDescriptor descriptor)

Leaves the question where does the user get the descriptor from? One way
could be to provide access to BeanDescriptor via ConstraintValidatorContext.
For nodes added via the deprecated method getDescriptor() we would likely
have to return null.

--Gunnar

[1] https://hibernate.onjira.com/browse/BVAL-336


2012/11/23 Emmanuel Bernard <emmanuel at hibernate.org>

> I guess you always learn something new every day :)
> This is indeed only working if we use interception types.
>
> The question is do we want to do that or lean towards one of the
> alternative methods:
>
> - an explicit new method deprecating addNode
> - relaxing NodeBuilderDefinedContext and adding the new contract on it
>
> Emmanuel
>
> On Fri 2012-11-23 12:57, Gunnar Morling wrote:
> > Hi,
> >
> > > Another approach would be to make NodeBuilderCustomizableContext a sub
> > insterface of NodeBuilderDefinedContext.
> >
> > I think changing the return type of ConstraintViolationBuilder#addNode()
> > to NodeBuilderCustomizableContext is a problem.
> >
> > While that change is source compatible (code using addNode() can be
> > compiled against the new API version without having to be adapted) it is
> > not binary compatible. That is, code compiled against the previous
> version
> > will fail at runtime:
> >
> > java.lang.NoSuchMethodError:
> >
> javax.validation.ConstraintValidatorContext$ConstraintViolationBuilder.addNode(Ljava/lang/String;)Ljavax/validation/ConstraintValidatorContext$ConstraintViolationBuilder$NodeBuilderDefinedContext;
> >
> > This error occurs, no matter wether the result of addNode() is assigned
> to
> > a variable or not.
> >
> > What we might try to do is to return an intersection type from
> > ConstraintViolationBuilder#addNode() like this:
> >
> > interface ConstraintViolationBuilder {
> >
> >     <T extends NodeBuilderDefinedContext &
> NodeBuilderCustomizableContext>
> > T addNode(String name);
> >
> >     ConstraintValidatorContext addConstraintViolation();
> > }
> >
> > This is source compatible and AFAICS it's also binary compatible because
> > the erasure of T is its leftmost bound, that is
> NodeBuilderDefinedContext.
> > That way code compiled against the old API can still dispatch the
> addNode()
> > method, while code written against the new version can invoke all methods
> > defined on NodeBuilderDefinedContext and NodeBuilderCustomizableContext.
> >
> > Btw. I stumbled upon [1] which gives a very good overview on the
> > compatibility of all sorts of API changes.
> >
> > --Gunnar
> >
> > [1]
> >
> http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces
> >
> >
> > 2012/11/22 Emmanuel Bernard <emmanuel at hibernate.org>
> >
> > > Unless anyone has concern, I plan to go for option 3 on
> > > http://beanvalidation.org/proposals/BVAL-221/
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
>
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121123/309e8c45/attachment-0001.html