http://jcp.org/aboutJava/communityprocess/edr/jsr308/index2.html. Aus der Spezi:
JSR 308 extends Java to allow annotations on any use of a type, and on type parameter declarations.
Beispiele:
for generic type arguments to parameterized classes:
Map<@NonNull String, @NonEmpty List<@Readonly Document>> files;
for generic type arguments in a generic method or constructor invocation:
o.<@NonNull String>m("…");
for type parameter bounds, including wildcard bounds:
class Folder<F extends @Existing File> { … }
Collection<? super @Existing File>
for class inheritance:
class UnmodifiableList<T> implements @Readonly List<@Readonly T> { … }
for throws clauses:
void monitorTemperature() throws @Critical TemperatureException { … }
for typecasts:
myString = (@NonNull String) myObject;
It is not permitted to omit the Java type, as in myString = (@NonNull) myObject;.
for constructor invocation results (that is, for object creation):
new @Interned MyObject()
new @NonEmpty @Readonly List<String>(myNonEmptyStringSet)
myVar . new @Tainted NestedClass
For generic constructors (JLS §8.8.4), the annotation follows the explicit type arguments (JLS §15.9):
new <String> @Interned MyObject()
for type tests:
boolean isNonNull = myString instanceof @NonNull String;
It is not permitted to omit the Java type, as in myString instanceof @NonNull.
Damit einher geht eine krasse Änderung, das bei Objektmethoden einfach so ein this Übergeben werden kann.
It is permitted to explicitly declare the method receiver as the first formal parameter
As an example, here are the standard definitions for toString and equals:
class MyClass {
…
public String toString() { … }
public boolean equals(Object other) { … }
}
It is equivalent to write instead
class MyClass {
…
public String toString(MyClass this) { … }
public boolean equals(MyClass this, Object other) { … }
}
and then it would be possible to annotate the receiver’s type:
class MyClass {
…
public String toString(@Readonly MyClass this) { … }
public boolean equals(@Readonly MyClass this, @Readonly Object other) { … }
}
Interessant finde ich noch:
To ease the transition from standard Java SE 7 code to code with type annotations, the reference implementation
recognizes the type annotations when surrounded by comment markers:
List</*@Readonly*/ Object> myList;
This permits use of both standard Java SE 7 tools and the new annotations even before Java SE 8 is released
Mal eine Verständnis Frage:
„Map<@NonNull String, @NonEmpty List> files;“
Bei dem @NonNull: wird von der JVM zur Laufzeit die Map dann durchsucht, ob auch wirklich keine null-Objekte drin sind, oder sind alle diese Annotations eher sowas wie eine gutgemeinte Garantie für die Aufrufer ohne Einfluss auf die Performanz durch zusätzlich generierten Code zu nehmen?
BTW: „bei Objektmethoden einfach so ein this Übergeben werden kann.“ Genau genommen ist es kein Methoden Parameter, oder? So wie ich es verstanden habe wird da durch nur ermöglicht das Verhalten/Zustand des Methoden-Owners zu verdeutlichen, wenn diese Methode ausgeführt wird.
Aus der Spec: „The optional this parameter has no effect on execution — it only serves as a place to write annotations on the
receiver.“ (Seite 4)
Ich bin ja kein großer Fan von Annotations muss ich sagen. Das ist im Prinzip als wenn man ein Postit an einen Baum kleben würde. Aber mal schaun. Von Lambdas habe ich mich mittlerweile auch überzeugen lassen. Vielleicht wird es nun das 2. große Feature auf das ich mich für Java8 freuen kann. 🙂
Diese Darstellung (linksbündig) ist sehr schwer zu lesen!
Dieser JSR ist sehr hilfreich:
• er dürfte einige Fehlerquellen reduzieren
• erleichtert debugging
Fraglich ist nur, wo die Annotations verarbeitet werden.
@Readonly dürfte sinnvollerweise vom Compiler überprüft werden.
@NonNull ist allerdings etwas schwieriger:
• der Compiler könnte überprüfen, ob irgendwo der Parameter ’null‘ übergeben werden könnte, wenn ja Warning; wenn sicher ’null‘ übergeben wird, Fehlermeldung
• wird die Annotation auch zur Laufzeit verarbeitet? Dann könnte man sie in einen null-check umwandeln:
public void machIrgendwas(@NonNull Object test){ …umwandeln in
public void machIrgendwas(Object test){ if(test != null) throw new NullPointerException(); …(natürlich nur Pseudo-Code)
Danke, die Formatierung sieht jetzt schon viel besser aus!