Re: JDK 9 RFR of JDK-8157663: Remove tools/jimage/JImageTest.java from ProblemList.txt

Looks fine Amy; thanks, -Joe On 5/25/2016 10:10 PM, Amy Lu wrote: tools/jimage/JImageTest.java This test is in ProblemList.txt with related bugid JDK-8150975. JDK-8150975 has been closed since previously reported image recreate issue now is not an issue anymore because the support for jimag

JDK 9 RFR of JDK-8157663: Remove tools/jimage/JImageTest.java from ProblemList.txt

tools/jimage/JImageTest.java This test is in ProblemList.txt with related bugid JDK-8150975. JDK-8150975 has been closed since previously reported image recreate issue now is not an issue anymore because the support for jimage recreate has been removed in JDK-8154090, in which test also update

Re: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec

> On May 25, 2016, at 5:11 PM, Stuart Marks wrote: > > On 5/25/16 4:58 PM, Mandy Chung wrote: >> Have you considered fixing this method to return a unmodifiable set and make >> this spec in JDK 9? It’s a small change. > > I did think about changing the behavior here but I decided against it b

Re: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec

On 5/25/16 4:58 PM, Mandy Chung wrote: Have you considered fixing this method to return a unmodifiable set and make this spec in JDK 9? It’s a small change. I did think about changing the behavior here but I decided against it because of the small compatibility risk. The main issue here is t

Re: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec

Hi Stuart, Have you considered fixing this method to return a unmodifiable set and make this spec in JDK 9? It’s a small change. Mandy > On May 25, 2016, at 4:11 PM, Stuart Marks wrote: > > Hi all, > > Please review this small spec change. Properties.stringPropertyNames() seems > to imply

Re: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec

Looks fine Stuart; thanks, -Joe On 5/25/2016 4:11 PM, Stuart Marks wrote: Hi all, Please review this small spec change. Properties.stringPropertyNames() seems to imply that the Set it returns is modifiable. It is, but only partially. Since it's a keySet() from a Hashtable, it supports remova

RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec

Hi all, Please review this small spec change. Properties.stringPropertyNames() seems to imply that the Set it returns is modifiable. It is, but only partially. Since it's a keySet() from a Hashtable, it supports removal but not addition. This change removes the implication that the returned se

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Hi Alan and Mandy, Thanks for confirming that. Thanks, Jiangli > On May 25, 2016, at 12:39 PM, Mandy Chung wrote: > > >> On May 25, 2016, at 12:24 PM, Jiangli Zhou wrote: >> >> Hi Mandy, >> >>> On May 25, 2016, at 12:17 PM, Mandy Chung wrote: >>> >>> On May 25, 2016, at 11:28 AM, J

Re: RFR: JDK-8157850 Jar tests should pass through VM options

On 05/25/2016 01:33 PM, David Holmes wrote: On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: Using JAVA_OPTIONS for tools is conceptually wrong. JAVA_OPTIONS is specifically intended to pass options to VM instances, as created by a "java" command. It is not intended that you should prefix the

Re: RFR: JDK-8157850 Jar tests should pass through VM options

On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: Using JAVA_OPTIONS for tools is conceptually wrong. JAVA_OPTIONS is specifically intended to pass options to VM instances, as created by a "java" command. It is not intended that you should prefix the options with -J and use them for arbitrary tool

Re: RFR: JDK-8157850 Jar tests should pass through VM options

Using JAVA_OPTIONS for tools is conceptually wrong. JAVA_OPTIONS is specifically intended to pass options to VM instances, as created by a "java" command. It is not intended that you should prefix the options with -J and use them for arbitrary tools. The code in the webrev is also perverse f

Re: RFR: JDK-8157850 Jar tests should pass through VM options

> On 25 May 2016, at 20:21, Martin Buchholz wrote: > > Agreed and Reviewed! +1. This looks fine. Hopefully it can be simplified, somewhat, in the future. -Chris. > > On Wed, May 25, 2016 at 11:57 AM, Andrey Nazarov > wrote: >> Hi Martin, >> >> See my comments inline. >>> On 25 May 2016, a

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

On 25/05/2016 20:47, Xueming Shen wrote: thanks! updated accordingly. http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev Looks good.

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

On 05/25/2016 12:49 PM, Alan Bateman wrote: On 25/05/2016 20:01, Xueming Shen wrote: : Sure, if there is such "plan". http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev Here is the updated webrev with the @module tag. In ZipPath.register then it would be good to in

Re: Review request JDK-8153944: wsimport and wsgen usage messages not printed

> On May 25, 2016, at 12:45 PM, Alan Bateman wrote: > > On 25/05/2016 20:29, Mandy Chung wrote: >> wsgen and wsimport tools use the utility classes in java.xml.bind module to >> localize messages. Resource bundles are encapsulated in named modules and >> hence utility like >> com.sun.istack.

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

On 25/05/2016 20:01, Xueming Shen wrote: : Sure, if there is such "plan". http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev Here is the updated webrev with the @module tag. In ZipPath.register then it would be good to include a comment to say something "watcher

Re: Review request JDK-8153944: wsimport and wsgen usage messages not printed

I looked at this also and do not see anything glaring. > On May 25, 2016, at 3:45 PM, Alan Bateman wrote: > > On 25/05/2016 20:29, Mandy Chung wrote: >> wsgen and wsimport tools use the utility classes in java.xml.bind module to >> localize messages. Resource bundles are encapsulated in named m

Re: Review request JDK-8157877: Clean up StackWalker permission checks

+1 > On May 25, 2016, at 3:46 PM, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157877/webrev.00/ > > Trivial cleanup to do the check after the options are cloned. > Mandy

Review request JDK-8157877: Clean up StackWalker permission checks

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157877/webrev.00/ Trivial cleanup to do the check after the options are cloned. Mandy

Re: Review request JDK-8153944: wsimport and wsgen usage messages not printed

On 25/05/2016 20:29, Mandy Chung wrote: wsgen and wsimport tools use the utility classes in java.xml.bind module to localize messages. Resource bundles are encapsulated in named modules and hence utility like com.sun.istack.internal.localization.LocalizableMessageFactory. The owner of the r

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

On 25/05/2016 20:24, Jiangli Zhou wrote: I think the proposed toFileURL method name is fine and perhaps the javadoc of toFileURL method could make it clearer. If we had to rename it, maybe toRealPathFileURL (mouthful but it clearly shows it’s “real path” as specified in java.nio.file.Path

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

> On May 25, 2016, at 12:24 PM, Jiangli Zhou wrote: > > Hi Mandy, > >> On May 25, 2016, at 12:17 PM, Mandy Chung wrote: >> >> >>> On May 25, 2016, at 11:28 AM, Jiangli Zhou wrote: >>> >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ >> >> The

Review request JDK-8153944: wsimport and wsgen usage messages not printed

wsgen and wsimport tools use the utility classes in java.xml.bind module to localize messages. Resource bundles are encapsulated in named modules and hence utility like com.sun.istack.internal.localization.LocalizableMessageFactory. The owner of the resource bundle should be the one loading R

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Hi Mandy, > On May 25, 2016, at 12:17 PM, Mandy Chung wrote: > > >> On May 25, 2016, at 11:28 AM, Jiangli Zhou wrote: >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ > > The version restoring toRealPath looks okay. Thanks for the review. > >

Re: RFR: JDK-8157850 Jar tests should pass through VM options

Agreed and Reviewed! On Wed, May 25, 2016 at 11:57 AM, Andrey Nazarov wrote: > Hi Martin, > > See my comments inline. >> On 25 May 2016, at 20:48, Martin Buchholz wrote: >> >> Hi Andrey, >> >> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >> I see we have both test.vm.opts and test.to

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Since canonicalization is an important part of this API, I suggest renaming toFileURL to toCanonicalFileURL by analogy with getCanonicalFile. Also, I'm sure your security experts have already considered the implications of following or not following symlinks when matching user-provided paths ...

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

> On May 25, 2016, at 11:28 AM, Jiangli Zhou wrote: > > Here is the updated webrev: > > http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ The version restoring toRealPath looks okay. I think the proposed toFileURL method name is fine and perhaps the javadoc of toFileURL method could ma

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

On 25/05/2016 20:04, Martin Buchholz wrote: : Also, I'm sure your security experts have already considered the implications of following or not following symlinks when matching user-provided paths ... Nothing has changed here and there is always a permission check before returning a URL to a r

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

On 05/25/2016 11:46 AM, Alexandre (Shura) Iline wrote: On May 25, 2016, at 11:31 AM, Xueming Shen wrote: On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: Sherman, Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such cas

Re: RFR: JDK-8157850 Jar tests should pass through VM options

Hi Martin, See my comments inline. > On 25 May 2016, at 20:48, Martin Buchholz wrote: > > Hi Andrey, > > Looking at http://openjdk.java.net/jtreg/vmoptions.html, > I see we have both test.vm.opts and test.tool.vm.opts > and the latter is supposed to take care of adding "-J". > > +VM_OP

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

> On May 25, 2016, at 11:43 AM, Alan Bateman wrote: > > > > On 25/05/2016 19:28, Jiangli Zhou wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ > This patch changes long standing behavior in URLs to resources on the class > path will no long

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

On 25/05/2016 19:50, Martin Buchholz wrote: Ohh, I missed that calling toRealPath was existing behavior, not changed by webrev.00 I agree changing that sort of thing is risky. I think so too as the existing behavior go way back (I think JDK 1.2). Will toFileURL really be called by the VM? I

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Ohh, I missed that calling toRealPath was existing behavior, not changed by webrev.00 I agree changing that sort of thing is risky. Will toFileURL really be called by the VM? It's not now. I'm surprised the VM would want an actual URL instead of a canonicalized native file name. On Wed, May 2

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

> On May 25, 2016, at 11:31 AM, Xueming Shen wrote: > > On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: >> Sherman, >> >> Not declaring any module dependencies in test is equivalent to declaring >> that the test only depends on java.base. In such case, the test will be >> picked up for e

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

On 25/05/2016 19:28, Jiangli Zhou wrote: Here is the updated webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ This patch changes long standing behavior in URLs to resources on the class path will no longer be URLs to the canonical file path. It's might be okay but it's impos

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: Sherman, Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

The tests under test/jdk/nio/zipfs are intended to test the zipfs implementation and hence they fail if the zipfs provider does not exist. So I agree with Shura that they should have @modules jdk.zipfs that enables test selection per the @modules declaration. Mandy > On May 25, 2016, at 11:06

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Here is the updated webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ Thanks, Jiangli > On May 24, 2016, at 1:00 PM, Jiangli Zhou wrote: > > Hi Martin, > > Thanks for the review. > >> On May 24, 2016, at 10:57 AM, Martin Buchholz wrote: >> >> English syntax error. >> >> +

Re: VarHandles on non-int-sized fields and atomic operations

On Wed, May 25, 2016 at 12:53 AM, Paul Sandoz wrote: > > Aleksey did some analysis to indicate we might be able to achieve access > atomicity (not conflated with being able to perform an efficient CAS) by > default without qualification for all types: > > http://shipilev.net/blog/2014/all-acce

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

On 24/05/2016 23:02, Martin Buchholz wrote: On Tue, May 24, 2016 at 11:49 AM, Alan Bateman wrote: Yeah, the context isn't clear here. This is all related to the HotSpot CDS feature and so very tied to the built-in class loaders. File paths are recorded at -Xshare:dump time and checked at -Xs

Re: VarHandles on non-int-sized fields and atomic operations

On Wed, May 25, 2016 at 12:53 AM, Paul Sandoz wrote: > >> On 25 May 2016, at 01:15, Martin Buchholz wrote: >> We already sort-of have an existing field qualifier for atomic: "volatile" ! >> It is already the case that e.g. volatile long is atomic while >> unadorned long is not. >> But atomics wi

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

Sherman, Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:”-limit

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

Should it? My understanding is that those tests don't use zipfs directly from zipfs module, it access it via java.base's FileSystemProvider interface. It depends on the jdk runtime to pick up the zipfs "provider" to function. So if the jdk runtime fails to pick up the zipfs module for whatever re

Re: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe

+1 Mandy > On May 25, 2016, at 3:43 AM, Chris Hegarty wrote: > > sun.misc.Unsafe, in the jdk.unsupported module, should not have any new > public > methods that were not already part of its API in JDK 8. This issue will > remove three > such methods, getUncompressedObject, getJavaMirror, and

Re: RFR: JDK-8157850 Jar tests should pass through VM options

Hi Andrey, Looking at http://openjdk.java.net/jtreg/vmoptions.html, I see we have both test.vm.opts and test.tool.vm.opts and the latter is supposed to take care of adding "-J". +VM_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); +JAVA_OPTIONS.stream().map(opt -> "

Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

Hi. Should the tests also declare “@modules jdk.zipfs”? Shura > On May 25, 2016, at 9:39 AM, Xueming Shen wrote: > > Hi, > > Please help review the changes for the following zipfs related bug fixes > > JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when > invoking regi

Re: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point

Never mind. You are right. The static case is fine with your fix. There won't be a JNI_OnLoad entry for the dynamic case, but that entry point is optional. On 05/25/16 12:44, Naoto Sato wrote: Attached is the output from "nm -g build/macosx_x64/jdk/lib/libzip.a" with the proposed fix applied. I

Re: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point

Attached is the output from "nm -g build/macosx_x64/jdk/lib/libzip.a" with the proposed fix applied. I see the symbol "_JNI_OnLoad_zip" in it. Am I missing something? Naoto On 5/25/16 9:01 AM, Gary Adams wrote: This fix will not work for the macosx static build. e.g. configure --enable-static

RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

Hi, Please help review the changes for the following zipfs related bug fixes JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result JDK-8146754: (zipfs) ZipPath.relativize() returns wr

Re: Fwd: Files.walk() is unusable because of AccessDeniedException

Hi Henry, I knew there was a work around as I created something similar than yours when I needed it. :) Apparently, we have two different opinions regarding Files.walk() and how this method is supposed to handle permissions. I just sent this email because I felt that Files.walk() didn't behave li

RFR: JDK-8157850 Jar tests should pass through VM options

Some jar tests start VMs without passing vmoptions from jtreg. This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, javac) started by tests. webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 --Andrey

Re: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point

This fix will not work for the macosx static build. e.g. configure --enable-static-build=yes When linking static libraries the entry point for JNI_OnLoad_zip is needed to inform the symbol lookups to be performed on the current executable, rather than a dynamic library. On 05/24/16 19:47, Naoto

RE: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe

+1 Let public Unsafe die (at least partially)! :-) 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] On > Behalf Of

Re: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe

On 25/05/2016 11:43, Chris Hegarty wrote: sun.misc.Unsafe, in the jdk.unsupported module, should not have any new public methods that were not already part of its API in JDK 8. This issue will remove three such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, that were added

Re: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe

On 05/25/2016 01:43 PM, Chris Hegarty wrote: > sun.misc.Unsafe, in the jdk.unsupported module, should not have any new > public > methods that were not already part of its API in JDK 8. This issue will > remove three > such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, tha

RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe

sun.misc.Unsafe, in the jdk.unsupported module, should not have any new public methods that were not already part of its API in JDK 8. This issue will remove three such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, that were added by JDK-8022853, in JDK 9. diff --git a/sr

Re: JDK 9 RFR of JDK-8157813: Remove sun/rmi/transport/proxy/EagerHttpFallback.java from ProblemList.txt

On 05/25/2016 12:44 PM, Amy Lu wrote: > This patch is to remove this test from ProblemList.txt as well. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157813 > webrev: http://cr.openjdk.java.net/~amlu/8157813/webrev.00/ Reviewed. Thanks, -Aleksey

JDK 9 RFR of JDK-8157813: Remove sun/rmi/transport/proxy/EagerHttpFallback.java from ProblemList.txt

sun/rmi/transport/proxy/EagerHttpFallback.java This test has been removed in JDK-8155978: JDK-8155978: Remove HTTP proxy implementation and tests from RMI https://bugs.openjdk.java.net/browse/JDK-8155978 This patch is to remove this test from ProblemList.txt as well. bug: https://bugs.openjdk.j

Re: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec

On 05/24/2016 05:24 PM, Pavel Rappo wrote: > Thanks for looking at this! > >> On 24 May 2016, at 15:16, Aleksey Shipilev >> wrote: >> >> *) CharArrayReader: code changes > > What's your concern with 'b'->'buf' rename? Access parameter's name through > reflection or something else? This change

Re: VarHandles on non-int-sized fields and atomic operations

> On 25 May 2016, at 01:15, Martin Buchholz wrote: > > More high-level observations on low-level operations: > > We already sort-of have an existing field qualifier for atomic: "volatile" ! > It is already the case that e.g. volatile long is atomic while > unadorned long is not. > But atomics w

Re: VarHandles on non-int-sized fields and atomic operations

> On 25 May 2016, at 01:14, David Holmes wrote: Yes, that's the "artisanal" version I would reach for. It doesn't scale well if there is unrelated activity on nearby bytes. >>> >>> Okay, we are exploring it here: >>> https://bugs.openjdk.java.net/browse/JDK-8157726 >> >> Don't overloo