@Documented @Retention(RUNTIME) @Target({TYPE_USE,TYPE_PARAMETER}) @SubtypeOf({Unsigned.class,Signed.class}) public @interface SignednessGlb

Client code may interpret the value either as Signed or as Unsigned. This primarily applies to values whose most significant bit is not set (i.e., SignedPositive), and thus the value has the same interpretation as signed or unsigned.

The programmer should not write this annotation. Instead, the programmer should write Signed or Unsigned to indicate how the programmer intends the value to be interpreted. For a value whose most significant bit is not set and different clients may treat it differently (say, the return value of certain library routines, or certain constant fields), the programmer should write @SignedPositive instead of @SignednessGlb.

The Signedness Checker applies this annotation to manifest literals. This permits a value like -1 or 255 or 0xFF to be used in both signed and unsigned contexts. The Signedness Checker has no way of knowing how a programmer intended a literal to be used, so it does not issue warnings for any uses of a literal. (An alternate design would require the programmer to explicitly annotate every manifest literal whose most significant bit is set. That might detect more errors, at the cost of much greater programmer annotation effort.)

The "Glb" in the name stands for "greatest lower bound", because this type is the greatest lower bound of the types Signed and Unsigned; that is, this type is a subtype of both of those types.

See Also:

SignedPositive

See the Checker Framework Manual:

Signedness Checker

Annotation Interface SignednessGlb