RFR 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe (original) (raw)
Chris Hegarty chris.hegarty at oracle.com
Tue Mar 19 11:49:47 PDT 2013
- Previous message: RFR 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe
- Next message: RFR 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 03/19/2013 06:16 PM, Kurchi Hazra wrote:
The if statements in the platform specific close methods do not have the spaces as we usually prefer to have them (I realize from before your changes), but otherwise this looks good to me.
Thanks Kurchi. I will put the space in the correct place before pushing.
I will revisit this file shortly. I want to move the common code into shared code, and just have the platform specific code separated out. I don't want to do it as part of this bug, as it may just confuse the actual changes.
-Chris.
- Kurchi On 3/19/2013 10:43 AM, Chris Hegarty wrote: JarFileFactory has two Maps that it uses to implement caching of jar files. Access to these maps should always be done while holding the instance lock, as multiple threads can be simultaneously updating the maps.
The close() method was added some time after the original implementation, and it looks like the locking was forgotten. Also, the locking strategy assumes that JarFileFactory is a singleton. It should be reworked to make it more robust. There is much more cleanup that can be done here, and I intend to do it as a separate bug, so as not to confuse the specifics of this issue. http://cr.openjdk.java.net/~chegar/8010282/webrev.00/webrev/ -Chris.
- Previous message: RFR 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe
- Next message: RFR 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]