Hi Naoto,
If I'm not mistaken, CacheKey is not subclassed anywhere, so it could
be final. I'm wondering whether it would be a better idea to implement
CacheKey.clone() with a private (copy?) constructor. It would make
it possible to make most fields final: I believe it would be beneficial
to have all fields in CacheKey either final or volatile - since AFAICT
CacheKey can be created by one thread and then read by another.
And if most fields could be final then all the better :-)
best regards,
-- daniel
On 12/01/17 01:45, Naoto Sato wrote:
Decided to include the fix to 8171140 [1] as well, as they are closely
related. Here is the updated webrev.
http://cr.openjdk.java.net/~naoto/8171139.8171140/webrev.01/
Additional changes to the version 00 are to mainly remove
clearCache(Module) method, as clearCache() is chiefly used in
combination with ResourceBundle.Control, which is not supported in named
modules. Still named modules can issue clearCache() with no argument
which will result in the same effect. Also, other clearCache() overloads
have clearer method descriptions.
CCC for 8171140 will be filed accordingly.
Naoto
--
[1]: https://bugs.openjdk.java.net/browse/JDK-8171140
On 1/10/17 4:10 PM, Naoto Sato wrote:
Hello,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8171139
The changes are located at:
http://cr.openjdk.java.net/~naoto/8171139/webrev.00/
The changeset is the same as the one in the mail thread [1]
contributed by Peter Levart, plus additional clearCache() test cases.
Naoto
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html
<http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html>
