From huaming.li at oracle.com Thu Jun 1 01:52:58 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 1 Jun 2017 09:52:58 +0800 Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell tests to java In-Reply-To: References: <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com> <658eff8e-77ff-89a0-6fc0-030ff75c6319@oracle.com> <6c685ce1-0e2a-1d6e-460c-babe2a2b754a@Oracle.com> <04f27f13-36b9-23fe-c6e6-56d521cbc919@oracle.com> Message-ID: Hi Roger, Thank you for detailed reviewing, fixed as you suggested except below comment: 81-83/93/95: use SHARE.resolve(xxx).toString to compute the paths. As the code is constructing a class path with 2 paths rather than constructing a path. new webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.03/ Thank you -Hamlin On 2017/6/1 0:47, Roger Riggs wrote: > Hi Hamlin, > > RenamePackageTest.java: > - 48,61: rename "sutup" -> "setup" > > 81-83/93/95: use SHARE.resolve(xxx).toString to compute the paths. > > ClassPathTest.java: > 42: add a space before "{" > > 56: Generally, exception messages should not end in "."; they are phrases > so they could be printed with context. > In this specific case it is not important, just a pattern to follow > consistently. > > Thanks, Roger > > On 5/26/2017 9:14 PM, Hamlin Li wrote: >> Hi Roger, >> >> Thank you for catching it, new webrev: >> http://cr.openjdk.java.net/~mli/8166142/webrev.02/ >> >> Thank you >> >> -Hamlin >> >> >> On 2017/5/27 3:30, Roger Riggs wrote: >>> Hi Hamlin, >>> >>> SubclassTest.java:37: typo" excepiton" -> exception >>> >>> >>> SubclassDataLossTest.java: >>> 103/104: Adding the class loader close() calls isn't very effective >>> since if there is an exception they are not >>> closed and the creation in a static initializer is mismatched with >>> main() code. >>> >>> It would be cleaner to open in main() using try-with-resources and >>> close them in a finally clause. >>> And pass the loaders to the test function. >>> But for simplicity, perhaps just leave out the new calls to >>> ldr1/2.close. >>> >>> (There is something odd about the webrev links, the nagivation links >>> don't work as expected. but that's transient) >>> >>> Thanks, Roger >>> >>> >>> >>> On 5/26/2017 12:26 AM, Hamlin Li wrote: >>>> Hi Roger, >>>> >>>> Thank you for detailed review. Fixed as you suggested, new webrev: >>>> http://cr.openjdk.java.net/~mli/8166142/webrev.01/ >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>>> >>>> On 2017/5/26 2:54, Roger Riggs wrote: >>>>> Hi Hamlin, >>>>> >>>>> For imports they should import specific classes, wildcards are not >>>>> used. >>>>> >>>>> maskSyntheticModifier/Test.java >>>>> consTest/Test.java >>>>> deserializeButton/Test.java >>>>> >>>>> test/java/io/Serializable/packageAccess/Driver.java: the name >>>>> "Driver" is not descriptive and should be. >>>>> >>>>> Each Driver.java should have a different and >>>>> functional/descriptive name. >>>>> >>>>> Better yet, there should be a single program that creates jar >>>>> files using command line arguments >>>>> that can be invoked depending on the test. >>>>> >>>>> There is a mix of Driver's copying files vs the test program >>>>> copying; can that be made more uniform. >>>>> >>>>> Test.java files should have descriptive/functional names. (Even if >>>>> the duplicating the directory) >>>>> >>>>> Regards, Roger >>>>> >>>>> >>>>> On 5/24/2017 5:09 AM, Hamlin Li wrote: >>>>>> Would you please review the below patch? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8166142 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/ >>>>>> >>>>>> >>>>>> Thank you >>>>>> >>>>>> -Hamlin >>>>>> >>>>> >>>> >>> >> > From huaming.li at oracle.com Thu Jun 1 01:55:12 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 1 Jun 2017 09:55:12 +0800 Subject: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in java.base & java.datatransfer module In-Reply-To: References: <735f89a2-8c5b-a08c-dc6f-5cd14ad1629a@oracle.com> <212618e5-6a12-42ab-bda6-0013d2816a79@oracle.com> Message-ID: <3a8691f5-54c6-7272-bcd1-48ac52155019@oracle.com> Ping. Thank you -Hamlin On 2017/5/31 8:13, Hamlin Li wrote: > Hi Alan, Sergey, > > Sorry for delayed reply, I have been on vacation for last few days. > > I do have a tool (still under development, it's based on javadoc > doclet) to scan versions (currently from 1.7 to 9) of jdk source, find > since tag issues, and give suggested since tag versions if feasible. > But for older versions of jdk source code, for example 1.6 or older > versions, the tool has trouble with them, so for classes added in > older versions, the tool can only detect the issues, but can not give > the suggested since tag versions, the changes in this webrev is > generated manually. As for older versions, we only need to fix issues > once, so I think it's worth to do the necessary manual check and fix. > > Thank you > > -Hamlin > > > On 2017/5/27 14:17, Alan Bateman wrote: >> >> >> On 27/05/2017 02:14, Hamlin Li wrote: >>> Is someone available to review the change? >>> >> I skimmed through it, crossing checking several against the docs for >> JDK 1.0, JDK 1.1, and JDK 1.2. I didn't spot any mistakes but I agree >> with Sergey, it would be good to know if this was done by creating >> the lists from the binaries rather than manual. >> >> -Alan >> >>> >>> >>> On 2017/5/25 17:19, Hamlin Li wrote: >>>> Would you please review below patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8181082 >>>> >>>> webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/ >>>> >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>> >> > From sergey.bylokhov at oracle.com Thu Jun 1 01:57:04 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 May 2017 18:57:04 -0700 (PDT) Subject: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in java.base & java.datatransfer module Message-ID: <9b06ce7d-5d52-408a-9347-513599614fcf@default> Looks fine to me. Thank you for clarification. ----- huaming.li at oracle.com wrote: > Ping. > > Thank you > > -Hamlin > > > On 2017/5/31 8:13, Hamlin Li wrote: > > Hi Alan, Sergey, > > > > Sorry for delayed reply, I have been on vacation for last few days. > > > > I do have a tool (still under development, it's based on javadoc > > doclet) to scan versions (currently from 1.7 to 9) of jdk source, > find > > since tag issues, and give suggested since tag versions if feasible. > > > But for older versions of jdk source code, for example 1.6 or older > > > versions, the tool has trouble with them, so for classes added in > > older versions, the tool can only detect the issues, but can not > give > > the suggested since tag versions, the changes in this webrev is > > generated manually. As for older versions, we only need to fix > issues > > once, so I think it's worth to do the necessary manual check and > fix. > > > > Thank you > > > > -Hamlin > > > > > > On 2017/5/27 14:17, Alan Bateman wrote: > >> > >> > >> On 27/05/2017 02:14, Hamlin Li wrote: > >>> Is someone available to review the change? > >>> > >> I skimmed through it, crossing checking several against the docs > for > >> JDK 1.0, JDK 1.1, and JDK 1.2. I didn't spot any mistakes but I > agree > >> with Sergey, it would be good to know if this was done by creating > > >> the lists from the binaries rather than manual. > >> > >> -Alan > >> > >>> > >>> > >>> On 2017/5/25 17:19, Hamlin Li wrote: > >>>> Would you please review below patch? > >>>> > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8181082 > >>>> > >>>> webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/ > >>>> > >>>> > >>>> Thank you > >>>> > >>>> -Hamlin > >>>> > >>> > >> > > From roger.riggs at oracle.com Thu Jun 1 02:09:02 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 31 May 2017 22:09:02 -0400 Subject: RFR 9+-: 8180582: The bind to rmiregistry is rejected by registryFilter even though registryFilter is set In-Reply-To: <6dc73b18-1bee-23a6-11c0-e80b5463a21f@oracle.com> References: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com> <996d590e-4d08-df0b-d20d-b65610ba472d@Oracle.com> <39f12457-65a8-36c9-cb32-babb74fa9c08@Oracle.com> <6dc73b18-1bee-23a6-11c0-e80b5463a21f@oracle.com> Message-ID: Hi Stuart, Good suggestions on the regex, but it will be simpler, as you suggest, to use a separate command line property. The webrev is updated in place. http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html Thanks, Roger On 5/31/17 7:09 PM, Stuart Marks wrote: > Hi Roger, > > RegistryImpl change looks fine. I have a quibble on the regex used in > the test. > > 162 Matcher m = Pattern > 163 .compile(".*maxdepth=(\\d*)") > 164 .matcher(Objects.requireNonNullElse(registryFilter, "")); > 165 int depthOverride = m.find() ? > Integer.parseInt(m.group(1)) : REGISTRY_MAX_DEPTH; > > Since Matcher.find() is called, the pattern can be found anywhere in > the input string, so the leading ".*" is unnecessary. I'd suggest > replacing it with "\\b" to match a word boundary immediately preceding > "maxdepth". Also, "\\d*" will match zero characters, which could cause > the subsequent parseInt() to fail. > > These issues aren't of immediate concern, as the test works as it > stands. They may make the test a bit harder to maintain, though. > > But I think the main concern is that if the regex were modified by > future maintenance, it might not match, which would cause the test to > test REGISTRY_MAX_DEPTH redundantly instead of the depth the filter is > attempting to specify. This problem wouldn't be completely silent, but > it'd be easy to miss. You'd have to inspect the log pretty carefully > to see what's going on. So maybe it would be good to have something > like a command-line argument that specifies the expected value of > maxdepth. Yes, this is redundant, but it's a useful cross-check, I think. > > There are several identical lines of code starting at line 184. Maybe > these could be extracted into a common method. > > These are all cleanup issues, so it's up to you how much additional > work you want to put into this before it gets into 9. > > s'marks > > > > On 5/31/17 7:02 AM, Roger Riggs wrote: >> Thanks Daniel for the review and corrected link. >> >> On 5/30/2017 7:04 PM, Daniel Fuchs wrote: >>> Hi Roger, >>> >>> On 30/05/17 19:26, Roger Riggs wrote: >>>> Hi Daniel, >>>> >>>> Fixed, there is no need for the unbind since the registry is not >>>> reused and >>>> it might >>>> cause a spurious success. >>>> >>>> (Also corrected the exception error message @ 151 and 153). >>>> >>>> Webrev updated in place. >>>> ... >>> >>> I assume you meant >>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html >>> which is what I reviewed ;-) >>> >>> Looks good! >>> >>> -- danel >>> >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 5/30/2017 2:00 PM, Daniel Fuchs wrote: >>>>> Hi Roger, >>>>> >>>>> Looks good! Just one nit with the test: >>>>> >>>>> 194 registry.unbind(name); >>>>> 195 Assert.fail("Registry filter should have rejected >>>>> depth: " >>>>> + depthOverride + 1); >>>>> >>>>> Technically, the test will also pass if bind() succeed but >>>>> unbind() fails - for some unforeseen reason. >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 25/05/17 16:31, Roger Riggs wrote: >>>>>> Please review an update to the RMI Registry built-in serial filter >>>>>> implementation limit on the depth >>>>>> of a instance that can be bound in the registry. The initial >>>>>> depth limit >>>>>> was 5 and it was too limiting >>>>>> for some existing applications. It limit is updated to depth = >>>>>> 20 and >>>>>> should be more than adequate. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html >>>>>> >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8180582 >>>>>> >>>>>> Thanks, Roger >>>>> >>>> >>> >> From roger.riggs at oracle.com Thu Jun 1 02:37:59 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 31 May 2017 22:37:59 -0400 Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell tests to java In-Reply-To: References: <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com> <658eff8e-77ff-89a0-6fc0-030ff75c6319@oracle.com> <6c685ce1-0e2a-1d6e-460c-babe2a2b754a@Oracle.com> <04f27f13-36b9-23fe-c6e6-56d521cbc919@oracle.com> Message-ID: <1617c283-dcb7-e089-8497-e62b12052edb@oracle.com> Hi Hamlin, Looks good. On to the next. Roger On 5/31/17 9:52 PM, Hamlin Li wrote: > Hi Roger, > > Thank you for detailed reviewing, fixed as you suggested except below > comment: > > 81-83/93/95: use SHARE.resolve(xxx).toString to compute the paths. > > As the code is constructing a class path with 2 paths rather than > constructing a path. right, my mistake. > > new webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.03/ > > Thank you > > -Hamlin > > > On 2017/6/1 0:47, Roger Riggs wrote: >> Hi Hamlin, >> >> RenamePackageTest.java: >> - 48,61: rename "sutup" -> "setup" >> >> 81-83/93/95: use SHARE.resolve(xxx).toString to compute the paths. >> >> ClassPathTest.java: >> 42: add a space before "{" >> >> 56: Generally, exception messages should not end in "."; they are >> phrases >> so they could be printed with context. >> In this specific case it is not important, just a pattern to follow >> consistently. >> >> Thanks, Roger >> >> On 5/26/2017 9:14 PM, Hamlin Li wrote: >>> Hi Roger, >>> >>> Thank you for catching it, new webrev: >>> http://cr.openjdk.java.net/~mli/8166142/webrev.02/ >>> >>> Thank you >>> >>> -Hamlin >>> >>> >>> On 2017/5/27 3:30, Roger Riggs wrote: >>>> Hi Hamlin, >>>> >>>> SubclassTest.java:37: typo" excepiton" -> exception >>>> >>>> >>>> SubclassDataLossTest.java: >>>> 103/104: Adding the class loader close() calls isn't very >>>> effective since if there is an exception they are not >>>> closed and the creation in a static initializer is mismatched with >>>> main() code. >>>> >>>> It would be cleaner to open in main() using try-with-resources and >>>> close them in a finally clause. >>>> And pass the loaders to the test function. >>>> But for simplicity, perhaps just leave out the new calls to >>>> ldr1/2.close. >>>> >>>> (There is something odd about the webrev links, the nagivation >>>> links don't work as expected. but that's transient) >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> On 5/26/2017 12:26 AM, Hamlin Li wrote: >>>>> Hi Roger, >>>>> >>>>> Thank you for detailed review. Fixed as you suggested, new webrev: >>>>> http://cr.openjdk.java.net/~mli/8166142/webrev.01/ >>>>> >>>>> Thank you >>>>> >>>>> -Hamlin >>>>> >>>>> >>>>> On 2017/5/26 2:54, Roger Riggs wrote: >>>>>> Hi Hamlin, >>>>>> >>>>>> For imports they should import specific classes, wildcards are >>>>>> not used. >>>>>> >>>>>> maskSyntheticModifier/Test.java >>>>>> consTest/Test.java >>>>>> deserializeButton/Test.java >>>>>> >>>>>> test/java/io/Serializable/packageAccess/Driver.java: the name >>>>>> "Driver" is not descriptive and should be. >>>>>> >>>>>> Each Driver.java should have a different and >>>>>> functional/descriptive name. >>>>>> >>>>>> Better yet, there should be a single program that creates jar >>>>>> files using command line arguments >>>>>> that can be invoked depending on the test. >>>>>> >>>>>> There is a mix of Driver's copying files vs the test program >>>>>> copying; can that be made more uniform. >>>>>> >>>>>> Test.java files should have descriptive/functional names. (Even >>>>>> if the duplicating the directory) >>>>>> >>>>>> Regards, Roger >>>>>> >>>>>> >>>>>> On 5/24/2017 5:09 AM, Hamlin Li wrote: >>>>>>> Would you please review the below patch? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8166142 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>> -Hamlin >>>>>>> >>>>>> >>>>> >>>> >>> >> > From igor.ignatyev at oracle.com Thu Jun 1 03:04:29 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 31 May 2017 20:04:29 -0700 Subject: RFR(S) : 8181391: remove explicit @build actions for the top level testlibary classes Message-ID: http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html > 55 lines changed: 1 ins; 50 del; 4 mod; Hi all, due to CODETOOLS-7901986[1], tests sporadically fail w/ CNFE or NCDFE, having explicit build actions has been proven to contribute into this[1-2]. this fix removes explicit @build actions for classes from jdk.test.lib.* packages (the top level testlibrary). webrev: http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8181391 testing: changed tests [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 [2] https://bugs.openjdk.java.net/browse/JDK-8157957 [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198.html Thanks, -- Igor From martinrb at google.com Thu Jun 1 03:11:18 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 31 May 2017 20:11:18 -0700 Subject: RFR(S) : 8181391: remove explicit @build actions for the top level testlibary classes In-Reply-To: References: Message-ID: Adding Jonathan Gibbons, clearly the most qualified reviewer... On Wed, May 31, 2017 at 8:04 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html > > 55 lines changed: 1 ins; 50 del; 4 mod; > > Hi all, > > due to CODETOOLS-7901986[1], tests sporadically fail w/ CNFE or NCDFE, > having explicit build actions has been proven to contribute into this[1-2]. > this fix removes explicit @build actions for classes from jdk.test.lib.* > packages (the top level testlibrary). > > webrev: http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/ > index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8181391 > testing: changed tests > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 > [2] https://bugs.openjdk.java.net/browse/JDK-8157957 > [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > August/024198.html > > Thanks, > -- Igor From amy.lu at oracle.com Thu Jun 1 03:19:49 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 1 Jun 2017 11:19:49 +0800 Subject: JDK 10 RFR of JDK-8181126: Refactor shell test java/nio/Buffer/LimitDirectMemory.sh to java In-Reply-To: References: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com> Message-ID: <63389024-9a37-7fb1-1bb6-84c4c5040228@oracle.com> Thank you all for reviewing. Pushed with minor update as Roger suggested. Thanks, Amy On 5/31/17 5:11 AM, Roger Riggs wrote: > Hi Amy, > > LimitDirectMemory.java: 61 - Can you add a usage message to the > exception identifying the arguments. > It is good practice to provide a message so when reading a failing > log, you don't have to go back to the source and stack trace. > > LimitDirectMemoryNegativeTest.java: > > 45: Add a usage message to the exception like: "missing size argument" > it will help someone who later tries to run it from the command line > > 51 - the test should check that the error message includes the > offending argument; append the arg[0] to ERR. > > .shouldContain(ERR*+ arg[0]*) > > Looks fine, no need for another review. > > Thanks, Roger > > > On 5/26/2017 8:29 PM, Brent Christian wrote: >> That all looks fine to me, Amy. >> >> (You'll also need a JDK 10 Reviewer). >> >> Thanks, >> -Brent >> >> On 5/25/17 7:42 PM, Amy Lu wrote: >>> java/nio/Buffer/LimitDirectMemory.sh >>> >>> Please review this patch to refactor the shell test to java. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8181126 >>> webrev: http://cr.openjdk.java.net/~amlu/8181126/webrev.00/ >>> >>> Thanks, >>> Amy > From amy.lu at oracle.com Thu Jun 1 03:20:37 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 1 Jun 2017 11:20:37 +0800 Subject: JDK 10 RFR of JDK-8181301: Refactor shell test AsynchronousChannelGroup/run_any_task.sh to java In-Reply-To: References: <1890eba3-8030-3ca6-ef5a-3e381c977eac@oracle.com> <99f549ea-c64c-6994-48e2-e17c078274a8@oracle.com> Message-ID: <8b4a5415-ecc1-36a7-6609-67513f021120@oracle.com> On 5/31/17 4:39 PM, Alan Bateman wrote: > On 31/05/2017 09:10, Amy Lu wrote: > >> Thank you Alan! >> >> Webrev updated according to the suggestions: >> http://cr.openjdk.java.net/~amlu/8181301/webrev.01 >> > Looks good. Thank you. Pushed. /Amy From felix.yang at oracle.com Thu Jun 1 03:27:41 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Jun 2017 11:27:41 +0800 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: Hi Chris and Daniel, new webrev with a few of explicit builds than wildcard. http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ Thanks, Felix On 2017/5/31 18:20, Chris Hegarty wrote: >> On 31 May 2017, at 10:42, Felix Yang wrote: >> >> Hi there, >> >> please review the patch to various jdk tests to explicitly compiling test libraries and the lib's dependencies. Though it could be a jtreg issue (I think so), it is necessary to get the tests running firstly. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8181299 >> >> Webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/ > This may be ok to get the tests running again, but explicit build targets > would be better. The contents, and module dependencies, from classes > in the test library are subject to change, so building all classes may > require more modules than in the @modules tags in the test. With latest webrev, no new @modules introduced by this change, though I fixed a missing from original tests. I prefer to keep "@build jdk.test.lib.process.*" here. Because, with current test lib package layout, "@build jdk.test.lib.process.*" equals with /@build jdk.test.lib.process.OutputAnalyzer //jdk.test.lib.process.OutputBuffer //jdk.test.lib.process.ProcessTools ////jdk.test.lib.process.//StreamPumper// ///jdk.test.lib.process.ExitCode/ /" It is a bit ugly and not productive, when I only use ProcessTools directly but have to declare a bunch of @builds. That is why I think this is not a fix but a workaround. Thanks, Felix > > I agree with Daniel, each test should be run separately in a clean > environment, to verify that it can build the necessary dependencies. This is actually not the case. I executed repeatedly each test works well separately. The problem occurs when there are more and more tests using the same test libs. As stated in the bugs [1] and [2], if there are multi tests using a lib, such as ProcessTools, there could be possible collision occurring on its dependencies. For ProcessTools, StreamPumper (ONLY) will be disappear sometimes. It looks some dependency classes were treated by jtreg as some-how shared, and removed unexpectedly. [1] https://bugs.openjdk.java.net/browse/JDK-8181299 [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986. Thanks, Felix > This may be a straight forward way to identify explicit build dependencies > and avoid the wildcards. > > -Chris. > From igor.ignatyev at oracle.com Thu Jun 1 03:32:26 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 31 May 2017 20:32:26 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: Hi Felix, I have suggested the exact opposite change[1-3] to fix the same problem. [1] https://bugs.openjdk.java.net/browse/JDK-8181391 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html Thanks, -- Igor > On May 31, 2017, at 8:27 PM, Felix Yang wrote: > > Hi Chris and Daniel, > > new webrev with a few of explicit builds than wildcard. > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ > > Thanks, > Felix > On 2017/5/31 18:20, Chris Hegarty wrote: >>> On 31 May 2017, at 10:42, Felix Yang wrote: >>> >>> Hi there, >>> >>> please review the patch to various jdk tests to explicitly compiling test libraries and the lib's dependencies. Though it could be a jtreg issue (I think so), it is necessary to get the tests running firstly. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8181299 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/ >> This may be ok to get the tests running again, but explicit build targets >> would be better. The contents, and module dependencies, from classes >> in the test library are subject to change, so building all classes may >> require more modules than in the @modules tags in the test. > With latest webrev, no new @modules introduced by this change, though I fixed a missing from original tests. > > I prefer to keep "@build jdk.test.lib.process.*" here. Because, with current test lib package layout, "@build jdk.test.lib.process.*" equals with > /@build jdk.test.lib.process.OutputAnalyzer > //jdk.test.lib.process.OutputBuffer > //jdk.test.lib.process.ProcessTools > ////jdk.test.lib.process.//StreamPumper// > ///jdk.test.lib.process.ExitCode/ /" > > It is a bit ugly and not productive, when I only use ProcessTools directly but have to declare a bunch of @builds. That is why I think this is not a fix but a workaround. > > Thanks, > Felix >> >> I agree with Daniel, each test should be run separately in a clean >> environment, to verify that it can build the necessary dependencies. > This is actually not the case. I executed repeatedly each test works well separately. The problem occurs when there are more and more tests using the same test libs. > > As stated in the bugs [1] and [2], if there are multi tests using a lib, such as ProcessTools, there could be possible collision occurring on its dependencies. > For ProcessTools, StreamPumper (ONLY) will be disappear sometimes. It looks some dependency classes were treated by jtreg as some-how shared, and removed unexpectedly. > > [1] https://bugs.openjdk.java.net/browse/JDK-8181299 > [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 . > > Thanks, > Felix >> This may be a straight forward way to identify explicit build dependencies >> and avoid the wildcards. >> >> -Chris. From vyom.tewari at oracle.com Thu Jun 1 04:15:08 2017 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Thu, 1 Jun 2017 09:45:08 +0530 Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds In-Reply-To: References: Message-ID: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> Hi Thomas, one minor comment apart from what Christoph gave, you can combine the the two explicit assignment statements to one in all three places. rv = (jlong)sb.st_mtimespec.tv_sec * 1000; rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; to rv= (jlong)sb.st_mtimespec.tv_sec * 1000 +(jlong)sb.st_mtimespec.tv_nsec / 1000000; Thanks, Vyom On Wednesday 31 May 2017 08:59 PM, Thomas St?fe wrote: > Hi Volker, > > Good suggestions! I completely overlooked the ..._n members in stat64 > struct. It seems it is even documented: > https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/stat.h.htm > > new webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.01/webrev/ > > ..Thomas > > On Wed, May 31, 2017 at 10:49 AM, Volker Simonis > wrote: > >> Hi Thomas, >> >> as far as I can see, AIX supports both, the st_[a,c,m]time members in >> the stat64 structure for seconds and the corresponding >> st_[a,c,m]time_n members for nanosecond resolution since at least 5.3. >> Can you please use both - there's no reason to discriminate AIX here >> :) >> >> Also, can you please change the code such that we have: >> >> #ifdef MACOSX >> ... >> #else >> #ifdef AIX >> ... >> #else >> ... >> #endif >> #endif >> >> I don't really like using "ifndef XXX" for everything else except XXX. >> >> Thnank you and best regards, >> Volker >> >> >> On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe >> wrote: >>> Hi all, >>> >>> may I have please a review for this tiny change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207 >>> webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8181207- >> 8177809-breaks-AIX-builds/webrev.00/webrev/ >>> This reverts 8177809 for AIX because it leads to build errors on older >> AIX >>> systems. We want to retain the ability to build on older AIX releases. >>> >>> Thanks, Thomas From felix.yang at oracle.com Thu Jun 1 04:49:03 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Jun 2017 12:49:03 +0800 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: <69795fc1-77a9-6ad4-bfb2-83f69a494549@oracle.com> Hi Igor, just noticed your change. It is indeed necessary to clarify what is the best practice here. Thanks, Felix On 2017/6/1 11:32, Igor Ignatyev wrote: > Hi Felix, > > I have suggested the exact opposite change[1-3] to fix the same problem. > > [1] https://bugs.openjdk.java.net/browse/JDK-8181391 > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html > [3] > http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html > > > Thanks, > -- Igor >> On May 31, 2017, at 8:27 PM, Felix Yang > > wrote: >> >> Hi Chris and Daniel, >> >> new webrev with a few of explicit builds than wildcard. >> >> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ >> >> >> Thanks, >> Felix >> On 2017/5/31 18:20, Chris Hegarty wrote: >>>> On 31 May 2017, at 10:42, Felix Yang >>> > wrote: >>>> >>>> Hi there, >>>> >>>> please review the patch to various jdk tests to explicitly >>>> compiling test libraries and the lib's dependencies. Though it >>>> could be a jtreg issue (I think so), it is necessary to get the >>>> tests running firstly. >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8181299 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/ >>>> >>> This may be ok to get the tests running again, but explicit build >>> targets >>> would be better. The contents, and module dependencies, from classes >>> in the test library are subject to change, so building all classes may >>> require more modules than in the @modules tags in the test. >> With latest webrev, no new @modules introduced by this change, though >> I fixed a missing from original tests. >> >> I prefer to keep "@build jdk.test.lib.process.*" here. Because, with >> current test lib package layout, "@build jdk.test.lib.process.*" >> equals with >> /@build jdk.test.lib.process.OutputAnalyzer >> //jdk.test.lib.process.OutputBuffer >> //jdk.test.lib.process.ProcessTools >> ////jdk.test.lib.process.//StreamPumper// >> ///jdk.test.lib.process.ExitCode/ /" >> >> It is a bit ugly and not productive, when I only use ProcessTools >> directly but have to declare a bunch of @builds. That is why I think >> this is not a fix but a workaround. >> >> Thanks, >> Felix >>> >>> I agree with Daniel, each test should be run separately in a clean >>> environment, to verify that it can build the necessary dependencies. >> This is actually not the case. I executed repeatedly each test works >> well separately. The problem occurs when there are more and more >> tests using the same test libs. >> >> As stated in the bugs [1] and [2], if there are multi tests using a >> lib, such as ProcessTools, there could be possible collision >> occurring on its dependencies. >> For ProcessTools, StreamPumper (ONLY) will be disappear sometimes. It >> looks some dependency classes were treated by jtreg as some-how >> shared, and removed unexpectedly. >> >> [1]https://bugs.openjdk.java.net/browse/JDK-8181299 >> [2]https://bugs.openjdk.java.net/browse/CODETOOLS-7901986. >> >> Thanks, >> Felix >>> This may be a straight forward way to identify explicit build >>> dependencies >>> and avoid the wildcards. >>> >>> -Chris. > From thomas.stuefe at gmail.com Thu Jun 1 06:13:05 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jun 2017 08:13:05 +0200 Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds In-Reply-To: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> References: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> Message-ID: Okay, last webrev, added Christoph' suggestions of reformulating the #ifdef chain. http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.02/webrev/ @Vyom: I'd rather keep the expression like it is to match the other platforms. Guys, lets get this in, this is a simple build fix :) On Thu, Jun 1, 2017 at 6:15 AM, Vyom Tewari wrote: > Hi Thomas, > > one minor comment apart from what Christoph gave, you can combine the the > two explicit assignment statements to one in all three places. > > rv = (jlong)sb.st_mtimespec.tv_sec * 1000; > > rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; > > to > rv= (jlong)sb.st_mtimespec.tv_sec * 1000 + (jlong)sb.st_mtimespec.tv_nsec / 1000000; > > Thanks, > Vyom > > > On Wednesday 31 May 2017 08:59 PM, Thomas St?fe wrote: > > Hi Volker, > > Good suggestions! I completely overlooked the ..._n members in stat64 > struct. It seems it is even documented:https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/stat.h.htm > > new webrev:http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.01/webrev/ > > ..Thomas > > On Wed, May 31, 2017 at 10:49 AM, Volker Simonis > wrote: > > > Hi Thomas, > > as far as I can see, AIX supports both, the st_[a,c,m]time members in > the stat64 structure for seconds and the corresponding > st_[a,c,m]time_n members for nanosecond resolution since at least 5.3. > Can you please use both - there's no reason to discriminate AIX here > :) > > Also, can you please change the code such that we have: > > #ifdef MACOSX > ... > #else > #ifdef AIX > ... > #else > ... > #endif > #endif > > I don't really like using "ifndef XXX" for everything else except XXX. > > Thnank you and best regards, > Volker > > > On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe > wrote: > > Hi all, > > may I have please a review for this tiny change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181207 > webrev:http://cr.openjdk.java.net/~stuefe/webrevs/8181207- > > 8177809-breaks-AIX-builds/webrev.00/webrev/ > > This reverts 8177809 for AIX because it leads to build errors on older > > AIX > > systems. We want to retain the ability to build on older AIX releases. > > Thanks, Thomas > > > From Alan.Bateman at oracle.com Thu Jun 1 06:18:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Jun 2017 07:18:06 +0100 Subject: RFR(S) : 8181391: remove explicit @build actions for the top level testlibary classes In-Reply-To: References: Message-ID: <35052edf-a1cb-90a1-81bc-ea4043045dfa@oracle.com> The library tests have been running in agentvm mode and with concurrency for several years and the intermittent CNFE/NCDFE issues have always been worked around by avoiding implicit compilation. There seems to be several more intermittent failures in jdk10/jdk10 compared to jdk9/dev with tests that have been changed to revert to implicit compilation. So I agree with Martin that Jon Gibbons (with his jtreg hat on) is the right person to comment on this. If the issue is really CODETOOLS-7901986 (and Ioi's analysis looks good) then I think we need to get that into a jtreg build before changing lots of tests to not explicitly compile the test infrastructure that they use. -Alan On 01/06/2017 04:04, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html >> 55 lines changed: 1 ins; 50 del; 4 mod; > Hi all, > > due to CODETOOLS-7901986[1], tests sporadically fail w/ CNFE or NCDFE, having explicit build actions has been proven to contribute into this[1-2]. this fix removes explicit @build actions for classes from jdk.test.lib.* packages (the top level testlibrary). > > webrev: http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8181391 > testing: changed tests > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 > [2] https://bugs.openjdk.java.net/browse/JDK-8157957 > [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198.html > > Thanks, > -- Igor From amy.lu at oracle.com Thu Jun 1 06:45:40 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 1 Jun 2017 14:45:40 +0800 Subject: JDK 10 RFR of JDK-8181393: Refactor shell test Selector/lots_of_updates.sh and SocketChannel/Open.sh to java Message-ID: java/nio/channels/Selector/lots_of_updates.sh java/nio/channels/SocketChannel/Open.java which runs shell test: * @run shell Open.sh Please review this patch to refactor above shell tests to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181393 webrev: http://cr.openjdk.java.net/~amlu/8181393/webrev.00/ Thanks, Amy From volker.simonis at gmail.com Thu Jun 1 06:47:45 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 1 Jun 2017 08:47:45 +0200 Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds In-Reply-To: References: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> Message-ID: Hi Thomas, the change looks good now. I think the comment about "AIX 5.3 backward compatibility" isn't strictly needed, but I leave it up to you (anyhow you decide, there's no need for a new webrev). Feel free to push it. Thanks, Volker On Thu, Jun 1, 2017 at 8:13 AM, Thomas St?fe wrote: > Okay, last webrev, added Christoph' suggestions of reformulating the #ifdef > chain. > > http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.02/webrev/ > > @Vyom: I'd rather keep the expression like it is to match the other > platforms. > > Guys, lets get this in, this is a simple build fix :) > > On Thu, Jun 1, 2017 at 6:15 AM, Vyom Tewari wrote: >> >> Hi Thomas, >> >> one minor comment apart from what Christoph gave, you can combine the the >> two explicit assignment statements to one in all three places. >> >> rv = (jlong)sb.st_mtimespec.tv_sec * 1000; >> >> rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; >> >> to >> rv= (jlong)sb.st_mtimespec.tv_sec * 1000 + (jlong)sb.st_mtimespec.tv_nsec >> / 1000000; >> >> Thanks, >> Vyom >> >> >> On Wednesday 31 May 2017 08:59 PM, Thomas St?fe wrote: >> >> Hi Volker, >> >> Good suggestions! I completely overlooked the ..._n members in stat64 >> struct. It seems it is even documented: >> >> https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/stat.h.htm >> >> new webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.01/webrev/ >> >> ..Thomas >> >> On Wed, May 31, 2017 at 10:49 AM, Volker Simonis >> >> wrote: >> >> Hi Thomas, >> >> as far as I can see, AIX supports both, the st_[a,c,m]time members in >> the stat64 structure for seconds and the corresponding >> st_[a,c,m]time_n members for nanosecond resolution since at least 5.3. >> Can you please use both - there's no reason to discriminate AIX here >> :) >> >> Also, can you please change the code such that we have: >> >> #ifdef MACOSX >> ... >> #else >> #ifdef AIX >> ... >> #else >> ... >> #endif >> #endif >> >> I don't really like using "ifndef XXX" for everything else except XXX. >> >> Thnank you and best regards, >> Volker >> >> >> On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe >> wrote: >> >> Hi all, >> >> may I have please a review for this tiny change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8181207- >> >> 8177809-breaks-AIX-builds/webrev.00/webrev/ >> >> This reverts 8177809 for AIX because it leads to build errors on older >> >> AIX >> >> systems. We want to retain the ability to build on older AIX releases. >> >> Thanks, Thomas >> >> > From thomas.stuefe at gmail.com Thu Jun 1 06:50:19 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jun 2017 08:50:19 +0200 Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds In-Reply-To: References: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> Message-ID: Thank you Volker! On Thu, Jun 1, 2017 at 8:47 AM, Volker Simonis wrote: > Hi Thomas, > > the change looks good now. I think the comment about "AIX 5.3 backward > compatibility" isn't strictly needed, but I leave it up to you (anyhow > you decide, there's no need for a new webrev). Feel free to push it. > > Thanks, > Volker > > > On Thu, Jun 1, 2017 at 8:13 AM, Thomas St?fe > wrote: > > Okay, last webrev, added Christoph' suggestions of reformulating the > #ifdef > > chain. > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8181207- > 8177809-breaks-AIX-builds/webrev.02/webrev/ > > > > @Vyom: I'd rather keep the expression like it is to match the other > > platforms. > > > > Guys, lets get this in, this is a simple build fix :) > > > > On Thu, Jun 1, 2017 at 6:15 AM, Vyom Tewari > wrote: > >> > >> Hi Thomas, > >> > >> one minor comment apart from what Christoph gave, you can combine the > the > >> two explicit assignment statements to one in all three places. > >> > >> rv = (jlong)sb.st_mtimespec.tv_sec * 1000; > >> > >> rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; > >> > >> to > >> rv= (jlong)sb.st_mtimespec.tv_sec * 1000 + > (jlong)sb.st_mtimespec.tv_nsec > >> / 1000000; > >> > >> Thanks, > >> Vyom > >> > >> > >> On Wednesday 31 May 2017 08:59 PM, Thomas St?fe wrote: > >> > >> Hi Volker, > >> > >> Good suggestions! I completely overlooked the ..._n members in stat64 > >> struct. It seems it is even documented: > >> > >> https://www.ibm.com/support/knowledgecenter/ssw_aix_72/ > com.ibm.aix.files/stat.h.htm > >> > >> new webrev: > >> > >> http://cr.openjdk.java.net/~stuefe/webrevs/8181207- > 8177809-breaks-AIX-builds/webrev.01/webrev/ > >> > >> ..Thomas > >> > >> On Wed, May 31, 2017 at 10:49 AM, Volker Simonis > >> > >> wrote: > >> > >> Hi Thomas, > >> > >> as far as I can see, AIX supports both, the st_[a,c,m]time members in > >> the stat64 structure for seconds and the corresponding > >> st_[a,c,m]time_n members for nanosecond resolution since at least 5.3. > >> Can you please use both - there's no reason to discriminate AIX here > >> :) > >> > >> Also, can you please change the code such that we have: > >> > >> #ifdef MACOSX > >> ... > >> #else > >> #ifdef AIX > >> ... > >> #else > >> ... > >> #endif > >> #endif > >> > >> I don't really like using "ifndef XXX" for everything else except XXX. > >> > >> Thnank you and best regards, > >> Volker > >> > >> > >> On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe > > >> wrote: > >> > >> Hi all, > >> > >> may I have please a review for this tiny change: > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207 > >> webrev: > >> http://cr.openjdk.java.net/~stuefe/webrevs/8181207- > >> > >> 8177809-breaks-AIX-builds/webrev.00/webrev/ > >> > >> This reverts 8177809 for AIX because it leads to build errors on older > >> > >> AIX > >> > >> systems. We want to retain the ability to build on older AIX releases. > >> > >> Thanks, Thomas > >> > >> > > > From felix.yang at oracle.com Thu Jun 1 07:13:58 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Jun 2017 15:13:58 +0800 Subject: RFR 8181413/10, Refactor test/sun/net/www/protocol/jar/jarbug/run.sh to plain java tests Message-ID: <6e2e1f59-04b7-4d70-f549-44d662d9c938@oracle.com> Hi there, please review the patch to covert a shell test to a plain java test, and simplify a few of unnecessary test logic. Bug: https://bugs.openjdk.java.net/browse/JDK-8181413 Webrev: http://cr.openjdk.java.net/~xiaofeya/8181413/webrev.00/ Thanks, Felix From felix.yang at oracle.com Thu Jun 1 07:39:30 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Jun 2017 15:39:30 +0800 Subject: RFR 8181414/10, Refactor misc test/sun/net/www/protocol/jar shell tests to plain java tests Message-ID: Hi there, please review the patch to convert several shell tests to plain java tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8181414 Webrev: http://cr.openjdk.java.net/~xiaofeya/8181414/webrev.00/ Thanks, Felix From chris.hegarty at oracle.com Thu Jun 1 08:20:07 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 Jun 2017 09:20:07 +0100 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: Igor, > On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: > > Hi Felix, > > I have suggested the exact opposite change[1-3] to fix the same problem. I?m sorry, but this is all just too confusing. After your change, who, or what, is responsible for building/compiling the test library dependencies? Test library code has no @modules tags, so does not explicitly declare its module dependencies. Instead module dependencies, required by test library code, are declared in the test using the library. If we wildcard, or otherwise leave broad build dependencies, from tests then there is no way to know what new module dependencies may be added in the future. That is, one of, the reason(s) I asked Felix to be explicit about the build dependencies. -Chris. > [1] https://bugs.openjdk.java.net/browse/JDK-8181391 > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html > [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html From huaming.li at oracle.com Thu Jun 1 08:22:21 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 1 Jun 2017 16:22:21 +0800 Subject: (10) RFR of JDK-8180927: refactor ./java/io/Serializable/class/run.sh to java test Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8180927 webrev: http://cr.openjdk.java.net/~mli/8180927/webrev.00/ Thank you -Hamlin From felix.yang at oracle.com Thu Jun 1 08:32:31 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Jun 2017 16:32:31 +0800 Subject: RFR 8181080/10, Refactor several sun/net shell tests to plain java tests Message-ID: <9c42dccf-df3f-94fa-e680-55b6a5ab4a32@oracle.com> Hi there, please review the patch convert several sun/net shell tests to plain java tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8181080 Webrev: http://cr.openjdk.java.net/~xiaofeya/8181080/webrev.00/ Thanks, Felix From daniel.fuchs at oracle.com Thu Jun 1 08:56:09 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 1 Jun 2017 09:56:09 +0100 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: Hi Felix, This looks much better to me. Thanks! -- daniel On 01/06/2017 04:27, Felix Yang wrote: > Hi Chris and Daniel, > > new webrev with a few of explicit builds than wildcard. > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ > > Thanks, > Felix > On 2017/5/31 18:20, Chris Hegarty wrote: >>> On 31 May 2017, at 10:42, Felix Yang wrote: >>> >>> Hi there, >>> >>> please review the patch to various jdk tests to explicitly compiling test libraries and the lib's dependencies. Though it could be a jtreg issue (I think so), it is necessary to get the tests running firstly. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8181299 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/ >> This may be ok to get the tests running again, but explicit build targets >> would be better. The contents, and module dependencies, from classes >> in the test library are subject to change, so building all classes may >> require more modules than in the @modules tags in the test. > With latest webrev, no new @modules introduced by this change, though I > fixed a missing from original tests. > > I prefer to keep "@build jdk.test.lib.process.*" here. Because, with > current test lib package layout, "@build jdk.test.lib.process.*" equals > with > /@build jdk.test.lib.process.OutputAnalyzer > //jdk.test.lib.process.OutputBuffer > //jdk.test.lib.process.ProcessTools > ////jdk.test.lib.process.//StreamPumper// > ///jdk.test.lib.process.ExitCode/ /" > > It is a bit ugly and not productive, when I only use ProcessTools > directly but have to declare a bunch of @builds. That is why I think > this is not a fix but a workaround. > > Thanks, > Felix >> >> I agree with Daniel, each test should be run separately in a clean >> environment, to verify that it can build the necessary dependencies. > This is actually not the case. I executed repeatedly each test works > well separately. The problem occurs when there are more and more tests > using the same test libs. > > As stated in the bugs [1] and [2], if there are multi tests using a lib, > such as ProcessTools, there could be possible collision occurring on its > dependencies. > For ProcessTools, StreamPumper (ONLY) will be disappear sometimes. It > looks some dependency classes were treated by jtreg as some-how shared, > and removed unexpectedly. > > [1] https://bugs.openjdk.java.net/browse/JDK-8181299 > [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986. > > Thanks, > Felix >> This may be a straight forward way to identify explicit build dependencies >> and avoid the wildcards. >> >> -Chris. >> > From chris.hegarty at oracle.com Thu Jun 1 09:11:45 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 Jun 2017 10:11:45 +0100 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: <7927ADA3-303F-4E8E-9DCF-812CEBCED6E3@oracle.com> > On 1 Jun 2017, at 04:27, Felix Yang wrote: > > Hi Chris and Daniel, > > new webrev with a few of explicit builds than wildcard. > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ This seems very odd to me: http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/test/sun/security/tools/jarsigner/AltProvider.java.sdiff.html The test is using jdk.test.lib.util.JarUtils ( which comes from the top-level test library ), but the @build specifies the JarUtils ( in the unnamed package ) from the jdk test library. Also, shouldn?t it use jdk.test.lib.compiler.CompilerUtils, rather than CompilerUtils? -Chris. From thomas.stuefe at gmail.com Thu Jun 1 09:20:32 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jun 2017 11:20:32 +0200 Subject: asserts in jdk coding (outside hotspot) Message-ID: Hi all, so, we have the hotspot asserts with all the niceties of our error reporting. But these asserts are only accessible from within hotspot coding. In the JDK, in a number of places, I see that we use the standard posix assert()( http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html). This means that when we trigger the assert, we will only get a brief message on stderr and a core, but no hs_err file. It also means that -XX:+CreateCoredumpOnCrash is ignored, so it is not possible to switch off those core dumps. This is unfortunate and also easy to fix. We do not even have to call into the hotspot to get hotspot asserts. We could just force a NULL pointer access or send ourselves a SIGILL or something. Anything which triggers the hotspot signal handling would be fine. What do you think? Kind Regards, Thomas From christoph.langer at sap.com Thu Jun 1 09:39:46 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Jun 2017 09:39:46 +0000 Subject: JDK 10 RFR 8181417: Code cleanups in com.sun.jdi Message-ID: Hi, during integration work of the jdi library for one of our projects I spotted some places where a few cleanups could be done. I'd like to contribute this. It is mostly about import statements and formatting/empty lines. I think at this stage of JDK10 it's a good time for such kind of work. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8181417.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8181417 Thanks and best regards Christoph From felix.yang at oracle.com Thu Jun 1 09:41:26 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Jun 2017 17:41:26 +0800 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <7927ADA3-303F-4E8E-9DCF-812CEBCED6E3@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <7927ADA3-303F-4E8E-9DCF-812CEBCED6E3@oracle.com> Message-ID: Hi Chris, updated webrev: http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ -Felix On 2017/6/1 17:11, Chris Hegarty wrote: >> On 1 Jun 2017, at 04:27, Felix Yang wrote: >> >> Hi Chris and Daniel, >> >> new webrev with a few of explicit builds than wildcard. >> >> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ > This seems very odd to me: > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/test/sun/security/tools/jarsigner/AltProvider.java.sdiff.html > > The test is using jdk.test.lib.util.JarUtils ( which comes from the > top-level test library ), but the @build specifies the JarUtils ( in > the unnamed package ) from the jdk test library. Fixed > Also, shouldn?t it use jdk.test.lib.compiler.CompilerUtils, rather than > CompilerUtils? Ok, refactored the test to use new CompilerUtils and then not referring /lib/testlibrary any more. I didn't touch other tests usage on CompilerUtils, because Igor has a single purpose task to unify the test libs. It will complicate his clean-up work. -Felix > > -Chris. From amy.lu at oracle.com Thu Jun 1 10:22:48 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 1 Jun 2017 18:22:48 +0800 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java Message-ID: java/nio/file/Files/walkFileTree/find.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181394 webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.00/ (I'll add @build jdk.test.lib.process.* if this is the "best" workaround of CODETOOLS-7901986) Thanks, Amy From Alan.Bateman at oracle.com Thu Jun 1 10:51:36 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Jun 2017 11:51:36 +0100 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java In-Reply-To: References: Message-ID: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> On 01/06/2017 11:22, Amy Lu wrote: > java/nio/file/Files/walkFileTree/find.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181394 > webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.00/ > > (I'll add @build jdk.test.lib.process.* if this is the "best" > workaround of CODETOOLS-7901986) I think it would be cleaner if you merged FindTest, CreateFileTree and PrintFileTree. That should eliminate the need to launch PrintFileTree in its own VM, it would make the test setup simpler too. Also it would be nice to avoid SerializationUtils too. -Alan From david.holmes at oracle.com Thu Jun 1 12:09:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Jun 2017 22:09:41 +1000 Subject: asserts in jdk coding (outside hotspot) In-Reply-To: References: Message-ID: <703c39a1-2cf1-24f3-2089-53faf0d87f64@oracle.com> Hi Thomas, On 1/06/2017 7:20 PM, Thomas St?fe wrote: > Hi all, > > so, we have the hotspot asserts with all the niceties of our error > reporting. But these asserts are only accessible from within hotspot coding. > > In the JDK, in a number of places, I see that we use the standard posix > assert()( > http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html). > > This means that when we trigger the assert, we will only get a brief > message on stderr and a core, but no hs_err file. > > It also means that -XX:+CreateCoredumpOnCrash is ignored, so it is not > possible to switch off those core dumps. > > This is unfortunate and also easy to fix. We do not even have to call into > the hotspot to get hotspot asserts. We could just force a NULL pointer > access or send ourselves a SIGILL or something. Anything which triggers the > hotspot signal handling would be fine. > > What do you think? Sending ourselves a fatal signal doesn't indicate what assertion failed. The error handler won't know it was an assert, just a SEGV or SIGILL ?? David > Kind Regards, Thomas > From thomas.stuefe at gmail.com Thu Jun 1 12:26:39 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jun 2017 14:26:39 +0200 Subject: asserts in jdk coding (outside hotspot) In-Reply-To: <703c39a1-2cf1-24f3-2089-53faf0d87f64@oracle.com> References: <703c39a1-2cf1-24f3-2089-53faf0d87f64@oracle.com> Message-ID: Hi David, On Thu, Jun 1, 2017 at 2:09 PM, David Holmes wrote: > Hi Thomas, > > On 1/06/2017 7:20 PM, Thomas St?fe wrote: > >> Hi all, >> >> so, we have the hotspot asserts with all the niceties of our error >> reporting. But these asserts are only accessible from within hotspot >> coding. >> >> In the JDK, in a number of places, I see that we use the standard posix >> assert()( >> http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html). >> >> This means that when we trigger the assert, we will only get a brief >> message on stderr and a core, but no hs_err file. >> >> It also means that -XX:+CreateCoredumpOnCrash is ignored, so it is not >> possible to switch off those core dumps. >> >> This is unfortunate and also easy to fix. We do not even have to call into >> the hotspot to get hotspot asserts. We could just force a NULL pointer >> access or send ourselves a SIGILL or something. Anything which triggers >> the >> hotspot signal handling would be fine. >> >> What do you think? >> > > Sending ourselves a fatal signal doesn't indicate what assertion failed. > The error handler won't know it was an assert, just a SEGV or SIGILL > > ?? > > David > Sure. But in many cases this still would be preferable to just a core. We'd get a hs-err file - admittedly with a Segv instead of an assert message - but we have a callstack and could deduce the error from there. I am not saying that this is an ideal solution. Of course, a really good solution may invoke the real hotspot assert or one might come up with a way to transfer assert information (message, file, line etc) to the hotspot error handler. E.g. store the assert message in a globally visible char array one could resolve via dlsym to avoid having to add link dependencies. ..Thomas > > Kind Regards, Thomas >> >> From thomas.stuefe at gmail.com Thu Jun 1 12:37:33 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jun 2017 14:37:33 +0200 Subject: JDK 10 RFR 8181417: Code cleanups in com.sun.jdi In-Reply-To: References: Message-ID: Hi Christoph, l Copyright years need adjusting in a large number of files. Otherwise looks ok. ..Thomas On Thu, Jun 1, 2017 at 11:39 AM, Langer, Christoph wrote: > Hi, > > during integration work of the jdi library for one of our projects I > spotted some places where a few cleanups could be done. I'd like to > contribute this. It is mostly about import statements and formatting/empty > lines. I think at this stage of JDK10 it's a good time for such kind of > work. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8181417.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8181417 > > Thanks and best regards > Christoph > > From Roger.Riggs at Oracle.com Thu Jun 1 13:06:49 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Jun 2017 09:06:49 -0400 Subject: asserts in jdk coding (outside hotspot) In-Reply-To: References: <703c39a1-2cf1-24f3-2089-53faf0d87f64@oracle.com> Message-ID: <629f3e54-b2b1-cdb1-bef1-921c16c51cf2@Oracle.com> Hi, Is there a clean way for hotspot to export the assert mechanism so it can be called from the C based native JDK libraries? Thanks, Roger On 6/1/2017 8:26 AM, Thomas St?fe wrote: > Hi David, > > On Thu, Jun 1, 2017 at 2:09 PM, David Holmes > wrote: > >> Hi Thomas, >> >> On 1/06/2017 7:20 PM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> so, we have the hotspot asserts with all the niceties of our error >>> reporting. But these asserts are only accessible from within hotspot >>> coding. >>> >>> In the JDK, in a number of places, I see that we use the standard posix >>> assert()( >>> http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html). >>> >>> This means that when we trigger the assert, we will only get a brief >>> message on stderr and a core, but no hs_err file. >>> >>> It also means that -XX:+CreateCoredumpOnCrash is ignored, so it is not >>> possible to switch off those core dumps. >>> >>> This is unfortunate and also easy to fix. We do not even have to call into >>> the hotspot to get hotspot asserts. We could just force a NULL pointer >>> access or send ourselves a SIGILL or something. Anything which triggers >>> the >>> hotspot signal handling would be fine. >>> >>> What do you think? >>> >> Sending ourselves a fatal signal doesn't indicate what assertion failed. >> The error handler won't know it was an assert, just a SEGV or SIGILL >> >> ?? >> >> David >> > Sure. But in many cases this still would be preferable to just a core. We'd > get a hs-err file - admittedly with a Segv instead of an assert message - > but we have a callstack and could deduce the error from there. > > I am not saying that this is an ideal solution. Of course, a really good > solution may invoke the real hotspot assert or one might come up with a way > to transfer assert information (message, file, line etc) to the hotspot > error handler. E.g. store the assert message in a globally visible char > array one could resolve via dlsym to avoid having to add link dependencies. > > > ..Thomas > > >> Kind Regards, Thomas >>> From thomas.stuefe at gmail.com Thu Jun 1 13:27:03 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jun 2017 15:27:03 +0200 Subject: asserts in jdk coding (outside hotspot) In-Reply-To: <629f3e54-b2b1-cdb1-bef1-921c16c51cf2@Oracle.com> References: <703c39a1-2cf1-24f3-2089-53faf0d87f64@oracle.com> <629f3e54-b2b1-cdb1-bef1-921c16c51cf2@Oracle.com> Message-ID: Hi Roger, On Thu, Jun 1, 2017 at 3:06 PM, Roger Riggs wrote: > Hi, > > Is there a clean way for hotspot to export the assert mechanism so it can > be called from > the C based native JDK libraries? > > Thanks, Roger > > It would be no problem to export a C stub which calls the error handler. And maybe wrap it with a macro which evolves to nothing in NDEBUG builds. The real problem is that this would mean you would have to link to the hotspot in a number of places, and that is very inconvenient. We (SAP) actually do this a lot, because we redirect a lot of functionality from the JDK into the hotspot (e.g. tracing or malloc tracking). But this is always a pain, you have to maintain make files and add -Ljvm to a number of places, and you create new dependencies. Hence my "lets just crash" idea David disliked :) Thomas > > > On 6/1/2017 8:26 AM, Thomas St?fe wrote: > >> Hi David, >> >> On Thu, Jun 1, 2017 at 2:09 PM, David Holmes >> wrote: >> >> Hi Thomas, >>> >>> On 1/06/2017 7:20 PM, Thomas St?fe wrote: >>> >>> Hi all, >>>> >>>> so, we have the hotspot asserts with all the niceties of our error >>>> reporting. But these asserts are only accessible from within hotspot >>>> coding. >>>> >>>> In the JDK, in a number of places, I see that we use the standard posix >>>> assert()( >>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html). >>>> >>>> This means that when we trigger the assert, we will only get a brief >>>> message on stderr and a core, but no hs_err file. >>>> >>>> It also means that -XX:+CreateCoredumpOnCrash is ignored, so it is not >>>> possible to switch off those core dumps. >>>> >>>> This is unfortunate and also easy to fix. We do not even have to call >>>> into >>>> the hotspot to get hotspot asserts. We could just force a NULL pointer >>>> access or send ourselves a SIGILL or something. Anything which triggers >>>> the >>>> hotspot signal handling would be fine. >>>> >>>> What do you think? >>>> >>>> Sending ourselves a fatal signal doesn't indicate what assertion failed. >>> The error handler won't know it was an assert, just a SEGV or SIGILL >>> >>> ?? >>> >>> David >>> >>> Sure. But in many cases this still would be preferable to just a core. >> We'd >> get a hs-err file - admittedly with a Segv instead of an assert message - >> but we have a callstack and could deduce the error from there. >> >> I am not saying that this is an ideal solution. Of course, a really good >> solution may invoke the real hotspot assert or one might come up with a >> way >> to transfer assert information (message, file, line etc) to the hotspot >> error handler. E.g. store the assert message in a globally visible char >> array one could resolve via dlsym to avoid having to add link >> dependencies. >> >> >> ..Thomas >> >> >> Kind Regards, Thomas >>> >>>> >>>> > From chris.hegarty at oracle.com Thu Jun 1 15:53:02 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 Jun 2017 16:53:02 +0100 Subject: RFR: JDK-8176784 - Amend HREF to technote/guides in CORBA API docs to unilinks for guides In-Reply-To: <0f827c59-8b9a-9351-bd74-35b93a4e51cb@oracle.com> References: <0f827c59-8b9a-9351-bd74-35b93a4e51cb@oracle.com> Message-ID: > On 31 May 2017, at 17:43, Mark Sheppard wrote: > > Hi, > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8176784-IV/webrev.02/ Looks good to me Mark. -Chris. From Roger.Riggs at Oracle.com Thu Jun 1 15:55:33 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Jun 2017 11:55:33 -0400 Subject: RFR: JDK-8176784 - Amend HREF to technote/guides in CORBA API docs to unilinks for guides In-Reply-To: References: <0f827c59-8b9a-9351-bd74-35b93a4e51cb@oracle.com> Message-ID: +1 On 6/1/2017 11:53 AM, Chris Hegarty wrote: >> On 31 May 2017, at 17:43, Mark Sheppard wrote: >> >> Hi, >> please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8176784-IV/webrev.02/ > Looks good to me Mark. > > -Chris. > From Paul.Sandoz at oracle.com Thu Jun 1 15:56:32 2017 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Jun 2017 08:56:32 -0700 Subject: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9 Message-ID: <75E82CFC-EC08-4FDA-AFE0-B7572D0AAB25@oracle.com> Hi, To make it easier on 166 and Graal code to support both 9 and 10 we should back port the renaming of the internal Unsafe.compareAndSwap to Unsafe.compareAndSet: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-hotspot/webrev/ This is an explicit back port with a new bug. This is the easiest approach given the current nature of how 9 and 10 are currently kept in sync. The change sets are the same as those associated with the following issues and apply cleanly without modification: Rename internal Unsafe.compare methods https://bugs.openjdk.java.net/browse/JDK-8159995 [TESTBUG] Some hotspot tests broken after internal Unsafe name changes https://bugs.openjdk.java.net/browse/JDK-8180479 When running JPRT tests i observe a Graal test error on linux_x64_3.8-fastdebug-c2-hotspot_fast_compiler [*]. I dunno how this is manifesting given i cannot find any explicit reference to jdk.internal.Unsafe.compareAndSwap. Any idea? Paul. [*] [2017-05-31 12:33:08,163] Agent[4]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) [2017-05-31 12:33:08,163] Agent[4]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) [2017-05-31 12:33:08,213] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.callerNative()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.callerNative(InvokeInterface.java:82) [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.(InvokeInterface.java:31) [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.main([Ljava/lang/String;)V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.main(InvokeInterface.java:35) [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.callee(IJFDLjava/lang/String;)Z: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.callee(InvokeInterface.java:60) [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) [2017-05-31 12:33:08,428] Agent[3]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) [2017-05-31 12:33:08,429] Agent[3]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) TEST: compiler/aot/calls/fromAot/AotInvokeInterface2AotTest.java TEST JDK: /opt/jprt/T/P1/191630.sandoz/testproduct/linux_x64_3.8-fastdebug From lance.andersen at oracle.com Thu Jun 1 17:34:04 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Jun 2017 13:34:04 -0400 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> Message-ID: Hi Roman, The webrev seems to have gotten moved as I was reviewing it and now it is gone :-) > On May 31, 2017, at 8:06 AM, Roman Grigoriadi wrote: > > Hi, > > New webrev can be found here: > http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ > > Previous review comments have been addressed. > > New changes since last webrev upload: > > Few ?opens xxx to java.xml.bind? in the module-info of java.xml.ws with descriptions of files in java.xml.ws, which calls JAXBContext#newInstance. > > JAXB-API: > - JAXBContext.java - deprecated implementation discovery with jaxb.properties resource. > - ContextFinder when called with String contextPath now tries to resolve jaxb.properties with Class#getResource if ClassLoader#getResource fails due to insufficient openness of jaxb.properties resource package. > - better JAXBException message when package of jaxb classes is not open to java.xml.bind > > JAXB-RI: > - fixed escaping newlines when using bundled jaxws transport. > > SAAJ-RI > - fixed TCK test failures > > JAXWS-RI > - fixed parsing wsdl in secure mode > > We have one JCK runtime test failure, which should be probably fixed in tests, I have created issue for it: https://bugs.openjdk.java.net/browse/JCK-7308397 > > Please review. > > Thanks, > Roman > >> On 8 May 2017, at 22:38, Lance Andersen > wrote: >> >> Hi Roman, >> >> I made a pass through the webrev and have the following feedback: >> >> >> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java and several files - which follow in the webrev, have formatting issues with the newly added @override and existing @overrides and should probably be cleaned up >> >> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java - can 960 -962 be deleted >> >> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - The copyright was reverted. Also what happens to the svn info in this file with the move to github? >> >> src/java.xml.ws/share/classes/javax/xml/soap/package-info.java - I would use ™ for TM >> >> src/java.xml.ws/share/classes/javax/xml/ws/Service.java - See comments starting at 230 seem off >> >> src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java - I would make the comments starting at 139 be consistent with the other comments >> >> src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/*.properties - the copyright date was reverted >> >> src/jdk.xml.bind/share/classes/module-info.java should already be updated in the workspace >> >> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java - The copyright should be updated to 2017 >> >> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java - the copyright was reverted >> >> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java - the copyright was reverted >> >> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java - the copyright was reverted >> >> src/jdk.xml.ws/share/classes/module-info.java - this was already updated in the workspace >> >> src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java - the copyright should only be 2017 >> >> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java. - the copyright should only be 2017 >> >> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/NewmessagesMessages.java - the copyright should only be 2017 >> >> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties - this is in the workspace already >> >> >> >>> On May 3, 2017, at 12:49 PM, Roman Grigoriadi > wrote: >>> >>> Hi, >>> >>> you can find new web rev here: >>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ > >>> >>> Previous review comments are addressed. >>> >>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>> >>> >>> Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example >>> in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties >>> There is: >>> # for JDK integration - include version in source zip >>> jaxb.jdk.version=2.3.0-b170412.1723 >>> >>> We can add another version.properties file with versions of all JAX-* components. We may also change version from 2.3.0-SNAPSHOT to something unique like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. >>> >>> Roman >>> >>> >>>> On 12 Mar 2017, at 16:14, Alan Bateman > wrote: >>>> >>>> >>>> >>>> On 12/03/2017 14:39, Roman Grigoriadi wrote: >>>>> Hi, >>>>> >>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 >>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ >>>>> >>>> I skimmed the changes and have a few comments (I'm sure Lance or someone else will do a more detailed review). >>>> >>>> In JAXBContext then "must be open to the java.xml.bind module" should be "must be open to at least the java.xml.bind module" so as to cover the case that the package is opened unconditionally or to java.xml.bind and other modules. In addition, include "at least" makes it consistent with other wording that we have agreed for other areas. >>>> >>>> In MailcapCommandMap then the following doesn't seem right for the class description: >>>> >>>> 59 * (Where java.home is the value of the "java.home" System property >>>> 60 * and conf is the directory named "conf" if it exists, >>>> 61 * otherwise the directory named "lib"; the "conf" directory was >>>> 62 * introduced in JDK 1.9.) >>>> >>>> It might be simpler to just have javadoc specify that it attepts to locate the `mailcap` file in the Java run-time image and then add an @implNote with the details as to where it looks for specific runtime releases. >>>> >>>> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's use in new code has been discouraged for many years and maybe this could start out using String.split rather than the legacy class. >>>> >>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>> >>>> -Alan >>> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From aleksej.efimov at oracle.com Thu Jun 1 18:06:25 2017 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 1 Jun 2017 19:06:25 +0100 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> Message-ID: <3914a110-e59a-8eaa-7058-8619e989ed56@oracle.com> I'm sorry Lance! I'm uploading new version of the webrev right now to the same location :-) It should be on-line soon =) Best, Aleksei On 06/01/2017 06:34 PM, Lance Andersen wrote: > Hi Roman, > > The webrev seems to have gotten moved as I was reviewing it and now it is gone :-) > >> On May 31, 2017, at 8:06 AM, Roman Grigoriadi wrote: >> >> Hi, >> >> New webrev can be found here: >> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ >> >> Previous review comments have been addressed. >> >> New changes since last webrev upload: >> >> Few ?opens xxx to java.xml.bind? in the module-info of java.xml.ws with descriptions of files in java.xml.ws, which calls JAXBContext#newInstance. >> >> JAXB-API: >> - JAXBContext.java - deprecated implementation discovery with jaxb.properties resource. >> - ContextFinder when called with String contextPath now tries to resolve jaxb.properties with Class#getResource if ClassLoader#getResource fails due to insufficient openness of jaxb.properties resource package. >> - better JAXBException message when package of jaxb classes is not open to java.xml.bind >> >> JAXB-RI: >> - fixed escaping newlines when using bundled jaxws transport. >> >> SAAJ-RI >> - fixed TCK test failures >> >> JAXWS-RI >> - fixed parsing wsdl in secure mode >> >> We have one JCK runtime test failure, which should be probably fixed in tests, I have created issue for it: https://bugs.openjdk.java.net/browse/JCK-7308397 >> >> Please review. >> >> Thanks, >> Roman >> >>> On 8 May 2017, at 22:38, Lance Andersen > wrote: >>> >>> Hi Roman, >>> >>> I made a pass through the webrev and have the following feedback: >>> >>> >>> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java and several files - which follow in the webrev, have formatting issues with the newly added @override and existing @overrides and should probably be cleaned up >>> >>> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java - can 960 -962 be deleted >>> >>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - The copyright was reverted. Also what happens to the svn info in this file with the move to github? >>> >>> src/java.xml.ws/share/classes/javax/xml/soap/package-info.java - I would use ™ for TM >>> >>> src/java.xml.ws/share/classes/javax/xml/ws/Service.java - See comments starting at 230 seem off >>> >>> src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java - I would make the comments starting at 139 be consistent with the other comments >>> >>> src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/*.properties - the copyright date was reverted >>> >>> src/jdk.xml.bind/share/classes/module-info.java should already be updated in the workspace >>> >>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java - The copyright should be updated to 2017 >>> >>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java - the copyright was reverted >>> >>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java - the copyright was reverted >>> >>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java - the copyright was reverted >>> >>> src/jdk.xml.ws/share/classes/module-info.java - this was already updated in the workspace >>> >>> src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java - the copyright should only be 2017 >>> >>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java. - the copyright should only be 2017 >>> >>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/NewmessagesMessages.java - the copyright should only be 2017 >>> >>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties - this is in the workspace already >>> >>> >>> >>>> On May 3, 2017, at 12:49 PM, Roman Grigoriadi > wrote: >>>> >>>> Hi, >>>> >>>> you can find new web rev here: >>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ > >>>> >>>> Previous review comments are addressed. >>>> >>>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>> >>>> Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example >>>> in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties >>>> There is: >>>> # for JDK integration - include version in source zip >>>> jaxb.jdk.version=2.3.0-b170412.1723 >>>> >>>> We can add another version.properties file with versions of all JAX-* components. We may also change version from 2.3.0-SNAPSHOT to something unique like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. >>>> >>>> Roman >>>> >>>> >>>>> On 12 Mar 2017, at 16:14, Alan Bateman > wrote: >>>>> >>>>> >>>>> >>>>> On 12/03/2017 14:39, Roman Grigoriadi wrote: >>>>>> Hi, >>>>>> >>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 >>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ >>>>>> >>>>> I skimmed the changes and have a few comments (I'm sure Lance or someone else will do a more detailed review). >>>>> >>>>> In JAXBContext then "must be open to the java.xml.bind module" should be "must be open to at least the java.xml.bind module" so as to cover the case that the package is opened unconditionally or to java.xml.bind and other modules. In addition, include "at least" makes it consistent with other wording that we have agreed for other areas. >>>>> >>>>> In MailcapCommandMap then the following doesn't seem right for the class description: >>>>> >>>>> 59 * (Where java.home is the value of the "java.home" System property >>>>> 60 * and conf is the directory named "conf" if it exists, >>>>> 61 * otherwise the directory named "lib"; the "conf" directory was >>>>> 62 * introduced in JDK 1.9.) >>>>> >>>>> It might be simpler to just have javadoc specify that it attepts to locate the `mailcap` file in the Java run-time image and then add an @implNote with the details as to where it looks for specific runtime releases. >>>>> >>>>> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's use in new code has been discouraged for many years and maybe this could start out using String.split rather than the legacy class. >>>>> >>>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>>> >>>>> -Alan >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Thu Jun 1 18:08:00 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Jun 2017 14:08:00 -0400 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: <3914a110-e59a-8eaa-7058-8619e989ed56@oracle.com> References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> <3914a110-e59a-8eaa-7058-8619e989ed56@oracle.com> Message-ID: <5D550AF0-1282-4D21-BCD2-13E50AC55A8C@oracle.com> Hi Aleks, Its all good. I don?t suppose there is a webrev of the diffs from 01 to 02 (or an easy way to see what changed)? Best Lance > On Jun 1, 2017, at 2:06 PM, Aleks Efimov wrote: > > I'm sorry Lance! I'm uploading new version of the webrev right now to the same location :-) It should be on-line soon =) > > Best, > Aleksei > > On 06/01/2017 06:34 PM, Lance Andersen wrote: >> Hi Roman, >> >> The webrev seems to have gotten moved as I was reviewing it and now it is gone :-) >> >>> On May 31, 2017, at 8:06 AM, Roman Grigoriadi wrote: >>> >>> Hi, >>> >>> New webrev can be found here: >>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ >>> >>> Previous review comments have been addressed. >>> >>> New changes since last webrev upload: >>> >>> Few ?opens xxx to java.xml.bind? in the module-info of java.xml.ws with descriptions of files in java.xml.ws, which calls JAXBContext#newInstance. >>> >>> JAXB-API: >>> - JAXBContext.java - deprecated implementation discovery with jaxb.properties resource. >>> - ContextFinder when called with String contextPath now tries to resolve jaxb.properties with Class#getResource if ClassLoader#getResource fails due to insufficient openness of jaxb.properties resource package. >>> - better JAXBException message when package of jaxb classes is not open to java.xml.bind >>> >>> JAXB-RI: >>> - fixed escaping newlines when using bundled jaxws transport. >>> >>> SAAJ-RI >>> - fixed TCK test failures >>> >>> JAXWS-RI >>> - fixed parsing wsdl in secure mode >>> >>> We have one JCK runtime test failure, which should be probably fixed in tests, I have created issue for it: https://bugs.openjdk.java.net/browse/JCK-7308397 >>> >>> Please review. >>> >>> Thanks, >>> Roman >>> >>>> On 8 May 2017, at 22:38, Lance Andersen > wrote: >>>> >>>> Hi Roman, >>>> >>>> I made a pass through the webrev and have the following feedback: >>>> >>>> >>>> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java and several files - which follow in the webrev, have formatting issues with the newly added @override and existing @overrides and should probably be cleaned up >>>> >>>> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java - can 960 -962 be deleted >>>> >>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - The copyright was reverted. Also what happens to the svn info in this file with the move to github? >>>> >>>> src/java.xml.ws/share/classes/javax/xml/soap/package-info.java - I would use ™ for TM >>>> >>>> src/java.xml.ws/share/classes/javax/xml/ws/Service.java - See comments starting at 230 seem off >>>> >>>> src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java - I would make the comments starting at 139 be consistent with the other comments >>>> >>>> src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/*.properties - the copyright date was reverted >>>> >>>> src/jdk.xml.bind/share/classes/module-info.java should already be updated in the workspace >>>> >>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java - The copyright should be updated to 2017 >>>> >>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java - the copyright was reverted >>>> >>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java - the copyright was reverted >>>> >>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java - the copyright was reverted >>>> >>>> src/jdk.xml.ws/share/classes/module-info.java - this was already updated in the workspace >>>> >>>> src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java - the copyright should only be 2017 >>>> >>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java. - the copyright should only be 2017 >>>> >>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/NewmessagesMessages.java - the copyright should only be 2017 >>>> >>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties - this is in the workspace already >>>> >>>> >>>> >>>>> On May 3, 2017, at 12:49 PM, Roman Grigoriadi > wrote: >>>>> >>>>> Hi, >>>>> >>>>> you can find new web rev here: >>>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ > >>>>> >>>>> Previous review comments are addressed. >>>>> >>>>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>>> >>>>> Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example >>>>> in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties >>>>> There is: >>>>> # for JDK integration - include version in source zip >>>>> jaxb.jdk.version=2.3.0-b170412.1723 >>>>> >>>>> We can add another version.properties file with versions of all JAX-* components. We may also change version from 2.3.0-SNAPSHOT to something unique like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. >>>>> >>>>> Roman >>>>> >>>>> >>>>>> On 12 Mar 2017, at 16:14, Alan Bateman > wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 12/03/2017 14:39, Roman Grigoriadi wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 >>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ >>>>>>> >>>>>> I skimmed the changes and have a few comments (I'm sure Lance or someone else will do a more detailed review). >>>>>> >>>>>> In JAXBContext then "must be open to the java.xml.bind module" should be "must be open to at least the java.xml.bind module" so as to cover the case that the package is opened unconditionally or to java.xml.bind and other modules. In addition, include "at least" makes it consistent with other wording that we have agreed for other areas. >>>>>> >>>>>> In MailcapCommandMap then the following doesn't seem right for the class description: >>>>>> >>>>>> 59 * (Where java.home is the value of the "java.home" System property >>>>>> 60 * and conf is the directory named "conf" if it exists, >>>>>> 61 * otherwise the directory named "lib"; the "conf" directory was >>>>>> 62 * introduced in JDK 1.9.) >>>>>> >>>>>> It might be simpler to just have javadoc specify that it attepts to locate the `mailcap` file in the Java run-time image and then add an @implNote with the details as to where it looks for specific runtime releases. >>>>>> >>>>>> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's use in new code has been discouraged for many years and maybe this could start out using String.split rather than the legacy class. >>>>>> >>>>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>>>> >>>>>> -Alan >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From roman.grigoriadi at oracle.com Thu Jun 1 18:18:16 2017 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Thu, 1 Jun 2017 20:18:16 +0200 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: <5D550AF0-1282-4D21-BCD2-13E50AC55A8C@oracle.com> References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> <3914a110-e59a-8eaa-7058-8619e989ed56@oracle.com> <5D550AF0-1282-4D21-BCD2-13E50AC55A8C@oracle.com> Message-ID: <8BB72B8F-866A-41AB-8FC5-F9D7A9A186B7@oracle.com> > On 1 Jun 2017, at 20:08, Lance Andersen wrote: > > Hi Aleks, > > Its all good. I don?t suppose there is a webrev of the diffs from 01 to 02 (or an easy way to see what changed)? Unfortunately no list of changed files, just a description of changes in my last message. In addition to those fix for JDK-8176741 is included in this upload and some new messages (modeler*.properties, wscompile*.properties) Maybe I can produce some diff of changed files from git history of the standalone (probably still many files) if that would be of any help. We may try to sync in a smaller parts next time. Roman > > Best > Lance >> On Jun 1, 2017, at 2:06 PM, Aleks Efimov > wrote: >> >> I'm sorry Lance! I'm uploading new version of the webrev right now to the same location :-) It should be on-line soon =) >> >> Best, >> Aleksei >> >> On 06/01/2017 06:34 PM, Lance Andersen wrote: >>> Hi Roman, >>> >>> The webrev seems to have gotten moved as I was reviewing it and now it is gone :-) >>> >>>> On May 31, 2017, at 8:06 AM, Roman Grigoriadi > wrote: >>>> >>>> Hi, >>>> >>>> New webrev can be found here: >>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ > >>>> >>>> Previous review comments have been addressed. >>>> >>>> New changes since last webrev upload: >>>> >>>> Few ?opens xxx to java.xml.bind? in the module-info of java.xml.ws with descriptions of files in java.xml.ws, which calls JAXBContext#newInstance. >>>> >>>> JAXB-API: >>>> - JAXBContext.java - deprecated implementation discovery with jaxb.properties resource. >>>> - ContextFinder when called with String contextPath now tries to resolve jaxb.properties with Class#getResource if ClassLoader#getResource fails due to insufficient openness of jaxb.properties resource package. >>>> - better JAXBException message when package of jaxb classes is not open to java.xml.bind >>>> >>>> JAXB-RI: >>>> - fixed escaping newlines when using bundled jaxws transport. >>>> >>>> SAAJ-RI >>>> - fixed TCK test failures >>>> >>>> JAXWS-RI >>>> - fixed parsing wsdl in secure mode >>>> >>>> We have one JCK runtime test failure, which should be probably fixed in tests, I have created issue for it: https://bugs.openjdk.java.net/browse/JCK-7308397 > >>>> >>>> Please review. >>>> >>>> Thanks, >>>> Roman >>>> >>>>> On 8 May 2017, at 22:38, Lance Andersen >> wrote: >>>>> >>>>> Hi Roman, >>>>> >>>>> I made a pass through the webrev and have the following feedback: >>>>> >>>>> >>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java and several files - which follow in the webrev, have formatting issues with the newly added @override and existing @overrides and should probably be cleaned up >>>>> >>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java - can 960 -962 be deleted >>>>> >>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - The copyright was reverted. Also what happens to the svn info in this file with the move to github? >>>>> >>>>> src/java.xml.ws/share/classes/javax/xml/soap/package-info.java - I would use ™ for TM >>>>> >>>>> src/java.xml.ws/share/classes/javax/xml/ws/Service.java - See comments starting at 230 seem off >>>>> >>>>> src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java - I would make the comments starting at 139 be consistent with the other comments >>>>> >>>>> src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/*.properties - the copyright date was reverted >>>>> >>>>> src/jdk.xml.bind/share/classes/module-info.java should already be updated in the workspace >>>>> >>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java - The copyright should be updated to 2017 >>>>> >>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java - the copyright was reverted >>>>> >>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java - the copyright was reverted >>>>> >>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java - the copyright was reverted >>>>> >>>>> src/jdk.xml.ws/share/classes/module-info.java - this was already updated in the workspace >>>>> >>>>> src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java - the copyright should only be 2017 >>>>> >>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java. - the copyright should only be 2017 >>>>> >>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/NewmessagesMessages.java - the copyright should only be 2017 >>>>> >>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties - this is in the workspace already >>>>> >>>>> >>>>> >>>>>> On May 3, 2017, at 12:49 PM, Roman Grigoriadi >> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> you can find new web rev here: >>>>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ > >> >>>>>> >>>>>> Previous review comments are addressed. >>>>>> >>>>>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>>>> >>>>>> Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example >>>>>> in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties >>>>>> There is: >>>>>> # for JDK integration - include version in source zip >>>>>> jaxb.jdk.version=2.3.0-b170412.1723 >>>>>> >>>>>> We can add another version.properties file with versions of all JAX-* components. We may also change version from 2.3.0-SNAPSHOT to something unique like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. >>>>>> >>>>>> Roman >>>>>> >>>>>> >>>>>>> On 12 Mar 2017, at 16:14, Alan Bateman >> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/03/2017 14:39, Roman Grigoriadi wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 > >>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ > >>>>>>>> >>>>>>> I skimmed the changes and have a few comments (I'm sure Lance or someone else will do a more detailed review). >>>>>>> >>>>>>> In JAXBContext then "must be open to the java.xml.bind module" should be "must be open to at least the java.xml.bind module" so as to cover the case that the package is opened unconditionally or to java.xml.bind and other modules. In addition, include "at least" makes it consistent with other wording that we have agreed for other areas. >>>>>>> >>>>>>> In MailcapCommandMap then the following doesn't seem right for the class description: >>>>>>> >>>>>>> 59 * (Where java.home is the value of the "java.home" System property >>>>>>> 60 * and conf is the directory named "conf" if it exists, >>>>>>> 61 * otherwise the directory named "lib"; the "conf" directory was >>>>>>> 62 * introduced in JDK 1.9.) >>>>>>> >>>>>>> It might be simpler to just have javadoc specify that it attepts to locate the `mailcap` file in the Java run-time image and then add an @implNote with the details as to where it looks for specific runtime releases. >>>>>>> >>>>>>> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's use in new code has been discouraged for many years and maybe this could start out using String.split rather than the legacy class. >>>>>>> >>>>>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>>>>> >>>>>>> -Alan >>>>> > >>>>> > > >>>>> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com > >>> > >>> > > >>> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com > >>> >>> >>> >> > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From vladimir.kozlov at oracle.com Thu Jun 1 18:28:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 1 Jun 2017 11:28:50 -0700 Subject: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9 In-Reply-To: <75E82CFC-EC08-4FDA-AFE0-B7572D0AAB25@oracle.com> References: <75E82CFC-EC08-4FDA-AFE0-B7572D0AAB25@oracle.com> Message-ID: <007e16b8-b342-53e9-be52-91f5d01e9f55@oracle.com> Thank you, Paul, for backporting it. On 6/1/17 8:56 AM, Paul Sandoz wrote: > Hi, > > To make it easier on 166 and Graal code to support both 9 and 10 we should back port the renaming of the internal Unsafe.compareAndSwap to Unsafe.compareAndSet: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-hotspot/webrev/ Hotspot changes are fine to me. > > This is an explicit back port with a new bug. This is the easiest approach given the current nature of how 9 and 10 are currently kept in sync. > > The change sets are the same as those associated with the following issues and apply cleanly without modification: > > Rename internal Unsafe.compare methods > https://bugs.openjdk.java.net/browse/JDK-8159995 > > [TESTBUG] Some hotspot tests broken after internal Unsafe name changes > https://bugs.openjdk.java.net/browse/JDK-8180479 > > > When running JPRT tests i observe a Graal test error on linux_x64_3.8-fastdebug-c2-hotspot_fast_compiler [*]. I dunno how this is manifesting given i cannot find any explicit reference to jdk.internal.Unsafe.compareAndSwap. Any idea? This is Graal bug I told about before - not all places in Graal are fixed with 8181292 changes (only a test was fixed): https://bugs.openjdk.java.net/browse/JDK-8180785 After you do backport we will fix Graal in JDK 9 and JDK 10. So don't worry about those failures. I will update 'Affected' and 'Fix' version later. Thanks, Vladimir > > Paul. > > [*] > [2017-05-31 12:33:08,163] Agent[4]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) > [2017-05-31 12:33:08,163] Agent[4]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) > [2017-05-31 12:33:08,213] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.callerNative()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) > [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.callerNative(InvokeInterface.java:82) > [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) > [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.(InvokeInterface.java:31) > [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.main([Ljava/lang/String;)V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) > [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.main(InvokeInterface.java:35) > [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.callee(IJFDLjava/lang/String;)Z: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) > [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.callee(InvokeInterface.java:60) > [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) > [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) > [2017-05-31 12:33:08,428] Agent[3]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) > [2017-05-31 12:33:08,429] Agent[3]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) > TEST: compiler/aot/calls/fromAot/AotInvokeInterface2AotTest.java > TEST JDK: /opt/jprt/T/P1/191630.sandoz/testproduct/linux_x64_3.8-fastdebug > From lance.andersen at oracle.com Thu Jun 1 19:03:23 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Jun 2017 15:03:23 -0400 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: <8BB72B8F-866A-41AB-8FC5-F9D7A9A186B7@oracle.com> References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> <3914a110-e59a-8eaa-7058-8619e989ed56@oracle.com> <5D550AF0-1282-4D21-BCD2-13E50AC55A8C@oracle.com> <8BB72B8F-866A-41AB-8FC5-F9D7A9A186B7@oracle.com> Message-ID: <45DB2706-CFD8-4CB5-A822-D41CACF8B9A8@oracle.com> > On Jun 1, 2017, at 2:18 PM, Roman Grigoriadi wrote: > >> >> On 1 Jun 2017, at 20:08, Lance Andersen > wrote: >> >> Hi Aleks, >> >> Its all good. I don?t suppose there is a webrev of the diffs from 01 to 02 (or an easy way to see what changed)? > > Unfortunately no list of changed files, just a description of changes in my last message. OK, thank you., > In addition to those fix for JDK-8176741 is included in this upload and some new messages (modeler*.properties, wscompile*.properties) > > Maybe I can produce some diff of changed files from git history of the standalone (probably still many files) if that would be of any help. We may try to sync in a smaller parts next time. I would not worry about it. I was hoping to just look at just the changes from the previous, but will be easier for me to just review the entire webrev again. > > Roman > > >> >> Best >> Lance >>> On Jun 1, 2017, at 2:06 PM, Aleks Efimov > wrote: >>> >>> I'm sorry Lance! I'm uploading new version of the webrev right now to the same location :-) It should be on-line soon =) >>> >>> Best, >>> Aleksei >>> >>> On 06/01/2017 06:34 PM, Lance Andersen wrote: >>>> Hi Roman, >>>> >>>> The webrev seems to have gotten moved as I was reviewing it and now it is gone :-) >>>> >>>>> On May 31, 2017, at 8:06 AM, Roman Grigoriadi > wrote: >>>>> >>>>> Hi, >>>>> >>>>> New webrev can be found here: >>>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ > >>>>> >>>>> Previous review comments have been addressed. >>>>> >>>>> New changes since last webrev upload: >>>>> >>>>> Few ?opens xxx to java.xml.bind? in the module-info of java.xml.ws with descriptions of files in java.xml.ws, which calls JAXBContext#newInstance. >>>>> >>>>> JAXB-API: >>>>> - JAXBContext.java - deprecated implementation discovery with jaxb.properties resource. >>>>> - ContextFinder when called with String contextPath now tries to resolve jaxb.properties with Class#getResource if ClassLoader#getResource fails due to insufficient openness of jaxb.properties resource package. >>>>> - better JAXBException message when package of jaxb classes is not open to java.xml.bind >>>>> >>>>> JAXB-RI: >>>>> - fixed escaping newlines when using bundled jaxws transport. >>>>> >>>>> SAAJ-RI >>>>> - fixed TCK test failures >>>>> >>>>> JAXWS-RI >>>>> - fixed parsing wsdl in secure mode >>>>> >>>>> We have one JCK runtime test failure, which should be probably fixed in tests, I have created issue for it: https://bugs.openjdk.java.net/browse/JCK-7308397 > >>>>> >>>>> Please review. >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>>> On 8 May 2017, at 22:38, Lance Andersen >> wrote: >>>>>> >>>>>> Hi Roman, >>>>>> >>>>>> I made a pass through the webrev and have the following feedback: >>>>>> >>>>>> >>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java and several files - which follow in the webrev, have formatting issues with the newly added @override and existing @overrides and should probably be cleaned up >>>>>> >>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java - can 960 -962 be deleted >>>>>> >>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - The copyright was reverted. Also what happens to the svn info in this file with the move to github? >>>>>> >>>>>> src/java.xml.ws/share/classes/javax/xml/soap/package-info.java - I would use ™ for TM >>>>>> >>>>>> src/java.xml.ws/share/classes/javax/xml/ws/Service.java - See comments starting at 230 seem off >>>>>> >>>>>> src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java - I would make the comments starting at 139 be consistent with the other comments >>>>>> >>>>>> src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/*.properties - the copyright date was reverted >>>>>> >>>>>> src/jdk.xml.bind/share/classes/module-info.java should already be updated in the workspace >>>>>> >>>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java - The copyright should be updated to 2017 >>>>>> >>>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java - the copyright was reverted >>>>>> >>>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java - the copyright was reverted >>>>>> >>>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java - the copyright was reverted >>>>>> >>>>>> src/jdk.xml.ws/share/classes/module-info.java - this was already updated in the workspace >>>>>> >>>>>> src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java - the copyright should only be 2017 >>>>>> >>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java. - the copyright should only be 2017 >>>>>> >>>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/NewmessagesMessages.java - the copyright should only be 2017 >>>>>> >>>>>> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties - this is in the workspace already >>>>>> >>>>>> >>>>>> >>>>>>> On May 3, 2017, at 12:49 PM, Roman Grigoriadi >> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> you can find new web rev here: >>>>>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ > >> >>>>>>> >>>>>>> Previous review comments are addressed. >>>>>>> >>>>>>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>>>>> >>>>>>> Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example >>>>>>> in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties >>>>>>> There is: >>>>>>> # for JDK integration - include version in source zip >>>>>>> jaxb.jdk.version=2.3.0-b170412.1723 >>>>>>> >>>>>>> We can add another version.properties file with versions of all JAX-* components. We may also change version from 2.3.0-SNAPSHOT to something unique like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. >>>>>>> >>>>>>> Roman >>>>>>> >>>>>>> >>>>>>>> On 12 Mar 2017, at 16:14, Alan Bateman >> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12/03/2017 14:39, Roman Grigoriadi wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 > >>>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ > >>>>>>>>> >>>>>>>> I skimmed the changes and have a few comments (I'm sure Lance or someone else will do a more detailed review). >>>>>>>> >>>>>>>> In JAXBContext then "must be open to the java.xml.bind module" should be "must be open to at least the java.xml.bind module" so as to cover the case that the package is opened unconditionally or to java.xml.bind and other modules. In addition, include "at least" makes it consistent with other wording that we have agreed for other areas. >>>>>>>> >>>>>>>> In MailcapCommandMap then the following doesn't seem right for the class description: >>>>>>>> >>>>>>>> 59 * (Where java.home is the value of the "java.home" System property >>>>>>>> 60 * and conf is the directory named "conf" if it exists, >>>>>>>> 61 * otherwise the directory named "lib"; the "conf" directory was >>>>>>>> 62 * introduced in JDK 1.9.) >>>>>>>> >>>>>>>> It might be simpler to just have javadoc specify that it attepts to locate the `mailcap` file in the Java run-time image and then add an @implNote with the details as to where it looks for specific runtime releases. >>>>>>>> >>>>>>>> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's use in new code has been discouraged for many years and maybe this could start out using String.split rather than the legacy class. >>>>>>>> >>>>>>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >>>>>>>> >>>>>>>> -Alan >>>>>> > >>>>>> > > >>>>>> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> Lance.Andersen at oracle.com > >>>> > >>>> > > >>>> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com > >>>> >>>> >>>> >>> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Thu Jun 1 19:25:59 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Jun 2017 12:25:59 -0700 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> Message-ID: <1AB6DFA3-81C4-4BA4-9697-5B9C6C3F81D0@oracle.com> > On May 31, 2017, at 5:06 AM, Roman Grigoriadi wrote: > > Hi, > > New webrev can be found here: > http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ jaxp/src/java.xml/share/classes/module-info.java I?m happy to see this qualified exports removed. Can you update jdk/test/jdk/modules/etc/JdkQualifiedExportTest.java to remove "java.xml/com.sun.xml.internal.stream.writers? from KNOWN_EXCEPTION. java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/MrJarUtil.java MrJarUtil::getNoPoolProperty is not MR specific. Are you trying to keep the different default value when building for older release? It would be clearer if you want to define a constant for the default value that is subject to the runtime version. XMLStreamReaderFactory and XMLStreamWriterFactory would get the property value with the MR-specific default. That?re the files I reviewed. Mandy From igor.ignatyev at oracle.com Thu Jun 1 20:17:25 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 1 Jun 2017 13:17:25 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: > On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: > > Igor, > >> On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: >> >> Hi Felix, >> >> I have suggested the exact opposite change[1-3] to fix the same problem. > > I?m sorry, but this is all just too confusing. After your change, who, or what, is > responsible for building/compiling the test library dependencies? jtreg is responsible, there is an implicit build for each @run, and jtreg will analyze a test class to get transitive closure for static dependencies, hence you have to have @build only for classes which are not in constant pool, e.g. used only by reflection or whose classnames are only used to spawn a new java instance. > > > Test library code has no @modules tags, so does not explicitly declare its > module dependencies. Instead module dependencies, required by test > library code, are declared in the test using the library. If we wildcard, or > otherwise leave broad build dependencies, from tests then there is no > way to know what new module dependencies may be added in the future. > That is, one of, the reason(s) I asked Felix to be explicit about the build > dependencies. having explicit builds does not really help w/ module dependency, if someone change a testlibrary class so it starts to depend on another testlibrary class, jtreg will implicitly build it and if this class has some module dependencies, you will have to reflect them in the test. generally speaking, I don't like having explicit build actions because build actions themselves are implicit, so they don't really help, it's still will be hard to spot missed explicit builds. not having (unneeded) explicit builds is an easy rule to follow and we can easily find all places which don't follow this rule by grep. -- Igor > > -Chris. > >> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >> [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html > From mandy.chung at oracle.com Thu Jun 1 21:55:13 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Jun 2017 14:55:13 -0700 Subject: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9 In-Reply-To: <75E82CFC-EC08-4FDA-AFE0-B7572D0AAB25@oracle.com> References: <75E82CFC-EC08-4FDA-AFE0-B7572D0AAB25@oracle.com> Message-ID: > On Jun 1, 2017, at 8:56 AM, Paul Sandoz wrote: > > Hi, > > To make it easier on 166 and Graal code to support both 9 and 10 we should back port the renaming of the internal Unsafe.compareAndSwap to Unsafe.compareAndSet: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-hotspot/webrev/ Looks fine to me. Just to mention - a few test/compiler/unsafe/SunMiscUnsafeAccessTestXXX.java tests only have the copyright header fix and it?s okay to backport them as it?s part of the JDK 10 changeset. Mandy From paul.sandoz at oracle.com Thu Jun 1 22:11:30 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Jun 2017 15:11:30 -0700 Subject: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9 In-Reply-To: References: <75E82CFC-EC08-4FDA-AFE0-B7572D0AAB25@oracle.com> Message-ID: > On 1 Jun 2017, at 14:55, Mandy Chung wrote: > > >> On Jun 1, 2017, at 8:56 AM, Paul Sandoz wrote: >> >> Hi, >> >> To make it easier on 166 and Graal code to support both 9 and 10 we should back port the renaming of the internal Unsafe.compareAndSwap to Unsafe.compareAndSet: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-jdk/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-hotspot/webrev/ > > Looks fine to me. Just to mention - a few test/compiler/unsafe/SunMiscUnsafeAccessTestXXX.java tests only have the copyright header fix and it?s okay to backport them as it?s part of the JDK 10 changeset. > Thanks, those non-functional updates are a result of updating the template and regenerating all instances. Paul. From ioi.lam at oracle.com Thu Jun 1 22:37:58 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 1 Jun 2017 15:37:58 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> On 6/1/17 1:17 PM, Igor Ignatyev wrote: >> On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: >> >> Igor, >> >>> On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: >>> >>> Hi Felix, >>> >>> I have suggested the exact opposite change[1-3] to fix the same problem. >> I?m sorry, but this is all just too confusing. After your change, who, or what, is >> responsible for building/compiling the test library dependencies? > jtreg is responsible, there is an implicit build for each @run, and jtreg will analyze a test class to get transitive closure for static dependencies, hence you have to have @build only for classes which are not in constant pool, e.g. used only by reflection or whose classnames are only used to spawn a new java instance. I suspect the problem is caused by a long standing bug in jtreg that results in library classes being partially compiled. Please see my evaluation in https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 In the bug report, there is test case that can reliably reproduce the NoClassDefFoundError problem. I think adding all the @build commands in the tests are just band-aids. Things will break unless every test explicitly uses @build to build every class in every library that they use, including all the private classes that are not directly accessible by the test cases. For example: doing this may be enough for now: * @build jdk.test.lib.process.* But what if in the future, jdk.test.lib.process is restructured to have a private package jdk.test.lib.process.hidden? To work around CODETOOLS-7901986, all the test cases that must be modified to the following, which unnecessarily exposes library implementation details to the library users: * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* Just imagine this -- "in order to use malloc() you must explicitly build not only malloc(), but also sbrk() ... and every other function in libc". That seems unreasonable to me. By the way, we made a fix in the HotSpot tests (see https://bugs.openjdk.java.net/browse/JDK-8157957) that got rid of many (but not all) of the NoClassDefFoundErrors by *removing* the @build lines ..... My proposal is, instead of just adding @build for band-aid, we should fix CODETOOLS-7901986 instead. Thanks - Ioi >> >> Test library code has no @modules tags, so does not explicitly declare its >> module dependencies. Instead module dependencies, required by test >> library code, are declared in the test using the library. If we wildcard, or >> otherwise leave broad build dependencies, from tests then there is no >> way to know what new module dependencies may be added in the future. >> That is, one of, the reason(s) I asked Felix to be explicit about the build >> dependencies. > having explicit builds does not really help w/ module dependency, if someone change a testlibrary class so it starts to depend on another testlibrary class, jtreg will implicitly build it and if this class has some module dependencies, you will have to reflect them in the test. > > generally speaking, I don't like having explicit build actions because build actions themselves are implicit, so they don't really help, it's still will be hard to spot missed explicit builds. not having (unneeded) explicit builds is an easy rule to follow and we can easily find all places which don't follow this rule by grep. > > -- Igor >> -Chris. >> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >>> [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html From ioi.lam at oracle.com Thu Jun 1 23:14:48 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 1 Jun 2017 16:14:48 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> On 6/1/17 1:17 PM, Igor Ignatyev wrote: >> On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: >> >> Igor, >> >>> On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: >>> >>> Hi Felix, >>> >>> I have suggested the exact opposite change[1-3] to fix the same problem. >> I?m sorry, but this is all just too confusing. After your change, who, or what, is >> responsible for building/compiling the test library dependencies? > jtreg is responsible, there is an implicit build for each @run, and jtreg will analyze a test class to get transitive closure for static dependencies, hence you have to have @build only for classes which are not in constant pool, e.g. used only by reflection or whose classnames are only used to spawn a new java instance. Just to add to what Igor said: In fact, what JTREG does is fairly simple, but kind of hidden so it's not obvious what it does with the @library tags. Let's say your test uses "@library /test/lib" After your test completes, open the .jtr file (JTREG Report). It should have a command-line for javac, like this: DISPLAY=:2 \\ HOME=/home/iklam \\ JTREG_COMPILEJDK=/home/iklam/jdk/bld/foobar/images/jdk \\ LANG=en_US.UTF-8 \\ LD_LIBRARY_PATH=/home/iklam/jdk/bld/foobar/images/jdk/../../images/test/hotspot/jtreg/native \\ PATH=/bin:/usr/bin \\ /home/iklam/jdk/bld/foobar/images/jdk/bin/javac \\ -J-Dtest.src=/jdk/foobar/hotspot/test/runtime/SharedArchiveFile \\ -J-Dtest.src.path=/jdk/foobar/hotspot/test/runtime/SharedArchiveFile:/jdk/foobar/test/lib \\ -J-Dtest.classes=/jdk/tmp/jtreg/work/classes/14/runtime/SharedArchiveFile \\ -J-Dtest.class.path=/jdk/tmp/jtreg/work/classes/14/runtime/SharedArchiveFile:/jdk/tmp/jtreg/work/classes/14/test/lib \\ -J-Dtest.vm.opts= \\ -J-Dtest.tool.vm.opts= \\ -J-Dtest.compiler.opts= \\ -J-Dtest.java.opts= \\ -J-Dtest.jdk=/home/iklam/jdk/bld/foobar-fastdebug/images/jdk \\ -J-Dcompile.jdk=/home/iklam/jdk/bld/foobar/images/jdk \\ -J-Dtest.timeout.factor=4.0 \\ -J-Dtest.modules='java.base/jdk.internal.misc java.management' \\ -J-Dtest.nativepath=/home/iklam/jdk/bld/foobar/images/jdk/../../images/test/hotspot/jtreg/native \\ @/jdk/tmp/jtreg/work/runtime/SharedArchiveFile/SpaceUtilizationCheck.d/compile.0.jta The gem is hidden in the compile.0.jta file. It contains something like: -sourcepath :/jdk/foobar/test/lib: So if my test refers to a class under /test/lib, such as jdk.test.lib.process.ProcessTools, javac will be able to locate it under /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will build it automatically. So really, there's no reason why the test must explicitly do an @build of the library classes that it uses. - Ioi >> >> Test library code has no @modules tags, so does not explicitly declare its >> module dependencies. Instead module dependencies, required by test >> library code, are declared in the test using the library. If we wildcard, or >> otherwise leave broad build dependencies, from tests then there is no >> way to know what new module dependencies may be added in the future. >> That is, one of, the reason(s) I asked Felix to be explicit about the build >> dependencies. > having explicit builds does not really help w/ module dependency, if someone change a testlibrary class so it starts to depend on another testlibrary class, jtreg will implicitly build it and if this class has some module dependencies, you will have to reflect them in the test. > > generally speaking, I don't like having explicit build actions because build actions themselves are implicit, so they don't really help, it's still will be hard to spot missed explicit builds. not having (unneeded) explicit builds is an easy rule to follow and we can easily find all places which don't follow this rule by grep. > > -- Igor >> -Chris. >> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >>> [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html From stuart.marks at oracle.com Thu Jun 1 23:48:51 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 1 Jun 2017 16:48:51 -0700 Subject: RFR 9+-: 8180582: The bind to rmiregistry is rejected by registryFilter even though registryFilter is set In-Reply-To: References: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com> <996d590e-4d08-df0b-d20d-b65610ba472d@Oracle.com> <39f12457-65a8-36c9-cb32-babb74fa9c08@Oracle.com> <6dc73b18-1bee-23a6-11c0-e80b5463a21f@oracle.com> Message-ID: <1db65a7f-f9c2-6948-f114-abac827a39c4@oracle.com> Hi Roger, Ah, so your alternative to fixing up the regex is to avoid using regexes entirely! :-) Seriously, removing the regex is an improvement; it reduces a major source of fragility. The update looks fine. I did notice one typo: 82 * Data RMI Regiry bind test. No need for another webrev for the fix for this one. Thanks, s'marks On 5/31/17 7:09 PM, Roger Riggs wrote: > Hi Stuart, > > Good suggestions on the regex, but it will be simpler, as you suggest, to use a > separate > command line property. > > The webrev is updated in place. > http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html > > Thanks, Roger > > > > On 5/31/17 7:09 PM, Stuart Marks wrote: >> Hi Roger, >> >> RegistryImpl change looks fine. I have a quibble on the regex used in the test. >> >> 162 Matcher m = Pattern >> 163 .compile(".*maxdepth=(\\d*)") >> 164 .matcher(Objects.requireNonNullElse(registryFilter, "")); >> 165 int depthOverride = m.find() ? Integer.parseInt(m.group(1)) : >> REGISTRY_MAX_DEPTH; >> >> Since Matcher.find() is called, the pattern can be found anywhere in the input >> string, so the leading ".*" is unnecessary. I'd suggest replacing it with >> "\\b" to match a word boundary immediately preceding "maxdepth". Also, "\\d*" >> will match zero characters, which could cause the subsequent parseInt() to fail. >> >> These issues aren't of immediate concern, as the test works as it stands. They >> may make the test a bit harder to maintain, though. >> >> But I think the main concern is that if the regex were modified by future >> maintenance, it might not match, which would cause the test to test >> REGISTRY_MAX_DEPTH redundantly instead of the depth the filter is attempting >> to specify. This problem wouldn't be completely silent, but it'd be easy to >> miss. You'd have to inspect the log pretty carefully to see what's going on. >> So maybe it would be good to have something like a command-line argument that >> specifies the expected value of maxdepth. Yes, this is redundant, but it's a >> useful cross-check, I think. >> >> There are several identical lines of code starting at line 184. Maybe these >> could be extracted into a common method. >> >> These are all cleanup issues, so it's up to you how much additional work you >> want to put into this before it gets into 9. >> >> s'marks >> >> >> >> On 5/31/17 7:02 AM, Roger Riggs wrote: >>> Thanks Daniel for the review and corrected link. >>> >>> On 5/30/2017 7:04 PM, Daniel Fuchs wrote: >>>> Hi Roger, >>>> >>>> On 30/05/17 19:26, Roger Riggs wrote: >>>>> Hi Daniel, >>>>> >>>>> Fixed, there is no need for the unbind since the registry is not reused and >>>>> it might >>>>> cause a spurious success. >>>>> >>>>> (Also corrected the exception error message @ 151 and 153). >>>>> >>>>> Webrev updated in place. >>>>> ... >>>> >>>> I assume you meant >>>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html >>>> which is what I reviewed ;-) >>>> >>>> Looks good! >>>> >>>> -- danel >>>> >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> On 5/30/2017 2:00 PM, Daniel Fuchs wrote: >>>>>> Hi Roger, >>>>>> >>>>>> Looks good! Just one nit with the test: >>>>>> >>>>>> 194 registry.unbind(name); >>>>>> 195 Assert.fail("Registry filter should have rejected depth: " >>>>>> + depthOverride + 1); >>>>>> >>>>>> Technically, the test will also pass if bind() succeed but >>>>>> unbind() fails - for some unforeseen reason. >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> On 25/05/17 16:31, Roger Riggs wrote: >>>>>>> Please review an update to the RMI Registry built-in serial filter >>>>>>> implementation limit on the depth >>>>>>> of a instance that can be bound in the registry. The initial depth limit >>>>>>> was 5 and it was too limiting >>>>>>> for some existing applications. It limit is updated to depth = 20 and >>>>>>> should be more than adequate. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html >>>>>>> >>>>>>> Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8180582 >>>>>>> >>>>>>> Thanks, Roger >>>>>> >>>>> >>>> >>> > From igor.ignatyev at oracle.com Thu Jun 1 23:58:49 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 1 Jun 2017 16:58:49 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> Message-ID: > For example: doing this may be enough for now: > > * @build jdk.test.lib.process.* > > But what if in the future, jdk.test.lib.process is restructured to have a private package jdk.test.lib.process.hidden? To work around CODETOOLS-7901986, all the test cases that must be modified to the following, which unnecessarily exposes library implementation details to the library users: > > * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* and in fact, there is already similar problem and http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ does not address it. jdk/test/lib/process/ProcessTools depends on jdk/test/lib/Utils so all tests which have '@build jdk.test.lib.process.ProcessTools' will have to have '@build jdk.test.lib.Utils'. then we have OutputAnalyzer which depends on ProcessTools so all tests which @build jdk.test.lib.process.OutputAnalyzer will @build ProcessTools and Utils explicitly. many testlibrary classes which on jdk.test.lib.process.OutputAnalyzer, so one will have to specify OutputAnalyzer ProcessTools and Utils in the tests which depends on other testlibrary classes. to make things even worse, Utils depends on OutputAnalyzer and there are lots of tests and test library classes which depend on Utils, so all of them will have to have at least '@build jdk.test.lib.Utils jdk.test.lib.process.OutputAnalyzer jdk.test.lib.process.ProcessTools'. and they will work stable till someone refactors them and extract some new classes. that is to say, it's nearly impossible to have all explicit @build actions. Cheers, -- Igor > On Jun 1, 2017, at 3:37 PM, Ioi Lam wrote: > > > > On 6/1/17 1:17 PM, Igor Ignatyev wrote: >>> On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: >>> >>> Igor, >>> >>>> On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: >>>> >>>> Hi Felix, >>>> >>>> I have suggested the exact opposite change[1-3] to fix the same problem. >>> I?m sorry, but this is all just too confusing. After your change, who, or what, is >>> responsible for building/compiling the test library dependencies? >> jtreg is responsible, there is an implicit build for each @run, and jtreg will analyze a test class to get transitive closure for static dependencies, hence you have to have @build only for classes which are not in constant pool, e.g. used only by reflection or whose classnames are only used to spawn a new java instance. > > > I suspect the problem is caused by a long standing bug in jtreg that results in library classes being partially compiled. Please see my evaluation in > > https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 > > In the bug report, there is test case that can reliably reproduce the NoClassDefFoundError problem. > > I think adding all the @build commands in the tests are just band-aids. Things will break unless every test explicitly uses @build to build every class in every library that they use, including all the private classes that are not directly accessible by the test cases. > > For example: doing this may be enough for now: > > * @build jdk.test.lib.process.* > > But what if in the future, jdk.test.lib.process is restructured to have a private package jdk.test.lib.process.hidden? To work around CODETOOLS-7901986, all the test cases that must be modified to the following, which unnecessarily exposes library implementation details to the library users: > > * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* > > Just imagine this -- "in order to use malloc() you must explicitly build not only malloc(), but also sbrk() ... and every other function in libc". That seems unreasonable to me. > > By the way, we made a fix in the HotSpot tests (see https://bugs.openjdk.java.net/browse/JDK-8157957 ) that got rid of many (but not all) of the NoClassDefFoundErrors by *removing* the @build lines ..... > > My proposal is, instead of just adding @build for band-aid, we should fix CODETOOLS-7901986 instead. > > Thanks > - Ioi > > >>> >>> Test library code has no @modules tags, so does not explicitly declare its >>> module dependencies. Instead module dependencies, required by test >>> library code, are declared in the test using the library. If we wildcard, or >>> otherwise leave broad build dependencies, from tests then there is no >>> way to know what new module dependencies may be added in the future. >>> That is, one of, the reason(s) I asked Felix to be explicit about the build >>> dependencies. >> having explicit builds does not really help w/ module dependency, if someone change a testlibrary class so it starts to depend on another testlibrary class, jtreg will implicitly build it and if this class has some module dependencies, you will have to reflect them in the test. >> >> generally speaking, I don't like having explicit build actions because build actions themselves are implicit, so they don't really help, it's still will be hard to spot missed explicit builds. not having (unneeded) explicit builds is an easy rule to follow and we can easily find all places which don't follow this rule by grep. >> >> -- Igor >>> -Chris. >>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >>>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >>>> [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html From david.holmes at oracle.com Fri Jun 2 00:52:25 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Jun 2017 10:52:25 +1000 Subject: asserts in jdk coding (outside hotspot) In-Reply-To: References: <703c39a1-2cf1-24f3-2089-53faf0d87f64@oracle.com> Message-ID: <0b37e8ae-2bfe-92a6-755e-8776384ab018@oracle.com> Hi Thomas, On 1/06/2017 10:26 PM, Thomas St?fe wrote: > Hi David, > > On Thu, Jun 1, 2017 at 2:09 PM, David Holmes > wrote: > > Hi Thomas, > > On 1/06/2017 7:20 PM, Thomas St?fe wrote: > > Hi all, > > so, we have the hotspot asserts with all the niceties of our error > reporting. But these asserts are only accessible from within > hotspot coding. > > In the JDK, in a number of places, I see that we use the > standard posix > assert()( > http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html > ). > > This means that when we trigger the assert, we will only get a brief > message on stderr and a core, but no hs_err file. > > It also means that -XX:+CreateCoredumpOnCrash is ignored, so it > is not > possible to switch off those core dumps. > > This is unfortunate and also easy to fix. We do not even have to > call into > the hotspot to get hotspot asserts. We could just force a NULL > pointer > access or send ourselves a SIGILL or something. Anything which > triggers the > hotspot signal handling would be fine. > > What do you think? > > > Sending ourselves a fatal signal doesn't indicate what assertion > failed. The error handler won't know it was an assert, just a SEGV > or SIGILL > > ?? > > David > > > Sure. But in many cases this still would be preferable to just a core. > We'd get a hs-err file - admittedly with a Segv instead of an assert > message - but we have a callstack and could deduce the error from there. I suppose we could do all the assert related printfs before sending the signal. The assertion info wouldn't be in the hs_err log, but at least it would be somewhere. Anyway I'll leave this for core-libs folk to mull over. Cheers, David > I am not saying that this is an ideal solution. Of course, a really good > solution may invoke the real hotspot assert or one might come up with a > way to transfer assert information (message, file, line etc) to the > hotspot error handler. E.g. store the assert message in a globally > visible char array one could resolve via dlsym to avoid having to add > link dependencies. > > > ..Thomas > > > Kind Regards, Thomas > > From felix.yang at oracle.com Fri Jun 2 01:52:27 2017 From: felix.yang at oracle.com (Felix Yang) Date: Fri, 2 Jun 2017 09:52:27 +0800 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> Message-ID: <7a62f2ee-69bc-0281-3e2f-85a25d917e51@oracle.com> Hi Igor and Ioi, I partially agree with you. As initially stated in the proposal and bug(JDK-8181299 ), I don't think this patch is a fix but a quick workaround to make them runnable. "explicit" is reasonable for me. But "explicit" should not be restricted as "explicit all, including dependencies", as it is not productive or even realistic in the long term. Thanks, Felix On 2017/6/2 7:58, Igor Ignatyev wrote: >> For example: doing this may be enough for now: >> >> * @build jdk.test.lib.process.* >> >> But what if in the future, jdk.test.lib.process is restructured to >> have a private package jdk.test.lib.process.hidden? To work around >> CODETOOLS-7901986, all the test cases that must be modified to the >> following, which unnecessarily exposes library implementation details >> to the library users: >> >> * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* > > and in fact, there is already similar problem and > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ > does not > address it. > jdk/test/lib/process/ProcessTools depends on jdk/test/lib/Utils so all > tests which have '@build jdk.test.lib.process.ProcessTools' will have > to have '@build jdk.test.lib.Utils'. then we have OutputAnalyzer > which depends on ProcessTools so all tests which > @build jdk.test.lib.process.OutputAnalyzer will @build ProcessTools > and Utils explicitly. many testlibrary classes which on > jdk.test.lib.process.OutputAnalyzer, so one will have to > specify OutputAnalyzer ProcessTools and Utils in the tests which > depends on other testlibrary classes. to make things even worse, > Utils depends on OutputAnalyzer and there are lots of tests and test > library classes which depend on Utils, so all of them will have to > have at least '@build jdk.test.lib.Utils > jdk.test.lib.process.OutputAnalyzer jdk.test.lib.process.ProcessTools'. > and they will work stable till someone refactors them and extract some > new classes. that is to say, it's nearly impossible to have all > explicit @build actions. > > Cheers, > -- Igor > >> On Jun 1, 2017, at 3:37 PM, Ioi Lam > > wrote: >> >> >> >> On 6/1/17 1:17 PM, Igor Ignatyev wrote: >>>> On Jun 1, 2017, at 1:20 AM, Chris Hegarty >>> > wrote: >>>> >>>> Igor, >>>> >>>>> On 1 Jun 2017, at 04:32, Igor Ignatyev >>>> > wrote: >>>>> >>>>> Hi Felix, >>>>> >>>>> I have suggested the exact opposite change[1-3] to fix the same >>>>> problem. >>>> I?m sorry, but this is all just too confusing. After your change, >>>> who, or what, is >>>> responsible for building/compiling the test library dependencies? >>> jtreg is responsible, there is an implicit build for each @run, and >>> jtreg will analyze a test class to get transitive closure for static >>> dependencies, hence you have to have @build only for classes which >>> are not in constant pool, e.g. used only by reflection or whose >>> classnames are only used to spawn a new java instance. >> >> >> I suspect the problem is caused by a long standing bug in jtreg that >> results in library classes being partially compiled. Please see my >> evaluation in >> >> https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 >> >> In the bug report, there is test case that can reliably reproduce the >> NoClassDefFoundError problem. >> >> I think adding all the @build commands in the tests are just >> band-aids. Things will break unless every test explicitly uses @build >> to build every class in every library that they use, including all >> the private classes that are not directly accessible by the test cases. >> >> For example: doing this may be enough for now: >> >> * @build jdk.test.lib.process.* >> >> But what if in the future, jdk.test.lib.process is restructured to >> have a private package jdk.test.lib.process.hidden? To work around >> CODETOOLS-7901986, all the test cases that must be modified to the >> following, which unnecessarily exposes library implementation details >> to the library users: >> >> * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* >> >> Just imagine this -- "in order to use malloc() you must explicitly >> build not only malloc(), but also sbrk() ... and every other function >> in libc". That seems unreasonable to me. >> >> By the way, we made a fix in the HotSpot tests >> (seehttps://bugs.openjdk.java.net/browse/JDK-8157957) that got rid of >> many (but not all) of the NoClassDefFoundErrors by *removing* the >> @build lines ..... >> >> My proposal is, instead of just adding @build for band-aid, we should >> fix CODETOOLS-7901986 instead. >> >> Thanks >> - Ioi >> >> >>>> >>>> Test library code has no @modules tags, so does not explicitly >>>> declare its >>>> module dependencies. Instead module dependencies, required by test >>>> library code, are declared in the test using the library. If we >>>> wildcard, or >>>> otherwise leave broad build dependencies, from tests then there is no >>>> way to know what new module dependencies may be added in the future. >>>> That is, one of, the reason(s) I asked Felix to be explicit about >>>> the build >>>> dependencies. >>> having explicit builds does not really help w/ module dependency, if >>> someone change a testlibrary class so it starts to depend on another >>> testlibrary class, jtreg will implicitly build it and if this class >>> has some module dependencies, you will have to reflect them in the test. >>> >>> generally speaking, I don't like having explicit build actions >>> because build actions themselves are implicit, so they don't really >>> help, it's still will be hard to spot missed explicit builds. not >>> having (unneeded) explicit builds is an easy rule to follow and we >>> can easily find all places which don't follow this rule by grep. >>> >>> -- Igor >>>> -Chris. >>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >>>>> [3] >>>>> http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html >>>>> > From igor.ignatyev at oracle.com Fri Jun 2 02:11:31 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 1 Jun 2017 19:11:31 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <7a62f2ee-69bc-0281-3e2f-85a25d917e51@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> <7a62f2ee-69bc-0281-3e2f-85a25d917e51@oracle.com> Message-ID: <4B7BC543-7A5A-4128-9433-DEDC2BCF27DB@oracle.com> Hi Felix, none of the jdk tests which fail w/ NCDFE: jdk/test/lib/process/StreamPumper depend on StreamPumper directly, they get this dependency transitively from jdk/test/lib/process/ProcessTools, so I don't see how you will find this good definition of "explicit" even for the failures at hand. I recommend to work around this the same way we did it in hotspot, which reliably removed almost all our NCDFE failures, -- remove explicit @build, if not all for all classes, then at least for jdk/test/lib/** classes. -- Igor > On Jun 1, 2017, at 6:52 PM, Felix Yang wrote: > > Hi Igor and Ioi, > > I partially agree with you. As initially stated in the proposal and bug(JDK-8181299 ), I don't think this patch is a fix but a quick workaround to make them runnable. > > "explicit" is reasonable for me. But "explicit" should not be restricted as "explicit all, including dependencies", as it is not productive or even realistic in the long term. > Thanks, > Felix > On 2017/6/2 7:58, Igor Ignatyev wrote: >>> For example: doing this may be enough for now: >>> >>> * @build jdk.test.lib.process.* >>> >>> But what if in the future, jdk.test.lib.process is restructured to have a private package jdk.test.lib.process.hidden? To work around CODETOOLS-7901986, all the test cases that must be modified to the following, which unnecessarily exposes library implementation details to the library users: >>> >>> * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* >> >> and in fact, there is already similar problem and http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ does not address it. >> jdk/test/lib/process/ProcessTools depends on jdk/test/lib/Utils so all tests which have '@build jdk.test.lib.process.ProcessTools' will have to have '@build jdk.test.lib.Utils'. then we have OutputAnalyzer which depends on ProcessTools so all tests which @build jdk.test.lib.process.OutputAnalyzer will @build ProcessTools and Utils explicitly. many testlibrary classes which on jdk.test.lib.process.OutputAnalyzer, so one will have to specify OutputAnalyzer ProcessTools and Utils in the tests which depends on other testlibrary classes. to make things even worse, Utils depends on OutputAnalyzer and there are lots of tests and test library classes which depend on Utils, so all of them will have to have at least '@build jdk.test.lib.Utils jdk.test.lib.process.OutputAnalyzer jdk.test.lib.process.ProcessTools'. and they will work stable till someone refactors them and extract some new classes. that is to say, it's nearly impossible to have all explicit @build actions. >> >> Cheers, >> -- Igor >> >>> On Jun 1, 2017, at 3:37 PM, Ioi Lam > wrote: >>> >>> >>> >>> On 6/1/17 1:17 PM, Igor Ignatyev wrote: >>>>> On Jun 1, 2017, at 1:20 AM, Chris Hegarty > wrote: >>>>> >>>>> Igor, >>>>> >>>>>> On 1 Jun 2017, at 04:32, Igor Ignatyev > wrote: >>>>>> >>>>>> Hi Felix, >>>>>> >>>>>> I have suggested the exact opposite change[1-3] to fix the same problem. >>>>> I?m sorry, but this is all just too confusing. After your change, who, or what, is >>>>> responsible for building/compiling the test library dependencies? >>>> jtreg is responsible, there is an implicit build for each @run, and jtreg will analyze a test class to get transitive closure for static dependencies, hence you have to have @build only for classes which are not in constant pool, e.g. used only by reflection or whose classnames are only used to spawn a new java instance. >>> >>> >>> I suspect the problem is caused by a long standing bug in jtreg that results in library classes being partially compiled. Please see my evaluation in >>> >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 >>> >>> In the bug report, there is test case that can reliably reproduce the NoClassDefFoundError problem. >>> >>> I think adding all the @build commands in the tests are just band-aids. Things will break unless every test explicitly uses @build to build every class in every library that they use, including all the private classes that are not directly accessible by the test cases. >>> >>> For example: doing this may be enough for now: >>> >>> * @build jdk.test.lib.process.* >>> >>> But what if in the future, jdk.test.lib.process is restructured to have a private package jdk.test.lib.process.hidden? To work around CODETOOLS-7901986, all the test cases that must be modified to the following, which unnecessarily exposes library implementation details to the library users: >>> >>> * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* >>> >>> Just imagine this -- "in order to use malloc() you must explicitly build not only malloc(), but also sbrk() ... and every other function in libc". That seems unreasonable to me. >>> >>> By the way, we made a fix in the HotSpot tests (see https://bugs.openjdk.java.net/browse/JDK-8157957 ) that got rid of many (but not all) of the NoClassDefFoundErrors by *removing* the @build lines ..... >>> >>> My proposal is, instead of just adding @build for band-aid, we should fix CODETOOLS-7901986 instead. >>> >>> Thanks >>> - Ioi >>> >>> >>>>> >>>>> Test library code has no @modules tags, so does not explicitly declare its >>>>> module dependencies. Instead module dependencies, required by test >>>>> library code, are declared in the test using the library. If we wildcard, or >>>>> otherwise leave broad build dependencies, from tests then there is no >>>>> way to know what new module dependencies may be added in the future. >>>>> That is, one of, the reason(s) I asked Felix to be explicit about the build >>>>> dependencies. >>>> having explicit builds does not really help w/ module dependency, if someone change a testlibrary class so it starts to depend on another testlibrary class, jtreg will implicitly build it and if this class has some module dependencies, you will have to reflect them in the test. >>>> >>>> generally speaking, I don't like having explicit build actions because build actions themselves are implicit, so they don't really help, it's still will be hard to spot missed explicit builds. not having (unneeded) explicit builds is an easy rule to follow and we can easily find all places which don't follow this rule by grep. >>>> >>>> -- Igor >>>>> -Chris. >>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >>>>>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >>>>>> [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html > From felix.yang at oracle.com Fri Jun 2 05:13:28 2017 From: felix.yang at oracle.com (Felix Yang) Date: Fri, 2 Jun 2017 13:13:28 +0800 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <4B7BC543-7A5A-4128-9433-DEDC2BCF27DB@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> <7a62f2ee-69bc-0281-3e2f-85a25d917e51@oracle.com> <4B7BC543-7A5A-4128-9433-DEDC2BCF27DB@oracle.com> Message-ID: Igor On 2017/6/2 10:11, Igor Ignatyev wrote: > Hi Felix, > > none of the jdk tests which fail w/ NCDFE: > jdk/test/lib/process/StreamPumper depend on StreamPumper directly, > they get this dependency transitively > from jdk/test/lib/process/ProcessTools, That is why I think it is a bug too. > so I don't see how you will find this good definition of "explicit" > even for the failures at hand. Just meant "expected behavior", as it makes test code clear for me. Of course it fails, otherwise there will be no such discussion at all. -Felix > > I recommend to work around this the same way we did it in hotspot, > which reliably removed almost all our NCDFE failures, -- remove > explicit @build, if not all for all classes, then at least for > jdk/test/lib/** classes. > > -- Igor > >> On Jun 1, 2017, at 6:52 PM, Felix Yang > > wrote: >> >> Hi Igor and Ioi, >> >> I partially agree with you. As initially stated in the proposal >> and bug(JDK-8181299 >> ), I don't think >> this patch is a fix but a quick workaround to make them runnable. >> >> "explicit" is reasonable for me. But "explicit" should not be >> restricted as "explicit all, including dependencies", as it is not >> productive or even realistic in the long term. >> >> Thanks, >> Felix >> On 2017/6/2 7:58, Igor Ignatyev wrote: >>>> For example: doing this may be enough for now: >>>> >>>> * @build jdk.test.lib.process.* >>>> >>>> But what if in the future, jdk.test.lib.process is restructured to >>>> have a private package jdk.test.lib.process.hidden? To work around >>>> CODETOOLS-7901986, all the test cases that must be modified to the >>>> following, which unnecessarily exposes library implementation >>>> details to the library users: >>>> >>>> * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* >>> >>> and in fact, there is already similar problem and >>> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ >>> does not >>> address it. >>> jdk/test/lib/process/ProcessTools depends on jdk/test/lib/Utils so >>> all tests which have '@build jdk.test.lib.process.ProcessTools' will >>> have to have '@build jdk.test.lib.Utils'. then we >>> have OutputAnalyzer which depends on ProcessTools so all tests which >>> @build jdk.test.lib.process.OutputAnalyzer will @build ProcessTools >>> and Utils explicitly. many testlibrary classes which on >>> jdk.test.lib.process.OutputAnalyzer, so one will have to >>> specify OutputAnalyzer ProcessTools and Utils in the tests which >>> depends on other testlibrary classes. to make things even worse, >>> Utils depends on OutputAnalyzer and there are lots of tests and test >>> library classes which depend on Utils, so all of them will have to >>> have at least '@build jdk.test.lib.Utils >>> jdk.test.lib.process.OutputAnalyzer jdk.test.lib.process.ProcessTools'. >>> and they will work stable till someone refactors them and extract >>> some new classes. that is to say, it's nearly impossible to have all >>> explicit @build actions. >>> >>> Cheers, >>> -- Igor >>> >>>> On Jun 1, 2017, at 3:37 PM, Ioi Lam >>> > wrote: >>>> >>>> >>>> >>>> On 6/1/17 1:17 PM, Igor Ignatyev wrote: >>>>>> On Jun 1, 2017, at 1:20 AM, Chris Hegarty >>>>>> > wrote: >>>>>> >>>>>> Igor, >>>>>> >>>>>>> On 1 Jun 2017, at 04:32, Igor Ignatyev >>>>>> > wrote: >>>>>>> >>>>>>> Hi Felix, >>>>>>> >>>>>>> I have suggested the exact opposite change[1-3] to fix the same >>>>>>> problem. >>>>>> I?m sorry, but this is all just too confusing. After your change, >>>>>> who, or what, is >>>>>> responsible for building/compiling the test library dependencies? >>>>> jtreg is responsible, there is an implicit build for each @run, >>>>> and jtreg will analyze a test class to get transitive closure for >>>>> static dependencies, hence you have to have @build only for >>>>> classes which are not in constant pool, e.g. used only by >>>>> reflection or whose classnames are only used to spawn a new java >>>>> instance. >>>> >>>> >>>> I suspect the problem is caused by a long standing bug in jtreg >>>> that results in library classes being partially compiled. Please >>>> see my evaluation in >>>> >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 >>>> >>>> In the bug report, there is test case that can reliably reproduce >>>> the NoClassDefFoundError problem. >>>> >>>> I think adding all the @build commands in the tests are just >>>> band-aids. Things will break unless every test explicitly uses >>>> @build to build every class in every library that they use, >>>> including all the private classes that are not directly accessible >>>> by the test cases. >>>> >>>> For example: doing this may be enough for now: >>>> >>>> * @build jdk.test.lib.process.* >>>> >>>> But what if in the future, jdk.test.lib.process is restructured to >>>> have a private package jdk.test.lib.process.hidden? To work around >>>> CODETOOLS-7901986, all the test cases that must be modified to the >>>> following, which unnecessarily exposes library implementation >>>> details to the library users: >>>> >>>> * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* >>>> >>>> Just imagine this -- "in order to use malloc() you must explicitly >>>> build not only malloc(), but also sbrk() ... and every other >>>> function in libc". That seems unreasonable to me. >>>> >>>> By the way, we made a fix in the HotSpot tests >>>> (seehttps://bugs.openjdk.java.net/browse/JDK-8157957) that got rid >>>> of many (but not all) of the NoClassDefFoundErrors by *removing* >>>> the @build lines ..... >>>> >>>> My proposal is, instead of just adding @build for band-aid, we >>>> should fix CODETOOLS-7901986 instead. >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>>>> >>>>>> Test library code has no @modules tags, so does not explicitly >>>>>> declare its >>>>>> module dependencies. Instead module dependencies, required by test >>>>>> library code, are declared in the test using the library. If we >>>>>> wildcard, or >>>>>> otherwise leave broad build dependencies, from tests then there is no >>>>>> way to know what new module dependencies may be added in the future. >>>>>> That is, one of, the reason(s) I asked Felix to be explicit about >>>>>> the build >>>>>> dependencies. >>>>> having explicit builds does not really help w/ module dependency, >>>>> if someone change a testlibrary class so it starts to depend on >>>>> another testlibrary class, jtreg will implicitly build it and if >>>>> this class has some module dependencies, you will have to reflect >>>>> them in the test. >>>>> >>>>> generally speaking, I don't like having explicit build actions >>>>> because build actions themselves are implicit, so they don't >>>>> really help, it's still will be hard to spot missed explicit >>>>> builds. not having (unneeded) explicit builds is an easy rule to >>>>> follow and we can easily find all places which don't follow this >>>>> rule by grep. >>>>> >>>>> -- Igor >>>>>> -Chris. >>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >>>>>>> [2] >>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >>>>>>> [3] >>>>>>> http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html >>>>>>> >>> >> > From roman.grigoriadi at oracle.com Fri Jun 2 05:29:33 2017 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Fri, 2 Jun 2017 07:29:33 +0200 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: <1AB6DFA3-81C4-4BA4-9697-5B9C6C3F81D0@oracle.com> References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> <1AB6DFA3-81C4-4BA4-9697-5B9C6C3F81D0@oracle.com> Message-ID: > On 1 Jun 2017, at 21:25, Mandy Chung wrote: > > >> On May 31, 2017, at 5:06 AM, Roman Grigoriadi wrote: >> >> Hi, >> >> New webrev can be found here: >> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ > > jaxp/src/java.xml/share/classes/module-info.java > I?m happy to see this qualified exports removed. > > Can you update jdk/test/jdk/modules/etc/JdkQualifiedExportTest.java to > remove "java.xml/com.sun.xml.internal.stream.writers? from KNOWN_EXCEPTION. > > java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java > java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java > jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/MrJarUtil.java > MrJarUtil::getNoPoolProperty is not MR specific. Are you trying to keep > the different default value when building for older release? In standalone MrJarUtil exists and is packaged twice, but there is no need / way to sync JDK8 and below version of this file. Here is second non-synced version of this file for 8 and below runtime: https://github.com/javaee/metro-jax-ws/blob/master/jaxws-ri/rt/src/main/java/com/sun/xml/ws/util/MrJarUtil.java > > It would be clearer if you want to define a constant for the default value that is subject to the runtime version. > > XMLStreamReaderFactory and XMLStreamWriterFactory would get the property value with the MR-specific default. > Than MrJarUtil would need to have only such constant for default value and metho getNoPoolProperty could be moved elsewhere. > That?re the files I reviewed. > > Mandy From mandy.chung at oracle.com Fri Jun 2 06:57:26 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Jun 2017 23:57:26 -0700 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com> <1AB6DFA3-81C4-4BA4-9697-5B9C6C3F81D0@oracle.com> Message-ID: > On Jun 1, 2017, at 10:29 PM, Roman Grigoriadi wrote: > > >> On 1 Jun 2017, at 21:25, Mandy Chung > wrote: >> >> >>> On May 31, 2017, at 5:06 AM, Roman Grigoriadi > wrote: >>> >>> Hi, >>> >>> New webrev can be found here: >>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ > >> >> jaxp/src/java.xml/share/classes/module-info.java >> I?m happy to see this qualified exports removed. >> >> Can you update jdk/test/jdk/modules/etc/JdkQualifiedExportTest.java to >> remove "java.xml/com.sun.xml.internal.stream.writers? from KNOWN_EXCEPTION. >> >> java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java >> java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java >> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/MrJarUtil.java >> MrJarUtil::getNoPoolProperty is not MR specific. Are you trying to keep >> the different default value when building for older release? > > In standalone MrJarUtil exists and is packaged twice, but there is no need / way to sync JDK8 and below version of this file. > Here is second non-synced version of this file for 8 and below runtime: > https://github.com/javaee/metro-jax-ws/blob/master/jaxws-ri/rt/src/main/java/com/sun/xml/ws/util/MrJarUtil.java >> >> It would be clearer if you want to define a constant for the default value that is subject to the runtime version. > >> >> XMLStreamReaderFactory and XMLStreamWriterFactory would get the property value with the MR-specific default. >> > > Than MrJarUtil would need to have only such constant for default value and metho getNoPoolProperty could be moved elsewhere. Since this is the only method right now, would it be better to check if Runtime.Version class is present, then use ?true? as the default for the ?noPool? property; otherwise ?false?. MrJarUtil seems a misleading name and maybe just move this method XMLStreamXXXFactory. It?s a suggestion. I won?t object if you want to keep this as is in JDK 9 and clean up in JDK 10 due to the timing. Mandy From daniel.fuchs at oracle.com Fri Jun 2 09:19:58 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 2 Jun 2017 10:19:58 +0100 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> Message-ID: <5f94d6e8-0a0d-bcf5-c5ed-9a522af3e213@oracle.com> Hi guys, The jtreg bug really needs to be fixed. What I hear is that adding an explicit @build in one test can make an unrelated test that depends on the same library but doesn't have the explicit @build fail (and possibly randomly and intermittently depending of the order in which tests are run). This is very unintuitive, and the 'obvious' (thouhj maybe wrong) fix for anyone stumbling on the issue would be to fix the failing test by adding the explicit @build - not grep the whole test base in search for a test that might have an explicit @build, which as pointed elsewhere might well be legitimate if the test is using reflection. So until the jtreg bug is fixed, I am not at all sure that removing all the explicit @build is the correct thing to do, as it's still bound to make existing unrelated tests fail randomly if new tests with an explicit @build are added later on... my2c -- daniel On 01/06/2017 23:37, Ioi Lam wrote: > > > On 6/1/17 1:17 PM, Igor Ignatyev wrote: >>> On Jun 1, 2017, at 1:20 AM, Chris Hegarty >>> wrote: >>> >>> Igor, >>> >>>> On 1 Jun 2017, at 04:32, Igor Ignatyev >>>> wrote: >>>> >>>> Hi Felix, >>>> >>>> I have suggested the exact opposite change[1-3] to fix the same >>>> problem. >>> I?m sorry, but this is all just too confusing. After your change, >>> who, or what, is >>> responsible for building/compiling the test library dependencies? >> jtreg is responsible, there is an implicit build for each @run, and >> jtreg will analyze a test class to get transitive closure for static >> dependencies, hence you have to have @build only for classes which are >> not in constant pool, e.g. used only by reflection or whose classnames >> are only used to spawn a new java instance. > > > I suspect the problem is caused by a long standing bug in jtreg that > results in library classes being partially compiled. Please see my > evaluation in > > https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 > > In the bug report, there is test case that can reliably reproduce the > NoClassDefFoundError problem. > > I think adding all the @build commands in the tests are just band-aids. > Things will break unless every test explicitly uses @build to build > every class in every library that they use, including all the private > classes that are not directly accessible by the test cases. > > For example: doing this may be enough for now: > > * @build jdk.test.lib.process.* > > But what if in the future, jdk.test.lib.process is restructured to have > a private package jdk.test.lib.process.hidden? To work around > CODETOOLS-7901986, all the test cases that must be modified to the > following, which unnecessarily exposes library implementation details to > the library users: > > * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* > > Just imagine this -- "in order to use malloc() you must explicitly build > not only malloc(), but also sbrk() ... and every other function in > libc". That seems unreasonable to me. > > By the way, we made a fix in the HotSpot tests (see > https://bugs.openjdk.java.net/browse/JDK-8157957) that got rid of many > (but not all) of the NoClassDefFoundErrors by *removing* the @build > lines ..... > > My proposal is, instead of just adding @build for band-aid, we should > fix CODETOOLS-7901986 instead. > > Thanks > - Ioi > > >>> >>> Test library code has no @modules tags, so does not explicitly >>> declare its >>> module dependencies. Instead module dependencies, required by test >>> library code, are declared in the test using the library. If we >>> wildcard, or >>> otherwise leave broad build dependencies, from tests then there is no >>> way to know what new module dependencies may be added in the future. >>> That is, one of, the reason(s) I asked Felix to be explicit about the >>> build >>> dependencies. >> having explicit builds does not really help w/ module dependency, if >> someone change a testlibrary class so it starts to depend on another >> testlibrary class, jtreg will implicitly build it and if this class >> has some module dependencies, you will have to reflect them in the test. >> >> generally speaking, I don't like having explicit build actions because >> build actions themselves are implicit, so they don't really help, it's >> still will be hard to spot missed explicit builds. not having >> (unneeded) explicit builds is an easy rule to follow and we can easily >> find all places which don't follow this rule by grep. >> >> -- Igor >>> -Chris. >>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >>>> >>>> [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html > From chris.hegarty at oracle.com Fri Jun 2 13:40:32 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 2 Jun 2017 14:40:32 +0100 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> Message-ID: <2e7ae109-2458-1540-069f-cb489a6a4ff3@oracle.com> On 02/06/17 00:14, Ioi Lam wrote: > ... > > The gem is hidden in the compile.0.jta file. It contains something like: > > -sourcepath :/jdk/foobar/test/lib: > > So if my test refers to a class under /test/lib, such as > jdk.test.lib.process.ProcessTools, javac will be able to locate it under > /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will > build it automatically. > > So really, there's no reason why the test must explicitly do an @build > of the library classes that it uses. Sure, you're relying on the implicit compilation of dependencies by javac. Look at the output, where it compiles the library classes to. It is part of the classes directory for the individual test. That means that the library classes will need to be compiled many many times. The @build tag will compile the library classes to a common output directory, where they can be reused ( unless I'm missing something ). -Chris. From ioi.lam at oracle.com Fri Jun 2 15:44:36 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 2 Jun 2017 08:44:36 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <2e7ae109-2458-1540-069f-cb489a6a4ff3@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> <2e7ae109-2458-1540-069f-cb489a6a4ff3@oracle.com> Message-ID: <82b8b490-41c4-3450-a32c-a830a906d43c@oracle.com> On 6/2/17 6:40 AM, Chris Hegarty wrote: > On 02/06/17 00:14, Ioi Lam wrote: >> ... >> >> The gem is hidden in the compile.0.jta file. It contains something like: >> >> -sourcepath :/jdk/foobar/test/lib: >> >> So if my test refers to a class under /test/lib, such as >> jdk.test.lib.process.ProcessTools, javac will be able to locate it under >> /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will >> build it automatically. >> >> So really, there's no reason why the test must explicitly do an @build >> of the library classes that it uses. > > Sure, you're relying on the implicit compilation of dependencies > by javac. Look at the output, where it compiles the library > classes to. It is part of the classes directory for the > individual test. That means that the library classes will need > to be compiled many many times. The @build tag will compile > the library classes to a common output directory, where they > can be reused ( unless I'm missing something ). > > -Chris. Yes, @build will compile classes so that they can be reused. But why should it be the responsibility of every test to do this? To reuse my malloc metaphore -- is it reasonable for every program that uses malloc to explicitly build libc? By the way, jtreg arranges the output directory of the test by the directory they sit in, so jdk/test/foo/bar/XTest.java jdk/test/foo/bar/YTest.java will all output their .class files to the same directory. Therefore, the amount of duplicated classes is not as bad as you might think. We've been omitting the @build tags in the hotspot tests and we haven't seen any problems. - Ioi From ioi.lam at oracle.com Fri Jun 2 16:04:52 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 2 Jun 2017 09:04:52 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <5f94d6e8-0a0d-bcf5-c5ed-9a522af3e213@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <87049e76-f95c-50c1-f901-e7e4919e6b12@oracle.com> <5f94d6e8-0a0d-bcf5-c5ed-9a522af3e213@oracle.com> Message-ID: <0ec9930c-02b3-a2de-8aed-de6e6d8c71a5@oracle.com> I agree with what Daniel said. Even without explicit @build tags (as in the reproducer in CODETOOLS-790198), if you use something like @run main RedefineClassHelper that would cause an implicit invocation of "@build test/lib", because RedefineClassHelper.java is part of test/lib So it's not possible to avoid @build altogether (even if you're not using reflection). ===== More explanation of the jtreg bug: In the CODETOOLS-790198 reproducer's case, another test (ModifyAnonymous.java) uses jdk.test.lib.compiler.InMemoryJavaCompiler without an explicit @build. Later, when RedefineRunningMethodsWithResolutionErrors.java is executed and runs "@run main RedefineClassHelper", the jtreg bug causes classes/test/lib to be partially compiled -- RedefineClassHelper.class is there, but InMemoryJavaCompiler.class is missing. Sure, according to the jtreg docs, "@build jdk.test.lib.compiler.InMemoryJavaCompiler" should be added to ModifyAnonymous.java. However, when you test fails because ANOTHER TEST forgets to add an @build, and you are looking at a sea of over 1000 test cases, you're completely lost. So what we have is a jtreg rule that says "you should ...", but there's no enforcement (every test runs perfectly fine by itself), and when failure happens there's no diagnostic that tells you who's to blame. Seems like a perfect recipe for anarchy. - Ioi On 6/2/17 2:19 AM, Daniel Fuchs wrote: > Hi guys, > > The jtreg bug really needs to be fixed. > What I hear is that adding an explicit @build in one test > can make an unrelated test that depends on the same library > but doesn't have the explicit @build fail (and possibly > randomly and intermittently depending of the order in > which tests are run). > > This is very unintuitive, and the 'obvious' (thouhj maybe > wrong) fix for anyone stumbling on the issue would be to fix > the failing test by adding the explicit @build - not grep > the whole test base in search for a test that might have an > explicit @build, which as pointed elsewhere might well be > legitimate if the test is using reflection. > > So until the jtreg bug is fixed, I am not at all sure that > removing all the explicit @build is the correct thing to do, > as it's still bound to make existing unrelated tests fail > randomly if new tests with an explicit @build are added > later on... > > my2c > > -- daniel > > On 01/06/2017 23:37, Ioi Lam wrote: >> >> >> On 6/1/17 1:17 PM, Igor Ignatyev wrote: >>>> On Jun 1, 2017, at 1:20 AM, Chris Hegarty >>>> wrote: >>>> >>>> Igor, >>>> >>>>> On 1 Jun 2017, at 04:32, Igor Ignatyev >>>>> wrote: >>>>> >>>>> Hi Felix, >>>>> >>>>> I have suggested the exact opposite change[1-3] to fix the same >>>>> problem. >>>> I?m sorry, but this is all just too confusing. After your change, >>>> who, or what, is >>>> responsible for building/compiling the test library dependencies? >>> jtreg is responsible, there is an implicit build for each @run, and >>> jtreg will analyze a test class to get transitive closure for static >>> dependencies, hence you have to have @build only for classes which >>> are not in constant pool, e.g. used only by reflection or whose >>> classnames are only used to spawn a new java instance. >> >> >> I suspect the problem is caused by a long standing bug in jtreg that >> results in library classes being partially compiled. Please see my >> evaluation in >> >> https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 >> >> In the bug report, there is test case that can reliably reproduce the >> NoClassDefFoundError problem. >> >> I think adding all the @build commands in the tests are just >> band-aids. Things will break unless every test explicitly uses @build >> to build every class in every library that they use, including all >> the private classes that are not directly accessible by the test cases. >> >> For example: doing this may be enough for now: >> >> * @build jdk.test.lib.process.* >> >> But what if in the future, jdk.test.lib.process is restructured to >> have a private package jdk.test.lib.process.hidden? To work around >> CODETOOLS-7901986, all the test cases that must be modified to the >> following, which unnecessarily exposes library implementation details >> to the library users: >> >> * @build jdk.test.lib.process.* jdk.test.lib.process.hidden.* >> >> Just imagine this -- "in order to use malloc() you must explicitly >> build not only malloc(), but also sbrk() ... and every other function >> in libc". That seems unreasonable to me. >> >> By the way, we made a fix in the HotSpot tests (see >> https://bugs.openjdk.java.net/browse/JDK-8157957) that got rid of >> many (but not all) of the NoClassDefFoundErrors by *removing* the >> @build lines ..... >> >> My proposal is, instead of just adding @build for band-aid, we should >> fix CODETOOLS-7901986 instead. >> >> Thanks >> - Ioi >> >> >>>> >>>> Test library code has no @modules tags, so does not explicitly >>>> declare its >>>> module dependencies. Instead module dependencies, required by test >>>> library code, are declared in the test using the library. If we >>>> wildcard, or >>>> otherwise leave broad build dependencies, from tests then there is no >>>> way to know what new module dependencies may be added in the future. >>>> That is, one of, the reason(s) I asked Felix to be explicit about >>>> the build >>>> dependencies. >>> having explicit builds does not really help w/ module dependency, if >>> someone change a testlibrary class so it starts to depend on another >>> testlibrary class, jtreg will implicitly build it and if this class >>> has some module dependencies, you will have to reflect them in the >>> test. >>> >>> generally speaking, I don't like having explicit build actions >>> because build actions themselves are implicit, so they don't really >>> help, it's still will be hard to spot missed explicit builds. not >>> having (unneeded) explicit builds is an easy rule to follow and we >>> can easily find all places which don't follow this rule by grep. >>> >>> -- Igor >>>> -Chris. >>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8181391 >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html >>>>> >>>>> [3] >>>>> http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html >> > From ioi.lam at oracle.com Fri Jun 2 16:14:19 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 2 Jun 2017 09:14:19 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <82b8b490-41c4-3450-a32c-a830a906d43c@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> <2e7ae109-2458-1540-069f-cb489a6a4ff3@oracle.com> <82b8b490-41c4-3450-a32c-a830a906d43c@oracle.com> Message-ID: On 6/2/17 8:44 AM, Ioi Lam wrote: > > > On 6/2/17 6:40 AM, Chris Hegarty wrote: >> On 02/06/17 00:14, Ioi Lam wrote: >>> ... >>> >>> The gem is hidden in the compile.0.jta file. It contains something >>> like: >>> >>> -sourcepath :/jdk/foobar/test/lib: >>> >>> So if my test refers to a class under /test/lib, such as >>> jdk.test.lib.process.ProcessTools, javac will be able to locate it >>> under >>> /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will >>> build it automatically. >>> >>> So really, there's no reason why the test must explicitly do an @build >>> of the library classes that it uses. >> >> Sure, you're relying on the implicit compilation of dependencies >> by javac. Look at the output, where it compiles the library >> classes to. It is part of the classes directory for the >> individual test. That means that the library classes will need >> to be compiled many many times. The @build tag will compile >> the library classes to a common output directory, where they >> can be reused ( unless I'm missing something ). >> >> -Chris. > Yes, @build will compile classes so that they can be reused. But why > should it be the responsibility of every test to do this? > > To reuse my malloc metaphore -- is it reasonable for every program > that uses malloc to explicitly build libc? > > By the way, jtreg arranges the output directory of the test by the > directory they sit in, so > > jdk/test/foo/bar/XTest.java > jdk/test/foo/bar/YTest.java > > will all output their .class files to the same directory. Therefore, > the amount of duplicated classes is not as bad as you might think. > We've been omitting the @build tags in the hotspot tests and we > haven't seen any problems. > > - Ioi To avoid repeat compilation of the library classes, a more reasonable solution would be: [1] Before test execution -- scan all the selected test to find all libraries specified by @library tags [2] Fully compile all the libraries into their own output directories [3] Then, start execution of the selected tests From igor.ignatyev at oracle.com Fri Jun 2 19:10:16 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 2 Jun 2017 12:10:16 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> <2e7ae109-2458-1540-069f-cb489a6a4ff3@oracle.com> <82b8b490-41c4-3450-a32c-a830a906d43c@oracle.com> Message-ID: > On Jun 2, 2017, at 9:14 AM, Ioi Lam wrote: > > On 6/2/17 8:44 AM, Ioi Lam wrote: >> >> On 6/2/17 6:40 AM, Chris Hegarty wrote: >>> On 02/06/17 00:14, Ioi Lam wrote: >>>> ... >>>> >>>> The gem is hidden in the compile.0.jta file. It contains something like: >>>> >>>> -sourcepath :/jdk/foobar/test/lib: >>>> >>>> So if my test refers to a class under /test/lib, such as >>>> jdk.test.lib.process.ProcessTools, javac will be able to locate it under >>>> /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will >>>> build it automatically. >>>> >>>> So really, there's no reason why the test must explicitly do an @build >>>> of the library classes that it uses. >>> >>> Sure, you're relying on the implicit compilation of dependencies >>> by javac. Look at the output, where it compiles the library >>> classes to. It is part of the classes directory for the >>> individual test. That means that the library classes will need >>> to be compiled many many times. The @build tag will compile >>> the library classes to a common output directory, where they >>> can be reused ( unless I'm missing something ). >>> >>> -Chris. >> Yes, @build will compile classes so that they can be reused. But why should it be the responsibility of every test to do this? >> >> To reuse my malloc metaphore -- is it reasonable for every program that uses malloc to explicitly build libc? >> >> By the way, jtreg arranges the output directory of the test by the directory they sit in, so >> >> jdk/test/foo/bar/XTest.java >> jdk/test/foo/bar/YTest.java >> >> will all output their .class files to the same directory. Therefore, the amount of duplicated classes is not as bad as you might think. We've been omitting the @build tags in the hotspot tests and we haven't seen any problems. >> >> - Ioi > To avoid repeat compilation of the library classes, a more reasonable solution would be: > > [1] Before test execution -- scan all the selected test to find all libraries specified by @library tags > > [2] Fully compile all the libraries into their own output directories > > [3] Then, start execution of the selected tests unfortunately, it is not that simple, there are at least 2 problems w/ that approach: 1. some of library classes have extra module dependency, e.g. jdk.test.lib.management.* depend on jdk.management module, ExtendedRobot (from jdk/test/testlibrary) depends on java.desktop. so compiling the whole library will require extra module dependency, which might be unneeded for the selected tests, as a result we won't be able to run these tests on configurations w/ limited module set. 2. to make our tests packagefull, we had to add '@library /' to many hotspot/test/compiler tests, so we will have to compile all files from hotspot/test. my take on all of this is that determination of output directory for classes is buggy, it uses directory of a @build or @run target to decide where put all produced classes files, but it should have mapping between source and destination paths instead, so all classes from jdk/test/foo/bar/ will go to a test scratch directory and all classes from /test/lib/ (assuming they are declared as @library) and /jdk/test/lib/ to different common directories which will be later added to classpath for the tests which use these libraries. Thanks, -- Igor From paul.sandoz at oracle.com Fri Jun 2 20:21:15 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Jun 2017 13:21:15 -0700 Subject: JDK 10 RFR of JDK-8181393: Refactor shell test Selector/lots_of_updates.sh and SocketChannel/Open.sh to java In-Reply-To: References: Message-ID: <549893D1-1B02-4060-8D0F-196A05D67689@oracle.com> > On 31 May 2017, at 23:45, Amy Lu wrote: > > java/nio/channels/Selector/lots_of_updates.sh > java/nio/channels/SocketChannel/Open.java which runs shell test: > * @run shell Open.sh > > Please review this patch to refactor above shell tests to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181393 > webrev: http://cr.openjdk.java.net/~amlu/8181393/webrev.00/ > +1 Out of curiosity is jtreg compilation of a test smart enough to know of at least some of its dependencies. 24 /* 25 * @test 26 * @bug 6824477 27 * @summary Selector.select can fail with IOException "Invalid argument" on 28 * Solaris if maximum number of file descriptors is less than 10000 29 * @requires (os.family != "windows") 30 * @library /test/lib 31 * @build LotsOfUpdates 32 * @run main LotsOfUpdatesTest 33 */ 34 35 import jdk.test.lib.process.ProcessTools; 36 37 public class LotsOfUpdatesTest { Do you require line 31 since LotsOfUpdatesTest refers directly to LotsOfUpdates? Paul. From paul.sandoz at oracle.com Fri Jun 2 21:08:05 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Jun 2017 14:08:05 -0700 Subject: RFR 8181413/10, Refactor test/sun/net/www/protocol/jar/jarbug/run.sh to plain java tests In-Reply-To: <6e2e1f59-04b7-4d70-f549-44d662d9c938@oracle.com> References: <6e2e1f59-04b7-4d70-f549-44d662d9c938@oracle.com> Message-ID: It looks ok, but i wonder why need to chmod? Paul. > On 1 Jun 2017, at 00:13, Felix Yang wrote: > > Hi there, > > please review the patch to covert a shell test to a plain java test, and simplify a few of unnecessary test logic. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8181413 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8181413/webrev.00/ > > Thanks, > > Felix > From paul.sandoz at oracle.com Fri Jun 2 21:13:37 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Jun 2017 14:13:37 -0700 Subject: RFR 8181414/10, Refactor misc test/sun/net/www/protocol/jar shell tests to plain java tests In-Reply-To: References: Message-ID: +1 Paul. > On 1 Jun 2017, at 00:39, Felix Yang wrote: > > Hi there, > > please review the patch to convert several shell tests to plain java tests. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8181414 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8181414/webrev.00/ > > Thanks, > > Felix > From igor.ignatyev at oracle.com Fri Jun 2 22:04:39 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 2 Jun 2017 15:04:39 -0700 Subject: RFR 8181414/10, Refactor misc test/sun/net/www/protocol/jar shell tests to plain java tests In-Reply-To: References: Message-ID: http://cr.openjdk.java.net/~xiaofeya/8181414/webrev.00/test/sun/net/www/protocol/jar/B5105410.java.udiff.html > + # @summary ZipFile$ZipFileInputStream doesn't close handle to zipfile a typo, it should be * @summary -- Igor > On Jun 1, 2017, at 12:39 AM, Felix Yang wrote: > > Hi there, > > please review the patch to convert several shell tests to plain java tests. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8181414 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8181414/webrev.00/ > > Thanks, > > Felix > From david.holmes at oracle.com Sat Jun 3 01:43:42 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 3 Jun 2017 11:43:42 +1000 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> <2e7ae109-2458-1540-069f-cb489a6a4ff3@oracle.com> <82b8b490-41c4-3450-a32c-a830a906d43c@oracle.com> Message-ID: <891dd5ce-9158-549c-4e1d-02534b3f08c2@oracle.com> On 3/06/2017 5:10 AM, Igor Ignatyev wrote: > >> On Jun 2, 2017, at 9:14 AM, Ioi Lam wrote: >> >> On 6/2/17 8:44 AM, Ioi Lam wrote: >>> >>> On 6/2/17 6:40 AM, Chris Hegarty wrote: >>>> On 02/06/17 00:14, Ioi Lam wrote: >>>>> ... >>>>> >>>>> The gem is hidden in the compile.0.jta file. It contains something like: >>>>> >>>>> -sourcepath :/jdk/foobar/test/lib: >>>>> >>>>> So if my test refers to a class under /test/lib, such as >>>>> jdk.test.lib.process.ProcessTools, javac will be able to locate it under >>>>> /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will >>>>> build it automatically. >>>>> >>>>> So really, there's no reason why the test must explicitly do an @build >>>>> of the library classes that it uses. >>>> >>>> Sure, you're relying on the implicit compilation of dependencies >>>> by javac. Look at the output, where it compiles the library >>>> classes to. It is part of the classes directory for the >>>> individual test. That means that the library classes will need >>>> to be compiled many many times. The @build tag will compile >>>> the library classes to a common output directory, where they >>>> can be reused ( unless I'm missing something ). >>>> >>>> -Chris. >>> Yes, @build will compile classes so that they can be reused. But why should it be the responsibility of every test to do this? >>> >>> To reuse my malloc metaphore -- is it reasonable for every program that uses malloc to explicitly build libc? >>> >>> By the way, jtreg arranges the output directory of the test by the directory they sit in, so >>> >>> jdk/test/foo/bar/XTest.java >>> jdk/test/foo/bar/YTest.java >>> >>> will all output their .class files to the same directory. Therefore, the amount of duplicated classes is not as bad as you might think. We've been omitting the @build tags in the hotspot tests and we haven't seen any problems. >>> >>> - Ioi >> To avoid repeat compilation of the library classes, a more reasonable solution would be: >> >> [1] Before test execution -- scan all the selected test to find all libraries specified by @library tags >> >> [2] Fully compile all the libraries into their own output directories >> >> [3] Then, start execution of the selected tests > > unfortunately, it is not that simple, there are at least 2 problems w/ that approach: > 1. some of library classes have extra module dependency, e.g. jdk.test.lib.management.* depend on jdk.management module, ExtendedRobot (from jdk/test/testlibrary) depends on java.desktop. so compiling the whole library will require extra module dependency, which might be unneeded for the selected tests, as a result we won't be able to run these tests on configurations w/ limited module set. > 2. to make our tests packagefull, we had to add '@library /' to many hotspot/test/compiler tests, so we will have to compile all files from hotspot/test. > > my take on all of this is that determination of output directory for classes is buggy, it uses directory of a @build or @run target to decide where put all produced classes files, but it should have mapping between source and destination paths instead, so all classes from jdk/test/foo/bar/ will go to a test scratch directory and all classes from /test/lib/ (assuming they are declared as @library) and /jdk/test/lib/ to different common directories which will be later added to classpath for the tests which use these libraries. But unless you explicitly compile the library classes you can't control where the class files are placed. The tests are compiled with a "-d" directive, so all classes, directly and implicitly compiled will be relative to that directory based on their package. If every test were declared in a package based on the source arrangement then jtreg would be able to use a common output directory. Neither suggested approach seems a great solution to me. Implicit compilation wastes effort rebuilding the libraries. Explicit compilation is instrusive and difficult to get right - and I have no idea how to get the module dependency stuff sorted out. Maybe the design flaw here is attempting to combine a test library with the tests that use it. You either want it to be a binary library jtreg can be pointed at, or you need a way to tell jtreg to build the library first and then use. But IIUC jtreg isn't set up to handle that - but it could be handled by running jtreg via make. My 2c. David > Thanks, > -- Igor > > > From igor.ignatyev at oracle.com Sat Jun 3 01:45:09 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 2 Jun 2017 18:45:09 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <82b8b490-41c4-3450-a32c-a830a906d43c@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> <2e7ae109-2458-1540-069f-cb489a6a4ff3@oracle.com> <82b8b490-41c4-3450-a32c-a830a906d43c@oracle.com> Message-ID: <5CAA67DE-1B70-431C-A15A-C898A8B608CE@oracle.com> I have measured how much time it takes to run :tier1 w/ and and w/o the fix which removes @build for jdk.test.lib.** classes[1-2]: - w/o 8181391, i.e. w/ @build: real 33m4.624s, user 111m56.758s, sys 6m24.022s. [3] is a breakdown for jtreg actions - w/ 8181391, i.e. w/o @build: real 32m17.259s, user 109m18.236s, sys 6m9.669s. [4] is a breakdown for jtreg actions as you can see there is no much difference in execution time, and the run w/o @build action was even a bit faster. the total time spend on build was lower. hence I'd say removing @build actions does not impact overall execution time. Even if it did, I don't think I'd prefer us to choose isolation and determinism over small performance improvements. as Ioi and I stated before, removing @build actions did not help in all cases in hotspot. the root cause of this is having @run actions whose target is a class from library, this is identical to have explicit @build action for this class. if this class has dependency on other classes from testlibrary, you can get a testlibrary split into different locations and as a results NCDFE in runtime due to CODETOOLS-7901986. Fortunately, it is not the case for jdk tests, the only test library class which is used in @run is ClassFileInstaller, which does not have any dependencies. Therefore I think removing explicit @build is a more reliable and clearer way to work around current problems and it does not have a big drawback if any. PS measurements were done on my mac 3.1 GHz Intel Core i7, 16 GB 1867 MHz DDR3, jtreg was run w/ "-conc:8 -agentvm" [1] http://scaab055.us.oracle.com:9502/vmsqe/home/iignatye/webrev//8181391/webrev.00/index.html [2] https://bugs.openjdk.java.net/browse/JDK-8181391 [3] compile: 826.206 build: 776.955 testng: 5362.58 junit: 640.705 shell: 861.206 main: 6823.19 clean: 0.004 driver: 6.578 [4] compile: 829.317 build: 774.904 testng: 5251 junit: 648.888 shell: 852.658 main: 6686.99 clean: 0.002 driver: 5.973 Thanks, -- Igor > On Jun 2, 2017, at 8:44 AM, Ioi Lam wrote: > > On 6/2/17 6:40 AM, Chris Hegarty wrote: >> On 02/06/17 00:14, Ioi Lam wrote: >>> ... >>> >>> The gem is hidden in the compile.0.jta file. It contains something like: >>> >>> -sourcepath :/jdk/foobar/test/lib: >>> >>> So if my test refers to a class under /test/lib, such as >>> jdk.test.lib.process.ProcessTools, javac will be able to locate it under >>> /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will >>> build it automatically. >>> >>> So really, there's no reason why the test must explicitly do an @build >>> of the library classes that it uses. >> >> Sure, you're relying on the implicit compilation of dependencies >> by javac. Look at the output, where it compiles the library >> classes to. It is part of the classes directory for the >> individual test. That means that the library classes will need >> to be compiled many many times. The @build tag will compile >> the library classes to a common output directory, where they >> can be reused ( unless I'm missing something ). >> >> -Chris. > Yes, @build will compile classes so that they can be reused. But why should it be the responsibility of every test to do this? > > To reuse my malloc metaphore -- is it reasonable for every program that uses malloc to explicitly build libc? > > By the way, jtreg arranges the output directory of the test by the directory they sit in, so > > jdk/test/foo/bar/XTest.java > jdk/test/foo/bar/YTest.java > > will all output their .class files to the same directory. Therefore, the amount of duplicated classes is not as bad as you might think. We've been omitting the @build tags in the hotspot tests and we haven't seen any problems. > > - Ioi From huaming.li at oracle.com Mon Jun 5 01:37:42 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 5 Jun 2017 09:37:42 +0800 Subject: (10) RFR of JDK-8180927: refactor ./java/io/Serializable/class/run.sh to java test In-Reply-To: References: Message-ID: Ping. Thank you -Hamlin On 2017/6/1 16:22, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8180927 > > webrev: http://cr.openjdk.java.net/~mli/8180927/webrev.00/ > > Thank you > > -Hamlin > From felix.yang at oracle.com Mon Jun 5 01:39:57 2017 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 5 Jun 2017 09:39:57 +0800 Subject: RFR 8181413/10, Refactor test/sun/net/www/protocol/jar/jarbug/run.sh to plain java tests In-Reply-To: References: <6e2e1f59-04b7-4d70-f549-44d662d9c938@oracle.com> Message-ID: <225e00fd-6ff1-5a7c-1d3f-65d1045f6871@oracle.com> Hi Paul, this is from original test logic. According with the bug history, it is added by https://bugs.openjdk.java.net/browse/JDK-7152892 to avoid intermittent test failures. Thanks, Felix On 2017/6/3 5:08, Paul Sandoz wrote: > It looks ok, but i wonder why need to chmod? > > Paul. > >> On 1 Jun 2017, at 00:13, Felix Yang wrote: >> >> Hi there, >> >> please review the patch to covert a shell test to a plain java test, and simplify a few of unnecessary test logic. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8181413 >> >> Webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8181413/webrev.00/ >> >> Thanks, >> >> Felix >> From felix.yang at oracle.com Mon Jun 5 02:01:43 2017 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 5 Jun 2017 10:01:43 +0800 Subject: RFR 8181414/10, Refactor misc test/sun/net/www/protocol/jar shell tests to plain java tests In-Reply-To: References: Message-ID: <56459324-14fb-2a89-2afe-17546fe67380@oracle.com> Igor and Paul, thanks for the review. Pushed with typo fixed. -Felix On 2017/6/3 6:04, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~xiaofeya/8181414/webrev.00/test/sun/net/www/protocol/jar/B5105410.java.udiff.html > > >> + # @summary ZipFile$ZipFileInputStream doesn't close handle to zipfile > a typo, it should be * @summary > > -- Igor > >> On Jun 1, 2017, at 12:39 AM, Felix Yang wrote: >> >> Hi there, >> >> please review the patch to convert several shell tests to plain >> java tests. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8181414 >> >> Webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8181414/webrev.00/ >> >> Thanks, >> >> Felix >> > From amy.lu at oracle.com Mon Jun 5 06:22:03 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 5 Jun 2017 14:22:03 +0800 Subject: JDK 10 RFR of JDK-8181393: Refactor shell test Selector/lots_of_updates.sh and SocketChannel/Open.sh to java In-Reply-To: <549893D1-1B02-4060-8D0F-196A05D67689@oracle.com> References: <549893D1-1B02-4060-8D0F-196A05D67689@oracle.com> Message-ID: <1a0c3e01-f9ea-0db3-4a8c-cdcfa9a2f60e@oracle.com> On 6/3/17 4:21 AM, Paul Sandoz wrote: >> webrev: http://cr.openjdk.java.net/~amlu/8181393/webrev.00/ >> >> > > +1 > > Out of curiosity is jtreg compilation of a test smart enough to know > of at least some of its dependencies. > > 24 /* > 25 * @test > 26 * @bug 6824477 > 27 * @summary Selector.select can fail with IOException "Invalid argument" on > 28 * Solaris if maximum number of file descriptors is less than 10000 > 29 * @requires (os.family != "windows") > 30 * @library /test/lib > 31 * @build LotsOfUpdates > 32 * @run main LotsOfUpdatesTest > 33 */ > 34 > 35 import jdk.test.lib.process.ProcessTools; > 36 > 37 public class LotsOfUpdatesTest { > Do you require line 31 since LotsOfUpdatesTest refers directly to > LotsOfUpdates? Actually test works fine without line 31 because it refers as LotsOfUpdates.class.getName() (instead of a String "LotsOfUpdates"). I still want the at build in this case just to indicate explicitly that the test has dependency other than @library Thank you Paul for reviewing. Pushed. Thanks, Amy From amy.lu at oracle.com Mon Jun 5 06:26:20 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 5 Jun 2017 14:26:20 +0800 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java In-Reply-To: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> References: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> Message-ID: Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.01 CreateFileTree is also used by other tests, no change. Thanks, Amy On 6/1/17 6:51 PM, Alan Bateman wrote: >> webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.00/ > I think it would be cleaner if you merged FindTest, CreateFileTree and > PrintFileTree. That should eliminate the need to launch PrintFileTree > in its own VM, it would make the test setup simpler too. Also it would > be nice to avoid SerializationUtils too. > > -Alan > From amy.lu at oracle.com Mon Jun 5 06:54:11 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 5 Jun 2017 14:54:11 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java Message-ID: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> java/nio/file/Files/delete_on_close.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181396 webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ Thanks, Amy From Alan.Bateman at oracle.com Mon Jun 5 14:52:08 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Jun 2017 15:52:08 +0100 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> Message-ID: <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> On 05/06/2017 07:54, Amy Lu wrote: > java/nio/file/Files/delete_on_close.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181396 > webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ I think it's a bit confusing to have both DeleteOnClose and DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself to create the file? -Alan From amy.lu at oracle.com Mon Jun 5 16:11:41 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 6 Jun 2017 00:11:41 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> Message-ID: <238ff235-0e4d-8889-32f1-753ffadf0a5f@oracle.com> Good point! Please review the updated version: http://cr.openjdk.java.net/~amlu/8181396/webrev.01 Thanks, Amy On 6/5/17 10:52 PM, Alan Bateman wrote: > On 05/06/2017 07:54, Amy Lu wrote: >> java/nio/file/Files/delete_on_close.sh >> >> Please review this patch to refactor the shell test to java. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8181396 >> webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ > I think it's a bit confusing to have both DeleteOnClose and > DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with > DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself to > create the file? > > -Alan From paul.sandoz at oracle.com Mon Jun 5 16:58:04 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Jun 2017 09:58:04 -0700 Subject: RFR 8181413/10, Refactor test/sun/net/www/protocol/jar/jarbug/run.sh to plain java tests In-Reply-To: <225e00fd-6ff1-5a7c-1d3f-65d1045f6871@oracle.com> References: <6e2e1f59-04b7-4d70-f549-44d662d9c938@oracle.com> <225e00fd-6ff1-5a7c-1d3f-65d1045f6871@oracle.com> Message-ID: <03E183A6-2DD1-48B4-AAC9-27422D74EB5D@oracle.com> Ok, thanks, Paul. > On Jun 4, 2017, at 18:39, Felix Yang wrote: > > Hi Paul, > > this is from original test logic. According with the bug history, it is added by https://bugs.openjdk.java.net/browse/JDK-7152892 to avoid intermittent test failures. > > Thanks, > Felix From amy.lu at oracle.com Mon Jun 5 18:03:24 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 6 Jun 2017 02:03:24 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <238ff235-0e4d-8889-32f1-753ffadf0a5f@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> <238ff235-0e4d-8889-32f1-753ffadf0a5f@oracle.com> Message-ID: <5baf0281-67e3-a0e3-e88f-99320d3f2b5c@oracle.com> On 6/6/17 12:11 AM, Amy Lu wrote: > Good point! > > Please review the updated version: > http://cr.openjdk.java.net/~amlu/8181396/webrev.01 Sorry, I have to withdraw this version. Somehow this does not work on Windows, the created blah*tmp will not be deleted until the launched DeleteOnClose (by itself) also exit. (webrev.00 works fine.) Thanks, Amy > > Thanks, > Amy > > On 6/5/17 10:52 PM, Alan Bateman wrote: >> On 05/06/2017 07:54, Amy Lu wrote: >>> java/nio/file/Files/delete_on_close.sh >>> >>> Please review this patch to refactor the shell test to java. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8181396 >>> webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ >> I think it's a bit confusing to have both DeleteOnClose and >> DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with >> DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself to >> create the file? >> >> -Alan > From jonathan.gibbons at oracle.com Mon Jun 5 22:08:52 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 05 Jun 2017 15:08:52 -0700 Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary In-Reply-To: <70aec07f-7357-4986-fb0d-4bc6a7dbbf86@oracle.com> References: <3b801b3a-1778-0085-7e0b-a3c92713d053@oracle.com> <70aec07f-7357-4986-fb0d-4bc6a7dbbf86@oracle.com> Message-ID: <5935D674.1080503@oracle.com> On 05/31/2017 01:38 AM, Alan Bateman wrote: > On 31/05/2017 09:05, Felix Yang wrote: > >> Hi Alan >> >> even with explicit compilation, I also observed failures. I'm >> curious what is the best practice here. IMO, there could be a >> potential jtreg bug. > One of the tests listed in JDK-8181299 is > java/net/URLConnection/6212146/TestDriver.java. In jdk10/jdk10 the > test description has: > > @build jdk.test.lib.JDKToolFinder jdk.test.lib.process.ProcessTools Test > > but the test fails intermittently with: > > java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper > at jdk.test.lib.process.ProcessTools.getOutput(ProcessTools.java:85) > at jdk.test.lib.process.OutputAnalyzer.(OutputAnalyzer.java:47) > at > jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:397) > at > jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:425) > at > jdk.test.lib.process.ProcessTools.executeCommand(ProcessTools.java:475) > at TestDriver.main(TestDriver.java:61) > > I assume changing the @build to jdk.test.lib.process.* will fix this, > assuming all the classes needed for ProcessTools are in this package. > > As to why it's intermittent then I think it's a side effect of test > library classes being compiled by one test and then re-used by a test > that runs sometime later in the same VM. Combine that with implicit > compilation, varied @build usages, and concurrently should explain why > it's intermittent. I see you've cc'ed Jon Gibbons and he is the best > person to comment on this. Now seems a good time to get to the bottom > of these issues, esp. with Igorchanging lots of tests to drop the > explicit compilation of test library classes. > > -Alan That's a Big Red Flag with a Titanic-sized fog-horn warning of the danger. jtreg is no different from make. If you want concurrency, you *must* provide accurate dependency information. As a general rule, each test should accurately define what library classes need to be built in order for it to be executed reliably and correctly in a multi-threaded environment. The one exception/clarification to make to that rule is that as a general rule, you can/should replace @compile with @build. @compile always performs a compilation, @build only performs the compilation if the .class file is out of date. I'll echo Alan's comment, which hit the nail on the head: > As to why it's intermittent then I think it's a side effect of test > library classes being compiled by one test and then re-used by a test > that runs sometime later in the same VM. Combine that with implicit > compilation, varied @build usages, and concurrently should explain why > it's intermittent. If you want a tip for seeing if you have the correct set o0f @build directives for a test ... use jtreg to build/run just that one test by itself in a *clean*/empty work directory. Look at the classes that were compiled. Were any of the generated classes compiled implicitly, i.e. not mentioned in @build directives? If so, add suitable @build directives. -- Jon From jonathan.gibbons at oracle.com Mon Jun 5 22:16:29 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 05 Jun 2017 15:16:29 -0700 Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary In-Reply-To: <758AC3CF-CB25-49C2-81D0-9C8D2AD9447A@oracle.com> References: <3b801b3a-1778-0085-7e0b-a3c92713d053@oracle.com> <70aec07f-7357-4986-fb0d-4bc6a7dbbf86@oracle.com> <758AC3CF-CB25-49C2-81D0-9C8D2AD9447A@oracle.com> Message-ID: <5935D83D.9010308@oracle.com> Igor, Ioi, I have read Ioi's mail and the supposed bug fix. While the fix may hide the problem, the root cause is still that tests are not providing accurate @build directives, and are relying on implicit compilation to compile the files. This is not the way that jtreg is intended to be used, and the fix merely helps hide the problem, albeit in a relatively elegant way. -- Jon On 05/31/2017 07:18 AM, Igor Ignatyev wrote: > Hi Alan, > > we believe it's a jtreg bug. we have seen similar intermittent failures in hotspot testing[1], Ioi(cc'ed) did a really great job analyzing the root cause[2], in to words jtreg puts a part of testlibrary to one path and another part to a different path. [3] is his suggested fix for jtreg. > > -- Igor > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 > [2] https://bugs.openjdk.java.net/secure/attachment/70197/jtreg_random_class_not_found.txt > [3] http://cr.openjdk.java.net/~iklam/jtreg/7901986_split_library/ > >> On May 31, 2017, at 1:38 AM, Alan Bateman wrote: >> >> On 31/05/2017 09:05, Felix Yang wrote: >> >>> Hi Alan >>> >>> even with explicit compilation, I also observed failures. I'm curious what is the best practice here. IMO, there could be a potential jtreg bug. >> One of the tests listed in JDK-8181299 is java/net/URLConnection/6212146/TestDriver.java. In jdk10/jdk10 the test description has: >> >> @build jdk.test.lib.JDKToolFinder jdk.test.lib.process.ProcessTools Test >> >> but the test fails intermittently with: >> >> java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper >> at jdk.test.lib.process.ProcessTools.getOutput(ProcessTools.java:85) >> at jdk.test.lib.process.OutputAnalyzer.(OutputAnalyzer.java:47) >> at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:397) >> at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:425) >> at jdk.test.lib.process.ProcessTools.executeCommand(ProcessTools.java:475) >> at TestDriver.main(TestDriver.java:61) >> >> I assume changing the @build to jdk.test.lib.process.* will fix this, assuming all the classes needed for ProcessTools are in this package. >> >> As to why it's intermittent then I think it's a side effect of test library classes being compiled by one test and then re-used by a test that runs sometime later in the same VM. Combine that with implicit compilation, varied @build usages, and concurrently should explain why it's intermittent. I see you've cc'ed Jon Gibbons and he is the best person to comment on this. Now seems a good time to get to the bottom of these issues, esp. with Igor changing lots of tests to drop the explicit compilation of test library classes. >> >> -Alan From jonathan.gibbons at oracle.com Mon Jun 5 22:20:24 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 05 Jun 2017 15:20:24 -0700 Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary In-Reply-To: References: Message-ID: <5935D928.2000805@oracle.com> On 05/31/2017 12:27 AM, Alan Bateman wrote: > On 27/05/2017 07:30, Igor Ignatyev wrote: > >> http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/index.html >>> 308 lines changed: 110 ins; 40 del; 158 mod >> > One general comment about all these moves is that I see that many > tests are being changed to no longer explicitly compile the test > infrastructure, instead I think it means the tests will rely on > implicit complication of the infrastructure classes - is that > intended? We've had a lot a issues in the past with agent VMs + > concurrency with implicit complication. Have you seen any issues with > these changes? > > -Alan Relying on implicit compilation sounds like a really bad idea. -- Jon From igor.ignatyev at oracle.com Mon Jun 5 22:20:49 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 5 Jun 2017 15:20:49 -0700 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <5CAA67DE-1B70-431C-A15A-C898A8B608CE@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> <9e03e223-73df-959d-41fe-2a0b9cccd98d@oracle.com> <2e7ae109-2458-1540-069f-cb489a6a4ff3@oracle.com> <82b8b490-41c4-3450-a32c-a830a906d43c@oracle.com> <5CAA67DE-1B70-431C-A15A-C898A8B608CE@oracle.com> Message-ID: <0A7DAAB5-E467-4675-A1B6-7915C052A682@oracle.com> just out of curiosity I have removed @build for all jdk.testlibary classes as well and run :tier1, it took approximately the same amount of time[1], the breakdown[2] shows that we spend 70 seconds more on build actions, which is not that big comparing to total execution time. -- Igor [1] real 33m39.697s user 112m5.722s sys 6m26.973s [2] compile: 903.9 build: 846.53 testng: 5515.98 junit: 674.429 shell: 885.103 main: 6973.12 clean: 0.001 driver: 9.125 > On Jun 2, 2017, at 6:45 PM, Igor Ignatyev wrote: > > I have measured how much time it takes to run :tier1 w/ and and w/o the fix which removes @build for jdk.test.lib.** classes[1-2]: > - w/o 8181391, i.e. w/ @build: real 33m4.624s, user 111m56.758s, sys 6m24.022s. [3] is a breakdown for jtreg actions > - w/ 8181391, i.e. w/o @build: real 32m17.259s, user 109m18.236s, sys 6m9.669s. [4] is a breakdown for jtreg actions > as you can see there is no much difference in execution time, and the run w/o @build action was even a bit faster. the total time spend on build was lower. hence I'd say removing @build actions does not impact overall execution time. Even if it did, I don't think I'd prefer us to choose isolation and determinism over small performance improvements. > > as Ioi and I stated before, removing @build actions did not help in all cases in hotspot. the root cause of this is having @run actions whose target is a class from library, this is identical to have explicit @build action for this class. if this class has dependency on other classes from testlibrary, you can get a testlibrary split into different locations and as a results NCDFE in runtime due to CODETOOLS-7901986. Fortunately, it is not the case for jdk tests, the only test library class which is used in @run is ClassFileInstaller, which does not have any dependencies. Therefore I think removing explicit @build is a more reliable and clearer way to work around current problems and it does not have a big drawback if any. > > PS measurements were done on my mac 3.1 GHz Intel Core i7, 16 GB 1867 MHz DDR3, jtreg was run w/ "-conc:8 -agentvm" > > [1] http://scaab055.us.oracle.com:9502/vmsqe/home/iignatye/webrev//8181391/webrev.00/index.html > [2] https://bugs.openjdk.java.net/browse/JDK-8181391 > [3] > compile: 826.206 > build: 776.955 > testng: 5362.58 > junit: 640.705 > shell: 861.206 > main: 6823.19 > clean: 0.004 > driver: 6.578 > [4] > compile: 829.317 > build: 774.904 > testng: 5251 > junit: 648.888 > shell: 852.658 > main: 6686.99 > clean: 0.002 > driver: 5.973 > > Thanks, > -- Igor > >> On Jun 2, 2017, at 8:44 AM, Ioi Lam > wrote: >> >> On 6/2/17 6:40 AM, Chris Hegarty wrote: >>> On 02/06/17 00:14, Ioi Lam wrote: >>>> ... >>>> >>>> The gem is hidden in the compile.0.jta file. It contains something like: >>>> >>>> -sourcepath :/jdk/foobar/test/lib: >>>> >>>> So if my test refers to a class under /test/lib, such as >>>> jdk.test.lib.process.ProcessTools, javac will be able to locate it under >>>> /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will >>>> build it automatically. >>>> >>>> So really, there's no reason why the test must explicitly do an @build >>>> of the library classes that it uses. >>> >>> Sure, you're relying on the implicit compilation of dependencies >>> by javac. Look at the output, where it compiles the library >>> classes to. It is part of the classes directory for the >>> individual test. That means that the library classes will need >>> to be compiled many many times. The @build tag will compile >>> the library classes to a common output directory, where they >>> can be reused ( unless I'm missing something ). >>> >>> -Chris. >> Yes, @build will compile classes so that they can be reused. But why should it be the responsibility of every test to do this? >> >> To reuse my malloc metaphore -- is it reasonable for every program that uses malloc to explicitly build libc? >> >> By the way, jtreg arranges the output directory of the test by the directory they sit in, so >> >> jdk/test/foo/bar/XTest.java >> jdk/test/foo/bar/YTest.java >> >> will all output their .class files to the same directory. Therefore, the amount of duplicated classes is not as bad as you might think. We've been omitting the @build tags in the hotspot tests and we haven't seen any problems. >> >> - Ioi > From martinrb at google.com Mon Jun 5 22:24:10 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Jun 2017 15:24:10 -0700 Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary In-Reply-To: <5935D928.2000805@oracle.com> References: <5935D928.2000805@oracle.com> Message-ID: Can we find missing @build directives by running each individual jtreg test by itself with a clean JTwork directory? From jonathan.gibbons at oracle.com Mon Jun 5 22:39:39 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 05 Jun 2017 15:39:39 -0700 Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary In-Reply-To: References: <5935D928.2000805@oracle.com> Message-ID: <5935DDAB.9080501@oracle.com> On 06/05/2017 03:24 PM, Martin Buchholz wrote: > Can we find missing @build directives by running each individual jtreg > test by itself with a clean JTwork directory? That's generally been the recommended way. You might also be able to do run groups of tests (such as all tests that use a given library) and then look for duplicate classes in the compiled classes directory. Such classes will generally be an indication of implicit compilation. -- Jon From vladimir.kozlov at oracle.com Mon Jun 5 22:43:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Jun 2017 15:43:32 -0700 Subject: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9 In-Reply-To: <007e16b8-b342-53e9-be52-91f5d01e9f55@oracle.com> References: <75E82CFC-EC08-4FDA-AFE0-B7572D0AAB25@oracle.com> <007e16b8-b342-53e9-be52-91f5d01e9f55@oracle.com> Message-ID: To clarify. I agree with this renaming to be pushed into JDK 9. AOT testing failures will be fixed separately as fix for 8180785 bug which requires changes in Graal. Renaming should be pushed first before we fix Graal to simplify Graal changes (no need to condition for JDK 10 and 9). Thanks, Vladimir On 6/1/17 11:28 AM, Vladimir Kozlov wrote: > Thank you, Paul, for backporting it. > > On 6/1/17 8:56 AM, Paul Sandoz wrote: >> Hi, >> >> To make it easier on 166 and Graal code to support both 9 and 10 we should back port the renaming of the internal Unsafe.compareAndSwap to Unsafe.compareAndSet: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-jdk/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-hotspot/webrev/ > > Hotspot changes are fine to me. > >> >> This is an explicit back port with a new bug. This is the easiest approach given the current nature of how 9 and 10 are currently kept in sync. >> >> The change sets are the same as those associated with the following issues and apply cleanly without modification: >> >> Rename internal Unsafe.compare methods >> https://bugs.openjdk.java.net/browse/JDK-8159995 >> >> [TESTBUG] Some hotspot tests broken after internal Unsafe name changes >> https://bugs.openjdk.java.net/browse/JDK-8180479 >> >> >> When running JPRT tests i observe a Graal test error on linux_x64_3.8-fastdebug-c2-hotspot_fast_compiler [*]. I dunno how this is manifesting given i cannot find any explicit reference to >> jdk.internal.Unsafe.compareAndSwap. Any idea? > > This is Graal bug I told about before - not all places in Graal are fixed with 8181292 changes (only a test was fixed): > > https://bugs.openjdk.java.net/browse/JDK-8180785 > > After you do backport we will fix Graal in JDK 9 and JDK 10. So don't worry about those failures. I will update 'Affected' and 'Fix' version later. > > Thanks, > Vladimir > >> >> Paul. >> >> [*] >> [2017-05-31 12:33:08,163] Agent[4]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: >> java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) >> [2017-05-31 12:33:08,163] Agent[4]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) >> [2017-05-31 12:33:08,213] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.callerNative()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: >> java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.callerNative(InvokeInterface.java:82) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: >> java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.(InvokeInterface.java:31) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.main([Ljava/lang/String;)V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: >> java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.main(InvokeInterface.java:35) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.callee(IJFDLjava/lang/String;)Z: >> org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.callee(InvokeInterface.java:60) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: >> java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) >> [2017-05-31 12:33:08,214] Agent[5]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) >> [2017-05-31 12:33:08,428] Agent[3]: stdout: Error: Failed compilation: compiler.calls.common.InvokeInterface.caller()V: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: >> java.lang.InternalError: java.lang.NoSuchMethodException: jdk.internal.misc.Unsafe.compareAndSwapInt(java.lang.Object, long, int, int) >> [2017-05-31 12:33:08,429] Agent[3]: stdout: at parsing app//compiler.calls.common.InvokeInterface.caller(InvokeInterface.java:45) >> TEST: compiler/aot/calls/fromAot/AotInvokeInterface2AotTest.java >> TEST JDK: /opt/jprt/T/P1/191630.sandoz/testproduct/linux_x64_3.8-fastdebug >> From paul.sandoz at oracle.com Mon Jun 5 22:41:55 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Jun 2017 15:41:55 -0700 Subject: (10) RFR of JDK-8180927: refactor ./java/io/Serializable/class/run.sh to java test In-Reply-To: References: Message-ID: I eyeballed quickly and it looks ok. NonSerializableTest -- 59 return new String[][][] { 60 // Write NonSerial1, Read NonSerial1 61 new String[][] {new String[] {"NonSerialA_1", "-cp", ".", "TestEntry", "-s", "A"}}, 62 new String[][] {new String[] {"NonSerialA_1", "-cp", ".", "TestEntry", "-d"}}, You don?t need declare the allocations within array initializer blocks. Paul. > On 4 Jun 2017, at 18:37, Hamlin Li wrote: > > Ping. > > Thank you > > -Hamlin > > > On 2017/6/1 16:22, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8180927 >> >> webrev: http://cr.openjdk.java.net/~mli/8180927/webrev.00/ >> >> Thank you >> >> -Hamlin >> > From paul.sandoz at oracle.com Mon Jun 5 22:48:45 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Jun 2017 15:48:45 -0700 Subject: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9 In-Reply-To: References: <75E82CFC-EC08-4FDA-AFE0-B7572D0AAB25@oracle.com> <007e16b8-b342-53e9-be52-91f5d01e9f55@oracle.com> Message-ID: Thanks. I accidentally deleted your first message so did not read it. Apologies for the confusion. Paul. > On 5 Jun 2017, at 15:43, Vladimir Kozlov wrote: > > To clarify. I agree with this renaming to be pushed into JDK 9. > > AOT testing failures will be fixed separately as fix for 8180785 bug which requires changes in Graal. Renaming should be pushed first before we fix Graal to simplify Graal changes (no need to condition for JDK 10 and 9). > > Thanks, > Vladimir From igor.ignatyev at oracle.com Mon Jun 5 22:50:03 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 5 Jun 2017 15:50:03 -0700 Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary In-Reply-To: <5935DDAB.9080501@oracle.com> References: <5935D928.2000805@oracle.com> <5935DDAB.9080501@oracle.com> Message-ID: <801828D0-3814-4013-A175-E2D69342FCCA@oracle.com> Hi Jon, if tests are supposed to declare all library classes they depend on, tests start to depend on a library design, so refactoring of the library will force us to do massive update of the tests to fix their explicit builds, but to find all such tests, we will have to run them one by one. so this approach does not really scale and it is also kinda fragile. if we can not relay on implicit compilation done by @build (and implicit @build) actions, shouldn't we remove it completely? or at least introduce a jtreg flag which disables it or reports all such usage as errors? this will give us a way to find all tests to fix and eventually will make the whole testsuite more reliable. -- Igor > On Jun 5, 2017, at 3:39 PM, Jonathan Gibbons wrote: > > > > On 06/05/2017 03:24 PM, Martin Buchholz wrote: >> Can we find missing @build directives by running each individual jtreg test by itself with a clean JTwork directory? > > That's generally been the recommended way. > > You might also be able to do run groups of tests (such as all tests that use a given library) and then look for duplicate classes in the compiled classes directory. Such classes will generally be an indication of implicit compilation. > > -- Jon From jonathan.gibbons at oracle.com Mon Jun 5 23:18:00 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 05 Jun 2017 16:18:00 -0700 Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary In-Reply-To: <801828D0-3814-4013-A175-E2D69342FCCA@oracle.com> References: <5935D928.2000805@oracle.com> <5935DDAB.9080501@oracle.com> <801828D0-3814-4013-A175-E2D69342FCCA@oracle.com> Message-ID: <5935E6A8.4010701@oracle.com> You cannot completely disable implicit compilation as a concept, because it is built into javac, and has been since Day One. But we could reduce its impact. javac does have an option -implicit:none, which stops it *writing* implicitly compiled classes, (but not stop it reading them). So the compilation will succeed, but the runtime may fail, because some necessary classes may not have been written. We may be able to test (play) with that idea by using the jtreg option "-javacoption: