Is the implementation thread-safe?
cowwoc opened this issue · comments
All the methods in the SCrypt class are static.
First of all, why? :) Generally speaking, this is a code smell and should be corrected.
Secondly, does this mean that the implementation is not thread-safe? If it is, the Javadoc should state as much.
This is such a big deal to people that Wikipedia actually lists a non-static alternative to your library: http://en.wikipedia.org/wiki/Scrypt#Implementations.2C_wrappers.2C_and_distributions
@cowwoc scrypt functions depend on no state. It's natural for them to be static. People who make a big deal out of it have way too much time on their hands.
As there is no state the functions depend on, it should be free of concurrency hazards. Concurrency safety depends on the algorithm and state invariants, not whether a method is static or not.
To add to the safety claim above: I'm talking about the Java implementation and haven't inspected the native version, but it's very likely that it also doesn't have any shared state.
I was actually more interested in the native code since you've got one interface both implementations. Please investigate and if the native code is thread-safe, add a note to the Javadoc that confirms all implementations are thread-safe.
@michaelklishin thank you for your great comments! You're spot on.
Yes, both the Java and native implementations are safe to call from multiple threads. I don't think javadoc comments are necessary, these days comments should be reserved for cases where a public API isn't thread safe.
Java Concurrency in Practice (the authoritative book on the matter) seems to disagree: http://stackoverflow.com/a/3778071/14731
Also, if you were right, annotations like @threadsafe would not exist. The reason they exist is because people expect you to document this even if the class is thread safe.
@wg I think it's worth explicitly documenting.