Correction to the first link....it should read DeflaterOutputStream...the target of the link is correct.
I may also be misunderstanding the javadoc. On Thu, May 20, 2010 at 10:22 AM, jonathan wood <jonathanshaww...@gmail.com>wrote: > > I guess I should have been more specific about why I think this is the > correct resolution: > > DataOutputStream.close()<http://java.sun.com/j2se/1.4.2/docs/api/java/util/zip/DeflaterOutputStream.html#close%28%29>claims > to close the underlying stream (ios). Ios is then flush()'ed and > close()'ed, after it has already been closed. > > I think the real issue is the addition of the deflateroutputstream close to > fix the sun finalizer problem with native zlib (bug > 46863<http://old.nabble.com/DO-NOT-REPLY--Bug-46863--New%3A-DeflaterOutputStream-not-closed,-causes-OutOfMemoryError-td22545206.html> > ) > > > On Thu, May 20, 2010 at 8:04 AM, <thomas.dewe...@kodak.com> wrote: > >> Hi Johnathan,. >> >> jonathan wood <jonathanshaww...@gmail.com> wrote on 05/18/2010 08:29:49 >> PM: >> >> >> > Looks like a double close on an output stream... >> >> IMHO that shouldn't be a problem... >> >> > I believe the solution is to apply the following to org/apache/ >> > batik/ext/awt/image/codec/png/PNGImageEncoder.java, although I'd >> > rely on Thomas DeWeese or other committer to verify. >> >> It seems to me the simplest (and potentially the safest) >> would be to modify the IDATOutputStream so that flush does nothing >> if no bytes have been written: >> >> Index: >> sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java >> =================================================================== >> --- sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java >> (revision 897441) >> +++ sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java >> (working copy) >> @@ -211,6 +211,8 @@ >> } >> >> public void flush() throws IOException { >> + if (bytesWritten == 0) return; >> + >> // Length >> writeInt(bytesWritten); >> // 'IDAT' signature >> >> > - removed ios.flush() and ios.close() since DeflaterOutputStream >> > claims to complete the stream write and close the close the underlying >> stream >> >> It seems to me we have gotten in trouble before when we didn't >> close >> streams. It's possible that doesn't apply here but still I'd feel better >> leaving the close calls. I don't feel quite a strongly about the flush >> as it is clear buffered data should be flushed before closing. >> >> Really in my mind the main issue is that you should be able to >> call >> flush whenever you want and not cause real havok which isn't the case >> without the proposed patch. >> >> >
