I would like to raise two related points in this message:
First point: The public review document contains some inaccuracies about
"the String implementation" (pages 14 and 15), which I interpret as the
String implementation in JDK 1.5 Beta.
The relevant sections of String.java:
public final class String
{
/** The value is used for character storage. */
private char value[];
/** The offset is the first index of the storage that is used. */
private int offset; // Default to 0
/** The count is the number of characters in the String. */
private int count; // Default to 0
/** Cache the hash code for the string */
private int hash; // Default to 0
public int hashCode() {
int h = hash;
if (h == 0) {
int off = offset;
char val[] = value;
int len = count;
for (int i = 0; i < len; i++) {
h = 31*h + val[off++];
}
hash = h;
}
return h;
}
The inaccuracies are the following:
A. "While the String implementation does not have any data races, [...]"
The String implementation in JDK 1.5 Beta does have a data race. It has
a data race on the "hash" field. Note, however, that this is a "benign"
data race; the code works perfectly (under the assumption that the reads
of the "value", "offset", and "count" fields, and of the array
components, return the values written during initialization).
B. "[...] if the fields of the String class were not final [...]"
This suggests that these fields are final; however, they are not. Even
if they were, the array components are not final.
Second point: It is clear that, in the Java Platform (the
specification), Strings are immutable (i.e. the inspectors always return
the same values). And if in any implementation, this is not the case,
then the implementation is incorrect. Now, I have the following questions:
A. Should the Java Language Specification or the Java API specification
be more explicit about the requirement that the String methods always
return the same values, even if String references are passed between
threads using data races?
B. Will 1.5 implementations, including notably Sun's implementations, be
correct in this respect? Given the String.java file included in the Beta
SDK, and if no special measures have been taken in the JVM, the 1.5 Beta
is not correct.
C. Which changes would have to be made to String.java and/or which
special measures would need to be taken in the JVM to make String
instances immutable? Would such changes or measures have a significant
performance impact?
D. Is all of this within the scope of JSR-133? If not, the public review
document should not give the impression that it solves the String
security issue. Moreover, it should probably state that it does not
solve this issue.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:57 EDT