I concur with Matt's point below. Because there hasn't been a
validation standard for most of Java's lifetime, most method
constraints are in javadoc contracts only. I think it's important for
the BV spec to recognize this fact -- not every precondition is
available for introspection at runtime. Thus, there is a long pedigree
here of people who could benefit from BV, if only by chucking their
custom validation code for BV.
The OrderService is a great example due to the total absence of BV
annotations. I don't think the spec should assume the lack of BV
annotations is an intentional use of BV (i.e., no constraints). I can
only see two ways out of this problem to address this fact. Either
annotate OrderService to signify its validation is undefined or
annotate OrderService to signify validation is intended. Thoughts?
Paul
On Mon, Jul 23, 2012 at 9:16 AM, Matt Benson <mbenson(a)apache.org> wrote:
Okay, point taken. Thanks for clarifying the distinction between
pre/post-conditions corresponding to method parameters vs. return
values here. Still, consider the JDK itself: the java.util.Deque
interface imposes no requirements on the parameter to its #push()
method, yet the java.util.ArrayDeque implementation forbids null
elements and is declared as throwing an NPE if the parameter to
#push() is null. I can fully understand your assertion that this
violates DbC and even basic OO principles, but is it *necessary* that
BV deny users the option to work with such a design? I'm not yet
convinced of the harm it would cause, beyond implementation complexity
(which IMO doesn't seem extensive), to permit a user to add decoupled
validation constraints per Paul's example, or to customize a given
implementation as in mine. Nothing here would prevent the purist user
from operating per your recommendations.