[9] RFR: 8171139: Simplify ResourceBundle.CacheKey and ClassLoader may not be needed

Daniel Fuchs daniel.fuchs at oracle.com
Thu Jan 12 13:57:04 UTC 2017


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>
>>
>>



More information about the core-libs-dev mailing list