On 12/18/17 11:42 AM, mandy chung wrote:
On 12/18/17 12:22 AM, Peter Levart wrote:
I created an enhancement request:
https://bugs.openjdk.java.net/browse/JDK-8193685
Here's also the webrev that goes with it:
http://cr.openjdk.java.net/~plevart/jdk-dev/8193685_ZipInDeFlater_cleanupImprovem
On 12/18/17 12:22 AM, Peter Levart wrote:
I created an enhancement request:
https://bugs.openjdk.java.net/browse/JDK-8193685
Here's also the webrev that goes with it:
http://cr.openjdk.java.net/~plevart/jdk-dev/8193685_ZipInDeFlater_cleanupImprovement/webrev.01/
Since jdk10 stabilizatio
On 12/18/17, 12:22 AM, Peter Levart wrote:
That said, in this case, it appears it does not require any "extra
effort" to simply move the
init(nowrap) invocation further down into the zstream constructor.
I'm fine to go with it.
I created an enhancement request:
https://bugs.openjdk.java.net/
Hi Sherman, Claes,
On 12/16/2017 08:29 PM, Xueming Shen wrote:
HI Peter,
We are back to the "the order of resource relocation and cleaner
registration" discussion again :-)
Yes, the story repeats itself :-)
The approach you are suggesting and was implemented in the previous
version for d
HI Peter,
We are back to the "the order of resource relocation and cleaner
registration" discussion again :-)
The approach you are suggesting and was implemented in the previous
version for de/inflater
via the lambda basically is the same to have a callback mechanism () to
delay the resourc
Hi Sherman,
Xueming Shen je 16. 12. 2017 ob 01:46 napisal:
On 12/15/17, 3:43 PM, Peter Levart wrote:
Hi Claes,
I see this is already pushed. I don't have any additional comments,
but just want to know what was wrong with old code. You say that you
used non-static inner classes. I don't see t
On 12/15/17, 3:43 PM, Peter Levart wrote:
Hi Claes,
I see this is already pushed. I don't have any additional comments,
but just want to know what was wrong with old code. You say that you
used non-static inner classes. I don't see that in old code. All the
lambdas you replaced with nested st
Hi Claes,
I see this is already pushed. I don't have any additional comments, but
just want to know what was wrong with old code. You say that you used
non-static inner classes. I don't see that in old code. All the lambdas
you replaced with nested static classes should have already captured
On 2017-12-14 16:03, Roger Riggs wrote:
Hi Claes,
Looks good; though I would rename the nested classes to have different
names
to avoid reader confusion. Like InflaterZStreamRef and
DeflaterZStreamRef.
Sure:
http://cr.openjdk.java.net/~redestad/8193507/open.02/
No further review if yo
Hi Claes,
Looks good; though I would rename the nested classes to have different names
to avoid reader confusion. Like InflaterZStreamRef and DeflaterZStreamRef.
No further review if you take up the renames.
Thanks, Roger
On 12/14/2017 9:20 AM, Claes Redestad wrote:
On 2017-12-14 15:16, Al
On 2017-12-14 15:16, Alan Bateman wrote:
webrev.01 looks good to me.
Thanks, Alan!
/Claes
On 14/12/2017 12:54, Claes Redestad wrote:
:
Also can the constructors be grouped as it's very confusing to not
have them grouped together (dropping the space in "ZStreamRef ("
would help too. Otherwise I think the approach is okay.
I've dropped the ZStreamRef(long) constructors and fixed a
On 2017-12-14 13:29, Alan Bateman wrote:
On 14/12/2017 12:25, Claes Redestad wrote:
We need the cleanable = null case for the FinalizableZStreamRef case,
otherwise we'd go into spin. The cleanable is implicitly checked for
null in the ZStreamRef.get method, which is the only one
used outsi
On 14/12/2017 12:25, Claes Redestad wrote:
We need the cleanable = null case for the FinalizableZStreamRef case,
otherwise we'd go into spin. The cleanable is implicitly checked for
null in the ZStreamRef.get method, which is the only one
used outside of these classes.
Okay but can the clean
On 2017-12-14 13:00, Alan Bateman wrote:
On 14/12/2017 11:07, Claes Redestad wrote:
Hi,
my previous fix failed due to use of non-static inner classes which
kept the cleanable objects around. Also, Sherman suggested a more
thorough fix to Inflater/Deflater after I had already pushed.
Webrev:
On 14/12/2017 11:07, Claes Redestad wrote:
Hi,
my previous fix failed due to use of non-static inner classes which
kept the cleanable objects around. Also, Sherman suggested a more
thorough fix to Inflater/Deflater after I had already pushed.
Webrev: http://cr.openjdk.java.net/~redestad/8193
Hi,
my previous fix failed due to use of non-static inner classes which kept
the cleanable objects around. Also, Sherman suggested a more thorough
fix to Inflater/Deflater after I had already pushed.
Webrev: http://cr.openjdk.java.net/~redestad/8193507/open.00/
Verified all java/util/zip tes
17 matches
Mail list logo
