[JSR308] array-valued annotations

[Ted Neward]

> One of the purposes of JSR308 annotations is to make it possible for
> plug-in writers to design and enforce richer type systems -- all without
> changing the base Java type system.
> 
We do have a significant problem in your example, though, David; unless I
miss my guess, it won't compile. (At least, not in 1.5; I don't have a 1.6
compiler handy to test it.) That means that no matter how much we want to
support that kind of syntax, it's not within the purview of this JSR to
permit or mandate. 

As I understand the scope of the JSR (and reinforced by Joe's comment of a
few days ago), we cannot change the language. Period. No matter how much we
might want to, no matter how useful the suggestion made will be, no matter
how much we all agree it should be there.

(Now, if we want to try and expand the scope of the JSR to include language
and/or JVM changes, and we can get buy-off from Sun to do so, then let's do
so, by all means....)

> I think that speaking of "the type system" is misleading.
> There is not just one type system; there may be multiple type systems
> floating around.
>
I *strongly* disagree with this assertion. If this is the Java language,
then there is only one "type system" in play here, and it's the one defined
by the JVMS and JLS. Annotations were never intended to replace or supplant
the Java type system, but to provide additional extensions to the (singular)
type system that others could process. If a plug-in wants to infer
additional information about the intent of the programmer as expressed by
annotations on a type within the type system from the annotations present in
the code (compiled or source), then that's certainly within their rights to
do so, but fundamentally annotations cannot alter the meaning of the
compiled code as javac sees it. This is documented in the annotation spec
(and, I believe, in the JLS itself), and before you cry foul, I agree it's
probably one of the slipperiest statements in the whole thing, and the one
thing I think we should have spent a LOT more time nailing down. :-/

> First, there is the base Java type system (i.e., the type system that
> results after erasing the annotations).  The base Java type system is
> what is enforced by "javac" and what is specified in the JLS.
>
Said annotations may not be erased, though--they are part of the type
metadata if the annotation was defined to be CLASS or RUNTIME retention.
Only SOURCE-retention annotations are erased after compilation.

> Second, there is the type system enforced by the plug-in that processes
> these annotations.  In many cases, the expectation is that there will be
> some plug-in or some source code analysis tool that will inspect the
> annotations and use the annotations to reject or warn about certain code
> constructs.  In many cases, this may amount to the plug-in specifying and
> enforcing a strictly more restrictive type system than the base Java type
> system.
>
Which doesn't define a new type system, but merely extends the old one.
Which, in essence, leaves us with one type system, whose rules we must
regard as a base minimum and not change. Which, thus, means that a plug-in
is restricted to offering warnings or messages about what the annotations
specified on the types in the existing type system imply based on usage. And
so on.

Seems to me our hands are kinda tied on this one, guys.

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 David Wagner
> Sent: Monday, January 29, 2007 7:00 PM
> To: jsr308 at csail.mit.edu
> Subject: [JSR308] array-valued annotations
> 
> Ted Neward writes:
> >I think we're trying to decide if (a) an annotation on a local variable
> >declaration is part of its type signature, [...]
> >Assuming (a) is false, and that the annotations are not part of the type
> >signature, [...]
> 
> I think that speaking of "the type system" is misleading.
> There is not just one type system; there may be multiple type systems
> floating around.
> 
> First, there is the base Java type system (i.e., the type system that
> results after erasing the annotations).  The base Java type system is
> what is enforced by "javac" and what is specified in the JLS.
> 
> Second, there is the type system enforced by the plug-in that processes
> these annotations.  In many cases, the expectation is that there will be
> some plug-in or some source code analysis tool that will inspect the
> annotations and use the annotations to reject or warn about certain code
> constructs.  In many cases, this may amount to the plug-in specifying and
> enforcing a strictly more restrictive type system than the base Java type
> system.
> 
> For instance, in the code:
>     @Nonnull Object[@Nonnull] a;
> the type of 'a' in the base Java type system is Object[], while the
> type in the plug-in's type system might be "a nonnull reference to an
> array holding nonnull references to Object".
> 
> Note that plug-ins can enforce a more restrictive type system even though
> they cannot change the underlying base Java type system.
> 
> One of the purposes of JSR308 annotations is to make it possible for
> plug-in writers to design and enforce richer type systems -- all without
> changing the base Java type system.
> 
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
> 2:49 PM
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
2:49 PM