On Wed, 19 Apr 2017 09:17:32 +0200, Emmanuel Bourg wrote:
Le 19/04/2017 à 00:23, Gary Gregory a écrit :
I'd like to see a real example before we talk about abstract
arguments and
counter-arguments, which will never end ;-)
Ok,
Good. [If only...] ;-)
here is a slightly more substantial example. The following class is
immutable but not thread-safe:
public class FileAppender {
private final File file;
public FileAppender(File file) {
this.file = file;
}
public void append(String message) throws IOException {
try (OutputStream out = new FileOutputStream(file)) {
out.write(message.getBytes());
}
}
}
The point is, if the class operates on resources outside the JVM, the
immutability doesn't ensure the thread safety. Immutability is only a
thread safety guarantee for data structures, and not for classes with
operations causing side effects (like writing to files, drawing on
the
screen, playing sounds, calling remote services, accessing off-heap
memory, etc).
The consequence should thus be that such classes should not be
documented as thread-safe _because_ such a qualifier would not
bring any actual benefit to the user.
Documenting/annotating a class as "immutable" or "thread-safe"
must be a _promise_ to the user, and it requires more analysis
than recognizing that all the fields are final.
To return to the question of which annotation, I'm unfazed by
the possibility of
@ThreadSafe
@NotThreadSafe
because it is an obvious documentation bug, with no more dire
consequences than saying
@ThreadSafe
when, in fact, it is not.
Gilles
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
