> - 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@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@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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >

> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev