> <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">- relaxing NodeBuilderDefinedContext and adding the new contract on it</span><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">I wouldn't really like that as it reduces safety of the AP</span><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">I.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">> </span><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">- an explicit new method deprecating addNode</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div><font face="arial, sans-serif">Related to this is </font><span style="font-family:arial,sans-serif">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?</span></div>
<div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">We could have a new method</span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div>
<span style="font-family:arial,sans-serif">addNode(String name, ElementDescriptor descriptor) or even </span></div><div><span style="font-family:arial,sans-serif">addNode(ElementDescriptor descriptor)</span></div><div><span style="font-family:arial,sans-serif"><br>
</span></div><div><span style="font-family:arial,sans-serif">Leaves the question where does the user get the descriptor from? One way could be to provide access to BeanDescriptor via </span>ConstraintValidatorContext. For nodes added via the deprecated method getDescriptor() we would likely have to return null.</div>
<div><br></div><div>--Gunnar</div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">[1] <a href="https://hibernate.onjira.com/browse/BVAL-336">https://hibernate.onjira.com/browse/BVAL-336</a></font></div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">2012/11/23 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I guess you always learn something new every day :)<br>
This is indeed only working if we use interception types.<br>
<br>
The question is do we want to do that or lean towards one of the<br>
alternative methods:<br>
<br>
- an explicit new method deprecating addNode<br>
- relaxing NodeBuilderDefinedContext and adding the new contract on it<br>
<span><font color="#888888"><br>
Emmanuel<br>
</font></span><div><div><br>
On Fri 2012-11-23 12:57, Gunnar Morling wrote:<br>
> Hi,<br>
><br>
> > Another approach would be to make NodeBuilderCustomizableContext a sub<br>
> insterface of NodeBuilderDefinedContext.<br>
><br>
> I think changing the return type of ConstraintViolationBuilder#addNode()<br>
> to NodeBuilderCustomizableContext is a problem.<br>
><br>
> While that change is source compatible (code using addNode() can be<br>
> compiled against the new API version without having to be adapted) it is<br>
> not binary compatible. That is, code compiled against the previous version<br>
> will fail at runtime:<br>
><br>
> java.lang.NoSuchMethodError:<br>
> javax.validation.ConstraintValidatorContext$ConstraintViolationBuilder.addNode(Ljava/lang/String;)Ljavax/validation/ConstraintValidatorContext$ConstraintViolationBuilder$NodeBuilderDefinedContext;<br>
><br>
> This error occurs, no matter wether the result of addNode() is assigned to<br>
> a variable or not.<br>
><br>
> What we might try to do is to return an intersection type from<br>
> ConstraintViolationBuilder#addNode() like this:<br>
><br>
> interface ConstraintViolationBuilder {<br>
><br>
> <T extends NodeBuilderDefinedContext & NodeBuilderCustomizableContext><br>
> T addNode(String name);<br>
><br>
> ConstraintValidatorContext addConstraintViolation();<br>
> }<br>
><br>
> This is source compatible and AFAICS it's also binary compatible because<br>
> the erasure of T is its leftmost bound, that is NodeBuilderDefinedContext.<br>
> That way code compiled against the old API can still dispatch the addNode()<br>
> method, while code written against the new version can invoke all methods<br>
> defined on NodeBuilderDefinedContext and NodeBuilderCustomizableContext.<br>
><br>
> Btw. I stumbled upon [1] which gives a very good overview on the<br>
> compatibility of all sorts of API changes.<br>
><br>
> --Gunnar<br>
><br>
> [1]<br>
> <a href="http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces" target="_blank">http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces</a><br>
><br>
><br>
> 2012/11/22 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>><br>
><br>
> > Unless anyone has concern, I plan to go for option 3 on<br>
> > <a href="http://beanvalidation.org/proposals/BVAL-221/" target="_blank">http://beanvalidation.org/proposals/BVAL-221/</a><br>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div>