Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> Thank you Alan. I’ll address the issues you bring up before integration. > Thanks. Are you planning to update the webrev too as it would be nice to see > the final javadoc? http://cr.openjdk.java.net/~sdrach/8132734/webrev.07/index.html

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 15/02/2016 16:30, Steve Drach wrote: Thank you Alan. I’ll address the issues you bring up before integration. Thanks. Are you planning to update the webrev too as it would be nice to see the final javadoc? -Alan

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Thank you Alan. I’ll address the issues you bring up before integration. > On Feb 15, 2016, at 4:30 AM, Alan Bateman wrote: > > > On 10/02/2016 01:04, Steve Drach wrote: >> Hi, >> >> Yet another webrev, http://cr.openjdk.java.net/~sdrach/8132734/webrev.06/ >>

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/02/2016 01:04, Steve Drach wrote: Hi, Yet another webrev, http://cr.openjdk.java.net/~sdrach/8132734/webrev.06/ , with a change to JarEntryIterator to fix a problem discovered by performance tests — calling hasNext() twice as

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Sherman, I like your suggestions and will open an issue to work on the performance after integration. I’ll fix the minor “bug” you pointed out at the same time. Steve > On Feb 12, 2016, at 5:19 PM, Xueming Shen wrote: > > > Steve, > > I would assume the

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, This patch has been cooking and re-heated enough times that i think it’s as good as done in terms of being reviewed. We can follow up with further issues for other aspects, such as performance if need be. Paul. > On 10 Feb 2016, at 02:04, Steve Drach wrote:

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Steve, I would assume the difference of the webrev.04 "old" iterator and the webrev.06 "new" iterator that might trigger a performance is how you create the JarFileEntry. The one parameter constructor invokes isMultiRelease(), which might be relatively expensive, when the "mr" is enabled.

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, Yet another webrev, http://cr.openjdk.java.net/~sdrach/8132734/webrev.06/ , with a change to JarEntryIterator to fix a problem discovered by performance tests — calling hasNext() twice as often as needed. I also removed the @since 9

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 03/02/2016 02:24, Steve Drach wrote: I created a new webrev, http://cr.openjdk.java.net/~sdrach/8132734/webrev.05/ , that implements what I outlined above. In particular I enhanced the JarEntryIterator class and I added additional

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Thanks for the comments Alan. Responses in-line. >> I created a new webrev, >> http://cr.openjdk.java.net/~sdrach/8132734/webrev.05/ >> , that implements >> what I outlined above. In particular I enhanced the JarEntryIterator class >>

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> I think the following is a reasonable solution. > > If the JarFile is constructed with any of the 5 constructors that do not > contain a Release argument, then entries()/stream() returns the set of all > entries in the jar file including those under the > META-INF/versions/directory. The

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 02/01/2016 09:58 AM, Steve Drach wrote: On Jan 30, 2016, at 12:00 AM, Alan Bateman wrote: On 29/01/2016 17:39, Paul Sandoz wrote: : Alan’s point is that traversing using entries()/stream() always returns the versioned entries (if any) rather than all entries,

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

I believe the answer should be based on your viewpoint of what "is" a JAR. Do you consider the JAR to be a dumb ZIP container or an artifact of the Java runtime? If it's the former, then return everything because the version folder is meaningless in this perspective. Otherwise, treat the JAR

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

I’m sorry, I didn’t look at the code close enough before I started talking ;-) Right now entries()/stream() returns all entries and if the JarFile is constructed with a Release object != Release.BASE, the base entries that are returned are the versioned entries. I think this behavior is a bit

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On Jan 30, 2016, at 12:00 AM, Alan Bateman wrote: > > > On 29/01/2016 17:39, Paul Sandoz wrote: >> : >> Alan’s point is that traversing using entries()/stream() always returns the >> versioned entries (if any) rather than all entries, thus in a sense filters. >> >>

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Alan’s point is that traversing using entries()/stream() always returns the versioned entries (if any) rather than all entries, thus in a sense filters. My assumption was the traversal should by default be consistent with a calls to getEntry, thus:

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 29/01/2016 17:39, Paul Sandoz wrote: : Alan’s point is that traversing using entries()/stream() always returns the versioned entries (if any) rather than all entries, thus in a sense filters. My assumption was the traversal should by default be consistent with a calls to getEntry, thus:

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 27/01/2016 23:37, Steve Drach wrote: I'm still wondering about the phrase "root entry" as it continues to give the impression (to me anyway) that it's a resource in the root directory. I think "root" works in the JEP because it deals with simple resources like A.class and B.class that are

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> I’ve released a new webrev, >> http://cr.openjdk.java.net/~sdrach/8132734/webrev.04/index.html >> that >> addresses the above issue. >> > Thank you, the javadoc is much clearer and readable now. > > The first mention of

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 29 Jan 2016, at 18:27, Steve Drach wrote: >> >> This may have come up before but JarFile has two sets of constructors, one >> takes the file path as a String, the other as a File. I just wondering about >> introduce a second constructor so that they match. > > We

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>>> One other thing that I've been wondering about is the stream() and >>> entries() methods. Has there been any discussion about these doing filter? >> >> Not that I’m aware of. >> >>> Maybe it is too expensive and best left to the user of the API? Part of the >>> context for asking is

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> What's the purpose of having a dedicated "JarFile.runtimeVersioned”? Consistency, so getVersion returns the same version as the version set when JarFile was constructed. > Based on > its only usages at ln#356 and #381, it appears, shouldn't getVersion() simply > returns

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Steve, What's the purpose of having a dedicated "JarFile.runtimeVersioned"? Based on its only usages at ln#356 and #381, it appears, shouldn't getVersion() simply returns Release.valueOf(version)? sherman On 01/27/2016 03:37 PM, Steve Drach wrote: I'm still wondering about the phrase "root

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>>> What's the purpose of having a dedicated "JarFile.runtimeVersioned”? >> Consistency, so getVersion returns the same version as the version set when >> JarFile was constructed. >> >>> Based on >>> its only usages at ln#356 and #381, it appears, shouldn't getVersion() >>> simply >>> returns

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 01/28/2016 11:28 AM, Steve Drach wrote: What's the purpose of having a dedicated "JarFile.runtimeVersioned”? Consistency, so getVersion returns the same version as the version set when JarFile was constructed. Based on its only usages at ln#356 and #381, it appears, shouldn't getVersion()

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> 78 * Class loaders that utilize {@code JarFile} to load classes from the > 79 * contents of {@code JarFile} entries should construct the {@code > JarFile} > 80 * by invoking the {@link JarFile#JarFile(File, boolean, int, Release)} > 81 * constructor with the value {@code

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Steve, 78 * Class loaders that utilize {@code JarFile} to load classes from the 79 * contents of {@code JarFile} entries should construct the {@code JarFile} 80 * by invoking the {@link JarFile#JarFile(File, boolean, int, Release)} 81 * constructor with the value {@code

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 01/28/2016 12:26 PM, Xueming Shen wrote: On 01/28/2016 11:28 AM, Steve Drach wrote: What's the purpose of having a dedicated "JarFile.runtimeVersioned”? Consistency, so getVersion returns the same version as the version set when JarFile was constructed. Based on its only usages at ln#356

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

+1 Paul. > On 28 Jan 2016, at 00:37, Steve Drach wrote: > > >> I'm still wondering about the phrase "root entry" as it continues to give >> the impression (to me anyway) that it's a resource in the root directory. I >> think "root" works in the JEP because it deals

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> I'm still wondering about the phrase "root entry" as it continues to give the > impression (to me anyway) that it's a resource in the root directory. I think > "root" works in the JEP because it deals with simple resources like A.class > and B.class that are in the root directory but it's

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On Jan 25, 2016, at 8:54 AM, Alan Bateman wrote: Somehow I missed this, sorry for the delayed response. >> >> Changed to BASE, i.e. Release.BASE >> > This looks better. Release.BASE is probably okay although it still feels like > Release.UNVERSIONED, esp. when it

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 22/01/2016 23:10, Steve Drach wrote: Hi Alan, et. al., I’ve released a new webrev that addresses all the issues you raised. http://cr.openjdk.java.net/~sdrach/8132734/webrev.03/index.html Specifically: For Release

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 22 Jan 2016, at 01:39, Mandy Chung wrote: > > >> On Jan 21, 2016, at 3:49 PM, Steve Drach wrote: >> I suspected this is a bike shed candidate. I think Release._9 is nicer and it conveys the same information in a less cluttered

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Alan, et. al., I’ve released a new webrev that addresses all the issues you raised. http://cr.openjdk.java.net/~sdrach/8132734/webrev.03/index.html Specifically: > For Release then I have to admit that I dislike _9 and

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 20/01/2016 17:56, Steve Drach wrote: Hi, This is a repeat of the RFR I sent last Wed (Jan 13). : Webrev: http://cr.openjdk.java.net/~sdrach/8132734/webrev.02/ Overall I think the API looks much better. For Release then I have to

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Thank you for the review Alan. See comments in line below. > Overall I think the API looks much better. With the advantage of being much simpler too. > For Release then I have to admit that I dislike _9 and wonder if other > options were considered? javax.lang.model.SourceVersion uses the

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 21/01/2016 18:02, Steve Drach wrote: : I suspected this is a bike shed candidate. I think Release._9 is nicer and it conveys the same information in a less cluttered way than Release.RELEASE_9. Yes a bike shed, I'm just saying that Release._9 looks odd/inconsistent when we have

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> I suspected this is a bike shed candidate. I think Release._9 is nicer and >> it conveys the same information in a less cluttered way than >> Release.RELEASE_9. > Yes a bike shed, I'm just saying that Release._9 looks odd/inconsistent when > we have SourceVersion.RELEASE_9 elsewhere. Maybe

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On Jan 21, 2016, at 3:49 PM, Steve Drach wrote: > >>> I suspected this is a bike shed candidate. I think Release._9 is nicer and >>> it conveys the same information in a less cluttered way than >>> Release.RELEASE_9. >> Yes a bike shed, I'm just saying that

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, This is a repeat of the RFR I sent last Wed (Jan 13). CCC had some suggestions to improve the code that was previously approved during review. As a consequence, I had to make significant changes to the API, and I believe the code need further review. Please review the latest iteration

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, CCC had some suggestions to improve the code that was previously approved during review. As a consequence, I had to make significant changes to the API, and I believe the code need further review. Please review the latest iteration of the webrev for runtime support of multi-release jar

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 18/11/2015 21:27, Steve Drach wrote: Hi, Please review the latest iteration of the webrev for runtime support of multi-release jar files. I think the latest looks okay and addressed all the issues that I was concerned with. -Alan

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, The change looks fine. thanks, Sherman On 11/18/2015 01:27 PM, Steve Drach wrote: Hi, Please review the latest iteration of the webrev for runtime support of multi-release jar files. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238:

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, Please review the latest iteration of the webrev for runtime support of multi-release jar files. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ I

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Alan, Thanks for looking at this. >> Please review the new webrev that addresses the issues raised by Sherman and >> Alan in the last iteration. In particular: >> - fixed the race condition in isMultiRelease() and another one with the >> variables ‘version’ and ‘configured’ >> - changed

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 11/11/15 8:44 AM, Steve Drach wrote: Hi, Please review the new webrev that addresses the issues raised by Sherman and Alan in the last iteration. In particular: - fixed the race condition in isMultiRelease() and another one with the variables ‘version’ and ‘configured’ - changed the

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Sherman, Thanks for looking at this. Comments in-line below. > On Nov 17, 2015, at 9:49 AM, Xueming Shen wrote: > > On 11/11/15 8:44 AM, Steve Drach wrote: >> Hi, >> >> Please review the new webrev that addresses the issues raised by Sherman and >> Alan in the

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 11/11/2015 16:44, Steve Drach wrote: Hi, Please review the new webrev that addresses the issues raised by Sherman and Alan in the last iteration. In particular: - fixed the race condition in isMultiRelease() and another one with the variables ‘version’ and ‘configured’ - changed the

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, Please review the new webrev that addresses the issues raised by Sherman and Alan in the last iteration. In particular: - fixed the race condition in isMultiRelease() and another one with the variables ‘version’ and ‘configured’ - changed the fragment for JarURLConnection runtime

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 9 Nov 2015, at 21:53, Steve Drach wrote: > As to whether this is implementation vs. JAR URL spec then I assume it needs to be spec so that libraries can create URLs that will use runtime versioning when access the JAR. >>> >>> Yeah, i don’t

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/11/2015 09:06, Paul Sandoz wrote: : It’s more common to register a URLStreamHandlerFactory via URL.setURLStreamHandlerFactory. I suspect that is used more for supporting different URL schemes than for overriding the “jar” scheme. This is a very delicate area, override the “jar" scheme

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

It’s nice to see these issues get resolved while I was sleeping ;-) >> On 08/11/2015 20:38, Paul Sandoz wrote: >>> : >>> The name is derived from the requirement that if the fragment is present a >>> call to getRuntimeVersionedEntry is required (or the equivalent of), thus >>> the URL is a

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>>> As to whether this is implementation vs. JAR URL spec then I assume it >>> needs to be spec so that libraries can create URLs that will use runtime >>> versioning when access the JAR. >>> >> >> Yeah, i don’t think we can avoid it. > > Ok. I guess I should put the information in

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 9 Nov 2015, at 09:19, Alan Bateman wrote: > > > > On 08/11/2015 20:38, Paul Sandoz wrote: >> : >> The name is derived from the requirement that if the fragment is present a >> call to getRuntimeVersionedEntry is required (or the equivalent of), thus >> the URL

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 08/11/2015 20:38, Paul Sandoz wrote: : The name is derived from the requirement that if the fragment is present a call to getRuntimeVersionedEntry is required (or the equivalent of), thus the URL is a reference to a runtime versioned entry. I was just wondering about something shorter,

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 05/11/2015 17:10, Steve Drach wrote: Hi, Here’s a new webrev that addresses the issues Paul brought up. The versioned entry cache has been removed, the search space has been reduced, the documentation for setVersioned(int) and setRuntimeVersioned() has been updated to clarify when

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 08/11/2015 19:36, Paul Sandoz wrote: : I was wondering if it might be possible to consider this a mostly internal contract since the URL class loading functionality (URLClassPath.java) creates such URLs for processing by JarURLConnection in some code paths (getResourceAsStream IIRC).

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 8 Nov 2015, at 16:51, Alan Bateman wrote: > > On 05/11/2015 17:10, Steve Drach wrote: >> Hi, >> >> Here’s a new webrev that addresses the issues Paul brought up. The >> versioned entry cache has been removed, the search space has been reduced, >> the

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 8 Nov 2015, at 21:21, Alan Bateman wrote: > > On 08/11/2015 19:36, Paul Sandoz wrote: >> : >> >> I was wondering if it might be possible to consider this a mostly internal >> contract since the URL class loading functionality (URLClassPath.java) >> creates such

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 6 Nov 2015, at 22:50, Xueming Shen wrote: > > Hi Steve, > > My apology for slow response. I was sick in bed since last Sat… > Oh no, i hope you are getting better. > I've scanned the update, here are my comments > > (1) The newly added "configured" obviously

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Note to readers, I sent an earlier incomplete version of this email due to fat finger syndrome. Hopefully this response will be complete. Hi Sherman, Thanks for looking at this. > (1) The newly added "configured" obviously will help in most use scenario, > but (yes, there is >always a

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Sherman, Thanks for looking at this. > (1) The newly added "configured" obviously will help in most use scenario, > but (yes, there is > always a but :-)), given the related code is not synchronized, I'm pretty > sure there is race > condition somewhere, for example betwen Ln#388 --

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, This looks good to me (i only browsed the test code). It’s been around the block a few times :-) IMO, baring any major issues, it’s time to push and we can clean up any ancillary issues with later pushes. Paul. > On 5 Nov 2015, at 18:10, Steve Drach wrote: >

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Sherman. Would you please give this another pass? I want make sure all your concerns are met. Thanks Steve > On Nov 6, 2015, at 12:44 AM, Paul Sandoz wrote: > > Hi Steve, > > This looks good to me (i only browsed the test code). It’s been around the > block a

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, My apology for slow response. I was sick in bed since last Sat... I've scanned the update, here are my comments (1) The newly added "configured" obviously will help in most use scenario, but (yes, there is always a but :-)), given the related code is not synchronized, I'm

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, Here’s a new webrev that addresses the issues Paul brought up. The versioned entry cache has been removed, the search space has been reduced, the documentation for setVersioned(int) and setRuntimeVersioned() has been updated to clarify when IllegalStateException is thrown, and the tests

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On Nov 4, 2015, at 1:01 AM, Paul Sandoz wrote: > > Hi Steve, > > Hi Steve, > > I don’t think we need to cache versioned entries (as we discussed a while > back). For class loading it’s likely to increase memory costs without any > performance benefit (if anything a

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, Hi Steve, I don’t think we need to cache versioned entries (as we discussed a while back). For class loading it’s likely to increase memory costs without any performance benefit (if anything a performance decrease). It’s easy to add back later on if we have data that suggests

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Please review the latest webrev that addresses the issue raised in Sherman’s comments below, with my comments interspersed in-line. The changes between this webrev and the last one are in the definition and use of the ismultiRelease() method and the introduction of a configuration lock, the

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Curious that you added a new method called jarFile.getRuntimeVersionedEntry(entryName). Is this the *only* method you would call for a multi-release jar? If so, is it still necessary to modify the old getEntry() method? Thanks Max > On Nov 4, 2015, at 1:11 AM, Steve Drach

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On Nov 3, 2015, at 5:24 PM, Wang Weijun wrote: > > Curious that you added a new method called > jarFile.getRuntimeVersionedEntry(entryName). It’s new to JarFile, but not new to the changeset, it’s been in there since the reviews started. > Is this the *only* method

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

FWIW I agree - it's just weird to have the behavior change after the fact like that. On 10/26/2015 11:37 PM, Xueming Shen wrote: Hi Steve, I know I stared to sound like a broken record :-) But I would like to suggest the team one more time to reconsider the current decision of using the "set"

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, I know I stared to sound like a broken record :-) But I would like to suggest the team one more time to reconsider the current decision of using the "set" methods to change the configuration setting/status of an existing JarFile to enable the multi-version support. public JarFile

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, We’ve published another webrev for review. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ This one addresses the issues regarding CodeSigners,

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, The reifiedEntry() approach probably can help the default JarVerifier work as expected, but if I read the code correctly I doubt you can get the expected CodSigner[] and Certificatte[] result from a "versioned" JarFileEntry, after having read all bytes from the input stream

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> So why do you want to put this field into the super class JarEntry, not the > JarFileEntry, don't see any > benefit of doing that. I changed it. I put the versionedEntry in JarFileEntry instead of JarEntry. Not too difficult although I had to add a package private method to support

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 15 Oct 2015, at 05:00, Xueming Shen wrote: > > I'm not sure if it is a good idea, from performance perspective, to add a > "versionEntry" field into the JarEntry > to support this feature, given most of the jar files might not be > multi-release-jar aware, and

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/15/15 1:53 AM, Paul Sandoz wrote: On 15 Oct 2015, at 05:00, Xueming Shen wrote: I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry to support this feature, given most of the jar files might not be

RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, Let’s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev:

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 14/10/2015 17:07, Steve Drach wrote: Hi, Let’s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Good to have tests this time :-) I see several JAR files in the webrev, shouldn't the tests create

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> The current test directory contains binary jar files. In fact in all the >> test directories, there are 52 binary .jar files. > I know but we need to work to remove those. I figured that might be the response, but thought it was worth the try ;-) > > >> I added three more. I thought

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 14 Oct 2015, at 21:12, Steve Drach wrote: > >>> The current test directory contains binary jar files. In fact in all the >>> test directories, there are 52 binary .jar files. >> I know but we need to work to remove those. > > I figured that might be the response,

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 14/10/2015 17:28, Steve Drach wrote: The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. I know but we need to work to remove those. I added three more. I thought about generating the jar files but the problem I

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. >>> I know but we need to work to remove those. >> >> I figured that might be the response, but thought it was worth the try ;-) >> > > A reasonable way forward

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Steve, Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? -Sherman On 10/14/2015 09:07 AM, Steve Drach wrote: Hi, Let’s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/14/2015 1:56 PM, Steve Drach wrote: The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files. I know but we need to work to remove those. I figured that might be the response, but thought it was worth the try ;-) A

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> Let’s try again, this time there are tests. Please review the following >> webrev that adds support for multi-release jars as specified in JEP-238. > Good to have tests this time :-) > > I see several JAR files in the webrev, shouldn't the tests create these so > that we don't have to check

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/14/15 4:04 PM, Steve Drach wrote: Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? It didn’t seem necessary. The root entries are the “public interface”, we’re just providing aliased entry contents. It does not sound right. The "exported public

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> Any reason the JarEntry.get/setSize() are the only ZipEntry methods get > overridden? It didn’t seem necessary. The root entries are the “public interface”, we’re just providing aliased entry contents. > > -Sherman > > On 10/14/2015 09:07 AM, Steve Drach wrote: >> Hi, >> >> Let’s try

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 05/10/2015 22:16, Steve Drach wrote: None of the other attributes have this. Are you suggesting I do this? Yes, and I assume this will rename to @since 9 once the versioning JEP goes in. -Alan

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Alan, > It would be good to add @since to Attributes#MULTI_RELEASE before this goes > in. None of the other attributes have this. Are you suggesting I do this? /** * {@code Name} object for {@code Multi-Release} * manifest attribute that indicates this is a multi-release JAR file. * *

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 1 Oct 2015, at 21:25, Alan Bateman wrote: > > On 01/10/2015 18:07, Steve Drach wrote: >> >> Yes, the JEP issue has several subtasks. This one, 8132734, is just for >> java.util.jar.JarFile. There will be a separate webrev for jar tool and >> another one for

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> To elaborate a bit, the implementation is quite straight forward. >> ZipFileSystem builds an Inode tree on open. That tree is implemented as a >> Map. For regular zip/jar files both the key and the value are >> the same Inode. For multi-release jar files the value is the

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> Okay. On the the ZipFileSystem then it would be good to get a summary on >> what you are proposing. > > Details of any JavacFileManager/ZipFileSystem support are still being hashed > out. They are mentioned in the JEP and we can update once those details are > finalized. To elaborate a

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 02/10/2015 15:52, Steve Drach wrote : To elaborate a bit, the implementation is quite straight forward. ZipFileSystem builds an Inode tree on open. That tree is implemented as a Map. For regular zip/jar files both the key and the value are the same Inode. For multi-release

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> 在 2015年10月1日，下午7:36，Sean Mullan 写道： > > > > On 10/1/15 5:10 AM, Wang Weijun wrote: >> >>> 在 2015年10月1日，上午7:53，Steve Drach 写道： >>> >>> - JDK 8 jar signer does not work with a JDK 9 created keystore >>> - JDK 8 signed jar with JDK 8 created

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/1/15 5:10 AM, Wang Weijun wrote: 在 2015年10月1日，上午7:53，Steve Drach 写道： - JDK 8 jar signer does not work with a JDK 9 created keystore - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore - JDK 8 signed jar

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 29/09/2015 21:46, Steve Drach wrote: Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238:

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>>> - JDK 8 jar signer does not work with a JDK 9 created keystore >>> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK >>> 9 signed jar with JDK 9 keystore >>> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK >>> 9 signed jar with the same JDK

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734

  1   2   >