Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-22 Thread Paul Sandoz
> On 23 Jun 2016, at 04:04, Steve Drach wrote: > >> 144 private boolean notVersioned; // legacy constructor called >> >> Do you need this? > > Unfortunately yes. It’s used in entries() and stream(). If it’s set, they > have the JDK 8 semantics. If not set, entries/stream only

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-22 Thread Steve Drach
> 144 private boolean notVersioned; // legacy constructor called > > Do you need this? Unfortunately yes. It’s used in entries() and stream(). If it’s set, they have the JDK 8 semantics. If not set, entries/stream only see the appropriate versioned entries. This will go away w

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-22 Thread Paul Sandoz
> On 21 Jun 2016, at 20:23, Steve Drach wrote: > > Hi Paul, > > I believe this webrev addresses your concerns: > > http://cr.openjdk.java.net/~sdrach/8150680/webrev.03/index.html > 141 private final int base_version; // BASE_VERSION.major() Why is this an instance field? make s

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-21 Thread Steve Drach
Hi Paul, > Hi. I would like to point out that it appears JarFile.Release enum is > specifically tailored to address multi-version jar specification. I think you are looking at the current code, not the webrev. What the webrev does is remove the JarFile.Release enum. > However, I find nothing

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-21 Thread Paul Benedict
Hi. I would like to point out that it appears JarFile.Release enum is specifically tailored to address multi-version jar specification. However, I find nothing in that enum specific except for the documentation and BASE_VERSION. Wouldn't it better to create a top-level Release enum that can be used

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-21 Thread Steve Drach
Hi Paul, I believe this webrev addresses your concerns: http://cr.openjdk.java.net/~sdrach/8150680/webrev.03/index.html > On Jun 16, 2016, at 3:49 PM, Paul Sandoz wrote: > > >> On 16 Jun 2016, at 14:44, Steve Drach wrote: >>

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-20 Thread Steve Drach
ibs-Dev" >> Envoyé: Jeudi 16 Juin 2016 23:44:14 >> Objet: [SPAM-RENATER]Re: RFR: 8150680 JarFile.Release enum needs >> reconsideration withrespect to it's values >> >> This webrev uses methods instead of fields to return the base and runtime >> v

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-18 Thread Remi Forax
Mail original - > De: "Steve Drach" > À: "Joseph D. Darcy" > Cc: "Core-Libs-Dev" > Envoyé: Jeudi 16 Juin 2016 23:44:14 > Objet: [SPAM-RENATER]Re: RFR: 8150680 JarFile.Release enum needs > reconsideration with respect to it's values > &g

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-16 Thread Paul Sandoz
> On 16 Jun 2016, at 14:44, Steve Drach wrote: > > This webrev uses methods instead of fields to return the base and runtime > values used internally by JarFile. I’ve also optimized it a bit. > > http://cr.openjdk.java.net/~sdrach/8150680/webrev.02/ >

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-16 Thread Steve Drach
This webrev uses methods instead of fields to return the base and runtime values used internally by JarFile. I’ve also optimized it a bit. http://cr.openjdk.java.net/~sdrach/8150680/webrev.02/ > On Jun 15, 2016, at 4:31 PM, Joseph D. Dar

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-15 Thread Joseph D. Darcy
Steve, In JarFile, please use methods not fields to return the new information. The information in question is not constant across versions. Using methods instead of fields avoid over-committing on a particular implementation, etc. Cheers, -Joe On 6/15/2016 3:49 PM, Steve Drach wrote: I’v

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-15 Thread Steve Drach
I’ve updated the webrev to address the issue of the constructor accepting values like Version.parse(“7.1”) http://cr.openjdk.java.net/~sdrach/8150680/webrev.01/ > On Jun 15, 2016, at 8:56 AM, Steve Drach wrote: > >>> Please review the fo

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-15 Thread Peter Levart
Hi Steve, On 06/15/2016 05:56 PM, Steve Drach wrote: >Fields or methods is another discussion point for the base and runtime versions. My thinking is, in this case fields and methods are equivalent, the method not giving any more flexibility than a field. For example the method JarFile.bas

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-15 Thread Steve Drach
>> Please review the following changeset: >> >> webrev: http://cr.openjdk.java.net/~sdrach/8150680/webrev.00/index.html >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8150680 >>

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-15 Thread Alan Bateman
On 15/06/2016 00:17, Steve Drach wrote: Hi, Please review the following changeset: webrev: http://cr.openjdk.java.net/~sdrach/8150680/webrev.00/index.html issue: https://bugs.openjdk.java.net/browse/JDK-8150680

RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

2016-06-14 Thread Steve Drach
Hi, Please review the following changeset: webrev: http://cr.openjdk.java.net/~sdrach/8150680/webrev.00/index.html issue: https://bugs.openjdk.java.net/browse/JDK-8150680 The is