[JSR308] updates to the Java Language Specification and other things to do

[Maxim Kizub]

Hello.

I have a few notes about proposed syntax changes.

1) I would vote for annotations in method bodies with my both hands. 
They will allow not only more verification possibilities,
but will make code generation much more powerful. For instance, a code 
generator may take the input code like

FileInputStream fis1, fis2;
...
@With ("fis1") { fis1.write(data); }
@With (value="fis2", log="logger") { fis2.write(data); }

and generate code like

try { fis1.write(data); } finally { fis1.close(); }
try { fis2.write(data); } finally { try { fis2.close(); } catch 
(Throwable t) {logger.log(ERROR, t);} }


2) I'd propose to add a standard type for arrays, so that they can be 
written in uniform way, like others
generic types. This may be a keyword type, but better it will be a type 
like "Object" - auto-imported
from java.lang package. In this way the syntax
Array<int> iarr = new Array<int>(10);
shell be semantically fully equivalent to
int[] iarr = new int[10];
The uniform representation will solve problems for annotations on array 
elements for all dimensions,
and the language syntax will be more uniform.

3) I already proposed usage of postfix operators for types. Of cause, [] 
operator will be a standard
operator for arrays. This can be a separate JSR, of cause. Actually, if 
Java will have user-defined
operators for types - why not to have user-defined operators for 
expressions?

4) From the point of view of JSR 305 it would be highly desirable to 
make some syntax for annotation
expressions. For instance, if we have a @NonNull annotation, and method 
that returns null for null
argument and non-null for non-null argument - we shell be able to 
express it somehow, because it's
not possible to calculate such output from method's signature. Something 
like

<@A?=@NonNull> String<@A> foo(String<@A> arg) {
  if (arg == null) return null;
  return "foo"+arg;
}

It's not the proposition of a concrete syntax, but a note, that just 
specification of annotation on
input/output types is not enough to cover all needs of JSR 305. Of 
cause, one may invent special
annotations, like

String<@NotNull_if_NotNull("arg")> foo(String arg);

But expressions are much more powerful, right? We don't invent a special 
operator PlusMinusMult for
expression like (a + b * c).

For concrete syntax and semantic of annotation expressions we may, I 
guess, take a Prolog-like syntax/semantic.