[JSR308] Section 3.5, syntax of array annotations

Tom Ball Tom.Ball at Sun.COM
Thu Aug 2 11:44:50 EDT 2007

Bill Pugh wrote:
  > Overall, all of the proposals for array syntax annotations are horrible
> complicated and I worry about whether people would apply/interpret them 
> correctly. It may be that the syntax/problem is so nasty that you can't 
> some up with a solution that is most developers could correctly use most 
> of the time, and so you just shouldn't bother.

That's very true, and they have the added disadvantage that compiler 
teams don't have a choice as to whether to ignore this syntax.  We 
therefore have an enhancement which requires a lot of work to implement 
but which few developers are likely to use (correctly), which are the 
normal criteria a project team uses to drop it.

> Anyway, the annotation you are going want to use most frequently on a 
> multidimensional array is
> @Matrix double [][] data;
> which indicates that data is a rectangular unaliased and unchanging matrix.
> If you want to do something for arrays, I'd encourage attemping 
> something simplier: just come up with a way to annotate the element at 
> the bottom of the array nesting. For example,
> @Nonnull int [] @Nonnegative data;
> to represent a nonnull reference to an array of nonnegative integers. While
> @Nonnegative int [] @Nonnull data;
> might make a little more sense, we can't use it since it won't be 
> compatible with pre-Java7 uses of annotations.

I agree completely; developers who want to define combinations of 
required nonnull and optionally null array contents should use different 
data structures, as there is a better design hiding within.

A simple example is the Swing event listener arrays, which are pairs of 
data elements -- whether the first half of each pair is nonnull or null, 
the other must be the same.  It's a mess of C code dressed up as Java. 
A better design is to declare a simple pair class, which has two nonnull 
data members, and then declare an array with possibly null elements. 
Besides being easier to test and more obvious when reading, the code 
that works with a pair can be moved into the new class where it belongs.


More information about the JSR308 mailing list