[JSR308] array-valued annotations
Tom.Ball at Sun.COM
Tue Jan 30 01:28:46 EST 2007
David Wagner wrote:
> Tom Ball writes:
>> It sounds like we are in agreement, but I prefer the term "contract"
>> (from Eiffel's "Design By Contract") to "type" when using metadata to
>> provide additional information to error-checkers regarding an API. My
>> guess is that the JSR's spec will be less confusing by keeping these
>> concepts separate.
> Well, I don't share that preference. A type is not the same thing as
> a contract. I prefer to use the term "contract" when it is right to do
> so, and the term "type" when that is right. Some error-checkers work
> by methods that are better understood as type-checking than as anything
> having to do with Eiffel's "design by contract"; others, just the reverse.
> (For instance, a type-qualifier system like CQual or JQual would be a good
> example of something best understood in terms of types, not contracts;
> in comparison, something like JML is about contracts, not types.)
Of course I know types and contracts aren't the same thing (my project
has been working closely with the javac team for the past two releases
on their intermediate model). My point was that a specification defines
more than types, and I believe that notes to error checkers are part of
a specification. Types don't equal the specification, even though they
are a major part of it. If you believe that annotations can be used to
define new types, then you are discussing a different language than Java
as they are explicitly not allowed to do so by the JLS. That is, unless
you are also redefining how the JLS defines "type", which doesn't make
much sense in the context of a JSR discussion.
I'm sorry I got your hackles up referring to Eiffel, and am not
suggesting in any way that we implement DBC. My references to contract
are always lower-case, referring to the usage agreement a good
specification outlines between a class's public design and its clients.
More information about the JSR308