"Lukasz Matuszczak" <[EMAIL PROTECTED]> wrote on 05/09/2006 07:29:17 AM:
> I've noticed a strange behaviour of batik considering URL Connections. I've made > my own java protocol handler, and I can see that method getInputStream() of my > ResourceURLConnection object is called, but the stream is never closed if it is > used by SVGImageElementBridge. > > I looked into createImageGraphicsNode os SVGImageElementBridge implementation > and I think there is a bug there. The stream is wrapped in ProtectedStream > object 'reference'. However reference.release() is called only if we get to the > last "try ... finally" (image is raster and ImageTagRegistry is allowed to open > URL). If the image is SVG the new GraphicsNode is returned and the 'reference' > is not released. Well the reference _is_ released but you are correct that we don't call 'release()' on it. Eventually this object will go to GC since all references to it are cleared, however if your class _requires_ that 'close' be called for proper operation this might be a problem (in this case I would argue that the bug was with your implementation of InputStream not our usage). > I would like to know is it a bug or an expected behavior? Somewhere between the two. We should close the stream when we know we are done with it to help the system reclaim resources sooner but I don't think this is a full out bug. I'll fix it anyway as it's easy to fix and I agree it's ugly. > I think there are many places where external resources can be loaded into > batik, so maybe there are other classes where similar bug can occur. This may be but as I say above I don't think the InputStream interface requires that close be called for proper operation. It is nice to call close as soon as you can but nothing should break as long as all references to the stream are cleared. I am fairly confident that we clear references to streams as otherwise we would have memory leaks and at least in released versions we have done some fairly extensive testing to ensure there aren't (even very small ones). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
