Re: RFR: 8164805: Fail to create a MR modular JAR with a versioned entry in base-versioned empty package

There is a new webrev at http://cr.openjdk.java.net/~sdrach/8164805/webrev.01/ >>> >>> sun/tools/jar/Main.java >>> >>> Thanks for refactoring and adding the findConcealedPackages method. What I >>> actually meant was to move out this line: >>> concealedPackages = findConcealedPacka

Re: RFR: 8164805: Fail to create a MR modular JAR with a versioned entry in base-versioned empty package

>> There is a new webrev at >> http://cr.openjdk.java.net/~sdrach/8164805/webrev.01/ > > sun/tools/jar/Main.java > > Thanks for refactoring and adding the findConcealedPackages method. What I > actually meant was to move out this line: >concealedPackages = findConcealedPackages(rd); > >

Re: RFR: 8164805: Fail to create a MR modular JAR with a versioned entry in base-versioned empty package

There is a new webrev at http://cr.openjdk.java.net/~sdrach/8164805/webrev.01/ that addresses the issues raised by Mandy. Comments inline. >> issue: https://bugs.openjdk.java.net/browse/JDK-8164805 >> webrev: http://cr.openjdk.java.net/~sd

Re: RFR: 8164805: Fail to create a MR modular JAR with a versioned entry in base-versioned empty package

>> On Oct 19, 2016, at 5:05 PM, Steve Drach wrote: >> >>>> issue: https://bugs.openjdk.java.net/browse/JDK-8164805 >>>> webrev: http://cr.openjdk.java.net/~sdrach/8164805/webrev.00/ >>> >>> Issue a warning is good in the case public classes

Re: RFR: 8164805: Fail to create a MR modular JAR with a versioned entry in base-versioned empty package

> 76 private String files(Path start) throws IOException { > Perhaps return Stream. That can replace the unnecessary concat in a > String and then later split to pass to javac. Is this better? private void javac(Path source, Path destination) throws IOException { Stream prefix

Re: RFR: 8164805: Fail to create a MR modular JAR with a versioned entry in base-versioned empty package

>> issue: https://bugs.openjdk.java.net/browse/JDK-8164805 >> webrev: http://cr.openjdk.java.net/~sdrach/8164805/webrev.00/ > > Issue a warning is good in the case public classes are added in a concealed > package. Some comments: > > Main.java > > addExtendedModuleAttributes does not seem to

RFR: 8164805: Fail to create a MR modular JAR with a versioned entry in base-versioned empty package

Hi, Please review the following changeset. This fix allows jar tool to add a new public class in a versioned directory in a modular multi-release jar file if the class is in a concealed package. When this event takes place, a warning message is emitted saying that placing this jar on a class p

Fwd: RFR: 8167237: Jar tool can not correctly find/process the --release option if it occurs before the file list

Hi again, Is there anyone willing to review this? It’s a very simple change. Thanks Steve > Begin forwarded message: > > From: Steve Drach > Subject: RFR: 8167237: Jar tool can not correctly find/process the --release > option if it occurs before the file list > Date: Oc

Re: RFR: 8166460: jdk/internal/util/jar/TestVersionedStream gets Assertion error

://cr.openjdk.java.net/~sdrach/8166460/webrev.03/ <http://cr.openjdk.java.net/~sdrach/8166460/webrev.03/> > On Oct 5, 2016, at 12:27 PM, Steve Drach wrote: > > Hi, > > Please review the following changeset that creates a replacement for the > TestVersionedStream test. The pr

RFR: 8167237: Jar tool can not correctly find/process the --release option if it occurs before the file list

Hi, Please review the changeset that fixes the problem of not “seeing” the jar tool —release option if it is not preceded by anything other than gnu-style options. It’s a simple one line change to process —release the same way as -C. issue: https://bugs.openjdk.java.net/browse/JDK-8167237

RFR: 8166460: jdk/internal/util/jar/TestVersionedStream gets Assertion error

Hi, Please review the following changeset that creates a replacement for the TestVersionedStream test. The previous test occasionally failed on Linux hotspot nightly testing due to jar tool sometimes changing the order of the entries. The new test specifically sets the order of the entries an

Re: RFR: 8165944 jar utility doesn't process more than one -C argument

://cr.openjdk.java.net/~sdrach/8165944/webrev.06/ <http://cr.openjdk.java.net/~sdrach/8165944/webrev.06/> > On Sep 27, 2016, at 12:31 PM, Steve Drach wrote: > > After a discussion with Paul Sandoz, I’ve simplified and, hopefully, thus > clarified the changeset. The new w

Re: RFR: 8165944 jar utility doesn't process more than one -C argument

After a discussion with Paul Sandoz, I’ve simplified and, hopefully, thus clarified the changeset. The new webrev is http://cr.openjdk.java.net/~sdrach/8165944/webrev.01/ <http://cr.openjdk.java.net/~sdrach/8165944/webrev.01/> > On Sep 26, 2016, at 12:31 PM, Steve Drach wrote

RFR: 8165944 jar utility doesn't process more than one -C argument

Hi, Please review these changes to the jar tool to fix a capability regression I introduced in an earlier revision. The issue is that this $ jar -cf test.jar -C test1 . -C test2 . only puts the files under test1 in the jar and ignores the files under test2. The DoubleCs test verified the pro

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

> This looks good. Thanks for the update. > > Minor comments below and you can make the change before you push (no need for > a new webrev). > > MultiReleaseException.java >key and msg should be final fields Done. > > VersionHelper.java > nameToVersion can simply be Map (I missed this

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

A relatively minor update. I simplified VersionHelper. No other changes. http://cr.openjdk.java.net/~sdrach/8153654/webrev.12/ <http://cr.openjdk.java.net/~sdrach/8153654/webrev.12/> > On Sep 14, 2016, at 4:06 PM, Steve Drach wrote: > > The most recent we

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

The most recent webrev is http://cr.openjdk.java.net/~sdrach/8153654/webrev.11/ Comments inline >> The latest web revs. Answers to questions in-line below: >> >> http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/ >> >> http://cr.openj

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

The latest web revs. Answers to questions in-line below: http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/ http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ >>> >>> This

Re: RFR: 8163798: Create a JarFile versionedStream method

I guess I’m going to keep doing this until I get it right ;-) Here’s another webrev that doesn’t use an exception for a common case, and addresses most of Mandy concerns. http://cr.openjdk.java.net/~sdrach/8163798/webrev.06/ Comments i

Re: RFR: 8163798: Create a JarFile versionedStream method

Here’s a new webrev addressing Paul’s additional concerns http://cr.openjdk.java.net/~sdrach/8163798/webrev.04/ > Ok, better. Now there is no need to create an instance of VersionedStream, > all methods can be static. Done > > I wonder

Re: RFR: 8163798: Create a JarFile versionedStream method

Here’s a new webrev that addresses Claes’ and Paul’s concerns http://cr.openjdk.java.net/~sdrach/8163798/webrev.03/ <http://cr.openjdk.java.net/~sdrach/8163798/webrev.03/> > On Sep 11, 2016, at 1:12 PM, Steve Drach wrote: > > I made a simple change, the new we

Re: RFR: 8163798: Create a JarFile versionedStream method

> functional and tested then tweaking for performance. > > Paul. > > > >>> On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: >>> >>> Hi, >>> >>> Please review this changeset that adds a VersionedStream class to the >>> jdk

Re: RFR: 8163798: Create a JarFile versionedStream method

: static final is preferred over final static done > > - nit: rename *ptr to *Index done > > Test and JarFile changes seem fine to me. > > Thanks! > > /Claes > > On 2016-09-11 22:12, Steve Drach wrote: >> I made a simple change, the new webrev is >&

Re: RFR: 8163798: Create a JarFile versionedStream method

I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ <http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/> > On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: > > Hi, > > Please review this changeset that adds a Version

RFR: 8163798: Create a JarFile versionedStream method

Hi, Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we get

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

new webrev addressing issues below: http://cr.openjdk.java.net/~sdrach/8153654/webrev.09/ >> Hi, >> >> Please review the following two changesets that enables jdeps to use >> multi-release jar files. The output from the tool shows versi

RFR: 8153654: Update jdeps to be multi-release jar aware

Hi, Please review the following two changesets that enables jdeps to use multi-release jar files. The output from the tool shows versioned dependencies by prefixing them with “version #/“ where version # is 9, 10, etc. webrevs: http://cr.openjdk.java.net/~sdrach/8153654/webrev.08/

Fwd: RFR 8163798: Add a versionedStream method to JarFile

Sorry, forget to Cc core-libs on my response to Peter’s questions > Begin forwarded message: > > From: Steve Drach > Subject: Re: RFR 8163798: Add a versionedStream method to JarFile > Date: August 26, 2016 at 9:44:39 AM PDT > To: Peter Levart > > Hi Peter, > &g

RFR 8163798: Add a versionedStream method to JarFile

Hi, Please review this changeset that adds a versionedStream method to JarFile. webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8163798

8164585: JarFile::isMultiRelease does not return true in all cases where it should return true

Hi, Please review this simple change to JarFile issue: https://bugs.openjdk.java.net/browse/JDK-8164585 webrev: http://cr.openjdk.java.net/~sdrach/8164585/webrev.00/ Thanks, Steve

Re: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

I’ve updated the webrev to incorporate most of Paul’s suggestions. http://cr.openjdk.java.net/~sdrach/8164389/webrev.01/index.html <http://cr.openjdk.java.net/~sdrach/8164389/webrev.01/index.html> > On Aug 18, 2016, at 5:01 PM, Paul Sandoz wrote: > > >> On 18 Aug 2016,

Re: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

>>> You might wanna create a temporary jar file if possible, just in case the >>> test somehow fails to clean things up. >> >> Unsure how to do that, or perhaps I don’t understand your request. > > I believe it’s possible to create a temporary directory, see > Files.createTempDirectory, and use

Re: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

> You might wanna create a temporary jar file if possible, just in case the > test somehow fails to clean things up. Unsure how to do that, or perhaps I don’t understand your request.

RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

Hi, Please review this rather simple fix to JarFileSystem. issue: https://bugs.openjdk.java.net/browse/JDK-8164389 webrev: http://cr.openjdk.java.net/~sdrach/8164389/webrev/index.html

RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

Hi, Please review this changset that makes jlink multi-release jar aware. issue: https://bugs.openjdk.java.net/browse/JDK-8156499 webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.00/index.html

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

ttp://cr.openjdk.java.net/~sdrach/8158295/webrev.03/index.html> > On Jul 18, 2016, at 6:33 PM, Steve Drach wrote: > >>> Please review the following: >>> >>> webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/ >>> <http://cr.openjdk.ja

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

> On Jul 28, 2016, at 11:59 AM, Oleg G. Barbashov > wrote: > > 27.07.2016 15:34, Oleg G. Barbashov пишет: >> >> 07.07.2016 23:32, Steve Drach пишет: >>> Hi, >>> >>> Please review the following: >>> >>> web

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

it does seem possible, and I’ll remember that in the future, but what I >> have works, so I think I’ll stick with it. > > In this case it is also needed to pass the jtreg's javac options > ("test.compiler.opts”). OK > > - Oleg >> >>> Thanks, &g

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

it. > > Thanks, > Oleg > > 07.07.2016 23:32, Steve Drach пишет: >> Hi, >> >> Please review the following: >> >> webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/ >> <http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/> >

Re: Question on MVJAR usage

ween the two cases (8 to 9 vs 9.0 to > 9.1). Does that make sense? Yes, it makes sense, but as I said, it’s a known restriction. > > Cheers, > Paul > > On Tue, Jul 19, 2016 at 1:41 PM, Steve Drach <mailto:steve.dr...@oracle.com>> wrote: > Hi Paul, > > >

Re: Question on MVJAR usage

Hi Paul, > I have some questions. I believe core-lib is the right place. If not please > let me know. This is the right place. First, the name was changed to Multi-Release JAR, so it’s MRJAR (or Mr. Jar) instead of MVJAR. > > 1) Given a Java 9 runtime, is there any perceptible difference betw

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

It doesn’t add that much value. I’ll take it out. > On Jul 19, 2016, at 1:12 AM, Paul Sandoz wrote: > > >> On 18 Jul 2016, at 20:06, Steve Drach wrote: >> >>> >>> I would be inclined to drop the note for Enumeration and add a @see tag >>>

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

>> Please review the following: >> >> webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/ >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8158295 >> >> >> This changeset ad

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

>> It’s used in two places, moving it to jarPackages won’t work, I think. I >> also put a check in to see if it’s a multi-release jar. > I meant to move the method down to where jarPackages is located. I would > probably adjust the comment too but we can do that once your changes are in > jdk9/

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

>> Please review this change to JarFile that reverts JarFile::stream and >> JarFile::entries to JDK 8 behavior. The code is identical to that in JDK 8 >> except line 504 in JarEntryIterator that now uses a different constructor to >> create a JarFileEntry. I also added some implementation note

RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

Hi, Please review this change to JarFile that reverts JarFile::stream and JarFile::entries to JDK 8 behavior. The code is identical to that in JDK 8 except line 504 in JarEntryIterator that now uses a different constructor to create a JarFileEntry. I also added some implementation notes expla

RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

Hi, Please review the following: webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8158295 This changeset adds a multi-release

RFR: 8155770 Correct URLClassLoader API documentation to explicitly say jar-scheme URL's are accepted

Hi, Please review this simple change to the URLClassLoader specification. issue: https://bugs.openjdk.java.net/browse/JDK-8155770 webrev: http://cr.openjdk.java.net/~sdrach/8155770/webrev/ T

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

> 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

d 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 to identify anything in the JDK with release semantics -- apart > from Jar files? > > Cheers, > Paul > > On Tue

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

Hi Paul, I believe this webrev addresses your concerns: http://cr.openjdk.java.net/~sdrach/8150680/webrev.03/index.html <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:4

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

gain did not see either class loaded. I also tried the tests with a jar file on the class path and did see both classes loaded. > > cheers, > Rémi > > ----- Mail original - >> De: "Steve Drach" >> À: "Joseph D. Darcy" >> Cc: "Core-L

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

eers, > > -Joe > > On 6/15/2016 3:49 PM, Steve Drach wrote: >> 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/ >> <http://cr.op

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

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/ <http://cr.openjdk.java.net/~sdrach/8150680/webrev.01/> > On Jun 15, 2016, at 8:56 AM, Steve Drach wrote: > >>&

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

>> 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

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

Re: RFR: 8153652 Update javap to be multi-release jar aware

>> Please review the following changeset that simply supplies the help >> information for the already existing javap command line option, >> -multi-release. >> >> webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/ >> >> issue: h

Re: RFR: 81536534 Update jdeps to be multi-release jar aware

Hi Mandy, >> Please review the following changeset to make jdeps multi-release jar aware. >> >> webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8153654

RFR: 81536534 Update jdeps to be multi-release jar aware

Hi, Please review the following changeset to make jdeps multi-release jar aware. webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html issue: https://bugs.openjdk.java.net/browse/JDK-8153654

RFR: 8153652 Update javap to be multi-release jar aware

Hi, Please review the following changeset that simply supplies the help information for the already existing javap command line option, -multi-release. webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/ issue: https://bugs.openj

RFR: 8114827: JDK 9 multi-release enabled jar tool

Hi, Please review the following changeset that makes it easier to create multi-release jar files with jar tool. webrev: http://cr.openjdk.java.net/~sdrach/8114827/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8114827 The changeset is the implementation of a new command line optio

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

Looks fine to me, although I am not an official reviewer. Thanks for doing this. > On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline > wrote: > > Hi, > > Can you please take a look on: > http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ > ? > > Thank you > > Shura >

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

Another webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.05/index.html Only URLClassPath has changed. I put a comment on url.getProtocol indicating the URL assures it’s lower case and I changed the long lines into mult

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

Hopefully the last one ;-) This webrev removes the lowercase of protocol, and incorporates better (in my mind) seperation of choices for choosing the loader, similar to what Paul suggested. Everything else remains the same. Only URLClassPath changed from previous webrev. http://cr.openjdk.ja

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

> On Apr 29, 2016, at 4:47 PM, Xueming Shen wrote: > > On 4/29/16 3:30 PM, Steve Drach wrote: >> I updated the webrev with changes that Alan suggested >> >> still needs to be fixed to compare the URL protocol without regard to >> case > > ->

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

I updated the webrev with changes that Alan suggested still needs to be fixed to compare the URL protocol without regard to case And Sherman suggested Shouldn't the realname just be the "super.getName()” ? The webrev is at http://cr.openjdk.java.net/~sdrach/8151542/webrev.03/i

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

>> I just didn’t see it as any higher than P4. What would you like it to be? >> >> > We've stumbled on an issue where the spec and implementation are in conflict. > The right thing to do it to fix it while we have a handle on it. I bumped the priority to P2.

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

>> I put a new webrev out with the change suggested by Paul, using >> file.indexOf(“!/“) instead of file.endsWith(“!/“). >> >> http://cr.openjdk.java.net/~sdrach/8151542/webrev.02/index.html >> This >> still needs to be fixed to

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

I put a new webrev out with the change suggested by Paul, using file.indexOf(“!/“) instead of file.endsWith(“!/“). http://cr.openjdk.java.net/~sdrach/8151542/webrev.02/index.html > So you are planning to eventually change the URL

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

>> I’ve updated the webrev to change all instances of the word “reified” to >> “real” as in getRealName(). >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 >> >> >> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/ >>

RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

I’ve updated the webrev to change all instances of the word “reified” to “real” as in getRealName(). Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

> On Apr 28, 2016, at 12:03 PM, Alan Bateman wrote: > > > > On 28/04/2016 19:53, Steve Drach wrote: >> : >> Yes, and for regular jar files, that worked fine, but when we tried it with >> a multi-release jar we found it by passed the part of JarLoader wh

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 >>> >>> >>> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev/ >>> >>> >>> This changeset causes the URL returned from a Cl

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

>> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 >> >> >> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev/ >> >> >> This changeset causes the URL returned from a ClassLoad

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

Keeping with the path precedent, is it acceptable to change “getReifiedName” to “getRealName”? >>> >>> Diction Note: Reified X means X wasn't real (in some sense) until now. As >>> in non-reified types, which are not real at runtime because the static >>> compiler discarded them. >>> >> >>

RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev/ This changeset causes the URL returned from a ClassLoader.getResource(name)

Re: Multi-Release JAR runtime support

Yes. > On Apr 19, 2016, at 5:11 PM, mark.reinh...@oracle.com wrote: > > 2016/4/19 12:37:41 -0700, Hervé BOUTEMY : >> that's it: I added this Multi-Release: true attribute configuration in the >> demo and now it works like a charm, thank you >> >> Perhaps this requirement should be described in

Re: Multi-Release JAR runtime support

Hi Herve, I checked the jar file created from your code and, as others have suspected, the manifest does not contain the “Multi-Release” attribute. I added the attribute with emacs and tried it out: $ java -classpath multirelease/target/multirelease-0.8-SNAPSHOT.jar base.Base 9-ea+113 FROM BAS

Request for comments -- resource reification vs. mrjar scheme for runtime versioning of multi-release jar files

We’ve identified two possible ways to address issue JDK-8151542. One way is to append a #runtime fragment to the input URL in URLClassPath to convey to URLJarFile that we want to have the JarFile opened with the parameter Release.RUNTIME, so a

RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

Hi, I’ve updated the following patch, incorporating code by Claes Redestad to handle some corner cases while processing the attribute value. Note that we’ve limited the location of the value part of the attribute to accommodate startup performance requirements. It’s not without precedent as a

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

followed by either ‘\r’ or ‘\n’ is the only acceptable value. > On Apr 8, 2016, at 11:34 AM, Steve Drach wrote: > > Okay, I’ll prepare a new webrev. I think all we need to check for after > “true” is \r or \n. If the manifest just ends without at least one of those, > it’s not

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

Okay, I’ll prepare a new webrev. I think all we need to check for after “true” is \r or \n. If the manifest just ends without at least one of those, it’s not a legal manifest. > On Apr 8, 2016, at 11:25 AM, Claes Redestad wrote: > > On 04/08/2016 07:54 PM, Steve Drach wrote: >&g

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

I’ve put up a new webrev that addresses the issue of having spaces before (and after) the value “true” in the Multi-Release attribute. >>> >>> Is some or all of that really necessary? since the we can specify domain of >>> values. >> >> I think it is. The spec states that one c

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

>> I’ve put up a new webrev that addresses the issue of having spaces before >> (and after) the value “true” in the Multi-Release attribute. >> > > Is some or all of that really necessary? since the we can specify domain of > values. I think it is. The spec states that one can have an arbitra

RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

I’ve put up a new webrev that addresses the issue of having spaces before (and after) the value “true” in the Multi-Release attribute. > Hi, > Please review this simple fix to require that the jar manifest Multi-Release > attribute has a value of “true" in order to be effective, i.e. to assert t

RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

Hi, Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of “true" in order to be effective, i.e. to assert the jar is a multi-release jar. issue: https://bugs.openjdk.java.net/browse/JDK-8153213 w

Re: RFR: 8152733: Avoid creating Manifest when checking for Multi-Release attribute

Hi, A minor nit on the comment > + * Since there are no repeated substrings in our search strings, > + * the good character shifts can be replaced with a comparison. Probably should be “good suffix shifts”. Steve

Re: 8151339 Adding fragment to JAR URLs breaks ant

ve > > Uwe > > - > Uwe Schindler > uschind...@apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -Original Message- >> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net

RFR: 8151339 Adding fragment to JAR URLs breaks ant

Hi, Please review the following changeset. We’d like to get this into build 109, which means by noon today. This is essentially a temporary fix, but it’s been tested and Lucene has been built against it. We will follow up with a more comprehensive fix by build 110. webrev: http://cr.openjdk

Re: RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734

> On Mar 3, 2016, at 3:26 AM, Paul Sandoz wrote: > > >> On 2 Mar 2016, at 20:12, Steve Drach wrote: >> >> Please review the following fix for JDK-8150679 >> >> webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ >> <http://cr.openjdk.j

RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734

Please review the following fix for JDK-8150679 webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ issue: https://bugs.openjdk.java.net/browse/JDK-8150679 The test was modified to dem

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

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

e for sure, but a kind of "regression". Defining two > iterator classes as suggested > above will also workaround this issue, as the "notVersioned" one will work > just as expected, no > regression. > > -Sherman > > On 2/9/16 5:04 PM, Steve Drach w

Re: RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

escind my request and will close the bug report with appropriate comment. > > -Sherman > > On 2/12/16 1:11 PM, Steve Drach wrote: >> Hi, >> >> Please review this simple fix to ZipFileSystemProvider. The issue is >> JDK-8149769 <https://bugs.openjdk.java.ne

Re: RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

>> Please review this simple fix to ZipFileSystemProvider. The issue is >> JDK-8149769 . I didn’t do >> a webrev but instead provide the following patch. >> >> > This looks okay. Can one of the existing tests be updated to cover this case? Ye

RFR JDK-8149769: Null pointer exception in ZipFileSystemProvider

Hi, Please review this simple fix to ZipFileSystemProvider. The issue is JDK-8149769 . I didn’t do a webrev but instead provide the following patch. Thanks Steve diff -r 2d6c2c75f338 src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemPro

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 ta

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

rev.05/>, that implements what I outlined above. In particular I enhanced the JarEntryIterator class and I added additional commentary to the entries() and stream() methods. I also added a new test, MultiReleaseJarIterators, to test entries() and stream(). > >> On Feb 1, 2016

  1   2   >