xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: SVGImageElementBridge and closing url connections
Date Tue, 09 May 2006 11:50:00 GMT
"Lukasz Matuszczak" <l.matuszczak@atrem.pl> wrote on 05/09/2006 07:29:17 

> 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 
> and I think there is a bug there. The stream is wrapped in 
> 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 
> 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 
to it are cleared, however if your class _requires_ that 'close' be called 
proper operation this might be a problem (in this case I would argue that 
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 
> 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 
as soon as you can but nothing should break as long as all references to 
stream are cleared.  I am fairly confident that we clear references to 
as otherwise we would have memory leaks and at least in released versions 
have done some fairly extensive testing to ensure there aren't (even very
small ones).

To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message