RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs and tests

Langer, Christoph christoph.langer at sap.com
Wed Dec 19 10:14:51 UTC 2018


Hi Sherman,

thanks for the confirmation. Further refactoring regarding Deflator caching can be done with a separate issue.

So, hearing no objections I'll push the patch once my testing is done.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Xueming Shen
> Sent: Mittwoch, 19. Dezember 2018 08:15
> To: core-libs-dev at openjdk.java.net
> Subject: Re: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs
> and tests
> 
> 
> On 12/18/18 5:44 AM, Langer, Christoph wrote:
> >
> >> In ZipFileSystem you remove the unused method releaseDeflater - to me
> >> this indicates the resource pooling is actually broken? I.e., shouldn't
> >> EntryOutputStreamDef return its Deflater to the cache when it's closed,
> >> similar to how the anonymous InflaterInputStream in getInputStream
> does
> >> it? As it's currently implemented the deflaters list will always be
> >> empty and no Deflater returned, so could go the other way and remove
> >> that cache if caching Deflaters isn't useful.
> > You are right. I think this is a flaw of the change for 8034802 [1] [2]. I added
> the call to releaseDeflater() in the close method of EntryOutputStreamDef.
> >
> >
> My bad. Adding the logic back looks fine. In latest implementation the
> EntryOutputStreamDef
> 
> is only created/used in sync() to write out any updated/compressed
> entry, which means there
> 
> is actually only one deflater is being used at a time during the sync(),
> so you can just have one
> 
> deflater and then reset it before passing on to the next entry write.
> And in fact even the EOSDef
> 
> is really not necessary. I was working on that ... but somehow I dropped
> the ball during copy/
> 
> paste :-( ended up using the deflater from the cache but failed to
> return it back.
> 
> 
> Anyway. It's fine to keep current deflater cache mechanism, but it might
> be worth considering
> 
> to "inline" the EntryOutputStreamDef logic and/or remove the deflater
> cache at all in the future.
> 
> 
> -Sherman



More information about the core-libs-dev mailing list