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

[Emmanuel Bernard]

The problem with returning `null` is that it literally creates an
exception clause in your code.

if (eltdescriptor == nukk) {
    /something
}
else {
    switch(eltdescriptor.getKind()) {
    case PARAMETER:
        //do something
    ...
}

So we might want to explore the idea of adding a `UnknownDescriptor` or
`FreeNodeDescriptor` is a specific kind for ad-hoc created via the API.

Should we have the ability to provide the element descriptor when
creating a node? That's a good question. It woud be nice if you could
explore how the code would look like in a "real life" example and see
where getting the elementDescriptor makes the most sense.

Emmanuel

On Fri 2012-11-23 15:21, Gunnar Morling wrote:
> > - 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
> >

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