From matthias.baesken at sap.com Tue Sep 3 15:26:41 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 3 Sep 2019 15:26:41 +0000 Subject: RFR: [XS] 8230485: add handling of aix tar in configure Message-ID: Hello, please review this small AIX related change . I noticed that configure does not recognize AIX tar correctly . This leads in the jdk/jdk AIX - build to a message : checking what type of tar was found... (without an info about the found tar ) Also the flag setting for aix tar is not correct . Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8230485 http://cr.openjdk.java.net/~mbaesken/webrevs/8230485.0/ From erik.joelsson at oracle.com Tue Sep 3 15:32:54 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 3 Sep 2019 08:32:54 -0700 Subject: RFR: [XS] 8230485: add handling of aix tar in configure In-Reply-To: References: Message-ID: <00420ecf-32d2-16e8-b6b0-3a49b4658d53@oracle.com> Looks good. /Erik On 2019-09-03 08:26, Baesken, Matthias wrote: > Hello, please review this small AIX related change . > > I noticed that configure does not recognize AIX tar correctly . This leads in the jdk/jdk AIX - build to a message : > > checking what type of tar was found... > (without an info about the found tar ) > > Also the flag setting for aix tar is not correct . > > > > Thanks, Matthias > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8230485 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230485.0/ > > > From erik.joelsson at oracle.com Fri Sep 6 17:13:42 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 6 Sep 2019 10:13:42 -0700 Subject: RFR: JDK-8230715: Baseline compare build on Windows fails intermittently in file type for jvm.pdb Message-ID: <620a18bc-cf62-ebca-4d22-591919e0c16c@oracle.com> The baseline compare builds on Windows fails intermittently. The output of the file command for jvm.pdb is not entirely stable. I have now seen a handful of failures over the last month looking like this: [2019-08-20T20:34:25,887Z] JDK File types... [2019-08-20T20:34:25,902Z] other: ./bin/server/jvm.pdb: MSVC program database ver 7.00, 4096*18031 bytes [2019-08-20T20:34:25,902Z] this : ./bin/server/jvm.pdb: MSVC program database ver 7.00, 4096*18033 bytes [2019-08-20T20:35:20,152Z] Test File types... [2019-08-20T20:35:20,152Z] other: ./bin/server/jvm.pdb: MSVC program database ver 7.00, 4096*18031 bytes [2019-08-20T20:35:20,152Z] this : ./bin/server/jvm.pdb: MSVC program database ver 7.00, 4096*18033 bytes We don't want to rely on the file command to compare file sizes, so I've implemented a special case for this type of file. Bug: https://bugs.openjdk.java.net/browse/JDK-8230715 Webrev: http://cr.openjdk.java.net/~erikj/8230715/webrev.01/ /Erik From mikael.vidstedt at oracle.com Fri Sep 6 19:46:32 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 6 Sep 2019 12:46:32 -0700 Subject: RFR: JDK-8230715: Baseline compare build on Windows fails intermittently in file type for jvm.pdb In-Reply-To: <620a18bc-cf62-ebca-4d22-591919e0c16c@oracle.com> References: <620a18bc-cf62-ebca-4d22-591919e0c16c@oracle.com> Message-ID: <546C08D5-4A90-41D4-93F6-2A3AFCF03352@oracle.com> Looks good. Cheers, Mikael > On Sep 6, 2019, at 10:13 AM, Erik Joelsson wrote: > > The baseline compare builds on Windows fails intermittently. The output of the file command for jvm.pdb is not entirely stable. I have now seen a handful of failures over the last month looking like this: > > [2019-08-20T20:34:25,887Z] JDK File types... > [2019-08-20T20:34:25,902Z] other: ./bin/server/jvm.pdb: MSVC program database ver 7.00, 4096*18031 bytes > [2019-08-20T20:34:25,902Z] this : ./bin/server/jvm.pdb: MSVC program database ver 7.00, 4096*18033 bytes > [2019-08-20T20:35:20,152Z] Test File types... > [2019-08-20T20:35:20,152Z] other: ./bin/server/jvm.pdb: MSVC program database ver 7.00, 4096*18031 bytes > [2019-08-20T20:35:20,152Z] this : ./bin/server/jvm.pdb: MSVC program database ver 7.00, 4096*18033 bytes > > We don't want to rely on the file command to compare file sizes, so I've implemented a special case for this type of file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230715 > > Webrev: http://cr.openjdk.java.net/~erikj/8230715/webrev.01/ > > /Erik > From joe.darcy at oracle.com Mon Sep 9 19:58:23 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 9 Sep 2019 12:58:23 -0700 Subject: JDK 14 RFR of 8225761: Update --release 13 symbol information after JDK 13 GA Message-ID: <65959e54-0763-bf17-0c26-eee2841f24d4@oracle.com> Hello, Looking ahead to JDK 13 GA scheduled for next week, please review ??? 8225761: Update --release 13 symbol information after JDK 13 GA ??? http://cr.openjdk.java.net/~darcy/8225761.0/ for JDK 14. This information was generated using JDK 13 b33. If there happens to be another JDK 13 build between now and GA, not expected, I'll regenerate the data. (I don't know why the list of modules in make/data/symbols/symbols differs between now and the previous time generation script was run.) Thanks, -Joe From leonid.mesnik at oracle.com Tue Sep 10 00:03:51 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 9 Sep 2019 17:03:51 -0700 Subject: RFR: 8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout Message-ID: Hi Could you please review following fix which add JTREG_FAILURE_HANDLER_TIMEOUT option to customize timeout handler timeout. webrev: http://cr.openjdk.java.net/~lmesnik/8230781/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8230781 I verified fix locally and with mach5. Leonid From david.holmes at oracle.com Tue Sep 10 00:12:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Sep 2019 10:12:18 +1000 Subject: RFR: 8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout In-Reply-To: References: Message-ID: <1df55fd1-d395-d666-dd9d-f85d23d05c8e@oracle.com> Hi Leonid, On 10/09/2019 10:03 am, Leonid Mesnik wrote: > Hi > > Could you please review following fix which add > JTREG_FAILURE_HANDLER_TIMEOUT option to customize timeout handler timeout. > > webrev: http://cr.openjdk.java.net/~lmesnik/8230781/webrev.00/ In terms of adding the flag the change itself appears okay to me. But what exactly is this timeout-handler timeout? We have enough issues with the timeout-handler running in response to test timeouts, let alone an additional timeout on top of that. Thanks, David > bug: https://bugs.openjdk.java.net/browse/JDK-8230781 > > I verified fix locally and with mach5. > > Leonid > From leonid.mesnik at oracle.com Tue Sep 10 00:43:30 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 9 Sep 2019 17:43:30 -0700 Subject: RFR: 8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout In-Reply-To: <1df55fd1-d395-d666-dd9d-f85d23d05c8e@oracle.com> References: <1df55fd1-d395-d666-dd9d-f85d23d05c8e@oracle.com> Message-ID: <4573e926-409e-c71e-e940-879d4e42a76f@oracle.com> Hi On 9/9/19 5:12 PM, David Holmes wrote: > Hi Leonid, > > On 10/09/2019 10:03 am, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which add >> JTREG_FAILURE_HANDLER_TIMEOUT option to customize timeout handler >> timeout. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8230781/webrev.00/ > > In terms of adding the flag the change itself appears okay to me. > > But what exactly is this timeout-handler timeout? We have enough > issues with the timeout-handler running in response to test timeouts, > let alone an additional timeout on top of that. > This timeout defines how long jtreg should wait for timeout handler completion. It helps to identify if timeout handler has any hangs during processing. Also it helps jtreg to complete in guaranteed time.? By default this feature? is disabled.? I want to enable it for some stress tests. http://openjdk.java.net/jtreg/faq.html#what-do-i-need-to-know-about-test-timeouts Leonid > Thanks, > David > >> bug: https://bugs.openjdk.java.net/browse/JDK-8230781 >> >> I verified fix locally and with mach5. >> >> Leonid >> From david.holmes at oracle.com Tue Sep 10 00:55:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Sep 2019 17:55:21 -0700 (PDT) Subject: RFR: 8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout In-Reply-To: <4573e926-409e-c71e-e940-879d4e42a76f@oracle.com> References: <1df55fd1-d395-d666-dd9d-f85d23d05c8e@oracle.com> <4573e926-409e-c71e-e940-879d4e42a76f@oracle.com> Message-ID: On 10/09/2019 10:43 am, Leonid Mesnik wrote: > Hi > > On 9/9/19 5:12 PM, David Holmes wrote: >> Hi Leonid, >> >> On 10/09/2019 10:03 am, Leonid Mesnik wrote: >>> Hi >>> >>> Could you please review following fix which add >>> JTREG_FAILURE_HANDLER_TIMEOUT option to customize timeout handler >>> timeout. >>> >>> webrev: http://cr.openjdk.java.net/~lmesnik/8230781/webrev.00/ >> >> In terms of adding the flag the change itself appears okay to me. >> >> But what exactly is this timeout-handler timeout? We have enough >> issues with the timeout-handler running in response to test timeouts, >> let alone an additional timeout on top of that. >> > This timeout defines how long jtreg should wait for timeout handler > completion. It helps to identify if timeout handler has any hangs during > processing. Also it helps jtreg to complete in guaranteed time.? By > default this feature? is disabled.? I want to enable it for some stress > tests. > > http://openjdk.java.net/jtreg/faq.html#what-do-i-need-to-know-about-test-timeouts Okay but what exactly happens with this timeout processing? Let's say the timeout handler is trying to run jstack and has hung, and this new timeout elapses - what happens? Will the attempt to execute jstack abort, or will something try to kill it? Can we end up with an orphaned hung jstack process on the machine? These are really jtreg questions though :) Cheers, David > > Leonid > >> Thanks, >> David >> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8230781 >>> >>> I verified fix locally and with mach5. >>> >>> Leonid >>> From leonid.mesnik at oracle.com Tue Sep 10 02:42:05 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 9 Sep 2019 19:42:05 -0700 Subject: RFR: 8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout In-Reply-To: References: <1df55fd1-d395-d666-dd9d-f85d23d05c8e@oracle.com> <4573e926-409e-c71e-e940-879d4e42a76f@oracle.com> Message-ID: <46321F06-8FFD-4A9E-86E7-B257D8ECF958@oracle.com> > On Sep 9, 2019, at 5:55 PM, David Holmes wrote: > > On 10/09/2019 10:43 am, Leonid Mesnik wrote: >> Hi >> On 9/9/19 5:12 PM, David Holmes wrote: >>> Hi Leonid, >>> >>> On 10/09/2019 10:03 am, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Could you please review following fix which add JTREG_FAILURE_HANDLER_TIMEOUT option to customize timeout handler timeout. >>>> >>>> webrev: http://cr.openjdk.java.net/~lmesnik/8230781/webrev.00/ >>> >>> In terms of adding the flag the change itself appears okay to me. >>> >>> But what exactly is this timeout-handler timeout? We have enough issues with the timeout-handler running in response to test timeouts, let alone an additional timeout on top of that. >>> >> This timeout defines how long jtreg should wait for timeout handler completion. It helps to identify if timeout handler has any hangs during processing. Also it helps jtreg to complete in guaranteed time. By default this feature is disabled. I want to enable it for some stress tests. >> http://openjdk.java.net/jtreg/faq.html#what-do-i-need-to-know-about-test-timeouts > > Okay but what exactly happens with this timeout processing? Let's say the timeout handler is trying to run jstack and has hung, and this new timeout elapses - what happens? Will the attempt to execute jstack abort, or will something try to kill it? Can we end up with an orphaned hung jstack process on the machine? The exact process of test timeout handling is: When test times out jtreg start process handler in separate thread and wait for it's completion . The current implementation of timeout handler run a bunch of tools as separate processes. Each tool is executed with it's own timeout and should be killed if hangs. This "timeout handler" timeout doesn't kill any processes by itself. It only reports about error and continue execution. Indeed such behavior might left stray processes and might look useless for someone. However this "timeout handler" timeout allows jtreg to complete test execution in the case if timeout handler stuck. I am going to use it for stress test execution where each task contains only single test. So task completed with test failure instead of getting task failure because of task timeout. As you know our task execution system doesn't provide any test results if task failed. So this is needed to somehow complete jtreg execution to get all results uploaded. Also it is responsibility of task execution system to clean hosts between tasks. Basically this change is needed only to complete jtreg execution and get test failures instead of hang execution with task failure. Leonid > > These are really jtreg questions though :) > > Cheers, > David > >> Leonid >>> Thanks, >>> David >>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8230781 >>>> >>>> I verified fix locally and with mach5. >>>> >>>> Leonid From jan.lahoda at oracle.com Tue Sep 10 12:36:25 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 10 Sep 2019 14:36:25 +0200 Subject: JDK 14 RFR of 8225761: Update --release 13 symbol information after JDK 13 GA In-Reply-To: <65959e54-0763-bf17-0c26-eee2841f24d4@oracle.com> References: <65959e54-0763-bf17-0c26-eee2841f24d4@oracle.com> Message-ID: <1bdc54de-f215-feb0-3780-f6b8866bfe71@oracle.com> Hi Joe, On 09. 09. 19 21:58, Joe Darcy wrote: > Hello, > > Looking ahead to JDK 13 GA scheduled for next week, please review > > ??? 8225761: Update --release 13 symbol information after JDK 13 GA > ??? http://cr.openjdk.java.net/~darcy/8225761.0/ > > for JDK 14. This information was generated using JDK 13 b33. If there > happens to be another JDK 13 build between now and GA, not expected, > I'll regenerate the data. > > (I don't know why the list of modules in make/data/symbols/symbols > differs between now and the previous time generation script was run.) I see two new modules were added: java.security.jgss and jdk.jartool. It seems there actually was an API added in java.security.jgss - field KRB_NT_ENTERPRISE in javax/security/auth/kerberos/KerberosPrincipal: http://hg.openjdk.java.net/jdk/jdk/rev/d65d3c37232c So I suspect the java.security.jgss-D.sym.txt will need to be included as well. For jdk.jartool, I don't think there was an API change, but some InnerClasses attribute was changed and the tool generated the description of the new state. So it might be good to include the jdk.jartool-D.sym.txt file as well. Thanks, Jan > > Thanks, > > -Joe > From erik.joelsson at oracle.com Tue Sep 10 13:17:01 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 10 Sep 2019 06:17:01 -0700 Subject: RFR: 8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-09-09 17:03, Leonid Mesnik wrote: > Hi > > Could you please review following fix which add > JTREG_FAILURE_HANDLER_TIMEOUT option to customize timeout handler > timeout. > > webrev: http://cr.openjdk.java.net/~lmesnik/8230781/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8230781 > > I verified fix locally and with mach5. > > Leonid > From joe.darcy at oracle.com Tue Sep 10 15:47:32 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 10 Sep 2019 08:47:32 -0700 Subject: JDK 14 RFR of 8225761: Update --release 13 symbol information after JDK 13 GA In-Reply-To: <1bdc54de-f215-feb0-3780-f6b8866bfe71@oracle.com> References: <65959e54-0763-bf17-0c26-eee2841f24d4@oracle.com> <1bdc54de-f215-feb0-3780-f6b8866bfe71@oracle.com> Message-ID: <55906c56-372a-6fbd-01c6-153bf98a66ae@oracle.com> Hi Jan, On 9/10/2019 5:36 AM, Jan Lahoda wrote: > Hi Joe, > > On 09. 09. 19 21:58, Joe Darcy wrote: >> Hello, >> >> Looking ahead to JDK 13 GA scheduled for next week, please review >> >> ???? 8225761: Update --release 13 symbol information after JDK 13 GA >> ???? http://cr.openjdk.java.net/~darcy/8225761.0/ >> >> for JDK 14. This information was generated using JDK 13 b33. If there >> happens to be another JDK 13 build between now and GA, not expected, >> I'll regenerate the data. >> >> (I don't know why the list of modules in make/data/symbols/symbols >> differs between now and the previous time generation script was run.) > > I see two new modules were added: java.security.jgss and jdk.jartool. > It seems there actually was an API added in java.security.jgss - field > KRB_NT_ENTERPRISE in javax/security/auth/kerberos/KerberosPrincipal: > http://hg.openjdk.java.net/jdk/jdk/rev/d65d3c37232c > > So I suspect the java.security.jgss-D.sym.txt will need to be included > as well. > > For jdk.jartool, I don't think there was an API change, but some > InnerClasses attribute was changed and the tool generated the > description of the new state. So it might be good to include the > jdk.jartool-D.sym.txt file as well. > I overlooked the new files that were created by the script; updated webrev: ??? http://cr.openjdk.java.net/~darcy/8225761.1/ Files added for java.security.jgss-D.sym.txt and jdk.jartool-D.sym.txt. Thanks, -Joe From jan.lahoda at oracle.com Tue Sep 10 16:05:24 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 10 Sep 2019 18:05:24 +0200 Subject: JDK 14 RFR of 8225761: Update --release 13 symbol information after JDK 13 GA In-Reply-To: <55906c56-372a-6fbd-01c6-153bf98a66ae@oracle.com> References: <65959e54-0763-bf17-0c26-eee2841f24d4@oracle.com> <1bdc54de-f215-feb0-3780-f6b8866bfe71@oracle.com> <55906c56-372a-6fbd-01c6-153bf98a66ae@oracle.com> Message-ID: Looks good to me, thanks! Jan On 10. 09. 19 17:47, Joe Darcy wrote: > Hi Jan, > > On 9/10/2019 5:36 AM, Jan Lahoda wrote: >> Hi Joe, >> >> On 09. 09. 19 21:58, Joe Darcy wrote: >>> Hello, >>> >>> Looking ahead to JDK 13 GA scheduled for next week, please review >>> >>> ???? 8225761: Update --release 13 symbol information after JDK 13 GA >>> ???? http://cr.openjdk.java.net/~darcy/8225761.0/ >>> >>> for JDK 14. This information was generated using JDK 13 b33. If there >>> happens to be another JDK 13 build between now and GA, not expected, >>> I'll regenerate the data. >>> >>> (I don't know why the list of modules in make/data/symbols/symbols >>> differs between now and the previous time generation script was run.) >> >> I see two new modules were added: java.security.jgss and jdk.jartool. >> It seems there actually was an API added in java.security.jgss - field >> KRB_NT_ENTERPRISE in javax/security/auth/kerberos/KerberosPrincipal: >> http://hg.openjdk.java.net/jdk/jdk/rev/d65d3c37232c >> >> So I suspect the java.security.jgss-D.sym.txt will need to be included >> as well. >> >> For jdk.jartool, I don't think there was an API change, but some >> InnerClasses attribute was changed and the tool generated the >> description of the new state. So it might be good to include the >> jdk.jartool-D.sym.txt file as well. >> > I overlooked the new files that were created by the script; updated webrev: > > ??? http://cr.openjdk.java.net/~darcy/8225761.1/ > > Files added for java.security.jgss-D.sym.txt and jdk.jartool-D.sym.txt. > > Thanks, > > -Joe > From leonid.mesnik at oracle.com Tue Sep 10 16:07:43 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 10 Sep 2019 09:07:43 -0700 Subject: RFR: 8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout In-Reply-To: References: Message-ID: <1FCF463C-45E0-441F-99E5-35F0846DB3E1@oracle.com> Thank you > On Sep 10, 2019, at 6:17 AM, Erik Joelsson wrote: > > Looks good. > > /Erik > > On 2019-09-09 17:03, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which add JTREG_FAILURE_HANDLER_TIMEOUT option to customize timeout handler timeout. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8230781/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8230781 >> >> I verified fix locally and with mach5. >> >> Leonid >> From joe.darcy at oracle.com Tue Sep 10 16:59:17 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 10 Sep 2019 09:59:17 -0700 Subject: JDK 14 RFR of 8225761: Update --release 13 symbol information after JDK 13 GA In-Reply-To: References: <65959e54-0763-bf17-0c26-eee2841f24d4@oracle.com> <1bdc54de-f215-feb0-3780-f6b8866bfe71@oracle.com> <55906c56-372a-6fbd-01c6-153bf98a66ae@oracle.com> Message-ID: <74e0e5fc-8b76-b40f-d9dc-ba8c702eb7dd@oracle.com> Thanks Jan; I'll get this pushed to JDK 14 shortly and if there happens to be a respin of JDK 13, push a follow-up. Thanks, -Joe On 9/10/2019 9:05 AM, Jan Lahoda wrote: > Looks good to me, thanks! > > Jan > > On 10. 09. 19 17:47, Joe Darcy wrote: >> Hi Jan, >> >> On 9/10/2019 5:36 AM, Jan Lahoda wrote: >>> Hi Joe, >>> >>> On 09. 09. 19 21:58, Joe Darcy wrote: >>>> Hello, >>>> >>>> Looking ahead to JDK 13 GA scheduled for next week, please review >>>> >>>> ???? 8225761: Update --release 13 symbol information after JDK 13 GA >>>> ???? http://cr.openjdk.java.net/~darcy/8225761.0/ >>>> >>>> for JDK 14. This information was generated using JDK 13 b33. If >>>> there happens to be another JDK 13 build between now and GA, not >>>> expected, I'll regenerate the data. >>>> >>>> (I don't know why the list of modules in make/data/symbols/symbols >>>> differs between now and the previous time generation script was run.) >>> >>> I see two new modules were added: java.security.jgss and >>> jdk.jartool. It seems there actually was an API added in >>> java.security.jgss - field KRB_NT_ENTERPRISE in >>> javax/security/auth/kerberos/KerberosPrincipal: >>> http://hg.openjdk.java.net/jdk/jdk/rev/d65d3c37232c >>> >>> So I suspect the java.security.jgss-D.sym.txt will need to be >>> included as well. >>> >>> For jdk.jartool, I don't think there was an API change, but some >>> InnerClasses attribute was changed and the tool generated the >>> description of the new state. So it might be good to include the >>> jdk.jartool-D.sym.txt file as well. >>> >> I overlooked the new files that were created by the script; updated >> webrev: >> >> ???? http://cr.openjdk.java.net/~darcy/8225761.1/ >> >> Files added for java.security.jgss-D.sym.txt and jdk.jartool-D.sym.txt. >> >> Thanks, >> >> -Joe >> From stooke at redhat.com Wed Sep 11 17:55:10 2019 From: stooke at redhat.com (Simon Tooke) Date: Wed, 11 Sep 2019 13:55:10 -0400 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 Message-ID: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> This is a trivial fix that has been sitting around since JDK8.? At one time, 8216354 was marked "won't fix", but I've seen people (including myself) run up against this issue enough that I think it should be addressed.? It's been reopened, and I have a webrev ready that I've tested in the jdk repo, on Windows.? It fixes the issue as described in the bug description.? I have tested the patch using a Cygwin build but not a WSL build. This patch alters a change introduced in https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autoconf/toolchain_windows.m4#l746 That change introduced an issue that prevented the use of directories with spaces. If this patch is accepted, I intend to backport it to 11u and 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk14/00/ Thank you, -Simon From erik.joelsson at oracle.com Wed Sep 11 20:13:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Sep 2019 13:13:00 -0700 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> References: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> Message-ID: <7b908cda-0955-e204-2baa-f99709a8bf1d@oracle.com> Looks good. /Erik On 2019-09-11 10:55, Simon Tooke wrote: > This is a trivial fix that has been sitting around since JDK8. > > At one time, 8216354 was marked "won't fix", but I've seen people > (including myself) run up against this issue enough that I think it > should be addressed.? It's been reopened, and I have a webrev ready that > I've tested in the jdk repo, on Windows.? It fixes the issue as > described in the bug description.? I have tested the patch using a > Cygwin build but not a WSL build. > > This patch alters a change introduced in > https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autoconf/toolchain_windows.m4#l746 > That change introduced an issue that prevented the use of directories > with spaces. > > If this patch is accepted, I intend to backport it to 11u and 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk14/00/ > > Thank you, > > -Simon > > > From david.holmes at oracle.com Wed Sep 11 22:07:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2019 08:07:47 +1000 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> References: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> Message-ID: Hi Simon, Erik, I'm a bit confused. Initially 8216354 was reported as already being fixed by 8215445. But the fix proposed here actually reverts a change from 8215445 which means that far from fixing this issue, 8215445 actually introduced it - correct? But 8215445 was only fixed in 13 - no backports - so it can't be responsible for any problem in 8u or 11u. So some other bug must have originally fixed this before 13, but was not itself backported to 8u or 11u. However the original version of the code was introduced by 8202557 in JDK 11 and was backported to 8u202/8u211. So the code there should be okay - no? The original code (still in 8u, I didn't check 11u) was: "$with_ucrt_dll_dir/*.dll" and the current proposed fix is: "$with_ucrt_dll_dir/"*.dll which suggests the new fix is less robust if the dll name were to contain a space rather than the path (but that's probably not good practice anyway). Or is there some further subtlety I'm missing here? Thanks, David ----- On 12/09/2019 3:55 am, Simon Tooke wrote: > This is a trivial fix that has been sitting around since JDK8. > > At one time, 8216354 was marked "won't fix", but I've seen people > (including myself) run up against this issue enough that I think it > should be addressed.? It's been reopened, and I have a webrev ready that > I've tested in the jdk repo, on Windows.? It fixes the issue as > described in the bug description.? I have tested the patch using a > Cygwin build but not a WSL build. > > This patch alters a change introduced in > https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autoconf/toolchain_windows.m4#l746 > That change introduced an issue that prevented the use of directories > with spaces. > > If this patch is accepted, I intend to backport it to 11u and 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk14/00/ > > Thank you, > > -Simon > > > From stooke at redhat.com Thu Sep 12 14:25:41 2019 From: stooke at redhat.com (Simon Tooke) Date: Thu, 12 Sep 2019 10:25:41 -0400 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: References: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> Message-ID: <3f48a6d8-ac5b-b0dd-1cff-ece4a162537f@redhat.com> On 9/11/2019 6:07 PM, David Holmes wrote: > Hi Simon, Erik, > > I'm a bit confused. Initially 8216354 was reported as already being > fixed by 8215445. But the fix proposed here actually reverts a change > from 8215445 which means that far from fixing this issue, 8215445 > actually introduced it - correct? > > But 8215445 was only fixed in 13 - no backports - so it can't be > responsible for any problem in 8u or 11u. So some other bug must have > originally fixed this before 13, but was not itself backported to 8u > or 11u. The actual history also includes the current jdk14 variant > line 811: if test -z "$(ls -d $with_ucrt_dll_dir/*.dll 2> /dev/null)"; then (i.e. no quotes at all; so failing at least the case where there is a space) If you look later in the file, there are lines that already incorporate use the proposed fix > 830: if test -z "$(ls -d "$UCRT_DLL_DIR/"*.dll 2> /dev/null)"; then ... > 835: || test -z "$(ls -d "$UCRT_DLL_DIR/"*.dll 2> /dev/null)"; then And there are some cases in other codepaths that may not handle spaces in paths either, but I am not addressing them here. > > However the original version of the code was introduced by 8202557 in > JDK 11 and was backported to 8u202/8u211. So the code there should be > okay - no? > > The original code (still in 8u, I didn't check 11u) was: > > "$with_ucrt_dll_dir/*.dll" > > and the current proposed fix is: > > "$with_ucrt_dll_dir/"*.dll > > which suggests the new fix is less robust if the dll name were to > contain a space rather than the path (but that's probably not good > practice anyway). Or is there some further subtlety I'm missing here? I have actually tested this fix in a cygwin build where there is a space in the path.? The directory was ??? "C:\tmp\build-jdk\ojdkbuild\tools\toolchain\sdk10_1607\Redist\ucrt\DLLs\ex x64" and the configuration argument: ??? --with-ucrt-dll-dir="%OJDKBUILD_DIR:/=\%\tools\toolchain\sdk10_1607\Redist\ucrt\DLLs\ex x64" > > > Thanks, > David > ----- Thanks for taking a look, -simon > > > On 12/09/2019 3:55 am, Simon Tooke wrote: >> This is a trivial fix that has been sitting around since JDK8. >> >> At one time, 8216354 was marked "won't fix", but I've seen people >> (including myself) run up against this issue enough that I think it >> should be addressed.? It's been reopened, and I have a webrev ready that >> I've tested in the jdk repo, on Windows.? It fixes the issue as >> described in the bug description.? I have tested the patch using a >> Cygwin build but not a WSL build. >> >> This patch alters a change introduced in >> https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autoconf/toolchain_windows.m4#l746 >> >> That change introduced an issue that prevented the use of directories >> with spaces. >> >> If this patch is accepted, I intend to backport it to 11u and 8u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 >> >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk14/00/ >> >> Thank you, >> >> -Simon >> >> >> From erik.joelsson at oracle.com Thu Sep 12 15:10:29 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Sep 2019 08:10:29 -0700 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: References: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> Message-ID: Hello David, The initial report was about this construct not working at all, as Bash will not expand wildcards inside of quotes: "$with_ucrt_dll_dir/*.dll" In 13 I changed that to remove the quotes to make the statement work at all. The drawback then, as Simon pointed out, was that if $with_ucrt_dll_dir contains a space, then it won't work. When declaring JDK-8216354 as already fixed, I did not consider the case with space. In my opinion, the proposed construct is the preferred one. The set of dlls are known and do not contain spaces. It's however common practice on Windows to install these dlls in directories that contain spaces. I would support backporting this fix as far back as anyone wants to, though the patch will not apply cleanly since different update lines currently have different variants of the statement. Note that internally at Oracle, this code path is not used in any official builds, so we are unaffected by this change, which is also why we have not detected it. /Erik On 2019-09-11 15:07, David Holmes wrote: > Hi Simon, Erik, > > I'm a bit confused. Initially 8216354 was reported as already being > fixed by 8215445. But the fix proposed here actually reverts a change > from 8215445 which means that far from fixing this issue, 8215445 > actually introduced it - correct? > > But 8215445 was only fixed in 13 - no backports - so it can't be > responsible for any problem in 8u or 11u. So some other bug must have > originally fixed this before 13, but was not itself backported to 8u > or 11u. > > However the original version of the code was introduced by 8202557 in > JDK 11 and was backported to 8u202/8u211. So the code there should be > okay - no? > > The original code (still in 8u, I didn't check 11u) was: > > "$with_ucrt_dll_dir/*.dll" > > and the current proposed fix is: > > "$with_ucrt_dll_dir/"*.dll > > which suggests the new fix is less robust if the dll name were to > contain a space rather than the path (but that's probably not good > practice anyway). Or is there some further subtlety I'm missing here? > > Thanks, > David > ----- > > > On 12/09/2019 3:55 am, Simon Tooke wrote: >> This is a trivial fix that has been sitting around since JDK8. >> >> At one time, 8216354 was marked "won't fix", but I've seen people >> (including myself) run up against this issue enough that I think it >> should be addressed.? It's been reopened, and I have a webrev ready that >> I've tested in the jdk repo, on Windows.? It fixes the issue as >> described in the bug description.? I have tested the patch using a >> Cygwin build but not a WSL build. >> >> This patch alters a change introduced in >> https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autoconf/toolchain_windows.m4#l746 >> >> That change introduced an issue that prevented the use of directories >> with spaces. >> >> If this patch is accepted, I intend to backport it to 11u and 8u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 >> >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk14/00/ >> >> Thank you, >> >> -Simon >> >> >> From christoph.langer at sap.com Thu Sep 12 20:00:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Sep 2019 20:00:56 +0000 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: References: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> Message-ID: Hi, I've also played with this already and support Simon's patch. Simon, shall I sponsor it for you? Best regards Christoph > -----Original Message----- > From: build-dev On Behalf Of Erik > Joelsson > Sent: Donnerstag, 12. September 2019 17:10 > To: David Holmes ; Simon Tooke > ; build-dev > Subject: Re: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 > > Hello David, > > The initial report was about this construct not working at all, as Bash > will not expand wildcards inside of quotes: > > "$with_ucrt_dll_dir/*.dll" > > In 13 I changed that to remove the quotes to make the statement work at > all. The drawback then, as Simon pointed out, was that if > $with_ucrt_dll_dir contains a space, then it won't work. When declaring > JDK-8216354 as already fixed, I did not consider the case with space. > > In my opinion, the proposed construct is the preferred one. The set of > dlls are known and do not contain spaces. It's however common practice > on Windows to install these dlls in directories that contain spaces. I > would support backporting this fix as far back as anyone wants to, > though the patch will not apply cleanly since different update lines > currently have different variants of the statement. > > Note that internally at Oracle, this code path is not used in any > official builds, so we are unaffected by this change, which is also why > we have not detected it. > > /Erik > > On 2019-09-11 15:07, David Holmes wrote: > > Hi Simon, Erik, > > > > I'm a bit confused. Initially 8216354 was reported as already being > > fixed by 8215445. But the fix proposed here actually reverts a change > > from 8215445 which means that far from fixing this issue, 8215445 > > actually introduced it - correct? > > > > But 8215445 was only fixed in 13 - no backports - so it can't be > > responsible for any problem in 8u or 11u. So some other bug must have > > originally fixed this before 13, but was not itself backported to 8u > > or 11u. > > > > However the original version of the code was introduced by 8202557 in > > JDK 11 and was backported to 8u202/8u211. So the code there should be > > okay - no? > > > > The original code (still in 8u, I didn't check 11u) was: > > > > "$with_ucrt_dll_dir/*.dll" > > > > and the current proposed fix is: > > > > "$with_ucrt_dll_dir/"*.dll > > > > which suggests the new fix is less robust if the dll name were to > > contain a space rather than the path (but that's probably not good > > practice anyway). Or is there some further subtlety I'm missing here? > > > > Thanks, > > David > > ----- > > > > > > On 12/09/2019 3:55 am, Simon Tooke wrote: > >> This is a trivial fix that has been sitting around since JDK8. > >> > >> At one time, 8216354 was marked "won't fix", but I've seen people > >> (including myself) run up against this issue enough that I think it > >> should be addressed.? It's been reopened, and I have a webrev ready that > >> I've tested in the jdk repo, on Windows.? It fixes the issue as > >> described in the bug description.? I have tested the patch using a > >> Cygwin build but not a WSL build. > >> > >> This patch alters a change introduced in > >> > https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autocon > f/toolchain_windows.m4#l746 > >> > >> That change introduced an issue that prevented the use of directories > >> with spaces. > >> > >> If this patch is accepted, I intend to backport it to 11u and 8u. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 > >> > >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354- > jdk14/00/ > >> > >> Thank you, > >> > >> -Simon > >> > >> > >> From stooke at redhat.com Thu Sep 12 20:25:15 2019 From: stooke at redhat.com (Simon Tooke) Date: Thu, 12 Sep 2019 16:25:15 -0400 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: References: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> Message-ID: On 9/12/2019 4:00 PM, Langer, Christoph wrote: > Hi, > > I've also played with this already and support Simon's patch. > > Simon, shall I sponsor it for you? Yes please, (and thank you).? -Simon > > Best regards > Christoph > >> -----Original Message----- >> From: build-dev On Behalf Of Erik >> Joelsson >> Sent: Donnerstag, 12. September 2019 17:10 >> To: David Holmes ; Simon Tooke >> ; build-dev >> Subject: Re: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 >> >> Hello David, >> >> The initial report was about this construct not working at all, as Bash >> will not expand wildcards inside of quotes: >> >> "$with_ucrt_dll_dir/*.dll" >> >> In 13 I changed that to remove the quotes to make the statement work at >> all. The drawback then, as Simon pointed out, was that if >> $with_ucrt_dll_dir contains a space, then it won't work. When declaring >> JDK-8216354 as already fixed, I did not consider the case with space. >> >> In my opinion, the proposed construct is the preferred one. The set of >> dlls are known and do not contain spaces. It's however common practice >> on Windows to install these dlls in directories that contain spaces. I >> would support backporting this fix as far back as anyone wants to, >> though the patch will not apply cleanly since different update lines >> currently have different variants of the statement. >> >> Note that internally at Oracle, this code path is not used in any >> official builds, so we are unaffected by this change, which is also why >> we have not detected it. >> >> /Erik >> >> On 2019-09-11 15:07, David Holmes wrote: >>> Hi Simon, Erik, >>> >>> I'm a bit confused. Initially 8216354 was reported as already being >>> fixed by 8215445. But the fix proposed here actually reverts a change >>> from 8215445 which means that far from fixing this issue, 8215445 >>> actually introduced it - correct? >>> >>> But 8215445 was only fixed in 13 - no backports - so it can't be >>> responsible for any problem in 8u or 11u. So some other bug must have >>> originally fixed this before 13, but was not itself backported to 8u >>> or 11u. >>> >>> However the original version of the code was introduced by 8202557 in >>> JDK 11 and was backported to 8u202/8u211. So the code there should be >>> okay - no? >>> >>> The original code (still in 8u, I didn't check 11u) was: >>> >>> "$with_ucrt_dll_dir/*.dll" >>> >>> and the current proposed fix is: >>> >>> "$with_ucrt_dll_dir/"*.dll >>> >>> which suggests the new fix is less robust if the dll name were to >>> contain a space rather than the path (but that's probably not good >>> practice anyway). Or is there some further subtlety I'm missing here? >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> On 12/09/2019 3:55 am, Simon Tooke wrote: >>>> This is a trivial fix that has been sitting around since JDK8. >>>> >>>> At one time, 8216354 was marked "won't fix", but I've seen people >>>> (including myself) run up against this issue enough that I think it >>>> should be addressed.? It's been reopened, and I have a webrev ready that >>>> I've tested in the jdk repo, on Windows.? It fixes the issue as >>>> described in the bug description.? I have tested the patch using a >>>> Cygwin build but not a WSL build. >>>> >>>> This patch alters a change introduced in >>>> >> https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autocon >> f/toolchain_windows.m4#l746 >>>> That change introduced an issue that prevented the use of directories >>>> with spaces. >>>> >>>> If this patch is accepted, I intend to backport it to 11u and 8u. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 >>>> >>>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354- >> jdk14/00/ >>>> Thank you, >>>> >>>> -Simon >>>> >>>> >>>> From david.holmes at oracle.com Fri Sep 13 05:47:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2019 15:47:17 +1000 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: References: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> Message-ID: <89899f06-6784-4b9a-900b-6326c5213982@oracle.com> Erik, Simon, Thanks for clarifying things. It would have been somewhat clearer if a new bug for the space-in-path problem has been filed rather then reopening the existing issue. Cheers, David On 13/09/2019 1:10 am, Erik Joelsson wrote: > Hello David, > > The initial report was about this construct not working at all, as Bash > will not expand wildcards inside of quotes: > > "$with_ucrt_dll_dir/*.dll" > > In 13 I changed that to remove the quotes to make the statement work at > all. The drawback then, as Simon pointed out, was that if > $with_ucrt_dll_dir contains a space, then it won't work. When declaring > JDK-8216354 as already fixed, I did not consider the case with space. > > In my opinion, the proposed construct is the preferred one. The set of > dlls are known and do not contain spaces. It's however common practice > on Windows to install these dlls in directories that contain spaces. I > would support backporting this fix as far back as anyone wants to, > though the patch will not apply cleanly since different update lines > currently have different variants of the statement. > > Note that internally at Oracle, this code path is not used in any > official builds, so we are unaffected by this change, which is also why > we have not detected it. > > /Erik > > On 2019-09-11 15:07, David Holmes wrote: >> Hi Simon, Erik, >> >> I'm a bit confused. Initially 8216354 was reported as already being >> fixed by 8215445. But the fix proposed here actually reverts a change >> from 8215445 which means that far from fixing this issue, 8215445 >> actually introduced it - correct? >> >> But 8215445 was only fixed in 13 - no backports - so it can't be >> responsible for any problem in 8u or 11u. So some other bug must have >> originally fixed this before 13, but was not itself backported to 8u >> or 11u. >> >> However the original version of the code was introduced by 8202557 in >> JDK 11 and was backported to 8u202/8u211. So the code there should be >> okay - no? >> >> The original code (still in 8u, I didn't check 11u) was: >> >> "$with_ucrt_dll_dir/*.dll" >> >> and the current proposed fix is: >> >> "$with_ucrt_dll_dir/"*.dll >> >> which suggests the new fix is less robust if the dll name were to >> contain a space rather than the path (but that's probably not good >> practice anyway). Or is there some further subtlety I'm missing here? >> >> Thanks, >> David >> ----- >> >> >> On 12/09/2019 3:55 am, Simon Tooke wrote: >>> This is a trivial fix that has been sitting around since JDK8. >>> >>> At one time, 8216354 was marked "won't fix", but I've seen people >>> (including myself) run up against this issue enough that I think it >>> should be addressed.? It's been reopened, and I have a webrev ready that >>> I've tested in the jdk repo, on Windows.? It fixes the issue as >>> described in the bug description.? I have tested the patch using a >>> Cygwin build but not a WSL build. >>> >>> This patch alters a change introduced in >>> https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autoconf/toolchain_windows.m4#l746 >>> >>> That change introduced an issue that prevented the use of directories >>> with spaces. >>> >>> If this patch is accepted, I intend to backport it to 11u and 8u. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 >>> >>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk14/00/ >>> >>> Thank you, >>> >>> -Simon >>> >>> >>> From stooke at redhat.com Fri Sep 13 14:05:14 2019 From: stooke at redhat.com (Simon Tooke) Date: Fri, 13 Sep 2019 10:05:14 -0400 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u Message-ID: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Hello all, This is a request for review of my patch to enable building 8u with modern (9,10,11) Xcode versions on macOS.? I've received a few recent enquiries so I thought I'd submit this. When I first created this patch is was more for convenience, but soon macOS will require applications to be "notarized", which cannot be done with the old version of Xcode.? This will become mandatory long before 8u is due to retire [1]. This patch is not intended to remove the current ability to build 8u on the current supported build platform. I have used the patch with Xcode 9,10 and a beta of 11, and used the resultant JDK to build Graal.? I have not build a JDK using the old Xcode and this patch; my intent was to ensure this was still possible. There is some information available on my GitHub page: https://github.com/stooke/jdk8u-xcode10 Issue: https://bugs.openjdk.java.net/browse/JDK-8226288 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/00/ Previous discussion:? https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009733.html? https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009760.html Thank you for your time, -Simon [1] https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution From spaace at gmail.com Fri Sep 13 16:35:03 2019 From: spaace at gmail.com (spaace) Date: Fri, 13 Sep 2019 22:05:03 +0530 Subject: External .debuginfo files Message-ID: Hi, Can someone please explain how external .debuginfo files are used? When jdk build is run, i can see that it generates .debug files in the .debuginfo package. However if i provide the flag "--with-native-debug-symbols=external", a set of .debuginfo files are also created. I know that GDB and similar tools know how to use the .debug files but iam not sure who/what can use the .debuginfo files. In general what are the recommended settings for creating release binaries, along with EXTERNAL files that do not affect the run time, but can be used to debug the libraries IF REQUIRED? Thanks Arun From christoph.langer at sap.com Sun Sep 15 05:49:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 15 Sep 2019 05:49:28 +0000 Subject: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: References: <8a9a0cd0-e318-8277-9af5-e2bf943b289d@redhat.com> Message-ID: Done. http://hg.openjdk.java.net/jdk/jdk/rev/593005ac5a0a > -----Original Message----- > From: Simon Tooke > Sent: Donnerstag, 12. September 2019 22:25 > To: Langer, Christoph ; Erik Joelsson > ; David Holmes ; > build-dev > Subject: Re: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 > > > On 9/12/2019 4:00 PM, Langer, Christoph wrote: > > Hi, > > > > I've also played with this already and support Simon's patch. > > > > Simon, shall I sponsor it for you? > > Yes please, (and thank you). > > -Simon > > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: build-dev On Behalf Of > Erik > >> Joelsson > >> Sent: Donnerstag, 12. September 2019 17:10 > >> To: David Holmes ; Simon Tooke > >> ; build-dev > >> Subject: Re: JDK 14 RFR: 8216354: Syntax error in toolchain_windows.m4 > >> > >> Hello David, > >> > >> The initial report was about this construct not working at all, as Bash > >> will not expand wildcards inside of quotes: > >> > >> "$with_ucrt_dll_dir/*.dll" > >> > >> In 13 I changed that to remove the quotes to make the statement work at > >> all. The drawback then, as Simon pointed out, was that if > >> $with_ucrt_dll_dir contains a space, then it won't work. When declaring > >> JDK-8216354 as already fixed, I did not consider the case with space. > >> > >> In my opinion, the proposed construct is the preferred one. The set of > >> dlls are known and do not contain spaces. It's however common practice > >> on Windows to install these dlls in directories that contain spaces. I > >> would support backporting this fix as far back as anyone wants to, > >> though the patch will not apply cleanly since different update lines > >> currently have different variants of the statement. > >> > >> Note that internally at Oracle, this code path is not used in any > >> official builds, so we are unaffected by this change, which is also why > >> we have not detected it. > >> > >> /Erik > >> > >> On 2019-09-11 15:07, David Holmes wrote: > >>> Hi Simon, Erik, > >>> > >>> I'm a bit confused. Initially 8216354 was reported as already being > >>> fixed by 8215445. But the fix proposed here actually reverts a change > >>> from 8215445 which means that far from fixing this issue, 8215445 > >>> actually introduced it - correct? > >>> > >>> But 8215445 was only fixed in 13 - no backports - so it can't be > >>> responsible for any problem in 8u or 11u. So some other bug must have > >>> originally fixed this before 13, but was not itself backported to 8u > >>> or 11u. > >>> > >>> However the original version of the code was introduced by 8202557 in > >>> JDK 11 and was backported to 8u202/8u211. So the code there should be > >>> okay - no? > >>> > >>> The original code (still in 8u, I didn't check 11u) was: > >>> > >>> "$with_ucrt_dll_dir/*.dll" > >>> > >>> and the current proposed fix is: > >>> > >>> "$with_ucrt_dll_dir/"*.dll > >>> > >>> which suggests the new fix is less robust if the dll name were to > >>> contain a space rather than the path (but that's probably not good > >>> practice anyway). Or is there some further subtlety I'm missing here? > >>> > >>> Thanks, > >>> David > >>> ----- > >>> > >>> > >>> On 12/09/2019 3:55 am, Simon Tooke wrote: > >>>> This is a trivial fix that has been sitting around since JDK8. > >>>> > >>>> At one time, 8216354 was marked "won't fix", but I've seen people > >>>> (including myself) run up against this issue enough that I think it > >>>> should be addressed.? It's been reopened, and I have a webrev ready > that > >>>> I've tested in the jdk repo, on Windows.? It fixes the issue as > >>>> described in the bug description.? I have tested the patch using a > >>>> Cygwin build but not a WSL build. > >>>> > >>>> This patch alters a change introduced in > >>>> > >> > https://hg.openjdk.java.net/jdk/jdk/annotate/50677f43ac3d/make/autocon > >> f/toolchain_windows.m4#l746 > >>>> That change introduced an issue that prevented the use of directories > >>>> with spaces. > >>>> > >>>> If this patch is accepted, I intend to backport it to 11u and 8u. > >>>> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 > >>>> > >>>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354- > >> jdk14/00/ > >>>> Thank you, > >>>> > >>>> -Simon > >>>> > >>>> > >>>> From Alan.Bateman at oracle.com Mon Sep 16 06:33:49 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Sep 2019 07:33:49 +0100 Subject: [PATCH] Add *.iml to .hgignore and .gitignore In-Reply-To: References: Message-ID: <377456cc-caf5-d678-0b64-ce11d608959b@oracle.com> I think the .ignore files are maintained on build-dev. Note that .idea is already excluded and it contains the .iml and other workspace files are created for the IntelliJ project, maybe your setup might be different? -Alan. On 15/09/2019 21:22, JARvis PROgrammer wrote: > This is a small patch to disable tracking of configuration files of > Intellij-based IDEs (.iml) > Diff: > diff -r a6f653312b19 .gitignore > --- a/.gitignore Sun Sep 15 08:41:48 2019 +0200 > +++ b/.gitignore Sun Sep 15 21:11:13 2019 +0100 > @@ -1,6 +1,7 @@ > /build/ > /dist/ > /.idea/ > +*.iml > nbproject/private/ > /webrev > /.src-rev > diff -r a6f653312b19 .hgignore > --- a/.hgignore Sun Sep 15 08:41:48 2019 +0200 > +++ b/.hgignore Sun Sep 15 21:11:13 2019 +0100 > @@ -1,6 +1,7 @@ > ^build/ > ^dist/ > ^.idea/ > +*.iml > nbproject/private/ > ^webrev > ^.src-rev$ > Hosted diff-file: > https://gist.github.com/JarvisCraft/d016d39a0342d09ce3a0a22a1893841d > > PS: if it is an unneeded patch or a wrong mailing list, please inform me > > Thanks, > Peter From erik.joelsson at oracle.com Mon Sep 16 15:41:38 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Sep 2019 08:41:38 -0700 Subject: [PATCH] Add *.iml to .hgignore and .gitignore In-Reply-To: <377456cc-caf5-d678-0b64-ce11d608959b@oracle.com> References: <377456cc-caf5-d678-0b64-ce11d608959b@oracle.com> Message-ID: <3de6b85c-6085-dbe5-8ac3-be714c973298@oracle.com> Hello, The .ignore file is currently in regexp format so new additions should probably be in that format. I don't object to ignoring .iml files. /Erik On 2019-09-15 23:33, Alan Bateman wrote: > > I think the .ignore files are maintained on build-dev. Note that .idea > is already excluded and it contains the .iml and other workspace files > are created for the IntelliJ project, maybe your setup might be > different? > > -Alan. > > > On 15/09/2019 21:22, JARvis PROgrammer wrote: >> This is a small patch to disable tracking of configuration files of >> Intellij-based IDEs (.iml) >> Diff: >> diff -r a6f653312b19 .gitignore >> --- a/.gitignore??????? Sun Sep 15 08:41:48 2019 +0200 >> +++ b/.gitignore??????? Sun Sep 15 21:11:13 2019 +0100 >> @@ -1,6 +1,7 @@ >> ? /build/ >> ? /dist/ >> ? /.idea/ >> +*.iml >> ? nbproject/private/ >> ? /webrev >> ? /.src-rev >> diff -r a6f653312b19 .hgignore >> --- a/.hgignore Sun Sep 15 08:41:48 2019 +0200 >> +++ b/.hgignore Sun Sep 15 21:11:13 2019 +0100 >> @@ -1,6 +1,7 @@ >> ? ^build/ >> ? ^dist/ >> ? ^.idea/ >> +*.iml >> ? nbproject/private/ >> ? ^webrev >> ? ^.src-rev$ >> Hosted diff-file: >> https://gist.github.com/JarvisCraft/d016d39a0342d09ce3a0a22a1893841d >> >> PS: if it is an unneeded patch or a wrong mailing list, please inform me >> >> Thanks, >> Peter > From Sergey.Bylokhov at oracle.com Mon Sep 16 21:50:19 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Sep 2019 14:50:19 -0700 Subject: [14] Review Request: JDK-8231027 Correct typos Message-ID: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8231027 Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00 One common typo is fixed across a few components like client, build, and hotspot. -- Best regards, Sergey. From lance.andersen at oracle.com Mon Sep 16 21:53:45 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 16 Sep 2019 17:53:45 -0400 Subject: [14] Review Request: JDK-8231027 Correct typos In-Reply-To: References: Message-ID: <88AA0415-B391-4CC5-8920-0FE1C62D9FD9@oracle.com> Looks fine Sergey > On Sep 16, 2019, at 5:50 PM, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231027 > Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00 > > One common typo is fixed across a few components like client, build, and hotspot. > > -- > Best regards, Sergey. 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 david.holmes at oracle.com Mon Sep 16 22:38:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2019 08:38:26 +1000 Subject: [14] Review Request: JDK-8231027 Correct typos In-Reply-To: References: Message-ID: <126806ec-a1d8-9bce-b5d0-b18d9f8f993f@oracle.com> Hi Sergey, These changes are all fine and trivial. Thanks, David On 17/09/2019 7:50 am, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231027 > Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00 > > One common typo is fixed across a few components like client, build, and > hotspot. > From david.holmes at oracle.com Mon Sep 16 23:01:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2019 09:01:15 +1000 Subject: RFR: 8230857: Avoid reflection in sun.tools.common.ProcessHelper In-Reply-To: References: <555a2cf2-e15e-abb6-5c0a-fb3ff4c0716f@oracle.com> Message-ID: <7cef2fd2-74cb-f069-d837-b5219924efc0@oracle.com> Hi Christoph, Sorry for the delay getting back you. cc'd build-dev to get some clarification on the below ... On 12/09/2019 7:30 pm, Langer, Christoph wrote: > Hi David, > >>> please review an enhancement which I've identified when working with >>> Processhelper for JDK-8230850. >>> >>> I noticed that ProcessHelper is an interface in common code with a >>> static method that would lookup the actual platform implementation via >>> reflection. This seems a little cumbersome since we can have a common >>> dummy for ProcessHelper and override it with the platform specific >>> implementation, leveraging the build system. >> >> I don't see you leveraging the build system. You have two source files >> that compile to the same destination class file. What is ensuring the >> platform specific version is compiled after the generic one? >> >> Service-provider patterns use reflection to instantiate the service >> implementation. I don't see any problem here that needs solving. > > TL;DR: > There are two source files, one in share/classes and one in linux/classes. The build system overrides the share/classes implementation with the linux/classes implementation in the linux build. This is not by coincidence and only one class is contained in the generated jdk.jcmd module. Then there won't be a need for having a service interface and a service implementation that is looked up via reflection (which is not a bad pattern by itself). I agree that it's not a big problem to be solved but still not "no problem". > Here is some longer elaboration how the build system prefers specific implementations of classes and filters generic duplicates: > The SetupJavaCompilation function from JavaCompilation.gmk [0] is used to compile the java sources for JDK modules. In its documentation, for argument SRC [1], it claims: "one or more directories to search for sources. The order of the source roots is significant. The first found file of a certain name has priority". In its implementation the found files are first ordered [3] and duplicates filtered out [4]. > The potential source files are handed to SetupJavaCompilation in CompileJavaModules.gmk [5] and were collected by a call to FindModuleSrcDirs [6]. FindModuleSrcDirs iterates over all potential source dirs for Java classes in the module [7]. The evaluated subdirs are (in that order) $(OPENJDK_TARGET_OS)/classes, $(OPENJDK_TARGET_OS_TYPE)/classes and share/classes, as per [8]. > Hope that explains what I'm trying to leverage here. I'm not 100% certain that what you describe actually ensures what you want it to ensure. I can't reconcile "the first found file ... has priority" with the fact found files are sorted and duplicates eliminated. It is the sorting that concerns me as it suggests linux/Foo.java might replace shared/Foo.java, but if we're on Windows then we have a problem! That said there is also this comment: # Order src files according to the order of the src dirs. Correct odering is # needed for correct overriding between different source roots. I'd need the build team to clarify what "correct overriding" is actually defined as. Thanks, David ----- > I've uploaded an updated webrev which contains some cleanup to the Test changes: http://cr.openjdk.java.net/~clanger/webrevs/8230857.1/ > > Thanks > Christoph > > [0] http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l185 > [1] http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l157 > [3] http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l225 > [4] http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l257 > [5] http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/CompileJavaModules.gmk#l603 > [6] http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/CompileJavaModules.gmk#l555 > [7] http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/Modules.gmk#l300 > [8] http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/Modules.gmk#l243 > > From magnus.ihse.bursie at oracle.com Tue Sep 17 11:26:19 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 17 Sep 2019 13:26:19 +0200 Subject: RFR: 8230857: Avoid reflection in sun.tools.common.ProcessHelper In-Reply-To: <7cef2fd2-74cb-f069-d837-b5219924efc0@oracle.com> References: <555a2cf2-e15e-abb6-5c0a-fb3ff4c0716f@oracle.com> <7cef2fd2-74cb-f069-d837-b5219924efc0@oracle.com> Message-ID: <105a9f1f-9b1e-c707-b65d-6e71db7c701d@oracle.com> On 2019-09-17 01:01, David Holmes wrote: > Hi Christoph, > > Sorry for the delay getting back you. > > cc'd build-dev to get some clarification on the below ... > > On 12/09/2019 7:30 pm, Langer, Christoph wrote: >> Hi David, >> >>>> please review an enhancement which I've identified when working with >>>> Processhelper for JDK-8230850. >>>> >>>> I noticed that ProcessHelper is an interface in common code with a >>>> static method that would lookup the actual platform implementation via >>>> reflection. This seems a little cumbersome since we can have a common >>>> dummy for ProcessHelper and override it with the platform specific >>>> implementation, leveraging the build system. >>> >>> I don't see you leveraging the build system. You have two source files >>> that compile to the same destination class file. What is ensuring the >>> platform specific version is compiled after the generic one? >>> >>> Service-provider patterns use reflection to instantiate the service >>> implementation. I don't see any problem here that needs solving. >> >> TL;DR: >> There are two source files, one in share/classes and one in >> linux/classes. The build system overrides the share/classes >> implementation with the linux/classes implementation in the linux >> build. This is not by coincidence and only one class is contained in >> the generated jdk.jcmd module. Then there won't be a need for having >> a service interface and a service implementation that is looked up >> via reflection (which is not a bad pattern by itself). I agree that >> it's not a big problem to be solved but still not "no problem". >> Here is some longer elaboration how the build system prefers specific >> implementations of classes and filters generic duplicates: >> The SetupJavaCompilation function from JavaCompilation.gmk [0] is >> used to compile the java sources for JDK modules. In its >> documentation, for argument SRC [1], it claims: "one or more >> directories to search for sources. The order of the source roots is >> significant. The first found file of a certain name has priority". In >> its implementation the found files are first ordered [3] and >> duplicates filtered out [4]. >> The potential source files are handed to SetupJavaCompilation in >> CompileJavaModules.gmk [5] and were collected by a call to >> FindModuleSrcDirs [6].? FindModuleSrcDirs iterates over all potential >> source dirs for Java classes in the module [7]. The evaluated subdirs >> are (in that order) $(OPENJDK_TARGET_OS)/classes, >> $(OPENJDK_TARGET_OS_TYPE)/classes and share/classes, as per [8]. >> Hope that explains what I'm trying to leverage here. > > I'm not 100% certain that what you describe actually ensures what you > want it to ensure. I can't reconcile "the first found file ... has > priority" with the fact found files are sorted and duplicates > eliminated. It is the sorting that concerns me as it suggests > linux/Foo.java might replace shared/Foo.java, but if we're on Windows > then we have a problem! That said there is also this comment: > > # Order src files according to the order of the src dirs. Correct > odering is > # needed for correct overriding between different source roots. > > I'd need the build team to clarify what "correct overriding" is > actually defined as. David, Christoph is correct. linux/Foo.java will override share/Foo.java. I don't remember how the magic in JavaCompilation.gmk works anymore :-), but we have relied on this behavior in other places for a long time, so I'm pretty certain it is still working correctly. Presumably, the $(sort ...) is there to remove (identical) duplicates, which is a side-effect of sort. /Magnus > > Thanks, > David > ----- > >> I've uploaded an updated webrev which contains some cleanup to the >> Test changes: http://cr.openjdk.java.net/~clanger/webrevs/8230857.1/ >> >> Thanks >> Christoph >> >> [0] >> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l185 >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l157 >> [3] >> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l225 >> [4] >> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l257 >> [5] >> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/CompileJavaModules.gmk#l603 >> [6] >> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/CompileJavaModules.gmk#l555 >> [7] >> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/Modules.gmk#l300 >> [8] >> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/Modules.gmk#l243 >> >> From david.holmes at oracle.com Tue Sep 17 12:59:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2019 22:59:40 +1000 Subject: RFR: 8230857: Avoid reflection in sun.tools.common.ProcessHelper In-Reply-To: <105a9f1f-9b1e-c707-b65d-6e71db7c701d@oracle.com> References: <555a2cf2-e15e-abb6-5c0a-fb3ff4c0716f@oracle.com> <7cef2fd2-74cb-f069-d837-b5219924efc0@oracle.com> <105a9f1f-9b1e-c707-b65d-6e71db7c701d@oracle.com> Message-ID: <431b85fb-b131-b55b-f7a8-d7112b2c9fa4@oracle.com> Hi Magnus, On 17/09/2019 9:26 pm, Magnus Ihse Bursie wrote: > On 2019-09-17 01:01, David Holmes wrote: >> Hi Christoph, >> >> Sorry for the delay getting back you. >> >> cc'd build-dev to get some clarification on the below ... >> >> On 12/09/2019 7:30 pm, Langer, Christoph wrote: >>> Hi David, >>> >>>>> please review an enhancement which I've identified when working with >>>>> Processhelper for JDK-8230850. >>>>> >>>>> I noticed that ProcessHelper is an interface in common code with a >>>>> static method that would lookup the actual platform implementation via >>>>> reflection. This seems a little cumbersome since we can have a common >>>>> dummy for ProcessHelper and override it with the platform specific >>>>> implementation, leveraging the build system. >>>> >>>> I don't see you leveraging the build system. You have two source files >>>> that compile to the same destination class file. What is ensuring the >>>> platform specific version is compiled after the generic one? >>>> >>>> Service-provider patterns use reflection to instantiate the service >>>> implementation. I don't see any problem here that needs solving. >>> >>> TL;DR: >>> There are two source files, one in share/classes and one in >>> linux/classes. The build system overrides the share/classes >>> implementation with the linux/classes implementation in the linux >>> build. This is not by coincidence and only one class is contained in >>> the generated jdk.jcmd module. Then there won't be a need for having >>> a service interface and a service implementation that is looked up >>> via reflection (which is not a bad pattern by itself). I agree that >>> it's not a big problem to be solved but still not "no problem". >>> Here is some longer elaboration how the build system prefers specific >>> implementations of classes and filters generic duplicates: >>> The SetupJavaCompilation function from JavaCompilation.gmk [0] is >>> used to compile the java sources for JDK modules. In its >>> documentation, for argument SRC [1], it claims: "one or more >>> directories to search for sources. The order of the source roots is >>> significant. The first found file of a certain name has priority". In >>> its implementation the found files are first ordered [3] and >>> duplicates filtered out [4]. >>> The potential source files are handed to SetupJavaCompilation in >>> CompileJavaModules.gmk [5] and were collected by a call to >>> FindModuleSrcDirs [6].? FindModuleSrcDirs iterates over all potential >>> source dirs for Java classes in the module [7]. The evaluated subdirs >>> are (in that order) $(OPENJDK_TARGET_OS)/classes, >>> $(OPENJDK_TARGET_OS_TYPE)/classes and share/classes, as per [8]. >>> Hope that explains what I'm trying to leverage here. >> >> I'm not 100% certain that what you describe actually ensures what you >> want it to ensure. I can't reconcile "the first found file ... has >> priority" with the fact found files are sorted and duplicates >> eliminated. It is the sorting that concerns me as it suggests >> linux/Foo.java might replace shared/Foo.java, but if we're on Windows >> then we have a problem! That said there is also this comment: >> >> # Order src files according to the order of the src dirs. Correct >> odering is >> # needed for correct overriding between different source roots. >> >> I'd need the build team to clarify what "correct overriding" is >> actually defined as. > David, > > Christoph is correct. linux/Foo.java will override share/Foo.java. I > don't remember how the magic in JavaCompilation.gmk works anymore :-), > but we have relied on this behavior in other places for a long time, so > I'm pretty certain it is still working correctly. Presumably, the $(sort > ...) is there to remove (identical) duplicates, which is a side-effect > of sort. Thanks for confirming. I'd still like to understand exactly what these overriding rules are though. It's not a mechanism I was aware of. Thanks, David > /Magnus > >> >> Thanks, >> David >> ----- >> >>> I've uploaded an updated webrev which contains some cleanup to the >>> Test changes: http://cr.openjdk.java.net/~clanger/webrevs/8230857.1/ >>> >>> Thanks >>> Christoph >>> >>> [0] >>> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l185 >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l157 >>> >>> [3] >>> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l225 >>> >>> [4] >>> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/JavaCompilation.gmk#l257 >>> >>> [5] >>> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/CompileJavaModules.gmk#l603 >>> >>> [6] >>> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/CompileJavaModules.gmk#l555 >>> >>> [7] >>> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/Modules.gmk#l300 >>> >>> [8] >>> http://hg.openjdk.java.net/jdk/jdk/file/ea93d6a9f720/make/common/Modules.gmk#l243 >>> >>> >>> > From erik.joelsson at oracle.com Tue Sep 17 13:16:24 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 17 Sep 2019 06:16:24 -0700 Subject: [14] Review Request: JDK-8231027 Correct typos In-Reply-To: References: Message-ID: <17674991-934e-7053-d59e-35f6e1569d9c@oracle.com> Looks good. /Erik On 2019-09-16 14:50, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231027 > Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00 > > One common typo is fixed across a few components like client, build, > and hotspot. > From erik.joelsson at oracle.com Tue Sep 17 13:39:25 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 17 Sep 2019 06:39:25 -0700 Subject: RFR: 8230857: Avoid reflection in sun.tools.common.ProcessHelper In-Reply-To: <431b85fb-b131-b55b-f7a8-d7112b2c9fa4@oracle.com> References: <555a2cf2-e15e-abb6-5c0a-fb3ff4c0716f@oracle.com> <7cef2fd2-74cb-f069-d837-b5219924efc0@oracle.com> <105a9f1f-9b1e-c707-b65d-6e71db7c701d@oracle.com> <431b85fb-b131-b55b-f7a8-d7112b2c9fa4@oracle.com> Message-ID: <98c7eadb-3003-cea7-f5a3-c902d9a6f1db@oracle.com> Hello, On 2019-09-17 05:59, David Holmes wrote: > Hi Magnus, > > On 17/09/2019 9:26 pm, Magnus Ihse Bursie wrote: >> On 2019-09-17 01:01, David Holmes wrote: >>> Hi Christoph, >>> >>> Sorry for the delay getting back you. >>> >>> cc'd build-dev to get some clarification on the below ... >>> >>> On 12/09/2019 7:30 pm, Langer, Christoph wrote: >>>> Hi David, >>>> >>>>>> please review an enhancement which I've identified when working with >>>>>> Processhelper for JDK-8230850. >>>>>> >>>>>> I noticed that ProcessHelper is an interface in common code with a >>>>>> static method that would lookup the actual platform >>>>>> implementation via >>>>>> reflection. This seems a little cumbersome since we can have a >>>>>> common >>>>>> dummy for ProcessHelper and override it with the platform specific >>>>>> implementation, leveraging the build system. >>>>> >>>>> I don't see you leveraging the build system. You have two source >>>>> files >>>>> that compile to the same destination class file. What is ensuring the >>>>> platform specific version is compiled after the generic one? >>>>> >>>>> Service-provider patterns use reflection to instantiate the service >>>>> implementation. I don't see any problem here that needs solving. >>>> >>>> TL;DR: >>>> There are two source files, one in share/classes and one in >>>> linux/classes. The build system overrides the share/classes >>>> implementation with the linux/classes implementation in the linux >>>> build. This is not by coincidence and only one class is contained >>>> in the generated jdk.jcmd module. Then there won't be a need for >>>> having a service interface and a service implementation that is >>>> looked up via reflection (which is not a bad pattern by itself). I >>>> agree that it's not a big problem to be solved but still not "no >>>> problem". >>>> Here is some longer elaboration how the build system prefers >>>> specific implementations of classes and filters generic duplicates: >>>> The SetupJavaCompilation function from JavaCompilation.gmk [0] is >>>> used to compile the java sources for JDK modules. In its >>>> documentation, for argument SRC [1], it claims: "one or more >>>> directories to search for sources. The order of the source roots is >>>> significant. The first found file of a certain name has priority". >>>> In its implementation the found files are first ordered [3] and >>>> duplicates filtered out [4]. >>>> The potential source files are handed to SetupJavaCompilation in >>>> CompileJavaModules.gmk [5] and were collected by a call to >>>> FindModuleSrcDirs [6]. FindModuleSrcDirs iterates over all >>>> potential source dirs for Java classes in the module [7]. The >>>> evaluated subdirs are (in that order) $(OPENJDK_TARGET_OS)/classes, >>>> $(OPENJDK_TARGET_OS_TYPE)/classes and share/classes, as per [8]. >>>> Hope that explains what I'm trying to leverage here. >>> >>> I'm not 100% certain that what you describe actually ensures what >>> you want it to ensure. I can't reconcile "the first found file ... >>> has priority" with the fact found files are sorted and duplicates >>> eliminated. It is the sorting that concerns me as it suggests >>> linux/Foo.java might replace shared/Foo.java, but if we're on >>> Windows then we have a problem! That said there is also this comment: >>> >>> # Order src files according to the order of the src dirs. Correct >>> odering is >>> # needed for correct overriding between different source roots. >>> >>> I'd need the build team to clarify what "correct overriding" is >>> actually defined as. >> David, >> >> Christoph is correct. linux/Foo.java will override share/Foo.java. I >> don't remember how the magic in JavaCompilation.gmk works anymore >> :-), but we have relied on this behavior in other places for a long >> time, so I'm pretty certain it is still working correctly. >> Presumably, the $(sort ...) is there to remove (identical) >> duplicates, which is a side-effect of sort. > > Thanks for confirming. I'd still like to understand exactly what these > overriding rules are though. It's not a mechanism I was aware of. > SetupJavaCompilation is indeed behaving as Christoph describes and it is by design. I implemented support for this behavior in: https://bugs.openjdk.java.net/browse/JDK-8079344 The relevant parts of SetupJavaCompilation look like this: ? # Order src files according to the order of the src dirs. Correct odering is ? # needed for correct overriding between different source roots. ? $1_ALL_SRC_RAW := $$(call FindFiles, $$($1_SRC)) ? $1_ALL_SRCS := $$($1_EXTRA_FILES) \ ????? $$(foreach d, $$($1_SRC), $$(filter $$d%, $$($1_ALL_SRC_RAW))) The second line orders the src files by the src roots. (We used to just call find for one src root at a time, but the above actually performs better due only running 1 external process) Further down we have this: ? ifneq ($$($1_KEEP_DUPS), true) ??? # Remove duplicate source files by keeping the first found of each duplicate. ??? # This allows for automatic overrides with custom or platform specific versions ??? # source files. ??? # ??? # For the smart javac wrapper case, add each removed file to an extra exclude ??? # file list to prevent sjavac from finding duplicate sources. ??? $1_SRCS := $$(strip $$(foreach s, $$($1_SRCS), \ ??????? $$(eval relative_src := $$(call remove-prefixes, $$($1_SRC), $$(s))) \ ??????? $$(if $$($1_$$(relative_src)), \ ????????? $$(eval $1_SJAVAC_EXCLUDE_FILES += $$(s)), \ ????????? $$(eval $1_$$(relative_src) := 1) $$(s)))) ? endif This loop is a bit hairy to wrap your head around. It's iterating over all the src files, in the order of importance. The variable relative_src is the path from the src root, the part that is common to all duplicate src files. The variables on the form $1_$$(relative_src) basically act as a hash map (string->boolean). So for each src file, if the relative path for it has already been seen, add it to an exclude list, else mark it as seen and add it to the return list. /Erik From dekeeler at microsoft.com Tue Sep 17 17:31:08 2019 From: dekeeler at microsoft.com (Derek Keeler) Date: Tue, 17 Sep 2019 17:31:08 +0000 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Message-ID: Hi build-dev friends! I'm Derek Keeler, the infrastructure lead on the Java Platform team within Microsoft, working with the AdoptOpenJDK's George Adams and John Oliver. Simon, I have pulled down your jdk8u patches and have built them against macOS Mojave (with a good amount of help from George and John). Currently, the build succeeds! I am planning to throw the entire AdoptOpenJDK test roster against it sometime today/tomorrow. I will let you know what I find as a result of those tests, and what if anything I had to do in order to get things up and running. -Derek ________________________________ From: build-dev on behalf of Simon Tooke Sent: September 13, 2019 7:05 AM To: jdk8u-dev at openjdk.java.net ; build-dev Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u Hello all, This is a request for review of my patch to enable building 8u with modern (9,10,11) Xcode versions on macOS. I've received a few recent enquiries so I thought I'd submit this. When I first created this patch is was more for convenience, but soon macOS will require applications to be "notarized", which cannot be done with the old version of Xcode. This will become mandatory long before 8u is due to retire [1]. This patch is not intended to remove the current ability to build 8u on the current supported build platform. I have used the patch with Xcode 9,10 and a beta of 11, and used the resultant JDK to build Graal. I have not build a JDK using the old Xcode and this patch; my intent was to ensure this was still possible. There is some information available on my GitHub page: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstooke%2Fjdk8u-xcode10&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=THixfdOpuZrY8%2BdEDHFVjmV%2BnePxVGFsof9eDoqJikE%3D&reserved=0 Issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8226288&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=VHN2S0uxbbeJiiuWznYafSpXmERDdp29U%2FqVMJSdUuw%3D&reserved=0 Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~stooke%2Fwebrevs%2Fjdk-8226288-jdk8u%2F00%2F&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=T6uq0ThFfHLrqslWfCz2x846ixtLMIW5EwaP4U4Jvqc%3D&reserved=0 Previous discussion: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-June%2F009733.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=WDUf2fhTqmcNTZJJ2NNnI%2FtCKxr%2BxQLiCfPmpj3m0p8%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-July%2F009760.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=pJXk%2Bg5LlmSpogNhcINgRezCSozo7MbW%2FNWLJNrf%2BV8%3D&reserved=0 Thank you for your time, -Simon [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fsecurity%2Fnotarizing_your_app_before_distribution&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=TZmbZfAFDXXwpBJ8xibzzfoCicd5Fwm0xwdCo2hIaYo%3D&reserved=0 From ekaterina.pavlova at oracle.com Tue Sep 17 22:45:19 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 17 Sep 2019 15:45:19 -0700 Subject: RFR(T/XS) 8231145: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails because DebugContextTest.testLogging.input is not available Message-ID: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> Hi, please review the following change which fixes org.graalvm.compiler.debug.test.DebugContextTest. The test fails because it tries to read DebugContextTest.testLogging.input file which is not available at runtime. The fix copies testLogging.input file into jdk.vm.compiler.tests.jar. JBS: https://bugs.openjdk.java.net/browse/JDK-8231145 webrev: http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html testing: run compiler/graalunit/DebugTest.java thanks, -katya From david.holmes at oracle.com Tue Sep 17 23:12:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Sep 2019 09:12:49 +1000 Subject: RFR: 8230857: Avoid reflection in sun.tools.common.ProcessHelper In-Reply-To: <98c7eadb-3003-cea7-f5a3-c902d9a6f1db@oracle.com> References: <555a2cf2-e15e-abb6-5c0a-fb3ff4c0716f@oracle.com> <7cef2fd2-74cb-f069-d837-b5219924efc0@oracle.com> <105a9f1f-9b1e-c707-b65d-6e71db7c701d@oracle.com> <431b85fb-b131-b55b-f7a8-d7112b2c9fa4@oracle.com> <98c7eadb-3003-cea7-f5a3-c902d9a6f1db@oracle.com> Message-ID: Hi Erik, Thanks for the additional details (I can't say I fully understand them :) ). David On 17/09/2019 11:39 pm, Erik Joelsson wrote: > Hello, > > On 2019-09-17 05:59, David Holmes wrote: >> Hi Magnus, >> >> On 17/09/2019 9:26 pm, Magnus Ihse Bursie wrote: >>> On 2019-09-17 01:01, David Holmes wrote: >>>> Hi Christoph, >>>> >>>> Sorry for the delay getting back you. >>>> >>>> cc'd build-dev to get some clarification on the below ... >>>> >>>> On 12/09/2019 7:30 pm, Langer, Christoph wrote: >>>>> Hi David, >>>>> >>>>>>> please review an enhancement which I've identified when working with >>>>>>> Processhelper for JDK-8230850. >>>>>>> >>>>>>> I noticed that ProcessHelper is an interface in common code with a >>>>>>> static method that would lookup the actual platform >>>>>>> implementation via >>>>>>> reflection. This seems a little cumbersome since we can have a >>>>>>> common >>>>>>> dummy for ProcessHelper and override it with the platform specific >>>>>>> implementation, leveraging the build system. >>>>>> >>>>>> I don't see you leveraging the build system. You have two source >>>>>> files >>>>>> that compile to the same destination class file. What is ensuring the >>>>>> platform specific version is compiled after the generic one? >>>>>> >>>>>> Service-provider patterns use reflection to instantiate the service >>>>>> implementation. I don't see any problem here that needs solving. >>>>> >>>>> TL;DR: >>>>> There are two source files, one in share/classes and one in >>>>> linux/classes. The build system overrides the share/classes >>>>> implementation with the linux/classes implementation in the linux >>>>> build. This is not by coincidence and only one class is contained >>>>> in the generated jdk.jcmd module. Then there won't be a need for >>>>> having a service interface and a service implementation that is >>>>> looked up via reflection (which is not a bad pattern by itself). I >>>>> agree that it's not a big problem to be solved but still not "no >>>>> problem". >>>>> Here is some longer elaboration how the build system prefers >>>>> specific implementations of classes and filters generic duplicates: >>>>> The SetupJavaCompilation function from JavaCompilation.gmk [0] is >>>>> used to compile the java sources for JDK modules. In its >>>>> documentation, for argument SRC [1], it claims: "one or more >>>>> directories to search for sources. The order of the source roots is >>>>> significant. The first found file of a certain name has priority". >>>>> In its implementation the found files are first ordered [3] and >>>>> duplicates filtered out [4]. >>>>> The potential source files are handed to SetupJavaCompilation in >>>>> CompileJavaModules.gmk [5] and were collected by a call to >>>>> FindModuleSrcDirs [6]. FindModuleSrcDirs iterates over all >>>>> potential source dirs for Java classes in the module [7]. The >>>>> evaluated subdirs are (in that order) $(OPENJDK_TARGET_OS)/classes, >>>>> $(OPENJDK_TARGET_OS_TYPE)/classes and share/classes, as per [8]. >>>>> Hope that explains what I'm trying to leverage here. >>>> >>>> I'm not 100% certain that what you describe actually ensures what >>>> you want it to ensure. I can't reconcile "the first found file ... >>>> has priority" with the fact found files are sorted and duplicates >>>> eliminated. It is the sorting that concerns me as it suggests >>>> linux/Foo.java might replace shared/Foo.java, but if we're on >>>> Windows then we have a problem! That said there is also this comment: >>>> >>>> # Order src files according to the order of the src dirs. Correct >>>> odering is >>>> # needed for correct overriding between different source roots. >>>> >>>> I'd need the build team to clarify what "correct overriding" is >>>> actually defined as. >>> David, >>> >>> Christoph is correct. linux/Foo.java will override share/Foo.java. I >>> don't remember how the magic in JavaCompilation.gmk works anymore >>> :-), but we have relied on this behavior in other places for a long >>> time, so I'm pretty certain it is still working correctly. >>> Presumably, the $(sort ...) is there to remove (identical) >>> duplicates, which is a side-effect of sort. >> >> Thanks for confirming. I'd still like to understand exactly what these >> overriding rules are though. It's not a mechanism I was aware of. >> > SetupJavaCompilation is indeed behaving as Christoph describes and it is > by design. I implemented support for this behavior in: > > https://bugs.openjdk.java.net/browse/JDK-8079344 > > The relevant parts of SetupJavaCompilation look like this: > > ? # Order src files according to the order of the src dirs. Correct > odering is > ? # needed for correct overriding between different source roots. > ? $1_ALL_SRC_RAW := $$(call FindFiles, $$($1_SRC)) > ? $1_ALL_SRCS := $$($1_EXTRA_FILES) \ > ????? $$(foreach d, $$($1_SRC), $$(filter $$d%, $$($1_ALL_SRC_RAW))) > > The second line orders the src files by the src roots. (We used to just > call find for one src root at a time, but the above actually performs > better due only running 1 external process) > > Further down we have this: > > ? ifneq ($$($1_KEEP_DUPS), true) > ??? # Remove duplicate source files by keeping the first found of each > duplicate. > ??? # This allows for automatic overrides with custom or platform > specific versions > ??? # source files. > ??? # > ??? # For the smart javac wrapper case, add each removed file to an > extra exclude > ??? # file list to prevent sjavac from finding duplicate sources. > ??? $1_SRCS := $$(strip $$(foreach s, $$($1_SRCS), \ > ??????? $$(eval relative_src := $$(call remove-prefixes, $$($1_SRC), > $$(s))) \ > ??????? $$(if $$($1_$$(relative_src)), \ > ????????? $$(eval $1_SJAVAC_EXCLUDE_FILES += $$(s)), \ > ????????? $$(eval $1_$$(relative_src) := 1) $$(s)))) > ? endif > > This loop is a bit hairy to wrap your head around. It's iterating over > all the src files, in the order of importance. The variable relative_src > is the path from the src root, the part that is common to all duplicate > src files. The variables on the form $1_$$(relative_src) basically act > as a hash map (string->boolean). So for each src file, if the relative > path for it has already been seen, add it to an exclude list, else mark > it as seen and add it to the return list. > > /Erik > From igor.veresov at oracle.com Tue Sep 17 23:27:34 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 17 Sep 2019 16:27:34 -0700 Subject: RFR(T/XS) 8231145: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails because DebugContextTest.testLogging.input is not available In-Reply-To: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> References: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> Message-ID: <2CC4E821-C510-4277-BCE6-41B6652E862A@oracle.com> Looks good. igor > On Sep 17, 2019, at 3:45 PM, Ekaterina Pavlova wrote: > > Hi, > > please review the following change which fixes org.graalvm.compiler.debug.test.DebugContextTest. > The test fails because it tries to read DebugContextTest.testLogging.input file which is not available at runtime. > The fix copies testLogging.input file into jdk.vm.compiler.tests.jar. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8231145 > webrev: http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html > testing: run compiler/graalunit/DebugTest.java > > thanks, > -katya From magnus.ihse.bursie at oracle.com Wed Sep 18 09:30:23 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 18 Sep 2019 11:30:23 +0200 Subject: RFR(T/XS) 8231145: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails because DebugContextTest.testLogging.input is not available In-Reply-To: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> References: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> Message-ID: On 2019-09-18 00:45, Ekaterina Pavlova wrote: > Hi, > > please review the following change which fixes > org.graalvm.compiler.debug.test.DebugContextTest. > The test fails because it tries to read > DebugContextTest.testLogging.input file which is not available at > runtime. > The fix copies testLogging.input file into jdk.vm.compiler.tests.jar. > > ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8231145 > ? webrev: > http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html Looks good to me. /Magnus > ?testing: run compiler/graalunit/DebugTest.java > > thanks, > -katya From jan.lahoda at oracle.com Wed Sep 18 11:33:45 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 Sep 2019 13:33:45 +0200 Subject: RFR: JDK-8231176: Test tools/javac/options/BCPOrSystemNotSpecified.java broken on Windows Message-ID: <0d02ca05-48bc-d73b-80fe-9e7ee16f5df5@oracle.com> Hi, The newly added tools/javac/options/BCPOrSystemNotSpecified.java test is failing on Windows, so tier 1 is failing. I'd like to temporarily problem list the test, so that it can be properly investigated: http://cr.openjdk.java.net/~jlahoda/8231176/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8231176 Does this look OK? Thanks, Jan From stooke at redhat.com Wed Sep 18 12:43:28 2019 From: stooke at redhat.com (Simon Tooke) Date: Wed, 18 Sep 2019 08:43:28 -0400 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Message-ID: On 9/17/2019 1:31 PM, Derek Keeler wrote: > Hi build-dev friends! > > I'm Derek Keeler,?the infrastructure lead on the Java Platform team > within?Microsoft, working with the AdoptOpenJDK's George Adams and > John Oliver. > > Simon, I have pulled down your jdk8u patches and have built them > against macOS Mojave (with a good amount of help from George and John). Hi, and thanks for your interest.? > > Currently, the build succeeds! > > I am planning to throw the entire AdoptOpenJDK test roster against it > sometime today/tomorrow. > > I will let you know what I find as a result of those tests, and what > if anything I had to do in order to get things up and running. Yes, please.? Also any difficulties you had with the initial script or instructions; I know there was a syntax error that I just fixed. -Simon > > -Derek > > > ------------------------------------------------------------------------ > *From:* build-dev on behalf of > Simon Tooke > *Sent:* September 13, 2019 7:05 AM > *To:* jdk8u-dev at openjdk.java.net ; > build-dev > *Subject:* [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u > and 11u > ? > Hello all, > > This is a request for review of my patch to enable building 8u with > modern (9,10,11) Xcode versions on macOS.? I've received a few recent > enquiries so I thought I'd submit this. > > When I first created this patch is was more for convenience, but soon > macOS will require applications to be "notarized", which cannot be done > with the old version of Xcode.? This will become mandatory long before > 8u is due to retire [1]. > > This patch is not intended to remove the current ability to build 8u on > the current supported build platform. > > I have used the patch with Xcode 9,10 and a beta of 11, and used the > resultant JDK to build Graal.? > > I have not build a JDK using the old Xcode and this patch; my intent was > to ensure this was still possible. > > There is some information available on my GitHub page: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstooke%2Fjdk8u-xcode10&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=THixfdOpuZrY8%2BdEDHFVjmV%2BnePxVGFsof9eDoqJikE%3D&reserved=0 > > Issue: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8226288&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=VHN2S0uxbbeJiiuWznYafSpXmERDdp29U%2FqVMJSdUuw%3D&reserved=0 > > Webrev: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~stooke%2Fwebrevs%2Fjdk-8226288-jdk8u%2F00%2F&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=T6uq0ThFfHLrqslWfCz2x846ixtLMIW5EwaP4U4Jvqc%3D&reserved=0 > > Previous discussion:? > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-June%2F009733.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=WDUf2fhTqmcNTZJJ2NNnI%2FtCKxr%2BxQLiCfPmpj3m0p8%3D&reserved=0? > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-July%2F009760.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=pJXk%2Bg5LlmSpogNhcINgRezCSozo7MbW%2FNWLJNrf%2BV8%3D&reserved=0 > > Thank you for your time, > > -Simon > > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fsecurity%2Fnotarizing_your_app_before_distribution&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=TZmbZfAFDXXwpBJ8xibzzfoCicd5Fwm0xwdCo2hIaYo%3D&reserved=0 > From vicente.romero at oracle.com Wed Sep 18 13:11:21 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Sep 2019 09:11:21 -0400 Subject: RFR: JDK-8231176: Test tools/javac/options/BCPOrSystemNotSpecified.java broken on Windows In-Reply-To: <0d02ca05-48bc-d73b-80fe-9e7ee16f5df5@oracle.com> References: <0d02ca05-48bc-d73b-80fe-9e7ee16f5df5@oracle.com> Message-ID: <1e933044-42f7-c888-6b5a-92f4edef4bee@oracle.com> looks good, Vicente On 9/18/19 7:33 AM, Jan Lahoda wrote: > Hi, > > The newly added tools/javac/options/BCPOrSystemNotSpecified.java test > is failing on Windows, so tier 1 is failing. I'd like to temporarily > problem list the test, so that it can be properly investigated: > http://cr.openjdk.java.net/~jlahoda/8231176/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8231176 > > Does this look OK? > > Thanks, > ??? Jan From ekaterina.pavlova at oracle.com Wed Sep 18 14:27:50 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 18 Sep 2019 07:27:50 -0700 Subject: RFR(T/XS) 8231145: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails because DebugContextTest.testLogging.input is not available In-Reply-To: References: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> Message-ID: <407c48b6-7adc-2c56-604f-d9a7e04fe8c4@oracle.com> Igor, Magnus, thank you for reviews. -katya On 9/18/19 2:30 AM, Magnus Ihse Bursie wrote: > On 2019-09-18 00:45, Ekaterina Pavlova wrote: >> Hi, >> >> please review the following change which fixes org.graalvm.compiler.debug.test.DebugContextTest. >> The test fails because it tries to read DebugContextTest.testLogging.input file which is not available at runtime. >> The fix copies testLogging.input file into jdk.vm.compiler.tests.jar. >> >> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8231145 >> ? webrev: http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html > Looks good to me. > > /Magnus >> ?testing: run compiler/graalunit/DebugTest.java >> >> thanks, >> -katya > From erik.joelsson at oracle.com Wed Sep 18 15:18:35 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Sep 2019 08:18:35 -0700 Subject: RFR(T/XS) 8231145: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails because DebugContextTest.testLogging.input is not available In-Reply-To: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> References: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> Message-ID: <61aee978-637c-ef70-b642-81b5c9289160@oracle.com> Hello Katya, The usual pattern for including a non class file from the source into the jar (typically a resource file) is to add it to the COPY parameter of SetupJavaCompilation, and then to the SUFFIXES of SetupJarArchive. This way you don't need to add a source dir to the input of SetupJarArchive, which is a bit weird. So in this case, you can add COPY := .input to BUILD_VM_COMPILER_TESTS and keep the SUFFIXES you already added, and skip the addition to SRCS. /Erik On 2019-09-17 15:45, Ekaterina Pavlova wrote: > Hi, > > please review the following change which fixes > org.graalvm.compiler.debug.test.DebugContextTest. > The test fails because it tries to read > DebugContextTest.testLogging.input file which is not available at > runtime. > The fix copies testLogging.input file into jdk.vm.compiler.tests.jar. > > ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8231145 > ? webrev: > http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html > ?testing: run compiler/graalunit/DebugTest.java > > thanks, > -katya From ekaterina.pavlova at oracle.com Wed Sep 18 17:16:04 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 18 Sep 2019 10:16:04 -0700 Subject: RFR(T/XS) 8231145: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails because DebugContextTest.testLogging.input is not available In-Reply-To: <61aee978-637c-ef70-b642-81b5c9289160@oracle.com> References: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> <61aee978-637c-ef70-b642-81b5c9289160@oracle.com> Message-ID: <28b1520d-ff95-622e-8038-582481ae191f@oracle.com> Erik, this way is definitely much better, thanks! I have regenerated webrev and retested: http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html -katya On 9/18/19 8:18 AM, Erik Joelsson wrote: > Hello Katya, > > The usual pattern for including a non class file from the source into the jar (typically a resource file) is to add it to the COPY parameter of SetupJavaCompilation, and then to the SUFFIXES of SetupJarArchive. This way you don't need to add a source dir to the input of SetupJarArchive, which is a bit weird. So in this case, you can add > > COPY := .input > > to BUILD_VM_COMPILER_TESTS and keep the SUFFIXES you already added, and skip the addition to SRCS. > > /Erik > > On 2019-09-17 15:45, Ekaterina Pavlova wrote: >> Hi, >> >> please review the following change which fixes org.graalvm.compiler.debug.test.DebugContextTest. >> The test fails because it tries to read DebugContextTest.testLogging.input file which is not available at runtime. >> The fix copies testLogging.input file into jdk.vm.compiler.tests.jar. >> >> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8231145 >> ? webrev: http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html >> ?testing: run compiler/graalunit/DebugTest.java >> >> thanks, >> -katya From erik.joelsson at oracle.com Wed Sep 18 17:46:51 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Sep 2019 10:46:51 -0700 Subject: RFR(T/XS) 8231145: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails because DebugContextTest.testLogging.input is not available In-Reply-To: <28b1520d-ff95-622e-8038-582481ae191f@oracle.com> References: <83553e2a-8a4c-71c7-70a2-2be707cf8921@oracle.com> <61aee978-637c-ef70-b642-81b5c9289160@oracle.com> <28b1520d-ff95-622e-8038-582481ae191f@oracle.com> Message-ID: Looks good. /Erik On 2019-09-18 10:16, Ekaterina Pavlova wrote: > Erik, > > this way is definitely much better, thanks! > I have regenerated webrev and retested: > ?http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html > > > -katya > > On 9/18/19 8:18 AM, Erik Joelsson wrote: >> Hello Katya, >> >> The usual pattern for including a non class file from the source into >> the jar (typically a resource file) is to add it to the COPY >> parameter of SetupJavaCompilation, and then to the SUFFIXES of >> SetupJarArchive. This way you don't need to add a source dir to the >> input of SetupJarArchive, which is a bit weird. So in this case, you >> can add >> >> COPY := .input >> >> to BUILD_VM_COMPILER_TESTS and keep the SUFFIXES you already added, >> and skip the addition to SRCS. >> >> /Erik >> >> On 2019-09-17 15:45, Ekaterina Pavlova wrote: >>> Hi, >>> >>> please review the following change which fixes >>> org.graalvm.compiler.debug.test.DebugContextTest. >>> The test fails because it tries to read >>> DebugContextTest.testLogging.input file which is not available at >>> runtime. >>> The fix copies testLogging.input file into jdk.vm.compiler.tests.jar. >>> >>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8231145 >>> ? webrev: >>> http://cr.openjdk.java.net/~epavlova//8231145/webrev.00/index.html >>> ?testing: run compiler/graalunit/DebugTest.java >>> >>> thanks, >>> -katya > From christoph.langer at sap.com Thu Sep 19 09:47:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Sep 2019 09:47:16 +0000 Subject: RFR: 8230857: Avoid reflection in sun.tools.common.ProcessHelper In-Reply-To: References: <555a2cf2-e15e-abb6-5c0a-fb3ff4c0716f@oracle.com> <7cef2fd2-74cb-f069-d837-b5219924efc0@oracle.com> <105a9f1f-9b1e-c707-b65d-6e71db7c701d@oracle.com> <431b85fb-b131-b55b-f7a8-d7112b2c9fa4@oracle.com> <98c7eadb-3003-cea7-f5a3-c902d9a6f1db@oracle.com> Message-ID: Hi, @Erik, Magnus: Thanks for stepping in to explain things. Now back to the actual change: Is this ok then (@David)? Any other reviews from somebody else? http://cr.openjdk.java.net/~clanger/webrevs/8230857.1/ Thank you! Best regards Christoph > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 18. September 2019 01:13 > To: Erik Joelsson ; Magnus Ihse Bursie > ; Langer, Christoph > ; OpenJDK Serviceability dev at openjdk.java.net>; build-dev > Subject: Re: RFR: 8230857: Avoid reflection in > sun.tools.common.ProcessHelper > > Hi Erik, > > Thanks for the additional details (I can't say I fully understand them :) ). > > David > > On 17/09/2019 11:39 pm, Erik Joelsson wrote: > > Hello, > > > > On 2019-09-17 05:59, David Holmes wrote: > >> Hi Magnus, > >> > >> On 17/09/2019 9:26 pm, Magnus Ihse Bursie wrote: > >>> On 2019-09-17 01:01, David Holmes wrote: > >>>> Hi Christoph, > >>>> > >>>> Sorry for the delay getting back you. > >>>> > >>>> cc'd build-dev to get some clarification on the below ... > >>>> > >>>> On 12/09/2019 7:30 pm, Langer, Christoph wrote: > >>>>> Hi David, > >>>>> > >>>>>>> please review an enhancement which I've identified when working > with > >>>>>>> Processhelper for JDK-8230850. > >>>>>>> > >>>>>>> I noticed that ProcessHelper is an interface in common code with a > >>>>>>> static method that would lookup the actual platform > >>>>>>> implementation via > >>>>>>> reflection. This seems a little cumbersome since we can have a > >>>>>>> common > >>>>>>> dummy for ProcessHelper and override it with the platform specific > >>>>>>> implementation, leveraging the build system. > >>>>>> > >>>>>> I don't see you leveraging the build system. You have two source > >>>>>> files > >>>>>> that compile to the same destination class file. What is ensuring the > >>>>>> platform specific version is compiled after the generic one? > >>>>>> > >>>>>> Service-provider patterns use reflection to instantiate the service > >>>>>> implementation. I don't see any problem here that needs solving. > >>>>> > >>>>> TL;DR: > >>>>> There are two source files, one in share/classes and one in > >>>>> linux/classes. The build system overrides the share/classes > >>>>> implementation with the linux/classes implementation in the linux > >>>>> build. This is not by coincidence and only one class is contained > >>>>> in the generated jdk.jcmd module. Then there won't be a need for > >>>>> having a service interface and a service implementation that is > >>>>> looked up via reflection (which is not a bad pattern by itself). I > >>>>> agree that it's not a big problem to be solved but still not "no > >>>>> problem". > >>>>> Here is some longer elaboration how the build system prefers > >>>>> specific implementations of classes and filters generic duplicates: > >>>>> The SetupJavaCompilation function from JavaCompilation.gmk [0] is > >>>>> used to compile the java sources for JDK modules. In its > >>>>> documentation, for argument SRC [1], it claims: "one or more > >>>>> directories to search for sources. The order of the source roots is > >>>>> significant. The first found file of a certain name has priority". > >>>>> In its implementation the found files are first ordered [3] and > >>>>> duplicates filtered out [4]. > >>>>> The potential source files are handed to SetupJavaCompilation in > >>>>> CompileJavaModules.gmk [5] and were collected by a call to > >>>>> FindModuleSrcDirs [6]. FindModuleSrcDirs iterates over all > >>>>> potential source dirs for Java classes in the module [7]. The > >>>>> evaluated subdirs are (in that order) > $(OPENJDK_TARGET_OS)/classes, > >>>>> $(OPENJDK_TARGET_OS_TYPE)/classes and share/classes, as per [8]. > >>>>> Hope that explains what I'm trying to leverage here. > >>>> > >>>> I'm not 100% certain that what you describe actually ensures what > >>>> you want it to ensure. I can't reconcile "the first found file ... > >>>> has priority" with the fact found files are sorted and duplicates > >>>> eliminated. It is the sorting that concerns me as it suggests > >>>> linux/Foo.java might replace shared/Foo.java, but if we're on > >>>> Windows then we have a problem! That said there is also this > comment: > >>>> > >>>> # Order src files according to the order of the src dirs. Correct > >>>> odering is > >>>> # needed for correct overriding between different source roots. > >>>> > >>>> I'd need the build team to clarify what "correct overriding" is > >>>> actually defined as. > >>> David, > >>> > >>> Christoph is correct. linux/Foo.java will override share/Foo.java. I > >>> don't remember how the magic in JavaCompilation.gmk works anymore > >>> :-), but we have relied on this behavior in other places for a long > >>> time, so I'm pretty certain it is still working correctly. > >>> Presumably, the $(sort ...) is there to remove (identical) > >>> duplicates, which is a side-effect of sort. > >> > >> Thanks for confirming. I'd still like to understand exactly what these > >> overriding rules are though. It's not a mechanism I was aware of. > >> > > SetupJavaCompilation is indeed behaving as Christoph describes and it is > > by design. I implemented support for this behavior in: > > > > https://bugs.openjdk.java.net/browse/JDK-8079344 > > > > The relevant parts of SetupJavaCompilation look like this: > > > > ? # Order src files according to the order of the src dirs. Correct > > odering is > > ? # needed for correct overriding between different source roots. > > ? $1_ALL_SRC_RAW := $$(call FindFiles, $$($1_SRC)) > > ? $1_ALL_SRCS := $$($1_EXTRA_FILES) \ > > ????? $$(foreach d, $$($1_SRC), $$(filter $$d%, $$($1_ALL_SRC_RAW))) > > > > The second line orders the src files by the src roots. (We used to just > > call find for one src root at a time, but the above actually performs > > better due only running 1 external process) > > > > Further down we have this: > > > > ? ifneq ($$($1_KEEP_DUPS), true) > > ??? # Remove duplicate source files by keeping the first found of each > > duplicate. > > ??? # This allows for automatic overrides with custom or platform > > specific versions > > ??? # source files. > > ??? # > > ??? # For the smart javac wrapper case, add each removed file to an > > extra exclude > > ??? # file list to prevent sjavac from finding duplicate sources. > > ??? $1_SRCS := $$(strip $$(foreach s, $$($1_SRCS), \ > > ??????? $$(eval relative_src := $$(call remove-prefixes, $$($1_SRC), > > $$(s))) \ > > ??????? $$(if $$($1_$$(relative_src)), \ > > ????????? $$(eval $1_SJAVAC_EXCLUDE_FILES += $$(s)), \ > > ????????? $$(eval $1_$$(relative_src) := 1) $$(s)))) > > ? endif > > > > This loop is a bit hairy to wrap your head around. It's iterating over > > all the src files, in the order of importance. The variable relative_src > > is the path from the src root, the part that is common to all duplicate > > src files. The variables on the form $1_$$(relative_src) basically act > > as a hash map (string->boolean). So for each src file, if the relative > > path for it has already been seen, add it to an exclude list, else mark > > it as seen and add it to the return list. > > > > /Erik > > From david.holmes at oracle.com Thu Sep 19 11:56:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Sep 2019 21:56:13 +1000 Subject: RFR: 8230857: Avoid reflection in sun.tools.common.ProcessHelper In-Reply-To: References: <555a2cf2-e15e-abb6-5c0a-fb3ff4c0716f@oracle.com> <7cef2fd2-74cb-f069-d837-b5219924efc0@oracle.com> <105a9f1f-9b1e-c707-b65d-6e71db7c701d@oracle.com> <431b85fb-b131-b55b-f7a8-d7112b2c9fa4@oracle.com> <98c7eadb-3003-cea7-f5a3-c902d9a6f1db@oracle.com> Message-ID: Hi Christoph, On 19/09/2019 7:47 pm, Langer, Christoph wrote: > Hi, > > @Erik, Magnus: Thanks for stepping in to explain things. > > Now back to the actual change: Is this ok then (@David)? Any other reviews from somebody else? > > http://cr.openjdk.java.net/~clanger/webrevs/8230857.1/ It seems okay. For the test I'm unclear on exactly how to ensure things are accessible, but presumably the +open is sufficient and works under all circumstances. Thanks, David > Thank you! > > Best regards > Christoph > >> -----Original Message----- >> From: David Holmes >> Sent: Mittwoch, 18. September 2019 01:13 >> To: Erik Joelsson ; Magnus Ihse Bursie >> ; Langer, Christoph >> ; OpenJDK Serviceability > dev at openjdk.java.net>; build-dev >> Subject: Re: RFR: 8230857: Avoid reflection in >> sun.tools.common.ProcessHelper >> >> Hi Erik, >> >> Thanks for the additional details (I can't say I fully understand them :) ). >> >> David >> >> On 17/09/2019 11:39 pm, Erik Joelsson wrote: >>> Hello, >>> >>> On 2019-09-17 05:59, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> On 17/09/2019 9:26 pm, Magnus Ihse Bursie wrote: >>>>> On 2019-09-17 01:01, David Holmes wrote: >>>>>> Hi Christoph, >>>>>> >>>>>> Sorry for the delay getting back you. >>>>>> >>>>>> cc'd build-dev to get some clarification on the below ... >>>>>> >>>>>> On 12/09/2019 7:30 pm, Langer, Christoph wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>>> please review an enhancement which I've identified when working >> with >>>>>>>>> Processhelper for JDK-8230850. >>>>>>>>> >>>>>>>>> I noticed that ProcessHelper is an interface in common code with a >>>>>>>>> static method that would lookup the actual platform >>>>>>>>> implementation via >>>>>>>>> reflection. This seems a little cumbersome since we can have a >>>>>>>>> common >>>>>>>>> dummy for ProcessHelper and override it with the platform specific >>>>>>>>> implementation, leveraging the build system. >>>>>>>> >>>>>>>> I don't see you leveraging the build system. You have two source >>>>>>>> files >>>>>>>> that compile to the same destination class file. What is ensuring the >>>>>>>> platform specific version is compiled after the generic one? >>>>>>>> >>>>>>>> Service-provider patterns use reflection to instantiate the service >>>>>>>> implementation. I don't see any problem here that needs solving. >>>>>>> >>>>>>> TL;DR: >>>>>>> There are two source files, one in share/classes and one in >>>>>>> linux/classes. The build system overrides the share/classes >>>>>>> implementation with the linux/classes implementation in the linux >>>>>>> build. This is not by coincidence and only one class is contained >>>>>>> in the generated jdk.jcmd module. Then there won't be a need for >>>>>>> having a service interface and a service implementation that is >>>>>>> looked up via reflection (which is not a bad pattern by itself). I >>>>>>> agree that it's not a big problem to be solved but still not "no >>>>>>> problem". >>>>>>> Here is some longer elaboration how the build system prefers >>>>>>> specific implementations of classes and filters generic duplicates: >>>>>>> The SetupJavaCompilation function from JavaCompilation.gmk [0] is >>>>>>> used to compile the java sources for JDK modules. In its >>>>>>> documentation, for argument SRC [1], it claims: "one or more >>>>>>> directories to search for sources. The order of the source roots is >>>>>>> significant. The first found file of a certain name has priority". >>>>>>> In its implementation the found files are first ordered [3] and >>>>>>> duplicates filtered out [4]. >>>>>>> The potential source files are handed to SetupJavaCompilation in >>>>>>> CompileJavaModules.gmk [5] and were collected by a call to >>>>>>> FindModuleSrcDirs [6]. FindModuleSrcDirs iterates over all >>>>>>> potential source dirs for Java classes in the module [7]. The >>>>>>> evaluated subdirs are (in that order) >> $(OPENJDK_TARGET_OS)/classes, >>>>>>> $(OPENJDK_TARGET_OS_TYPE)/classes and share/classes, as per [8]. >>>>>>> Hope that explains what I'm trying to leverage here. >>>>>> >>>>>> I'm not 100% certain that what you describe actually ensures what >>>>>> you want it to ensure. I can't reconcile "the first found file ... >>>>>> has priority" with the fact found files are sorted and duplicates >>>>>> eliminated. It is the sorting that concerns me as it suggests >>>>>> linux/Foo.java might replace shared/Foo.java, but if we're on >>>>>> Windows then we have a problem! That said there is also this >> comment: >>>>>> >>>>>> # Order src files according to the order of the src dirs. Correct >>>>>> odering is >>>>>> # needed for correct overriding between different source roots. >>>>>> >>>>>> I'd need the build team to clarify what "correct overriding" is >>>>>> actually defined as. >>>>> David, >>>>> >>>>> Christoph is correct. linux/Foo.java will override share/Foo.java. I >>>>> don't remember how the magic in JavaCompilation.gmk works anymore >>>>> :-), but we have relied on this behavior in other places for a long >>>>> time, so I'm pretty certain it is still working correctly. >>>>> Presumably, the $(sort ...) is there to remove (identical) >>>>> duplicates, which is a side-effect of sort. >>>> >>>> Thanks for confirming. I'd still like to understand exactly what these >>>> overriding rules are though. It's not a mechanism I was aware of. >>>> >>> SetupJavaCompilation is indeed behaving as Christoph describes and it is >>> by design. I implemented support for this behavior in: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8079344 >>> >>> The relevant parts of SetupJavaCompilation look like this: >>> >>> ? # Order src files according to the order of the src dirs. Correct >>> odering is >>> ? # needed for correct overriding between different source roots. >>> ? $1_ALL_SRC_RAW := $$(call FindFiles, $$($1_SRC)) >>> ? $1_ALL_SRCS := $$($1_EXTRA_FILES) \ >>> ????? $$(foreach d, $$($1_SRC), $$(filter $$d%, $$($1_ALL_SRC_RAW))) >>> >>> The second line orders the src files by the src roots. (We used to just >>> call find for one src root at a time, but the above actually performs >>> better due only running 1 external process) >>> >>> Further down we have this: >>> >>> ? ifneq ($$($1_KEEP_DUPS), true) >>> ??? # Remove duplicate source files by keeping the first found of each >>> duplicate. >>> ??? # This allows for automatic overrides with custom or platform >>> specific versions >>> ??? # source files. >>> ??? # >>> ??? # For the smart javac wrapper case, add each removed file to an >>> extra exclude >>> ??? # file list to prevent sjavac from finding duplicate sources. >>> ??? $1_SRCS := $$(strip $$(foreach s, $$($1_SRCS), \ >>> ??????? $$(eval relative_src := $$(call remove-prefixes, $$($1_SRC), >>> $$(s))) \ >>> ??????? $$(if $$($1_$$(relative_src)), \ >>> ????????? $$(eval $1_SJAVAC_EXCLUDE_FILES += $$(s)), \ >>> ????????? $$(eval $1_$$(relative_src) := 1) $$(s)))) >>> ? endif >>> >>> This loop is a bit hairy to wrap your head around. It's iterating over >>> all the src files, in the order of importance. The variable relative_src >>> is the path from the src root, the part that is common to all duplicate >>> src files. The variables on the form $1_$$(relative_src) basically act >>> as a hash map (string->boolean). So for each src file, if the relative >>> path for it has already been seen, add it to an exclude list, else mark >>> it as seen and add it to the return list. >>> >>> /Erik >>> From erik.joelsson at oracle.com Fri Sep 20 18:11:12 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 20 Sep 2019 11:11:12 -0700 Subject: RFR: JDK-8150741: make not equivalent to make Message-ID: <09c41b4b-dbc1-d793-74b0-b33ffd680d3e@oracle.com> This patch adds the currently missing dependencies between the top level meta-targets for each module (named just $module). Currently, we only add dependencies between the java targets for each module (as those are the only ones needed for compilation to work). With the added dependencies, it is now possible to do: $ make java.compiler $ build/linux-x86_64-normal-server-release/jdk/bin/javac Where before you had to manually add at least "java.base" to that make command line. Bug: https://bugs.openjdk.java.net/browse/JDK-8150741 Webrev: http://cr.openjdk.java.net/~erikj/8150741/webrev.01/ /Erik From mandy.chung at oracle.com Fri Sep 20 18:31:38 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Sep 2019 11:31:38 -0700 Subject: RFR: JDK-8150741: make not equivalent to make In-Reply-To: <09c41b4b-dbc1-d793-74b0-b33ffd680d3e@oracle.com> References: <09c41b4b-dbc1-d793-74b0-b33ffd680d3e@oracle.com> Message-ID: This looks right to me. Mandy On 9/20/19 11:11 AM, Erik Joelsson wrote: > This patch adds the currently missing dependencies between the top > level meta-targets for each module (named just $module). Currently, we > only add dependencies between the java targets for each module (as > those are the only ones needed for compilation to work). With the > added dependencies, it is now possible to do: > > $ make java.compiler > $ build/linux-x86_64-normal-server-release/jdk/bin/javac > > Where before you had to manually add at least "java.base" to that make > command line. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150741 > > Webrev: http://cr.openjdk.java.net/~erikj/8150741/webrev.01/ > > /Erik > From dekeeler at microsoft.com Fri Sep 20 20:42:48 2019 From: dekeeler at microsoft.com (Derek Keeler) Date: Fri, 20 Sep 2019 20:42:48 +0000 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> , Message-ID: I'd been over-optimistic in my estimate and haven't gotten our pipeline in a state where it runs the AdoptOpenJDK tests completely quite yet. However, the build works just fine, and many of the tests do complete successfully. I'll follow up with more detailed results next week. -Derek ________________________________ From: Simon Tooke Sent: September 18, 2019 5:43 AM To: Derek Keeler ; jdk8u-dev at openjdk.java.net ; build-dev Subject: Re: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u On 9/17/2019 1:31 PM, Derek Keeler wrote: Hi build-dev friends! I'm Derek Keeler, the infrastructure lead on the Java Platform team within Microsoft, working with the AdoptOpenJDK's George Adams and John Oliver. Simon, I have pulled down your jdk8u patches and have built them against macOS Mojave (with a good amount of help from George and John). Hi, and thanks for your interest. Currently, the build succeeds! I am planning to throw the entire AdoptOpenJDK test roster against it sometime today/tomorrow. I will let you know what I find as a result of those tests, and what if anything I had to do in order to get things up and running. Yes, please. Also any difficulties you had with the initial script or instructions; I know there was a syntax error that I just fixed. -Simon -Derek ________________________________ From: build-dev on behalf of Simon Tooke Sent: September 13, 2019 7:05 AM To: jdk8u-dev at openjdk.java.net ; build-dev Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u Hello all, This is a request for review of my patch to enable building 8u with modern (9,10,11) Xcode versions on macOS. I've received a few recent enquiries so I thought I'd submit this. When I first created this patch is was more for convenience, but soon macOS will require applications to be "notarized", which cannot be done with the old version of Xcode. This will become mandatory long before 8u is due to retire [1]. This patch is not intended to remove the current ability to build 8u on the current supported build platform. I have used the patch with Xcode 9,10 and a beta of 11, and used the resultant JDK to build Graal. I have not build a JDK using the old Xcode and this patch; my intent was to ensure this was still possible. There is some information available on my GitHub page: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstooke%2Fjdk8u-xcode10&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=THixfdOpuZrY8%2BdEDHFVjmV%2BnePxVGFsof9eDoqJikE%3D&reserved=0 Issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8226288&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=VHN2S0uxbbeJiiuWznYafSpXmERDdp29U%2FqVMJSdUuw%3D&reserved=0 Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~stooke%2Fwebrevs%2Fjdk-8226288-jdk8u%2F00%2F&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=T6uq0ThFfHLrqslWfCz2x846ixtLMIW5EwaP4U4Jvqc%3D&reserved=0 Previous discussion: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-June%2F009733.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=WDUf2fhTqmcNTZJJ2NNnI%2FtCKxr%2BxQLiCfPmpj3m0p8%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-July%2F009760.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=pJXk%2Bg5LlmSpogNhcINgRezCSozo7MbW%2FNWLJNrf%2BV8%3D&reserved=0 Thank you for your time, -Simon [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fsecurity%2Fnotarizing_your_app_before_distribution&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=TZmbZfAFDXXwpBJ8xibzzfoCicd5Fwm0xwdCo2hIaYo%3D&reserved=0 From erik.joelsson at oracle.com Fri Sep 20 21:44:22 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 20 Sep 2019 14:44:22 -0700 Subject: RFR: JDK-8206125: [windows] cannot pass relative path to --with-boot-jdk Message-ID: <3b640ca5-9e1c-2fa2-4b4a-0bc814b86903@oracle.com> On Windows, the BASIC_FIXUP_PATH macro in configure does not actually convert relative paths to absolute like the description claims. This patch takes the implementation already present for Unix and applies it to all the different Windows environment specific implementations. I have verified that it's now possible to use relative paths as well as ~ based paths in both Cygwin and WSL for the --with-jtreg parameter, and relative paths for --with-boot-jdk. Bug: https://bugs.openjdk.java.net/browse/JDK-8206125 Webrev: http://cr.openjdk.java.net/~erikj/8206125/webrev.01/ /Erik From tim.bell at oracle.com Fri Sep 20 22:16:19 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 20 Sep 2019 15:16:19 -0700 Subject: RFR: JDK-8206125: [windows] cannot pass relative path to --with-boot-jdk In-Reply-To: <3b640ca5-9e1c-2fa2-4b4a-0bc814b86903@oracle.com> References: <3b640ca5-9e1c-2fa2-4b4a-0bc814b86903@oracle.com> Message-ID: <1fa74043-3f7b-94b0-f6a7-d2e2ccf8dc58@oracle.com> Erik: > On Windows, the BASIC_FIXUP_PATH macro in configure does not actually > convert relative paths to absolute like the description claims. This > patch takes the implementation already present for Unix and applies it > to all the different Windows environment specific implementations. I > have verified that it's now possible to use relative paths as well as ~ > based paths in both Cygwin and WSL for the --with-jtreg parameter, and > relative paths for --with-boot-jdk. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8206125 > > Webrev: http://cr.openjdk.java.net/~erikj/8206125/webrev.01/ Looks good. Tim From zuismanm at gmail.com Sun Sep 22 13:06:13 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Sun, 22 Sep 2019 16:06:13 +0300 Subject: How to get a specific tag from Opne jdk source control. Message-ID: Hi. I need to build open JDK jdk8u 222 . I know that I can download precompiled binary distro of this version. But I need to compile it at our site. Question is - how can I get source of it? I am going to : https://hg.openjdk.java.net/jdk8u/jdk8u/tags then to jdk8u222-ga and download zip file with source directory. Then perform "get_sources.sh" and build it... When I perform java -version I get:: [jdkbuild at vl-tlv-ctm-dv7j jdk8u-eeeabadc6bf0]$ jdk8u/build/linux-x86_64-normal-server-release/images/j2re-image/bin/java -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-jdkbuild_2019_09_22_17_42-b00) OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) and not something like: openjdk version "1.8.0-b222" that I get if I download binary distro from AdoptOpenJDK site... What am I doing wrong? From david.holmes at oracle.com Sun Sep 22 23:08:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Sep 2019 09:08:08 +1000 Subject: How to get a specific tag from Opne jdk source control. In-Reply-To: References: Message-ID: Hi, On 22/09/2019 11:06 pm, Moshe Zuisman wrote: > Hi. > I need to build open JDK jdk8u 222 > > . > I know that I can download precompiled binary distro of this version. But I > need to compile it at our site. > Question is - how can I get source of it? > I am going to : > https://hg.openjdk.java.net/jdk8u/jdk8u/tags then to jdk8u222-ga > > and download zip file with source directory. > Then perform "get_sources.sh" and build it... > When I perform java -version > I get:: > [jdkbuild at vl-tlv-ctm-dv7j jdk8u-eeeabadc6bf0]$ > jdk8u/build/linux-x86_64-normal-server-release/images/j2re-image/bin/java > -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build > 1.8.0-internal-jdkbuild_2019_09_22_17_42-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > and not something like: openjdk version "1.8.0-b222" > that I get if I download binary distro from AdoptOpenJDK site... > What am I doing wrong? The build number (and other version info) is set as a configure arg when you do the build, it isn't hard-coded into the sources. David From zuismanm at gmail.com Mon Sep 23 08:13:45 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Mon, 23 Sep 2019 11:13:45 +0300 Subject: How to get a specific tag from Opne jdk source control. In-Reply-To: References: Message-ID: Hi. I just want to clarify it. If I understand you right: 1. when I download b222 - and run "get_source script - I really get source of b222 2. Text - that I get, when run "java -version" - is something that I can set , when running "configure" script Am I right? If so - what is parameter,that I have to pass to "configure" utility, to set this text? ??, 23 ????. 2019 ?. ? 02:08, David Holmes : > Hi, > > On 22/09/2019 11:06 pm, Moshe Zuisman wrote: > > Hi. > > I need to build open JDK jdk8u 222 > > < > https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u222-b10 > > > > . > > I know that I can download precompiled binary distro of this version. > But I > > need to compile it at our site. > > Question is - how can I get source of it? > > I am going to : > > https://hg.openjdk.java.net/jdk8u/jdk8u/tags then to jdk8u222-ga > > > > and download zip file with source directory. > > Then perform "get_sources.sh" and build it... > > When I perform java -version > > I get:: > > [jdkbuild at vl-tlv-ctm-dv7j jdk8u-eeeabadc6bf0]$ > > jdk8u/build/linux-x86_64-normal-server-release/images/j2re-image/bin/java > > -version > > openjdk version "1.8.0-internal" > > OpenJDK Runtime Environment (build > > 1.8.0-internal-jdkbuild_2019_09_22_17_42-b00) > > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > > > and not something like: openjdk version "1.8.0-b222" > > that I get if I download binary distro from AdoptOpenJDK site... > > What am I doing wrong? > > The build number (and other version info) is set as a configure arg when > you do the build, it isn't hard-coded into the sources. > > David > From sgehwolf at redhat.com Mon Sep 23 08:18:08 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Sep 2019 10:18:08 +0200 Subject: How to get a specific tag from Opne jdk source control. In-Reply-To: References: Message-ID: On Sun, 2019-09-22 at 16:06 +0300, Moshe Zuisman wrote: > Hi. > I need to build open JDK jdk8u 222 > > . > I know that I can download precompiled binary distro of this version. But I > need to compile it at our site. > Question is - how can I get source of it? > I am going to : > https://hg.openjdk.java.net/jdk8u/jdk8u/tags then to jdk8u222-ga > > and download zip file with source directory. > Then perform "get_sources.sh" and build it... > When I perform java -version > I get:: > [jdkbuild at vl-tlv-ctm-dv7j jdk8u-eeeabadc6bf0]$ > jdk8u/build/linux-x86_64-normal-server-release/images/j2re-image/bin/java > -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build > 1.8.0-internal-jdkbuild_2019_09_22_17_42-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > and not something like: openjdk version "1.8.0-b222" > that I get if I download binary distro from AdoptOpenJDK site... > What am I doing wrong? Like David said, you'd need to configure the build properly so as to pass the right flags. For inspiration consider these: https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/blob/master/build-openjdk8.sh#L45 Thanks, Severin From david.holmes at oracle.com Mon Sep 23 08:31:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Sep 2019 18:31:27 +1000 Subject: How to get a specific tag from Opne jdk source control. In-Reply-To: References: Message-ID: On 23/09/2019 6:13 pm, Moshe Zuisman wrote: > Hi. > I just want to clarify?it. > If I understand you right: > > 1. when I download b222 - and run "get_source script - I really get > source of b222 Yes. > 2. Text - that I get, when run "java -version" - is something that I > can set , when running "configure" script > > Am I right? If so - what is parameter,that I have to pass to "configure" > utility, to set this text? Yes you have control via a number of flags as per Severin's link. I don't know the full set of what you would need, but look at: --with-milestone --with-update-version --with-build-number David > ??, 23 ????. 2019 ?. ? 02:08, David Holmes >: > > Hi, > > On 22/09/2019 11:06 pm, Moshe Zuisman wrote: > > Hi. > > I need to build open JDK jdk8u 222 > > > > > . > > I know that I can download precompiled binary distro of this > version. But I > > need to compile it at our site. > > Question is - how can I get source of it? > > I am going to : > > https://hg.openjdk.java.net/jdk8u/jdk8u/tags then to jdk8u222-ga > > > > and download? zip file? with source directory. > > Then perform "get_sources.sh" and build it... > > When I perform java -version > > I get:: > > [jdkbuild at vl-tlv-ctm-dv7j jdk8u-eeeabadc6bf0]$ > > > jdk8u/build/linux-x86_64-normal-server-release/images/j2re-image/bin/java > > -version > > openjdk version "1.8.0-internal" > > OpenJDK Runtime Environment (build > > 1.8.0-internal-jdkbuild_2019_09_22_17_42-b00) > > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > > > and not something like:? openjdk version "1.8.0-b222" > > that I get if I download binary distro from AdoptOpenJDK site... > > What am I doing wrong? > > The build number (and other version info) is set as a configure arg > when > you do the build, it isn't hard-coded into the sources. > > David > From huangjia at loongson.cn Mon Sep 23 10:04:20 2019 From: huangjia at loongson.cn (Jia Huang) Date: Mon, 23 Sep 2019 18:04:20 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc Message-ID: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> Hi all, JBS: https://bugs.openjdk.java.net/browse/JDK-8231351 Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. According to the comments in JDK-8231338, it was caused by the improper NSS libs of the system. These failures are confusing and hard to diagnose. It might be better to add some notes for the pkcs11 tests. Thanks a lot. Best regards, Jia From sha.jiang at oracle.com Mon Sep 23 12:54:51 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 23 Sep 2019 20:54:51 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> Message-ID: <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Hi Jia, I think this isn't a general testing problem. It may not worthy of highlighting this point in the JDK testing doc. In fact, PKCS11 tests have their own doc at: test/jdk/sun/security/pkcs11/README Best regards, John Jiang On 2019/9/23 18:04, Jia Huang wrote: > Hi all, > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231351 > Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ > > sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. > According to the comments in JDK-8231338, it was caused by the > improper NSS libs of the system. > > These failures are confusing and hard to diagnose. > It might be better to add some notes for the pkcs11 tests. > > Thanks a lot. > > Best regards, > Jia > > > From erik.joelsson at oracle.com Mon Sep 23 15:18:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Sep 2019 08:18:00 -0700 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Message-ID: I think this type of comment fits well in the top level test doc. It just provides basic instructions for setting up these tests so that they pass without going into too much detail. Perhaps a reference to the pkcs11 README for more details would be a good idea. Looks good to me. /Erik On 2019-09-23 05:54, sha.jiang at oracle.com wrote: > Hi Jia, > I think this isn't a general testing problem. > It may not worthy of highlighting this point in the JDK testing doc. > In fact, PKCS11 tests have their own doc at: > test/jdk/sun/security/pkcs11/README > > Best regards, > John Jiang > > On 2019/9/23 18:04, Jia Huang wrote: >> Hi all, >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231351 >> Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ >> >> sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. >> According to the comments in JDK-8231338, it was caused by the >> improper NSS libs of the system. >> >> These failures are confusing and hard to diagnose. >> It might be better to add some notes for the pkcs11 tests. >> >> Thanks a lot. >> >> Best regards, >> Jia >> >> >> From erik.joelsson at oracle.com Mon Sep 23 17:12:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Sep 2019 10:12:17 -0700 Subject: RFR: JDK-8210794: Incorrect escaping of $ORIGIN in native test libraries Message-ID: This patch fixes an escaping issue that causes a broken runpath to be set in test libraries. Bug: https://bugs.openjdk.java.net/browse/JDK-8210794 Webrev: http://cr.openjdk.java.net/~erikj/8210794/webrev.01/index.html /Erik From tim.bell at oracle.com Mon Sep 23 18:55:30 2019 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 23 Sep 2019 11:55:30 -0700 Subject: RFR: JDK-8210794: Incorrect escaping of $ORIGIN in native test libraries In-Reply-To: References: Message-ID: Erik: > This patch fixes an escaping issue that causes a broken runpath to be > set in test libraries. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210794 > > Webrev: http://cr.openjdk.java.net/~erikj/8210794/webrev.01/index.html Looks good. Tim From huangjia at loongson.cn Tue Sep 24 03:57:07 2019 From: huangjia at loongson.cn (Jia Huang) Date: Tue, 24 Sep 2019 11:57:07 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Message-ID: <701123fd-1fe4-7a25-619e-651a9dd7f415@loongson.cn> Hi Erik, Thank you for your review and valuable comments. Updated: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ - The reference to the pkcs11 README and the reviewers had been added. Please note the user in the patch. Hope you wouldn't mind it. Thanks. Could you please sponsor it? Thanks a lot. Best regards, Jia ? 2019?09?23? 23:18, Erik Joelsson ??: > I think this type of comment fits well in the top level test doc. It > just provides basic instructions for setting up these tests so that > they pass without going into too much detail. Perhaps a reference to > the pkcs11 README for more details would be a good idea. > > Looks good to me. > > /Erik > > On 2019-09-23 05:54, sha.jiang at oracle.com wrote: >> Hi Jia, >> I think this isn't a general testing problem. >> It may not worthy of highlighting this point in the JDK testing doc. >> In fact, PKCS11 tests have their own doc at: >> test/jdk/sun/security/pkcs11/README >> >> Best regards, >> John Jiang >> >> On 2019/9/23 18:04, Jia Huang wrote: >>> Hi all, >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8231351 >>> Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ >>> >>> sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. >>> According to the comments in JDK-8231338, it was caused by the >>> improper NSS libs of the system. >>> >>> These failures are confusing and hard to diagnose. >>> It might be better to add some notes for the pkcs11 tests. >>> >>> Thanks a lot. >>> >>> Best regards, >>> Jia >>> >>> >>> From huangjia at loongson.cn Tue Sep 24 04:06:03 2019 From: huangjia at loongson.cn (Jia Huang) Date: Tue, 24 Sep 2019 12:06:03 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Message-ID: Hi John Jiang, Thank you for your review. ? 2019?09?23? 20:54, sha.jiang at oracle.com ??: > In fact, PKCS11 tests have their own doc at: > test/jdk/sun/security/pkcs11/README I'm afraid most people wouldn't see test/jdk/sun/security/pkcs11/README at all. So it makes very little sense to add the notes in it. I still prefer doc/testing.md. A reference to test/jdk/sun/security/pkcs11/README had been added in [1]. Thanks a lot. Best regards, Jia [1] http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ From magnus.ihse.bursie at oracle.com Tue Sep 24 10:00:09 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Sep 2019 12:00:09 +0200 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Message-ID: On 2019-09-17 19:31, Derek Keeler wrote: > Hi build-dev friends! > > I'm Derek Keeler, the infrastructure lead on the Java Platform team within Microsoft, working with the AdoptOpenJDK's George Adams and John Oliver. Hi Derek, Welcome to build-dev! I'm happy to see how the shared efforts of getting OpenJDK to build on multiple platforms are ever expanding. /Magnus > > Simon, I have pulled down your jdk8u patches and have built them against macOS Mojave (with a good amount of help from George and John). > > Currently, the build succeeds! > > I am planning to throw the entire AdoptOpenJDK test roster against it sometime today/tomorrow. > > I will let you know what I find as a result of those tests, and what if anything I had to do in order to get things up and running. > > -Derek > > > ________________________________ > From: build-dev on behalf of Simon Tooke > Sent: September 13, 2019 7:05 AM > To: jdk8u-dev at openjdk.java.net ; build-dev > Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u > > Hello all, > > This is a request for review of my patch to enable building 8u with > modern (9,10,11) Xcode versions on macOS. I've received a few recent > enquiries so I thought I'd submit this. > > When I first created this patch is was more for convenience, but soon > macOS will require applications to be "notarized", which cannot be done > with the old version of Xcode. This will become mandatory long before > 8u is due to retire [1]. > > This patch is not intended to remove the current ability to build 8u on > the current supported build platform. > > I have used the patch with Xcode 9,10 and a beta of 11, and used the > resultant JDK to build Graal. > > I have not build a JDK using the old Xcode and this patch; my intent was > to ensure this was still possible. > > There is some information available on my GitHub page: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstooke%2Fjdk8u-xcode10&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=THixfdOpuZrY8%2BdEDHFVjmV%2BnePxVGFsof9eDoqJikE%3D&reserved=0 > > Issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8226288&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=VHN2S0uxbbeJiiuWznYafSpXmERDdp29U%2FqVMJSdUuw%3D&reserved=0 > > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~stooke%2Fwebrevs%2Fjdk-8226288-jdk8u%2F00%2F&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=T6uq0ThFfHLrqslWfCz2x846ixtLMIW5EwaP4U4Jvqc%3D&reserved=0 > > Previous discussion: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-June%2F009733.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=WDUf2fhTqmcNTZJJ2NNnI%2FtCKxr%2BxQLiCfPmpj3m0p8%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-July%2F009760.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=pJXk%2Bg5LlmSpogNhcINgRezCSozo7MbW%2FNWLJNrf%2BV8%3D&reserved=0 > > Thank you for your time, > > -Simon > > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fsecurity%2Fnotarizing_your_app_before_distribution&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=TZmbZfAFDXXwpBJ8xibzzfoCicd5Fwm0xwdCo2hIaYo%3D&reserved=0 > From erik.joelsson at oracle.com Tue Sep 24 15:19:33 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Sep 2019 08:19:33 -0700 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <701123fd-1fe4-7a25-619e-651a9dd7f415@loongson.cn> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> <701123fd-1fe4-7a25-619e-651a9dd7f415@loongson.cn> Message-ID: Sure, will do. /Erik On 2019-09-23 20:57, Jia Huang wrote: > Hi Erik, > > Thank you for your review and valuable comments. > > Updated: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ > ?- The reference to the pkcs11 README and the reviewers had been added. > > Please note the user in the patch. > Hope you wouldn't mind it. Thanks. > > Could you please sponsor it? > > Thanks a lot. > Best regards, > Jia > > ? 2019?09?23? 23:18, Erik Joelsson ??: >> I think this type of comment fits well in the top level test doc. It >> just provides basic instructions for setting up these tests so that >> they pass without going into too much detail. Perhaps a reference to >> the pkcs11 README for more details would be a good idea. >> >> Looks good to me. >> >> /Erik >> >> On 2019-09-23 05:54, sha.jiang at oracle.com wrote: >>> Hi Jia, >>> I think this isn't a general testing problem. >>> It may not worthy of highlighting this point in the JDK testing doc. >>> In fact, PKCS11 tests have their own doc at: >>> test/jdk/sun/security/pkcs11/README >>> >>> Best regards, >>> John Jiang >>> >>> On 2019/9/23 18:04, Jia Huang wrote: >>>> Hi all, >>>> >>>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231351 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ >>>> >>>> sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. >>>> According to the comments in JDK-8231338, it was caused by the >>>> improper NSS libs of the system. >>>> >>>> These failures are confusing and hard to diagnose. >>>> It might be better to add some notes for the pkcs11 tests. >>>> >>>> Thanks a lot. >>>> >>>> Best regards, >>>> Jia >>>> >>>> >>>> > > From zuismanm at gmail.com Tue Sep 24 15:31:52 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Tue, 24 Sep 2019 18:31:52 +0300 Subject: How to get a specific tag from Opne jdk source control. In-Reply-To: References: Message-ID: Thanks! ??, 23 ????. 2019 ?. ? 11:33, David Holmes : > On 23/09/2019 6:13 pm, Moshe Zuisman wrote: > > Hi. > > I just want to clarify it. > > If I understand you right: > > > > 1. when I download b222 - and run "get_source script - I really get > > source of b222 > > Yes. > > > 2. Text - that I get, when run "java -version" - is something that I > > can set , when running "configure" script > > > > Am I right? If so - what is parameter,that I have to pass to "configure" > > utility, to set this text? > > Yes you have control via a number of flags as per Severin's link. I > don't know the full set of what you would need, but look at: > > --with-milestone > --with-update-version > --with-build-number > > David > > > ??, 23 ????. 2019 ?. ? 02:08, David Holmes > >: > > > > Hi, > > > > On 22/09/2019 11:06 pm, Moshe Zuisman wrote: > > > Hi. > > > I need to build open JDK jdk8u 222 > > > > > < > https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u222-b10 > > > > > . > > > I know that I can download precompiled binary distro of this > > version. But I > > > need to compile it at our site. > > > Question is - how can I get source of it? > > > I am going to : > > > https://hg.openjdk.java.net/jdk8u/jdk8u/tags then to jdk8u222-ga > > > > > > and download zip file with source directory. > > > Then perform "get_sources.sh" and build it... > > > When I perform java -version > > > I get:: > > > [jdkbuild at vl-tlv-ctm-dv7j jdk8u-eeeabadc6bf0]$ > > > > > > jdk8u/build/linux-x86_64-normal-server-release/images/j2re-image/bin/java > > > -version > > > openjdk version "1.8.0-internal" > > > OpenJDK Runtime Environment (build > > > 1.8.0-internal-jdkbuild_2019_09_22_17_42-b00) > > > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > > > > > and not something like: openjdk version "1.8.0-b222" > > > that I get if I download binary distro from AdoptOpenJDK site... > > > What am I doing wrong? > > > > The build number (and other version info) is set as a configure arg > > when > > you do the build, it isn't hard-coded into the sources. > > > > David > > > From huangjia at loongson.cn Wed Sep 25 02:06:23 2019 From: huangjia at loongson.cn (Jia Huang) Date: Wed, 25 Sep 2019 10:06:23 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> <701123fd-1fe4-7a25-619e-651a9dd7f415@loongson.cn> Message-ID: <8f6c88b2-d2e7-61c0-97ee-6688adb2a378@loongson.cn> Thanks Erik. ? 2019?09?24? 23:19, Erik Joelsson ??: > Sure, will do. > > /Erik From erik.joelsson at oracle.com Wed Sep 25 17:59:27 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 25 Sep 2019 10:59:27 -0700 Subject: RFR: JDK-8231467: Missing make prerequisite declaration corrupts make dependency files on Windows Message-ID: <3960057f-4662-a22b-8b02-ad9465a48c13@oracle.com> In JDK-8217728 I introduced a new rule in SetupNativeCompilation which combines all the generated *.d dependency files into one for each link target. This combining currently depends on all the object files being compiled first. On Windows, we sometimes also create a resource file, which also produces a *.d dependency file. This file is not declared as a prerequisite of the combined *.d file, which causes a race between the two. Bug: https://bugs.openjdk.java.net/browse/JDK-8231467 Webrev: http://cr.openjdk.java.net/~erikj/8231467/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Wed Sep 25 18:59:37 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Sep 2019 20:59:37 +0200 Subject: RFR: JDK-8231467: Missing make prerequisite declaration corrupts make dependency files on Windows In-Reply-To: <3960057f-4662-a22b-8b02-ad9465a48c13@oracle.com> References: <3960057f-4662-a22b-8b02-ad9465a48c13@oracle.com> Message-ID: Looks good to me. /Magnus > 25 sep. 2019 kl. 19:59 skrev Erik Joelsson : > > In JDK-8217728 I introduced a new rule in SetupNativeCompilation which combines all the generated *.d dependency files into one for each link target. This combining currently depends on all the object files being compiled first. On Windows, we sometimes also create a resource file, which also produces a *.d dependency file. This file is not declared as a prerequisite of the combined *.d file, which causes a race between the two. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231467 > > Webrev: http://cr.openjdk.java.net/~erikj/8231467/webrev.01/ > > /Erik > From tim.bell at oracle.com Wed Sep 25 20:24:18 2019 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 25 Sep 2019 13:24:18 -0700 Subject: RFR: JDK-8231467: Missing make prerequisite declaration corrupts make dependency files on Windows In-Reply-To: References: <3960057f-4662-a22b-8b02-ad9465a48c13@oracle.com> Message-ID: <86818c40-6387-8873-6e33-491844cdb16b@oracle.com> Erik: Looks good to me as well. Tim On 2019-09-25 11:59, Magnus Ihse Bursie wrote: > Looks good to me. > > /Magnus > >> 25 sep. 2019 kl. 19:59 skrev Erik Joelsson : >> >> In JDK-8217728 I introduced a new rule in SetupNativeCompilation which combines all the generated *.d dependency files into one for each link target. This combining currently depends on all the object files being compiled first. On Windows, we sometimes also create a resource file, which also produces a *.d dependency file. This file is not declared as a prerequisite of the combined *.d file, which causes a race between the two. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231467 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8231467/webrev.01/ >> >> /Erik >> > From sgehwolf at redhat.com Fri Sep 27 15:48:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Sep 2019 17:48:02 +0200 Subject: [8u] RFR: 8227397: Add --with-extra-asflags configure option Message-ID: <62e03a27132a82b9f8f22c8fb16d21fba66a7bb6.camel@redhat.com> Hi, Could I please get a review of this 8u build change backport which adds --with-extra-asflags to OpenJDK 8u. At Red Hat, we need to pass certain assembler only flags for some builds. For example "-Wa,--generate- missing-build-notes=yes", to assembly files only. As the build system is different in 8u over 11u I've re-done the patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8227397 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/jdk8/01/ Testing: Built with --with-extra-asflags=-Wa,--generate-missing-build- notes=yes on Linux x86_64, confirmed linux_x86_64.s gets assembled with the flag and only that file. I've omitted the windows portion of passing as flags to the hotspot build as I've no idea how. Contributions welcome if that should get included. Thoughts? Thanks, Severin From erik.joelsson at oracle.com Fri Sep 27 22:37:53 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 27 Sep 2019 15:37:53 -0700 Subject: RFR: JDK-8231594: Configure fails on some Linux systems Message-ID: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> In my recent change JDK-8206125, I introduced a bash conditional that checks if a string starts with ~. That check seems to fail on some Linux systems unless the ~ is quoted. Bug: https://bugs.openjdk.java.net/browse/JDK-8231594 Webrev: http://cr.openjdk.java.net/~erikj/8231594/webrev.01 /Erik From tim.bell at oracle.com Fri Sep 27 23:15:43 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 27 Sep 2019 16:15:43 -0700 Subject: RFR: JDK-8231594: Configure fails on some Linux systems In-Reply-To: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> References: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> Message-ID: <5ce8f361-0794-957a-4db3-adde6741a1e6@oracle.com> Erik: > In my recent change JDK-8206125, I introduced a bash conditional that > checks if a string starts with ~. That check seems to fail on some Linux > systems unless the ~ is quoted. That's a very dark corner for the shell to be in... > Bug: https://bugs.openjdk.java.net/browse/JDK-8231594 > > Webrev: http://cr.openjdk.java.net/~erikj/8231594/webrev.01 Looks good. Tim From martinrb at google.com Sat Sep 28 01:12:55 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 27 Sep 2019 18:12:55 -0700 Subject: RFR: JDK-8231594: Configure fails on some Linux systems In-Reply-To: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> References: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> Message-ID: Looks good, ... although I question whether any Unix program other than the shell itself should be trying to do tilde-path-expansion. Consider fixing the code by deleting it. On Fri, Sep 27, 2019 at 3:42 PM Erik Joelsson wrote: > In my recent change JDK-8206125, I introduced a bash conditional that > checks if a string starts with ~. That check seems to fail on some Linux > systems unless the ~ is quoted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231594 > > Webrev: http://cr.openjdk.java.net/~erikj/8231594/webrev.01 > > /Erik > > From magnus.ihse.bursie at oracle.com Mon Sep 30 09:36:07 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 30 Sep 2019 11:36:07 +0200 Subject: [8u] RFR: 8227397: Add --with-extra-asflags configure option In-Reply-To: <62e03a27132a82b9f8f22c8fb16d21fba66a7bb6.camel@redhat.com> References: <62e03a27132a82b9f8f22c8fb16d21fba66a7bb6.camel@redhat.com> Message-ID: On 2019-09-27 17:48, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this 8u build change backport which adds > --with-extra-asflags to OpenJDK 8u. At Red Hat, we need to pass certain > assembler only flags for some builds. For example "-Wa,--generate- > missing-build-notes=yes", to assembly files only. As the build system > is different in 8u over 11u I've re-done the patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227397 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/jdk8/01/ Looks good to me. /Magnus > > Testing: Built with --with-extra-asflags=-Wa,--generate-missing-build- > notes=yes on Linux x86_64, confirmed linux_x86_64.s gets assembled with > the flag and only that file. > > I've omitted the windows portion of passing as flags to the hotspot > build as I've no idea how. Contributions welcome if that should get > included. > > Thoughts? > > Thanks, > Severin > From sgehwolf at redhat.com Mon Sep 30 09:40:26 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Sep 2019 11:40:26 +0200 Subject: [8u] RFR: 8227397: Add --with-extra-asflags configure option In-Reply-To: References: <62e03a27132a82b9f8f22c8fb16d21fba66a7bb6.camel@redhat.com> Message-ID: <2713290d3fe9b5fd4aecc47edb1e16d9b79c1063.camel@redhat.com> On Mon, 2019-09-30 at 11:36 +0200, Magnus Ihse Bursie wrote: > On 2019-09-27 17:48, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review of this 8u build change backport which adds > > --with-extra-asflags to OpenJDK 8u. At Red Hat, we need to pass certain > > assembler only flags for some builds. For example "-Wa,--generate- > > missing-build-notes=yes", to assembly files only. As the build system > > is different in 8u over 11u I've re-done the patch. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227397 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/jdk8/01/ > Looks good to me. > > /Magnus Thanks for the review, Magnus! Cheers, Severin > > Testing: Built with --with-extra-asflags=-Wa,--generate-missing-build- > > notes=yes on Linux x86_64, confirmed linux_x86_64.s gets assembled with > > the flag and only that file. > > > > I've omitted the windows portion of passing as flags to the hotspot > > build as I've no idea how. Contributions welcome if that should get > > included. > > > > Thoughts? > > > > Thanks, > > Severin > > > From magnus.ihse.bursie at oracle.com Mon Sep 30 09:41:32 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 30 Sep 2019 11:41:32 +0200 Subject: RFR: JDK-8231594: Configure fails on some Linux systems In-Reply-To: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> References: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> Message-ID: <1e238bdc-5e47-2053-b2c3-01910d45419c@oracle.com> On 2019-09-28 00:37, Erik Joelsson wrote: > In my recent change JDK-8206125, I introduced a bash conditional that > checks if a string starts with ~. That check seems to fail on some > Linux systems unless the ~ is quoted. Do you need the check? The old code, prior to JDK-8206125, unconditionally made the eval. Maybe that was a safer route? This feels a bit shaky, and the old code has (afaik) been working okay. /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231594 > > Webrev: http://cr.openjdk.java.net/~erikj/8231594/webrev.01 > > /Erik > From erik.joelsson at oracle.com Mon Sep 30 15:02:14 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 30 Sep 2019 08:02:14 -0700 Subject: RFR: JDK-8231594: Configure fails on some Linux systems In-Reply-To: <1e238bdc-5e47-2053-b2c3-01910d45419c@oracle.com> References: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> <1e238bdc-5e47-2053-b2c3-01910d45419c@oracle.com> Message-ID: <52b699ee-fe92-5efa-2292-ff79055354a5@oracle.com> On 2019-09-30 02:41, Magnus Ihse Bursie wrote: > On 2019-09-28 00:37, Erik Joelsson wrote: >> In my recent change JDK-8206125, I introduced a bash conditional that >> checks if a string starts with ~. That check seems to fail on some >> Linux systems unless the ~ is quoted. > Do you need the check? The old code, prior to JDK-8206125, > unconditionally made the eval. Maybe that was a safer route? This > feels a bit shaky, and the old code has (afaik) been working okay. > The check prior to JDK-8206125 only applied to Unix platforms, but in that change I made it also apply to Windows. At the point where it's called, we may still have spaces in the path, and the eval does not work with spaces. If we add quotes to handle spaces in the eval, then any ~ will not be evaluated. Basically we have to choose between supporting spaces or ~ in any one fixup call. By adding the conditional, we get to do so on Windows. /Erik > /Magnus >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231594 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8231594/webrev.01 >> >> /Erik >> > From erik.joelsson at oracle.com Mon Sep 30 15:23:50 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 30 Sep 2019 08:23:50 -0700 Subject: RFR: JDK-8231594: Configure fails on some Linux systems In-Reply-To: <52b699ee-fe92-5efa-2292-ff79055354a5@oracle.com> References: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> <1e238bdc-5e47-2053-b2c3-01910d45419c@oracle.com> <52b699ee-fe92-5efa-2292-ff79055354a5@oracle.com> Message-ID: Uploaded new webrev in place with a comment explaining this. /Erik On 2019-09-30 08:02, Erik Joelsson wrote: > On 2019-09-30 02:41, Magnus Ihse Bursie wrote: >> On 2019-09-28 00:37, Erik Joelsson wrote: >>> In my recent change JDK-8206125, I introduced a bash conditional >>> that checks if a string starts with ~. That check seems to fail on >>> some Linux systems unless the ~ is quoted. >> Do you need the check? The old code, prior to JDK-8206125, >> unconditionally made the eval. Maybe that was a safer route? This >> feels a bit shaky, and the old code has (afaik) been working okay. >> > The check prior to JDK-8206125 only applied to Unix platforms, but in > that change I made it also apply to Windows. At the point where it's > called, we may still have spaces in the path, and the eval does not > work with spaces. If we add quotes to handle spaces in the eval, then > any ~ will not be evaluated. Basically we have to choose between > supporting spaces or ~ in any one fixup call. By adding the > conditional, we get to do so on Windows. > > /Erik > >> /Magnus >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231594 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8231594/webrev.01 >>> >>> /Erik >>> >>