String in Java is immutable. The following snippet is, broadly speaking, "wrong".
String s = "hello world!";
s.toUpperCase(); // "wrong"!!
System.out.println(s); // still "hello world!"!!!
Despite this being "wrong", the code compiles and runs, perhaps to the confusion of many beginners, who must either be told what the mistake is, or to find out for themselves by consulting the documentation.
Reading the documentation is an essential part of understanding an API, but I'm wondering if this can be supplemented by additional compile-time checks. In particular, I'm wondering if perhaps Java's annotation framework can be used to enforce that the value returned by certain methods are not ignored. API designers/library authors would then use this annotation in their methods to document which return values should not be ignored.
Once the API is supplemented with this annotation (or perhaps another mechanism), then whenever a user writes a code such as above, it would not compile (or do so with a stern warning).
So can this be done, and how would you go about doing something like this?
Appendix: The Motivation
It seems clear that in the general case, Java should allow return values of methods to be ignored. The returned values of methods like List.add (always true), System.setProperty (previous value), can probably be safely ignored most of the times.
However, there are also many methods whose return values should NOT be ignored. Doing so is almost always a programmer error, or otherwise not a proper usage of the API. These includes things like:
- Methods on immutable types (e.g.
String,BigInteger, etc) that return the result of operations instead of mutating the instance it is invoked on. - Methods whose return value is a critical part of its behavior and should not be ignored, but people sometimes do anyway (e.g.
InputStream.read(byte[])returns the number of bytes read, which should NOT be assumed to be the entire length of the array)
Currently we can write codes that ignores these return values and have them compile and run without warning. Static analysis checkers/bug finders/style enforcers/etc can almost certainly flag these as possible code smells, but it would seem to be appropriate/ideal if this can be enforced by the API itself, perhaps through annotations.
It is almost impossible for a class to ensure that it is always used "properly", but there are things it can do to help guide clients to proper usage (see: Effective Java 2nd Edition, Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors and Item 62: Document all exceptions thrown by each method). Having an annotation that would enforce clients to not ignore return values of certain methods, and having it enforced by the compiler at compile-time either in the form of errors or warnings, would seem to be in line with this idea.
Appendix 2: Snippet
The following is a preliminary attempt that succinctly illustrates what I want to achieve:
@interface Undiscardable { }
//attachable to methods to indicate that its
//return value must not be discarded
public class UndiscardableTest {
public static @Undiscardable int f() {
return 42;
}
public static void main(String[] args) {
f(); // what do I have to do so this generates
// compilation warning/error?
System.out.println(f()); // this one would be fine!
}
}
The above code compiles and runs fine (as seen on ideone.com). How can I make it not so? How can I assign the semantics I want to @Undiscardable?
@Nullable/NotNullannotation, and this seems to be quite similar in spirit with what I want to do, so this must be doable: jetbrains.com/idea/documentation/howto.html ("IntelliJ IDEA warns you if these contracts are violated.") – SuctionInputStream.readis not idempotent. This isn't really about compiler optimization, but how to write user friendly API. – SuctionInputStream.read(byte[])does not always fill the buffer. You must not discard the returned value, which tells you how many bytes were actually read. – Suction