[JSR308] array-valued annotations

Sun Jan 28 20:09:48 EST 2007

> > I think I see Pavel's point, though; the declaration "doc" implicitly
> > suggests that all of the dimensions to the "jagged" array behind the
> > reference are of the same type (Document).
> 
> I presume you mean all the values, not all the dimensions.
>
No, in this case, I meant dimensions, but in the more loosely-based notion
that the arrays are based around the Document type. (I'm not speaking of the
Document vs. Document[] vs. Document[][] as being separate types for
purposes of this discussion.)

> Correct.  But using this notation,
>    Document [][] doc
> means
>    Document [Document[]] doc
> 
> And we find that, unfortunately, Java programmers like to sometimes
> make the outer Document[] type different than the inner Document[];
> i.e., one might permit null elements and one might not.
>
Ew; count me out of that crowd.

> To me, supporting type annotations in Java means supporting
> annotating *all* of the types one can declare in Java, not just some
> of them.
>
Does that include the types that are created by the Dynamic Proxy class? Or
the primitive types themselves? I hate to say it, but the array types are
referred to as "pseudo-types" for a reason.

> Doesn't this represent a fairly conservative view of what constitutes
> a type?  I certainly consider such annotations as part of the type
> signature.
>
Conservative or not, two classes whose only differentiation (including name)
is the presence or lack thereof of an annotation, is illegal. The presence
or absence of an annotation does not show up in the JVM-level signature, and
therefore cannot be used to differentiate in method overloading. Ditto for
fields. The annotation is not part of the signature, and to change that
would be a fairly drastic change throughout the JVM, I would think.

Let's not create a JSR that's unworkable for the implementors. Joe, assuming
this JSR goes to Final status, who would be implementing this in the JVM and
related tools?

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com

> -----Original Message-----
> From: Joseph Kiniry [mailto:kiniry at acm.org]
> Sent: Sunday, January 28, 2007 1:20 AM
> To: Ted Neward
> Cc: 'Gary T. Leavens'; 'Pavel Krupets'; jsr308 at lists.csail.mit.edu
> Subject: Re: [JSR308] array-valued annotations
> 
> Hi Ted et al,
> 
> Thank you all for these quality initial discussions.  It is nice to
> see new perspectives and hear new voices on these issues.
> 
> On 28 Jan, 2007, at 3:09, Ted Neward wrote:
> 
> > I think I see Pavel's point, though; the declaration "doc" implicitly
> > suggests that all of the dimensions to the "jagged" array behind the
> > reference are of the same type (Document).
> 
> I presume you mean all the values, not all the dimensions.
> 
> > I can't declare the different dimensions to be of different types,
> > a la:
> >
> > Document[Object[]] doc = ...
> >
> > Meaning, a single dimenion of Document objects each of which in
> > turn are
> > also references to Object arrays. (Makes no sense!)
> 
> Correct.  But using this notation,
>    Document [][] doc
> means
>    Document [Document[]] doc
> 
> And we find that, unfortunately, Java programmers like to sometimes
> make the outer Document[] type different than the inner Document[];
> i.e., one might permit null elements and one might not.
> 
> To me, supporting type annotations in Java means supporting
> annotating *all* of the types one can declare in Java, not just some
> of them.
> 
> > If annotations are to be considered part of the type's signature
> > (which is
> > WAAAAY beyond what we designed or had in mind), then Pavel's right, a
> > multidimensional array has to contain all the same type, regardless
> > of the
> > number of dimensions.
> 
> Doesn't this represent a fairly conservative view of what constitutes
> a type?  I certainly consider such annotations as part of the type
> signature.
> 
> Indeed, as reiterated above, a multi-dimensional array does contain
> only a single value type.  Unfortunately, such arrays in Java are
> decomposed into more than just their data values.  Consequently,
> those of us that must write rich type annotations on such arrays in
> "real" software frequently see situations like those mentioned
> earlier by John and Gary.
> 
> While perhaps we'd like to say the use of types like these represent
> a bad practice in software design, as emphasized by Tom, they are
> actually fairly common, and thus we need to be able to describe them
> precisely, preferably in a manner that is easily understood by Java
> developers.
> 
> Joe
> ---
> Joseph Kiniry
> School of Computer Science and Informatics
> University College Dublin
> http://secure.ucd.ie/
> http://srg.cs.ucd.ie/
> 
> > Ted Neward
> > Java, .NET, XML Services
> > Consulting, Teaching, Speaking, Writing
> > http://www.tedneward.com
> >
> >
> >> -----Original Message-----
> >> From: jsr308-bounces at lists.csail.mit.edu [mailto:jsr308-
> >> bounces at lists.csail.mit.edu] On Behalf Of Gary T. Leavens
> >> Sent: Thursday, January 25, 2007 9:48 AM
> >> To: Pavel Krupets
> >> Cc: jsr308 at lists.csail.mit.edu
> >> Subject: Re: [JSR308] array-valued annotations
> >>
> >> Hi Pavel and all,
> >>
> >> On Thu, 25 Jan 2007, Pavel Krupets wrote:
> >>
> >>> Hello,
> >>>
> >>> I don't think it's appropriate to use annotations like:
> >>> "Document[][@Readonly]". What I mean is that there is no much
> >>> sense in
> >>> specifying different annotations for different dimensions of the
> >>> array.
> >> If
> >>> such behavior is needed other types can be used (like List<...>,
> >>> etc). I
> >>> think annotations should be used only with:
> >>>
> >>> - array as an object (like: @NonNull @Readonly Document[][] doc
> >>> = ...)
> >>> - objects which are stored inside arrays (like: Document @NonNull
> >>> @Readonly [][] doc = ...)
> >>>
> >>> The reason behind this is that array (one or multi-dimensional)
> >>> is an
> >>> 'atomic' type which has type of stored object and dimensions.
> >>> Just want
> >> to
> >>> keep things simple.
> >>
> >> I agree that keeping things simple is good when possible.  But
> >> semantically, each array declared is itself a location which holds a
> >> collection of locations.  Thus, to simplify to one dimension:
> >>
> >>     Document[] docs;
> >>
> >> could look like
> >>
> >>                        0  1  2  3
> >>     docs [ *-]------> [  |  |  |  ]
> >>
> >> and the location named doc can be null or readonly independent of the
> >> locations doc[0]..doc[3].  The same holds for readonly.
> >>
> >> You would lose expressiveness if you can't independently talk about
> >> these different locations.
> >>
> >>          Gary T. Leavens
> >>          Department of Computer Science, Iowa State University
> >>          229 Atanasoff Hall, Ames, Iowa 50011-1041 USA
> >>          http://www.cs.iastate.edu/~leavens  phone: +1-515-294-1580
> 
> 
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.12/653 - Release Date: 1/26/2007
> 11:11 AM
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.12/655 - Release Date: 1/28/2007
1:12 PM