From jvanek at redhat.com Mon Jan 2 16:41:06 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 2 Jan 2017 17:41:06 +0100 Subject: RFC: nashorn sources are missing in src.zip Message-ID: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ Hello good people! I have found, that nashorn sources are missing in src.zip. It is easily fixable by webrev above. If you will think about it as "private api", jdk9 *have* nashorn module sources included. Actually more sun* sources are missing. Or even more sources which result to ext directory. Imho they should be included too. I will prepare patches for each set separately, if it will be agreed. I know that sun* are somehow deprecated. But it is sad when you can not easily debug inside the JDK. The absence of theirs in src.zip is not the cure. Thanx! J. From erik.joelsson at oracle.com Tue Jan 3 08:03:28 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 3 Jan 2017 09:03:28 +0100 Subject: RFC: nashorn sources are missing in src.zip In-Reply-To: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> References: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> Message-ID: <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> Hello Jiri, Please see related issue [1] which was included early in JDK 9 but the backport was never done. I don't personally mind including more sources in src.zip for OpenJDK, but instead of adding them piecemeal I would argue for reopening the backport. I don't know if such a change is suitable for 8u at this point though. The size of src.zip increases quite dramatically. However, it should be noted that it's only included in the JDK image and not the JRE. For anyone unsure of the role of src.zip, it's only use is for IDEs to see the JDK sources to aid debugging of other applications. /Erik [1] https://bugs.openjdk.java.net/browse/JDK-8044235 On 2017-01-02 17:41, Jiri Vanek wrote: > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ > > > Hello good people! > > I have found, that nashorn sources are missing in src.zip. > It is easily fixable by webrev above. > > If you will think about it as "private api", jdk9 *have* nashorn > module sources included. > > Actually more sun* sources are missing. Or even more sources which > result to ext directory. Imho they should be included too. I will > prepare patches for each set separately, if it will be agreed. > > I know that sun* are somehow deprecated. But it is sad when you can > not easily debug inside the JDK. The absence of theirs in src.zip is > not the cure. > > Thanx! > J. From jvanek at redhat.com Tue Jan 3 12:12:01 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 3 Jan 2017 13:12:01 +0100 Subject: RFC: nashorn sources are missing in src.zip In-Reply-To: <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> References: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> Message-ID: <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> Hello! Thank you very much for kind answer and additional resources. There is modified backport of patch you mentioned: https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v2/webrev/ Except the backport itself, I had to add also nashorn sources (as jdk9 is handling this a bit differently). At the end I added also sources for zipfs, as jdk9 have them too, and they were the last missing bits as far as I saw. The size of src.zip grown from 26 to 52MB (still less then 62 of jdk9). I think the change i suitable for 8u, as it is bug in truth. I found it when I faced strange behaviour in rhino and wonted to step in (with src.zip linked to ide)...and... nothing. So it was not nice surprise. Tahnx again! J. On 01/03/2017 09:03 AM, Erik Joelsson wrote: > Hello Jiri, > > Please see related issue [1] which was included early in JDK 9 but the backport was never done. I > don't personally mind including more sources in src.zip for OpenJDK, but instead of adding them > piecemeal I would argue for reopening the backport. I don't know if such a change is suitable for 8u > at this point though. The size of src.zip increases quite dramatically. However, it should be noted > that it's only included in the JDK image and not the JRE. > > For anyone unsure of the role of src.zip, it's only use is for IDEs to see the JDK sources to aid > debugging of other applications. > > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8044235 > > On 2017-01-02 17:41, Jiri Vanek wrote: >> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ >> >> Hello good people! >> >> I have found, that nashorn sources are missing in src.zip. >> It is easily fixable by webrev above. >> >> If you will think about it as "private api", jdk9 *have* nashorn module sources included. >> >> Actually more sun* sources are missing. Or even more sources which result to ext directory. Imho >> they should be included too. I will prepare patches for each set separately, if it will be agreed. >> >> I know that sun* are somehow deprecated. But it is sad when you can not easily debug inside the >> JDK. The absence of theirs in src.zip is not the cure. >> >> Thanx! >> J. > From erik.joelsson at oracle.com Tue Jan 3 12:43:38 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 3 Jan 2017 13:43:38 +0100 Subject: RFC: nashorn sources are missing in src.zip In-Reply-To: <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> References: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> Message-ID: Hello Jiri, From a pure build point of view, the change looks ok, but I don't think we are allowed to accept patches not hosted on openjdk infrastructure. The suitability of the change is a topic for jdk8u-dev (added). This should be considered an enhancement though. The restrictive inclusion of packages in JDK 8 and older was intentional and changing it in JDK 9 was definitely an enhancement. (Note that JDK 9 recently changed the src.zip again) One could argue that your original change to just include the jdk package is a bug fix since the intention of the original filtering was to just include public APIs. /Erik On 2017-01-03 13:12, Jiri Vanek wrote: > Hello! > > Thank you very much for kind answer and additional resources. > There is modified backport of patch you mentioned: > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v2/webrev/ > > > Except the backport itself, I had to add also nashorn sources (as jdk9 > is handling this a bit differently). > At the end I added also sources for zipfs, as jdk9 have them too, and > they were the last missing bits as far as I saw. > > The size of src.zip grown from 26 to 52MB (still less then 62 of jdk9). > > I think the change i suitable for 8u, as it is bug in truth. I found > it when I faced strange behaviour in rhino and wonted to step in (with > src.zip linked to ide)...and... nothing. So it was not nice surprise. > > Tahnx again! > J. > > On 01/03/2017 09:03 AM, Erik Joelsson wrote: >> Hello Jiri, >> >> Please see related issue [1] which was included early in JDK 9 but >> the backport was never done. I >> don't personally mind including more sources in src.zip for OpenJDK, >> but instead of adding them >> piecemeal I would argue for reopening the backport. I don't know if >> such a change is suitable for 8u >> at this point though. The size of src.zip increases quite >> dramatically. However, it should be noted >> that it's only included in the JDK image and not the JRE. >> >> For anyone unsure of the role of src.zip, it's only use is for IDEs >> to see the JDK sources to aid >> debugging of other applications. >> >> /Erik >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8044235 >> >> On 2017-01-02 17:41, Jiri Vanek wrote: >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ >>> >>> >>> Hello good people! >>> >>> I have found, that nashorn sources are missing in src.zip. >>> It is easily fixable by webrev above. >>> >>> If you will think about it as "private api", jdk9 *have* nashorn >>> module sources included. >>> >>> Actually more sun* sources are missing. Or even more sources which >>> result to ext directory. Imho >>> they should be included too. I will prepare patches for each set >>> separately, if it will be agreed. >>> >>> I know that sun* are somehow deprecated. But it is sad when you can >>> not easily debug inside the >>> JDK. The absence of theirs in src.zip is not the cure. >>> >>> Thanx! >>> J. >> > From jvanek at redhat.com Tue Jan 3 15:11:30 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 3 Jan 2017 16:11:30 +0100 Subject: RFC: nashorn sources are missing in src.zip In-Reply-To: References: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> Message-ID: <5e1001c2-e143-ded1-9992-035391613ca4@redhat.com> On 01/03/2017 01:43 PM, Erik Joelsson wrote: > Hello Jiri, > > From a pure build point of view, the change looks ok, but I don't think we are allowed to accept > patches not hosted on openjdk infrastructure. Those patches were already accepted. And the policy "patch first, member later" is actually enforcing patch elsewhere. I'm already in author group (jdk9 project only) so I should have place on java.net, so if this is blocker, it can be fixed. > > The suitability of the change is a topic for jdk8u-dev (added). This should be considered an Thanx! > enhancement though. The restrictive inclusion of packages in JDK 8 and older was intentional and > changing it in JDK 9 was definitely an enhancement. (Note that JDK 9 recently changed the src.zip > again) > > One could argue that your original change to just include the jdk package is a bug fix since the > intention of the original filtering was to just include public APIs. Its up to you and build-dev to decide this. If nashorn-only change will be accepted, Then I will very soon post also zipfs patch, as it is very similar. If not, then it will become just another distro-only (fedora/rhel) patch, as those sources *are* missing (if not all then nashorn definitely) Thanx a lot! All the best, J. > > /Erik > > On 2017-01-03 13:12, Jiri Vanek wrote: >> Hello! >> >> Thank you very much for kind answer and additional resources. >> There is modified backport of patch you mentioned: >> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v2/webrev/ >> >> Except the backport itself, I had to add also nashorn sources (as jdk9 is handling this a bit >> differently). >> At the end I added also sources for zipfs, as jdk9 have them too, and they were the last missing >> bits as far as I saw. >> >> The size of src.zip grown from 26 to 52MB (still less then 62 of jdk9). >> >> I think the change i suitable for 8u, as it is bug in truth. I found it when I faced strange >> behaviour in rhino and wonted to step in (with src.zip linked to ide)...and... nothing. So it was >> not nice surprise. >> >> Tahnx again! >> J. >> >> On 01/03/2017 09:03 AM, Erik Joelsson wrote: >>> Hello Jiri, >>> >>> Please see related issue [1] which was included early in JDK 9 but the backport was never done. I >>> don't personally mind including more sources in src.zip for OpenJDK, but instead of adding them >>> piecemeal I would argue for reopening the backport. I don't know if such a change is suitable for 8u >>> at this point though. The size of src.zip increases quite dramatically. However, it should be noted >>> that it's only included in the JDK image and not the JRE. >>> >>> For anyone unsure of the role of src.zip, it's only use is for IDEs to see the JDK sources to aid >>> debugging of other applications. >>> >>> /Erik >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8044235 >>> >>> On 2017-01-02 17:41, Jiri Vanek wrote: >>>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ >>>> >>>> Hello good people! >>>> >>>> I have found, that nashorn sources are missing in src.zip. >>>> It is easily fixable by webrev above. >>>> >>>> If you will think about it as "private api", jdk9 *have* nashorn module sources included. >>>> >>>> Actually more sun* sources are missing. Or even more sources which result to ext directory. Imho >>>> they should be included too. I will prepare patches for each set separately, if it will be agreed. >>>> >>>> I know that sun* are somehow deprecated. But it is sad when you can not easily debug inside the >>>> JDK. The absence of theirs in src.zip is not the cure. >>>> >>>> Thanx! >>>> J. >>> >> > From tim.bell at oracle.com Tue Jan 3 19:19:59 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 3 Jan 2017 11:19:59 -0800 Subject: RFR: JDK-8172037: Change log message of SetupCopyFiles In-Reply-To: <2e08604e-8074-a59b-6a69-47632d9296cd@oracle.com> References: <2e08604e-8074-a59b-6a69-47632d9296cd@oracle.com> Message-ID: Erik: > The makefile macro SetupCopyFiles is sometimes used for other things > than simple copying. In those cases, it would be helpful to also change > the log message that the generated recipes print to reflect that. This > patch adds such an option to the macro and applies different messages > where appropriate. > > One could argue that the name of the macro is misleading given it's > broadened usage, but I chose not to tackle that problem with this bug. > That may happen later. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172037 > > Webrev: http://cr.openjdk.java.net/~erikj/8172037/webrev.01/ Looks good. /Tim From tim.bell at oracle.com Tue Jan 3 19:24:25 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 3 Jan 2017 11:24:25 -0800 Subject: RFR: JDK-8171922: Hotspot code coverage doesn't seem to work In-Reply-To: <0ddca452-6fe6-190e-199a-3fad89058258@oracle.com> References: <0ddca452-6fe6-190e-199a-3fad89058258@oracle.com> Message-ID: <985d2944-d92e-e882-38f8-8094c38cce93@oracle.com> Erik: > When the new hotspot build was introduced, we missed converting the > support for compiling in code coverage using gcov. This patch fixes > that. While making the change I discovered that the LEGACY_EXTRA_*FLAGS > variables are now unused and can finally be completely removed, so I > went ahead and did that too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171922 > > Webrev: http://cr.openjdk.java.net/~erikj/8171922/webrev.01/ Looks good to me. /Tim From tim.bell at oracle.com Tue Jan 3 19:26:52 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 3 Jan 2017 11:26:52 -0800 Subject: RFR: JDK-8171500: Explicitly set --with-target-bits=64 in 64bit jib profiles In-Reply-To: References: Message-ID: Erik: > If a user asks Jib to build a profile that is supposed to be 64bit, we > want configure to fail early if it cannot be done. Currently, if > configure thinks the build platform only supports 32bit builds, it will > just default to 32bit. By explicitly setting --with-target-bits=64, we > instead get a failure. This patch adds the argument to all relevant Jib > profile configurations. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171500 > > Webrev: http://cr.openjdk.java.net/~erikj/8171500/webrev.01/ Looks good. /Tim From mandy.chung at oracle.com Tue Jan 3 19:27:53 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 Jan 2017 11:27:53 -0800 Subject: RFR: JDK-8171929: "make docs" in clean forest is broken In-Reply-To: <76a41c8f-5a37-87a8-e901-968867f2e83a@oracle.com> References: <76a41c8f-5a37-87a8-e901-968867f2e83a@oracle.com> Message-ID: <8CF3A7C0-C26B-46C2-B7D9-FF696C9B5AA6@oracle.com> > On Dec 27, 2016, at 2:40 AM, Erik Joelsson wrote: > > The new module, jdk.vm.compiler (as well as jdk.vm.ci), requires access to some of the newly built class files in order to run an annotation processor in the gensrc step. The extra dependency declaration for this is currently missing one module (java.instrument) in make/Main.gmk. To avoid having to maintain the list of modules they depend on in two places (module-info.java and the makefile), we can generate the dependency targets in the makefile, since we already have the module dependency information in make. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171929 > > Webrev: http://cr.openjdk.java.net/~erikj/8171929/webrev.01/ This looks okay to me. Mandy From tim.bell at oracle.com Tue Jan 3 19:31:13 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 3 Jan 2017 11:31:13 -0800 Subject: RFR: JDK-8171929: "make docs" in clean forest is broken In-Reply-To: <8CF3A7C0-C26B-46C2-B7D9-FF696C9B5AA6@oracle.com> References: <76a41c8f-5a37-87a8-e901-968867f2e83a@oracle.com> <8CF3A7C0-C26B-46C2-B7D9-FF696C9B5AA6@oracle.com> Message-ID: <2ec3b9b7-4365-8a7b-0906-8185cdba1347@oracle.com> Erik: On 01/03/17 11:27, Mandy Chung wrote: > >> On Dec 27, 2016, at 2:40 AM, Erik Joelsson wrote: >> >> The new module, jdk.vm.compiler (as well as jdk.vm.ci), requires access to some of the newly built class files in order to run an annotation processor in the gensrc step. The extra dependency declaration for this is currently missing one module (java.instrument) in make/Main.gmk. To avoid having to maintain the list of modules they depend on in two places (module-info.java and the makefile), we can generate the dependency targets in the makefile, since we already have the module dependency information in make. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171929 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8171929/webrev.01/ > > This looks okay to me. > > Mandy Looks good to me as well. /Tim From david.holmes at oracle.com Tue Jan 3 20:50:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jan 2017 06:50:06 +1000 Subject: RFC: nashorn sources are missing in src.zip In-Reply-To: <5e1001c2-e143-ded1-9992-035391613ca4@redhat.com> References: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> <5e1001c2-e143-ded1-9992-035391613ca4@redhat.com> Message-ID: Hi Jiri, On 4/01/2017 1:11 AM, Jiri Vanek wrote: > On 01/03/2017 01:43 PM, Erik Joelsson wrote: >> Hello Jiri, >> >> From a pure build point of view, the change looks ok, but I don't >> think we are allowed to accept >> patches not hosted on openjdk infrastructure. > > Those patches were already accepted. And the policy "patch first, member > later" is actually enforcing patch elsewhere. > > I'm already in author group (jdk9 project only) so I should have place > on java.net, so if this is blocker, it can be fixed. Yes please fix, it is a requirement for contribution acceptance. >> >> The suitability of the change is a topic for jdk8u-dev (added). This >> should be considered an > > Thanx! > >> enhancement though. The restrictive inclusion of packages in JDK 8 and >> older was intentional and >> changing it in JDK 9 was definitely an enhancement. (Note that JDK 9 >> recently changed the src.zip >> again) >> >> One could argue that your original change to just include the jdk >> package is a bug fix since the >> intention of the original filtering was to just include public APIs. > > > Its up to you and build-dev to decide this. > If nashorn-only change will be accepted, Then I will very soon post also > zipfs patch, as it is very similar. This is an enhancement and needs to follow the process described here: http://openjdk.java.net/projects/jdk8u/enhancement-template.html that process itself is somewhat hard to find but referenced from Rule 3 here: http://openjdk.java.net/projects/jdk8u/groundrules.html Thanks, David > If not, then it will become just another distro-only (fedora/rhel) > patch, as those sources *are* missing (if not all then nashorn definitely) > > Thanx a lot! > > All the best, > J. >> >> /Erik >> >> On 2017-01-03 13:12, Jiri Vanek wrote: >>> Hello! >>> >>> Thank you very much for kind answer and additional resources. >>> There is modified backport of patch you mentioned: >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v2/webrev/ >>> >>> >>> Except the backport itself, I had to add also nashorn sources (as >>> jdk9 is handling this a bit >>> differently). >>> At the end I added also sources for zipfs, as jdk9 have them too, >>> and they were the last missing >>> bits as far as I saw. >>> >>> The size of src.zip grown from 26 to 52MB (still less then 62 of jdk9). >>> >>> I think the change i suitable for 8u, as it is bug in truth. I found >>> it when I faced strange >>> behaviour in rhino and wonted to step in (with src.zip linked to >>> ide)...and... nothing. So it was >>> not nice surprise. >>> >>> Tahnx again! >>> J. >>> >>> On 01/03/2017 09:03 AM, Erik Joelsson wrote: >>>> Hello Jiri, >>>> >>>> Please see related issue [1] which was included early in JDK 9 but >>>> the backport was never done. I >>>> don't personally mind including more sources in src.zip for OpenJDK, >>>> but instead of adding them >>>> piecemeal I would argue for reopening the backport. I don't know if >>>> such a change is suitable for 8u >>>> at this point though. The size of src.zip increases quite >>>> dramatically. However, it should be noted >>>> that it's only included in the JDK image and not the JRE. >>>> >>>> For anyone unsure of the role of src.zip, it's only use is for IDEs >>>> to see the JDK sources to aid >>>> debugging of other applications. >>>> >>>> /Erik >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8044235 >>>> >>>> On 2017-01-02 17:41, Jiri Vanek wrote: >>>>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ >>>>> >>>>> >>>>> Hello good people! >>>>> >>>>> I have found, that nashorn sources are missing in src.zip. >>>>> It is easily fixable by webrev above. >>>>> >>>>> If you will think about it as "private api", jdk9 *have* nashorn >>>>> module sources included. >>>>> >>>>> Actually more sun* sources are missing. Or even more sources which >>>>> result to ext directory. Imho >>>>> they should be included too. I will prepare patches for each set >>>>> separately, if it will be agreed. >>>>> >>>>> I know that sun* are somehow deprecated. But it is sad when you can >>>>> not easily debug inside the >>>>> JDK. The absence of theirs in src.zip is not the cure. >>>>> >>>>> Thanx! >>>>> J. >>>> >>> >> > From tim.bell at oracle.com Thu Jan 5 19:12:17 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 5 Jan 2017 11:12:17 -0800 Subject: OpenJDK6 End Of Life In-Reply-To: Message-ID: <20170105191217.GA4169@spin> Hello- Here is what I propose for the OpenJDK6 transition process [1]: A) The current project leader (Andrew Haley) [2] resigns B) I, as leader of the build group, can put forward Andrew Brygin as the new project leader. C) As the only group leader involved in the project, the nomination is automatically approved. What remains to be done will be sending out an announcement to notify the Registrar and have it recorded. Tim [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2016-October/003606.html http://mail.openjdk.java.net/pipermail/jdk6-dev/2016-November/003607.html http://mail.openjdk.java.net/pipermail/jdk6-dev/2016-December/ [2] http://openjdk.java.net/census#jdk6 From aph at redhat.com Fri Jan 6 09:46:31 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 6 Jan 2017 09:46:31 +0000 Subject: OpenJDK6 End Of Life In-Reply-To: <20170105191217.GA4169@spin> References: <20170105191217.GA4169@spin> Message-ID: <906c1548-ac64-5a8d-f20f-9508a4b03fcd@redhat.com> On 05/01/17 19:12, Tim Bell wrote: > A) The current project leader (Andrew Haley) [2] resigns I hereby resign of the leader of the OpenJDK 6 group. > B) I, as leader of the build group, can put forward Andrew Brygin as > the new project leader. > > C) As the only group leader involved in the project, the nomination is > automatically approved. What remains to be done will be sending > out an announcement to notify the Registrar and have it recorded. I think that's right. Andrew. From tim.bell at oracle.com Fri Jan 6 15:30:28 2017 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 6 Jan 2017 07:30:28 -0800 Subject: New lead for the JDK 6 Project: Andrew Brygin Message-ID: <20170106153028.GA5354@spin> Andrew Haley has resigned as lead for the JDK 6 Project [1]. Under the bylaws for Project Roles [2], a new Project Lead may be nominated by the Group Leads of the Project's sponsoring groups. The Build Infrastructure Group is sponsor of the project. As Group Leader, I would like to nominate Andrew Brygin [3] to be the new Project Lead. The Build Infrastructure Group is the only sponsoring group for this project. I believe that makes the nomination automatically approved. -Tim [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2017-January/003613.html [2] http://openjdk.java.net/bylaws#project-lead [3] http://openjdk.java.net/census#bae From erik.joelsson at oracle.com Mon Jan 9 12:37:44 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 9 Jan 2017 13:37:44 +0100 Subject: RFR: JDK-8172241: Cleanup mistakes in jib publish support change Message-ID: <8d748a78-2e70-2057-785d-3676e25d8787@oracle.com> Hello, This is a small followup fix for JDK-8170741. It addresses the following: * The new run-test-prebuilt profile is missing the JT_HOME environment variable from boot_jdk. * There are no compact profiles bundles to publish. I have created a new top level target to create these bundles and enabled publishing of them in jib-profiles.js. Bug: https://bugs.openjdk.java.net/browse/JDK-8172241 Webrev: http://cr.openjdk.java.net/~erikj/8172241/webrev.01/ From tim.bell at oracle.com Mon Jan 9 15:47:12 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 9 Jan 2017 07:47:12 -0800 Subject: RFR: JDK-8172241: Cleanup mistakes in jib publish support change In-Reply-To: <8d748a78-2e70-2057-785d-3676e25d8787@oracle.com> References: <8d748a78-2e70-2057-785d-3676e25d8787@oracle.com> Message-ID: <0381c998-aec1-dd99-5386-2ce9ab01cb12@oracle.com> Erik: > This is a small followup fix for JDK-8170741. It addresses the following: > > * The new run-test-prebuilt profile is missing the JT_HOME environment > variable from boot_jdk. > > * There are no compact profiles bundles to publish. I have created a new > top level target to create these bundles and enabled publishing of them > in jib-profiles.js. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172241 > > Webrev: http://cr.openjdk.java.net/~erikj/8172241/webrev.01/ Looks good. Tim From erik.joelsson at oracle.com Mon Jan 9 16:32:09 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 9 Jan 2017 17:32:09 +0100 Subject: RFR: JDK-8171932: unresolved macro in javadoc command Message-ID: <9b73d965-0bfb-9a55-b51c-38457f8cbba3@oracle.com> Hello, In the new Javadoc.gmk, there is a problem with a make variable, $(HASH), that doesn't get resolved properly into # in the final html files. My conclusion is that the # character is problematic when being passed inside an argument to one of our named parameter macros. I have fixed this by always escaping any # characters in the input parameters to these macros. With this fix, the html files come out with the correct # and the background color of the snippet looks correct. Bug: https://bugs.openjdk.java.net/browse/JDK-8171932 Webrev: http://cr.openjdk.java.net/~erikj/8171932/webrev.01/ /Erik From erik.joelsson at oracle.com Mon Jan 9 16:41:43 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 9 Jan 2017 17:41:43 +0100 Subject: RFR: JDK-8170862: VarDeps breaks when a file with overridden CFLAGS has the same name as the library Message-ID: Hello, VarDeps breaks when a file with overridden CFLAGS has the same name as the library. SetupNativeCompilation(FOO, LIBRARY:=foo, foo_CFLAGS := -DmakeItBreak) We then get the vardeps file for linking the library and the vardeps file for the specific CFLAGS ending up with the same name: "foo.vardeps" I chose to fix this by not stripping off the object extension from the filename when generating the vardeps file for specific object files. This also aligns better with other files we generate next to the objects, like foo.o.cmdline and foo.o.log, and now foo.o.vardeps. Bug: https://bugs.openjdk.java.net/browse/JDK-8170862 Patch: diff -r ef056360ddf3 make/common/NativeCompilation.gmk --- a/make/common/NativeCompilation.gmk +++ b/make/common/NativeCompilation.gmk @@ -288,8 +288,7 @@ $$($1_$(notdir $2)_OPTIMIZATION)), ) $1_$2_VARDEPS := $$($1_$(notdir $2)_CFLAGS) $$($1_$(notdir $2)_CXXFLAGS) \ $$($1_$(notdir $2)_OPT_CFLAGS) $$($1_$(notdir $2)_OPT_CXXFLAGS) - $1_$2_VARDEPS_FILE := $$(call DependOnVariable, $1_$2_VARDEPS, \ - $$(patsubst %$(OBJ_SUFFIX),%.vardeps,$$($1_$2_OBJ))) + $1_$2_VARDEPS_FILE := $$(call DependOnVariable, $1_$2_VARDEPS, $$($1_$2_OBJ).vardeps) endif $$($1_$2_OBJ) : $2 $$($1_COMPILE_VARDEPS_FILE) $$($1_$2_VARDEPS_FILE) | $$($1_BUILD_INFO) /Erik From tim.bell at oracle.com Mon Jan 9 16:41:53 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 9 Jan 2017 08:41:53 -0800 Subject: RFR: JDK-8171932: unresolved macro in javadoc command In-Reply-To: <9b73d965-0bfb-9a55-b51c-38457f8cbba3@oracle.com> References: <9b73d965-0bfb-9a55-b51c-38457f8cbba3@oracle.com> Message-ID: Erik: > In the new Javadoc.gmk, there is a problem with a make variable, > $(HASH), that doesn't get resolved properly into # in the final html > files. My conclusion is that the # character is problematic when being > passed inside an argument to one of our named parameter macros. I have > fixed this by always escaping any # characters in the input parameters > to these macros. With this fix, the html files come out with the correct > # and the background color of the snippet looks correct. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171932 > > Webrev: http://cr.openjdk.java.net/~erikj/8171932/webrev.01/ Looks good to me. Tim From tim.bell at oracle.com Mon Jan 9 16:46:13 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 9 Jan 2017 08:46:13 -0800 Subject: RFR: JDK-8170862: VarDeps breaks when a file with overridden CFLAGS has the same name as the library In-Reply-To: References: Message-ID: Hello Erik: > VarDeps breaks when a file with overridden CFLAGS has the same name as > the library. > > SetupNativeCompilation(FOO, > LIBRARY:=foo, > foo_CFLAGS := -DmakeItBreak) > > We then get the vardeps file for linking the library and the vardeps > file for the specific CFLAGS ending up with the same name: "foo.vardeps" > > I chose to fix this by not stripping off the object extension from the > filename when generating the vardeps file for specific object files. > This also aligns better with other files we generate next to the > objects, like foo.o.cmdline and foo.o.log, and now foo.o.vardeps. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170862 > > Patch: > > diff -r ef056360ddf3 make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk > +++ b/make/common/NativeCompilation.gmk > @@ -288,8 +288,7 @@ > $$($1_$(notdir $2)_OPTIMIZATION)), ) > $1_$2_VARDEPS := $$($1_$(notdir $2)_CFLAGS) $$($1_$(notdir > $2)_CXXFLAGS) \ > $$($1_$(notdir $2)_OPT_CFLAGS) $$($1_$(notdir $2)_OPT_CXXFLAGS) > - $1_$2_VARDEPS_FILE := $$(call DependOnVariable, $1_$2_VARDEPS, \ > - $$(patsubst %$(OBJ_SUFFIX),%.vardeps,$$($1_$2_OBJ))) > + $1_$2_VARDEPS_FILE := $$(call DependOnVariable, $1_$2_VARDEPS, > $$($1_$2_OBJ).vardeps) > endif > > $$($1_$2_OBJ) : $2 $$($1_COMPILE_VARDEPS_FILE) > $$($1_$2_VARDEPS_FILE) | $$($1_BUILD_INFO) Looks good to me. Thanks- Tim From ioi.lam at oracle.com Mon Jan 9 20:40:50 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 09 Jan 2017 12:40:50 -0800 Subject: Using hard links for debug builds Message-ID: <5873F552.2080504@oracle.com> Hi, libjvm.so gets copied a few times during the build. I usually build slowdebug builds with --with-native-debug-symbols=internal (to make it easier with gdb). This gives me 8 libjvm.so files: ./support/interim-image/lib/server/libjvm.so ./support/modules_libs/java.base/server/libjvm.so ./hotspot/variant-server/libjvm/gtest/libjvm.so ./images/test/hotspot/gtest/server/libjvm.so ./images/serverjre/lib/server/libjvm.so ./images/jdk/lib/server/libjvm.so ./images/jre/lib/server/libjvm.so ./jdk/lib/server/libjvm.so Each of them is 320+MB. Even though I have a fast SSD, it's overwhelmed by the large churn and my machine becomes unresponsive for a long time. The 8 libjvm.so files have 2 variants -- the gtest version (2 of them) vs the normal version (6 of them). Would it make sense to change the 'cp' to hard links instead? For now, I am doing a hack by patching this in the generated spec.gmk file: CP:=/bin/cp to point to my script, which uses 'ln' instead of /bin/cp when dealing with libjvm.so .... BTW, what's the use for the 'gtest' versions of libjvm.so? Thanks - Ioi From kim.barrett at oracle.com Mon Jan 9 23:17:55 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 9 Jan 2017 18:17:55 -0500 Subject: Using hard links for debug builds In-Reply-To: <5873F552.2080504@oracle.com> References: <5873F552.2080504@oracle.com> Message-ID: <93BFA3E4-DE95-4347-BFAF-5DDAE76BFD56@oracle.com> > On Jan 9, 2017, at 3:40 PM, Ioi Lam wrote: > > Hi, > > libjvm.so gets copied a few times during the build. I usually build slowdebug builds with --with-native-debug-symbols=internal (to make it easier with gdb). This gives me 8 libjvm.so files: > > ./support/interim-image/lib/server/libjvm.so > ./support/modules_libs/java.base/server/libjvm.so > ./hotspot/variant-server/libjvm/gtest/libjvm.so > ./images/test/hotspot/gtest/server/libjvm.so > ./images/serverjre/lib/server/libjvm.so > ./images/jdk/lib/server/libjvm.so > ./images/jre/lib/server/libjvm.so > ./jdk/lib/server/libjvm.so > > Each of them is 320+MB. Even though I have a fast SSD, it's overwhelmed by the large churn and my machine becomes unresponsive for a long time. > > The 8 libjvm.so files have 2 variants -- the gtest version (2 of them) vs the normal version (6 of them). Would it make sense to change the 'cp' to hard links instead? Are reflinks available? e.g. ?cp ?reflink ?? That might be a better solution than hard links. > For now, I am doing a hack by patching this in the generated spec.gmk file: > > CP:=/bin/cp > > to point to my script, which uses 'ln' instead of /bin/cp when dealing with libjvm.so .... From erik.joelsson at oracle.com Tue Jan 10 08:56:45 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 10 Jan 2017 09:56:45 +0100 Subject: Using hard links for debug builds In-Reply-To: <5873F552.2080504@oracle.com> References: <5873F552.2080504@oracle.com> Message-ID: <93eadc8f-58bf-c497-a266-bb36c17e8255@oracle.com> Hello, I recently did work to reduce the number of copies. While doing that I did investigate using softlinks, but that didn't work for .so files. I did not consider hard links. All other files in the exploded image are however softlinked when possible. For all the copies in images, any kind of linking won't work because those are generated with jlink, not cp. This means you would only be able to eliminate 2 copies by linking out of the below 8. I did put in more detailed top level targets to make it possible for an active user to get fewer copies. For example, instead of building "images", you can build just "jdk-image" and you will skip 2 of the copies (jre and serverjre). If you don't need a real jdk image, you can build just "exploded-image" and you skip 2 more (jdk and support/interim-image). I have tried to optimize the "test*" targets to only depend on the appropriate images as well. If you don't care for the gtest binaries, you can configure --disable-hotspot-gtest to get rid of those. Doing all of this and you are down to 2 copies, which your trick takes down to one. The gtest version of libjvm.so contains all the objects of the normal libjvm.so + the gtest unit tests. This is used to run the gtest unit tests. In general, --with-native-debug-symbols=external is easier on disk usage since the debug symbols aren't copied everywhere like the libraries are. Also note that even if you do =zipped (the default), there will be a link to an unzipped copy available in the exploded image. /Erik On 2017-01-09 21:40, Ioi Lam wrote: > Hi, > > libjvm.so gets copied a few times during the build. I usually build > slowdebug builds with --with-native-debug-symbols=internal (to make it > easier with gdb). This gives me 8 libjvm.so files: > > ./support/interim-image/lib/server/libjvm.so > ./support/modules_libs/java.base/server/libjvm.so > ./hotspot/variant-server/libjvm/gtest/libjvm.so > ./images/test/hotspot/gtest/server/libjvm.so > ./images/serverjre/lib/server/libjvm.so > ./images/jdk/lib/server/libjvm.so > ./images/jre/lib/server/libjvm.so > ./jdk/lib/server/libjvm.so > > Each of them is 320+MB. Even though I have a fast SSD, it's > overwhelmed by the large churn and my machine becomes unresponsive for > a long time. > > The 8 libjvm.so files have 2 variants -- the gtest version (2 of them) > vs the normal version (6 of them). Would it make sense to change the > 'cp' to hard links instead? > > For now, I am doing a hack by patching this in the generated spec.gmk > file: > > CP:=/bin/cp > > to point to my script, which uses 'ln' instead of /bin/cp when dealing > with libjvm.so .... > > BTW, what's the use for the 'gtest' versions of libjvm.so? > > Thanks > - Ioi From ioi.lam at oracle.com Wed Jan 11 00:57:03 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 10 Jan 2017 16:57:03 -0800 Subject: Using hard links for debug builds In-Reply-To: <93eadc8f-58bf-c497-a266-bb36c17e8255@oracle.com> References: <5873F552.2080504@oracle.com> <93eadc8f-58bf-c497-a266-bb36c17e8255@oracle.com> Message-ID: <587582DF.5000205@oracle.com> Hi Eric, Thanks for the detailed explanation. Perhaps this one copy can be changed to a hard link? Copying jdk/lib/server/libjvm.so /bin/cp -fP '/home/iklam/jdk/bld/hs-debug/support/modules_libs/java.base/server/libjvm.so' '/home/iklam/jdk/bld/hs-debug/jdk/lib/server/libjvm.so' My script changed it to a hard link and I see no ill effects: '/home/iklam/jdk/bld/hs-debug/jdk/lib/server/libjvm.so' => '/home/iklam/jdk/bld/hs-debug/support/modules_libs/java.base/server/libjvm.so' 15452588 -rwxr-xr-x 2 iklam dba 322793048 Jan 10 16:54 /home/iklam/jdk/bld/hs-debug/jdk/lib/server/libjvm.so 15452588 -rwxr-xr-x 2 iklam dba 322793048 Jan 10 16:54 /home/iklam/jdk/bld/hs-debug/support/modules_libs/java.base/server/libjvm.so Thanks - Ioi On 1/10/17 12:56 AM, Erik Joelsson wrote: > Hello, > > I recently did work to reduce the number of copies. While doing that I > did investigate using softlinks, but that didn't work for .so files. I > did not consider hard links. All other files in the exploded image are > however softlinked when possible. For all the copies in images, any > kind of linking won't work because those are generated with jlink, not > cp. This means you would only be able to eliminate 2 copies by linking > out of the below 8. > > I did put in more detailed top level targets to make it possible for > an active user to get fewer copies. For example, instead of building > "images", you can build just "jdk-image" and you will skip 2 of the > copies (jre and serverjre). If you don't need a real jdk image, you > can build just "exploded-image" and you skip 2 more (jdk and > support/interim-image). I have tried to optimize the "test*" targets > to only depend on the appropriate images as well. > > If you don't care for the gtest binaries, you can configure > --disable-hotspot-gtest to get rid of those. > > Doing all of this and you are down to 2 copies, which your trick takes > down to one. > > The gtest version of libjvm.so contains all the objects of the normal > libjvm.so + the gtest unit tests. This is used to run the gtest unit > tests. > > In general, --with-native-debug-symbols=external is easier on disk > usage since the debug symbols aren't copied everywhere like the > libraries are. Also note that even if you do =zipped (the default), > there will be a link to an unzipped copy available in the exploded image. > > /Erik > > On 2017-01-09 21:40, Ioi Lam wrote: >> Hi, >> >> libjvm.so gets copied a few times during the build. I usually build >> slowdebug builds with --with-native-debug-symbols=internal (to make >> it easier with gdb). This gives me 8 libjvm.so files: >> >> ./support/interim-image/lib/server/libjvm.so >> ./support/modules_libs/java.base/server/libjvm.so >> ./hotspot/variant-server/libjvm/gtest/libjvm.so >> ./images/test/hotspot/gtest/server/libjvm.so >> ./images/serverjre/lib/server/libjvm.so >> ./images/jdk/lib/server/libjvm.so >> ./images/jre/lib/server/libjvm.so >> ./jdk/lib/server/libjvm.so >> >> Each of them is 320+MB. Even though I have a fast SSD, it's >> overwhelmed by the large churn and my machine becomes unresponsive >> for a long time. >> >> The 8 libjvm.so files have 2 variants -- the gtest version (2 of >> them) vs the normal version (6 of them). Would it make sense to >> change the 'cp' to hard links instead? >> >> For now, I am doing a hack by patching this in the generated spec.gmk >> file: >> >> CP:=/bin/cp >> >> to point to my script, which uses 'ln' instead of /bin/cp when >> dealing with libjvm.so .... >> >> BTW, what's the use for the 'gtest' versions of libjvm.so? >> >> Thanks >> - Ioi > From volker.simonis at gmail.com Wed Jan 11 10:43:42 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 11 Jan 2017 11:43:42 +0100 Subject: Using hard links for debug builds In-Reply-To: <587582DF.5000205@oracle.com> References: <5873F552.2080504@oracle.com> <93eadc8f-58bf-c497-a266-bb36c17e8255@oracle.com> <587582DF.5000205@oracle.com> Message-ID: Hi Ioi, I think the problem with links (both, hard and soft) is that they are not supported on all filesystems. The same applies to the proposed "cp --reflink". So you would at least have to check if it works during the configuration step. Regards, Volker On Wed, Jan 11, 2017 at 1:57 AM, Ioi Lam wrote: > Hi Eric, > > Thanks for the detailed explanation. > > Perhaps this one copy can be changed to a hard link? > > Copying jdk/lib/server/libjvm.so > /bin/cp -fP > '/home/iklam/jdk/bld/hs-debug/support/modules_libs/java.base/server/libjvm.so' > '/home/iklam/jdk/bld/hs-debug/jdk/lib/server/libjvm.so' > > My script changed it to a hard link and I see no ill effects: > > '/home/iklam/jdk/bld/hs-debug/jdk/lib/server/libjvm.so' => > '/home/iklam/jdk/bld/hs-debug/support/modules_libs/java.base/server/libjvm.so' > 15452588 -rwxr-xr-x 2 iklam dba 322793048 Jan 10 16:54 > /home/iklam/jdk/bld/hs-debug/jdk/lib/server/libjvm.so > 15452588 -rwxr-xr-x 2 iklam dba 322793048 Jan 10 16:54 > /home/iklam/jdk/bld/hs-debug/support/modules_libs/java.base/server/libjvm.so > > Thanks > - Ioi > > > > On 1/10/17 12:56 AM, Erik Joelsson wrote: >> >> Hello, >> >> I recently did work to reduce the number of copies. While doing that I did >> investigate using softlinks, but that didn't work for .so files. I did not >> consider hard links. All other files in the exploded image are however >> softlinked when possible. For all the copies in images, any kind of linking >> won't work because those are generated with jlink, not cp. This means you >> would only be able to eliminate 2 copies by linking out of the below 8. >> >> I did put in more detailed top level targets to make it possible for an >> active user to get fewer copies. For example, instead of building "images", >> you can build just "jdk-image" and you will skip 2 of the copies (jre and >> serverjre). If you don't need a real jdk image, you can build just >> "exploded-image" and you skip 2 more (jdk and support/interim-image). I have >> tried to optimize the "test*" targets to only depend on the appropriate >> images as well. >> >> If you don't care for the gtest binaries, you can configure >> --disable-hotspot-gtest to get rid of those. >> >> Doing all of this and you are down to 2 copies, which your trick takes >> down to one. >> >> The gtest version of libjvm.so contains all the objects of the normal >> libjvm.so + the gtest unit tests. This is used to run the gtest unit tests. >> >> In general, --with-native-debug-symbols=external is easier on disk usage >> since the debug symbols aren't copied everywhere like the libraries are. >> Also note that even if you do =zipped (the default), there will be a link to >> an unzipped copy available in the exploded image. >> >> /Erik >> >> On 2017-01-09 21:40, Ioi Lam wrote: >>> >>> Hi, >>> >>> libjvm.so gets copied a few times during the build. I usually build >>> slowdebug builds with --with-native-debug-symbols=internal (to make it >>> easier with gdb). This gives me 8 libjvm.so files: >>> >>> ./support/interim-image/lib/server/libjvm.so >>> ./support/modules_libs/java.base/server/libjvm.so >>> ./hotspot/variant-server/libjvm/gtest/libjvm.so >>> ./images/test/hotspot/gtest/server/libjvm.so >>> ./images/serverjre/lib/server/libjvm.so >>> ./images/jdk/lib/server/libjvm.so >>> ./images/jre/lib/server/libjvm.so >>> ./jdk/lib/server/libjvm.so >>> >>> Each of them is 320+MB. Even though I have a fast SSD, it's overwhelmed >>> by the large churn and my machine becomes unresponsive for a long time. >>> >>> The 8 libjvm.so files have 2 variants -- the gtest version (2 of them) vs >>> the normal version (6 of them). Would it make sense to change the 'cp' to >>> hard links instead? >>> >>> For now, I am doing a hack by patching this in the generated spec.gmk >>> file: >>> >>> CP:=/bin/cp >>> >>> to point to my script, which uses 'ln' instead of /bin/cp when dealing >>> with libjvm.so .... >>> >>> BTW, what's the use for the 'gtest' versions of libjvm.so? >>> >>> Thanks >>> - Ioi >> >> > From magnus.ihse.bursie at oracle.com Wed Jan 11 13:03:36 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 11 Jan 2017 14:03:36 +0100 Subject: RFR: JDK-8172562 Changing log level on Javadoc causes total rebuild Message-ID: <32414f61-c7d8-3c49-7c23-4afe8fd72ef2@oracle.com> This patch makes debugging Javadoc builds a bit easier. It makes sure debug flags are not stored in vardeps files, and it also sets the -verbose flag on LOG=trace. Bug: https://bugs.openjdk.java.net/browse/JDK-8172562 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8172562-javadoc-debuggability/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Jan 11 14:41:16 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Jan 2017 15:41:16 +0100 Subject: RFR: JDK-8172562 Changing log level on Javadoc causes total rebuild In-Reply-To: <32414f61-c7d8-3c49-7c23-4afe8fd72ef2@oracle.com> References: <32414f61-c7d8-3c49-7c23-4afe8fd72ef2@oracle.com> Message-ID: <6f00015b-6d51-2d64-f390-2dd6d3026d61@oracle.com> Looks good. /Erik On 2017-01-11 14:03, Magnus Ihse Bursie wrote: > This patch makes debugging Javadoc builds a bit easier. It makes sure > debug flags are not stored in vardeps files, and it also sets the > -verbose flag on LOG=trace. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172562 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8172562-javadoc-debuggability/webrev.01 > > /Magnus From tim.bell at oracle.com Wed Jan 11 15:10:46 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 11 Jan 2017 07:10:46 -0800 Subject: RFR: JDK-8172562 Changing log level on Javadoc causes total rebuild In-Reply-To: <6f00015b-6d51-2d64-f390-2dd6d3026d61@oracle.com> References: <32414f61-c7d8-3c49-7c23-4afe8fd72ef2@oracle.com> <6f00015b-6d51-2d64-f390-2dd6d3026d61@oracle.com> Message-ID: Hello Magnus Looks good to me as well. Tim On 01/11/17 06:41, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2017-01-11 14:03, Magnus Ihse Bursie wrote: >> This patch makes debugging Javadoc builds a bit easier. It makes sure >> debug flags are not stored in vardeps files, and it also sets the >> -verbose flag on LOG=trace. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172562 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8172562-javadoc-debuggability/webrev.01 >> >> >> /Magnus > From thomas.stuefe at gmail.com Wed Jan 11 16:09:20 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Jan 2017 17:09:20 +0100 Subject: RFR(xxs): 8172579: 8168503 broke AIX build Message-ID: Dear all, please take a look at this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8172579 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8172579-colon-8168503-broke-AIX-build/webrev/common/autoconf/hotspot.m4.udiff.html JDK-8168503 exposed a bug in AIX grep. AIX grep, when called like this: "grep -Fx " is unable to handle empty patterns correctly. 8168503 added a line break in the definition of a variable: VALID_JVM_FEATURES="compiler1 compiler2 zero shark minimal dtrace jvmti jvmci \ - graal fprof vm-structs jni-check services management all-gcs nmt cds static-build aot" + graal fprof vm-structs jni-check services management all-gcs nmt cds \ + static-build link-time-opt aot" So now, "cds" is followed by multiple spaces, which are later expanded to multiple newlines, and grep is unable to match the pattern immediately preceding these newlines (in this case, "cds"). This causes the HOTSPOT_VALIDATE_JVM_FEATURES function to fail with "Invalid JVM feature: cds". The error would also happened before when trying to match "jvmci", but so far we do not build jvmci on powerpc. The workaround for now is just to remove the superfluous spaces. I tried for some hours to find a better solution but could not find one which was small enough and worked on all platforms. I tried using sed to change multiple spaces to a single space, but did not get it to work correctly on AIX either. I thought about passing the pattern list as file to grep - which opposed to passing the pattern in the command line works as expected - but refrained from this because creating temporary files is error prone. I attempted to change the whole NEEDLE/STACK expression to a loop checking each single feature with '=~' against the list of valid features, but this felt too intrusive. The proposed fix is not the most elegant one but the risk for other platforms is minimal and it works. Kind Regards, Thomas From erik.joelsson at oracle.com Wed Jan 11 16:40:12 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Jan 2017 17:40:12 +0100 Subject: RFR: JDK-8172577: Builds for OS X after build 149 does not include Java Mission Control.app Message-ID: <22bb9228-8172-5067-b877-807ed016c104@oracle.com> Hello, This patch fixes bug in the bundle logic, specifically the part that tries to work around files with spaces in them. In one of my recent changes in Bundles.gmk, I managed to break this completely. Bug: https://bugs.openjdk.java.net/browse/JDK-8172577 Webrev: http://cr.openjdk.java.net/~erikj/8172577/webrev.01/ /Erik From volker.simonis at gmail.com Wed Jan 11 17:51:55 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 11 Jan 2017 17:51:55 +0000 Subject: RFR(xxs): 8172579: 8168503 broke AIX build In-Reply-To: References: Message-ID: Hi Thomas, why not simply using GNU grep? We already insist for so many other tools on the GNU version that this wouldn't be a big thing. And as far as I remember, GNU grep is already installed on most of our machines anyway. You just have to place /opt/freeware/bin in front of your PATH. Your fix is actually also fine, although it breaks the informal code formatting rules, which require the indentation of wrapped strings. But it is also quite sensitive and I'm sure this will break again in the future (in this or in other places). By the way, why does it break for 'cds' if it didn't for 'jvmci'? I didn't knew that we support 'cds' on AIX either? Regards, Volker Thomas St?fe schrieb am Mi., 11. Jan. 2017 um 16:09: > Dear all, > > > > please take a look at this tiny fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172579 > > Webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8172579-colon-8168503-broke-AIX-build/webrev/common/autoconf/hotspot.m4.udiff.html > > > > JDK-8168503 exposed a bug in AIX grep. AIX grep, when called like this: > > "grep -Fx " is unable to handle empty patterns correctly. > > 8168503 added a line break in the definition of a variable: > > > > VALID_JVM_FEATURES="compiler1 compiler2 zero shark minimal dtrace jvmti > > jvmci \ > > - graal fprof vm-structs jni-check services management all-gcs nmt cds > > static-build aot" > > + graal fprof vm-structs jni-check services management all-gcs nmt cds \ > > > > + static-build link-time-opt aot" > > > > > > So now, "cds" is followed by multiple spaces, which are later expanded to > > multiple newlines, and grep is unable to match the pattern immediately > > preceding these newlines (in this case, "cds"). This causes the > > HOTSPOT_VALIDATE_JVM_FEATURES > > function to fail with "Invalid JVM feature: cds". > > > > The error would also happened before when trying to match "jvmci", but so > > far we do not build jvmci on powerpc. > > > > The workaround for now is just to remove the superfluous spaces. > > > > I tried for some hours to find a better solution but could not find one > > which was small enough and worked on all platforms. > > > > I tried using sed to change multiple spaces to a single space, but did not > > get it to work correctly on AIX either. > > > > I thought about passing the pattern list as file to grep - which opposed to > > passing the pattern in the command line works as expected - but refrained > > from this because creating temporary files is error prone. > > > > I attempted to change the whole NEEDLE/STACK expression to a loop checking > > each single feature with '=~' against the list of valid features, but this > > felt too intrusive. > > > > The proposed fix is not the most elegant one but the risk for other > > platforms is minimal and it works. > > > > Kind Regards, Thomas > > From tim.bell at oracle.com Wed Jan 11 18:03:06 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 11 Jan 2017 10:03:06 -0800 Subject: RFR: JDK-8172577: Builds for OS X after build 149 does not include Java Mission Control.app In-Reply-To: <22bb9228-8172-5067-b877-807ed016c104@oracle.com> References: <22bb9228-8172-5067-b877-807ed016c104@oracle.com> Message-ID: Erik: > This patch fixes bug in the bundle logic, specifically the part that > tries to work around files with spaces in them. In one of my recent > changes in Bundles.gmk, I managed to break this completely. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172577 > > Webrev: http://cr.openjdk.java.net/~erikj/8172577/webrev.01/ Looks good. /Tim From thomas.stuefe at gmail.com Thu Jan 12 08:56:18 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 09:56:18 +0100 Subject: RFR(xxs): 8172579: 8168503 broke AIX build In-Reply-To: References: Message-ID: Hi Volker, thanks for the hint. GNU grep works, so I close this as wontfix. ..Thomas On Wed, Jan 11, 2017 at 6:51 PM, Volker Simonis wrote: > Hi Thomas, > > why not simply using GNU grep? We already insist for so many other tools > on the GNU version that this wouldn't be a big thing. > > And as far as I remember, GNU grep is already installed on most of our > machines anyway. You just have to place /opt/freeware/bin in front of your > PATH. > > Your fix is actually also fine, although it breaks the informal code > formatting rules, which require the indentation of wrapped strings. But it > is also quite sensitive and I'm sure this will break again in the future > (in this or in other places). > > By the way, why does it break for 'cds' if it didn't for 'jvmci'? I didn't > knew that we support 'cds' on AIX either? > > Regards, > Volker > > Thomas St?fe schrieb am Mi., 11. Jan. 2017 um > 16:09: > >> Dear all, >> >> >> >> please take a look at this tiny fix: >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172579 >> >> Webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8172579-colon- >> 8168503-broke-AIX-build/webrev/common/autoconf/hotspot.m4.udiff.html >> >> >> >> JDK-8168503 exposed a bug in AIX grep. AIX grep, when called like this: >> >> "grep -Fx " is unable to handle empty patterns correctly. >> >> 8168503 added a line break in the definition of a variable: >> >> >> >> VALID_JVM_FEATURES="compiler1 compiler2 zero shark minimal dtrace jvmti >> >> jvmci \ >> >> - graal fprof vm-structs jni-check services management all-gcs nmt cds >> >> static-build aot" >> >> + graal fprof vm-structs jni-check services management all-gcs nmt cds >> \ >> >> >> >> + static-build link-time-opt aot" >> >> >> >> >> >> So now, "cds" is followed by multiple spaces, which are later expanded to >> >> multiple newlines, and grep is unable to match the pattern immediately >> >> preceding these newlines (in this case, "cds"). This causes the >> >> HOTSPOT_VALIDATE_JVM_FEATURES >> >> function to fail with "Invalid JVM feature: cds". >> >> >> >> The error would also happened before when trying to match "jvmci", but so >> >> far we do not build jvmci on powerpc. >> >> >> >> The workaround for now is just to remove the superfluous spaces. >> >> >> >> I tried for some hours to find a better solution but could not find one >> >> which was small enough and worked on all platforms. >> >> >> >> I tried using sed to change multiple spaces to a single space, but did not >> >> get it to work correctly on AIX either. >> >> >> >> I thought about passing the pattern list as file to grep - which opposed >> to >> >> passing the pattern in the command line works as expected - but refrained >> >> from this because creating temporary files is error prone. >> >> >> >> I attempted to change the whole NEEDLE/STACK expression to a loop checking >> >> each single feature with '=~' against the list of valid features, but this >> >> felt too intrusive. >> >> >> >> The proposed fix is not the most elegant one but the risk for other >> >> platforms is minimal and it works. >> >> >> >> Kind Regards, Thomas >> >> From magnus.ihse.bursie at oracle.com Thu Jan 12 09:07:32 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Jan 2017 10:07:32 +0100 Subject: RFR: JDK-8172702 Remove left-over OPENJDK_TARGET_CPU_JLI_CFLAGS Message-ID: <8fccacc6-77f7-a3a8-5ab3-9cffd45e7dfc@oracle.com> In JDK-8066474, all references to OPENJDK_TARGET_CPU_JLI_CFLAGS except one was removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8172702 Patch inline: diff --git a/common/autoconf/buildjdk-spec.gmk.in b/common/autoconf/buildjdk-spec.gmk.in --- a/common/autoconf/buildjdk-spec.gmk.in +++ b/common/autoconf/buildjdk-spec.gmk.in @@ -68,7 +68,6 @@ CFLAGS_JDKEXE := @OPENJDK_BUILD_CFLAGS_JDKEXE@ CXXFLAGS_JDKEXE := @OPENJDK_BUILD_CXXFLAGS_JDKEXE@ LDFLAGS_JDKEXE := @OPENJDK_BUILD_LDFLAGS_JDKEXE@ -OPENJDK_TARGET_CPU_JLI_CFLAGS := @OPENJDK_BUILD_CPU_JLI_CFLAGS@ JVM_CFLAGS := @OPENJDK_BUILD_JVM_CFLAGS@ JVM_LDFLAGS := @OPENJDK_BUILD_JVM_LDFLAGS@ /Magnus From erik.joelsson at oracle.com Thu Jan 12 09:25:05 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Jan 2017 10:25:05 +0100 Subject: RFR: JDK-8172702 Remove left-over OPENJDK_TARGET_CPU_JLI_CFLAGS In-Reply-To: <8fccacc6-77f7-a3a8-5ab3-9cffd45e7dfc@oracle.com> References: <8fccacc6-77f7-a3a8-5ab3-9cffd45e7dfc@oracle.com> Message-ID: <2c60e5e2-91a2-d631-1e2c-1e6485de633f@oracle.com> Looks good. /Erik On 2017-01-12 10:07, Magnus Ihse Bursie wrote: > In JDK-8066474, all references to OPENJDK_TARGET_CPU_JLI_CFLAGS except > one was removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172702 > Patch inline: > diff --git a/common/autoconf/buildjdk-spec.gmk.in > b/common/autoconf/buildjdk-spec.gmk.in > --- a/common/autoconf/buildjdk-spec.gmk.in > +++ b/common/autoconf/buildjdk-spec.gmk.in > @@ -68,7 +68,6 @@ > CFLAGS_JDKEXE := @OPENJDK_BUILD_CFLAGS_JDKEXE@ > CXXFLAGS_JDKEXE := @OPENJDK_BUILD_CXXFLAGS_JDKEXE@ > LDFLAGS_JDKEXE := @OPENJDK_BUILD_LDFLAGS_JDKEXE@ > -OPENJDK_TARGET_CPU_JLI_CFLAGS := @OPENJDK_BUILD_CPU_JLI_CFLAGS@ > > JVM_CFLAGS := @OPENJDK_BUILD_JVM_CFLAGS@ > JVM_LDFLAGS := @OPENJDK_BUILD_JVM_LDFLAGS@ > > /Magnus > From magnus.ihse.bursie at oracle.com Thu Jan 12 09:32:29 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Jan 2017 10:32:29 +0100 Subject: RFR(xxs): 8172579: 8168503 broke AIX build In-Reply-To: References: Message-ID: <788a126e-3780-4704-c095-cb298ed165ba@oracle.com> On 2017-01-12 09:56, Thomas St?fe wrote: > Hi Volker, > > thanks for the hint. GNU grep works, so I close this as wontfix. You might want to add a test in configure that it is picking up a correct grep. /Magnus > > ..Thomas > > On Wed, Jan 11, 2017 at 6:51 PM, Volker Simonis > wrote: > >> Hi Thomas, >> >> why not simply using GNU grep? We already insist for so many other tools >> on the GNU version that this wouldn't be a big thing. >> >> And as far as I remember, GNU grep is already installed on most of our >> machines anyway. You just have to place /opt/freeware/bin in front of your >> PATH. >> >> Your fix is actually also fine, although it breaks the informal code >> formatting rules, which require the indentation of wrapped strings. But it >> is also quite sensitive and I'm sure this will break again in the future >> (in this or in other places). >> >> By the way, why does it break for 'cds' if it didn't for 'jvmci'? I didn't >> knew that we support 'cds' on AIX either? >> >> Regards, >> Volker >> >> Thomas St?fe schrieb am Mi., 11. Jan. 2017 um >> 16:09: >> >>> Dear all, >>> >>> >>> >>> please take a look at this tiny fix: >>> >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172579 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8172579-colon- >>> 8168503-broke-AIX-build/webrev/common/autoconf/hotspot.m4.udiff.html >>> >>> >>> >>> JDK-8168503 exposed a bug in AIX grep. AIX grep, when called like this: >>> >>> "grep -Fx " is unable to handle empty patterns correctly. >>> >>> 8168503 added a line break in the definition of a variable: >>> >>> >>> >>> VALID_JVM_FEATURES="compiler1 compiler2 zero shark minimal dtrace jvmti >>> >>> jvmci \ >>> >>> - graal fprof vm-structs jni-check services management all-gcs nmt cds >>> >>> static-build aot" >>> >>> + graal fprof vm-structs jni-check services management all-gcs nmt cds >>> \ >>> >>> >>> >>> + static-build link-time-opt aot" >>> >>> >>> >>> >>> >>> So now, "cds" is followed by multiple spaces, which are later expanded to >>> >>> multiple newlines, and grep is unable to match the pattern immediately >>> >>> preceding these newlines (in this case, "cds"). This causes the >>> >>> HOTSPOT_VALIDATE_JVM_FEATURES >>> >>> function to fail with "Invalid JVM feature: cds". >>> >>> >>> >>> The error would also happened before when trying to match "jvmci", but so >>> >>> far we do not build jvmci on powerpc. >>> >>> >>> >>> The workaround for now is just to remove the superfluous spaces. >>> >>> >>> >>> I tried for some hours to find a better solution but could not find one >>> >>> which was small enough and worked on all platforms. >>> >>> >>> >>> I tried using sed to change multiple spaces to a single space, but did not >>> >>> get it to work correctly on AIX either. >>> >>> >>> >>> I thought about passing the pattern list as file to grep - which opposed >>> to >>> >>> passing the pattern in the command line works as expected - but refrained >>> >>> from this because creating temporary files is error prone. >>> >>> >>> >>> I attempted to change the whole NEEDLE/STACK expression to a loop checking >>> >>> each single feature with '=~' against the list of valid features, but this >>> >>> felt too intrusive. >>> >>> >>> >>> The proposed fix is not the most elegant one but the risk for other >>> >>> platforms is minimal and it works. >>> >>> >>> >>> Kind Regards, Thomas >>> >>> From staffan.larsen at oracle.com Thu Jan 12 10:43:46 2017 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Jan 2017 11:43:46 +0100 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 Message-ID: jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. Thanks, /Staffan diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js --- a/common/conf/jib-profiles.js +++ b/common/conf/jib-profiles.js @@ -870,7 +870,7 @@ jtreg: { server: "javare", revision: "4.2", - build_number: "b04", + build_number: "b05", checksum_file: "MD5_VALUES", file: "jtreg_bin-4.2.zip", environment_name: "JT_HOME", From chris.hegarty at oracle.com Thu Jan 12 10:44:54 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 Jan 2017 10:44:54 +0000 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: <58905D7B-71CE-4FE7-9DCE-3F981F528FF4@oracle.com> > On 12 Jan 2017, at 10:43, Staffan Larsen wrote: > > jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. > > Thanks, > /Staffan > > > diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js > +++ b/common/conf/jib-profiles.js > @@ -870,7 +870,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b04", > + build_number: "b05", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", Looks fine. Thanks Staffan. -Chris. From erik.joelsson at oracle.com Thu Jan 12 11:44:18 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Jan 2017 12:44:18 +0100 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: <817cab3a-97b2-ff22-d1df-f1128c0a8790@oracle.com> Looks good. /Erik On 2017-01-12 11:43, Staffan Larsen wrote: > jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. > > Thanks, > /Staffan > > > diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js > +++ b/common/conf/jib-profiles.js > @@ -870,7 +870,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b04", > + build_number: "b05", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", From magnus.ihse.bursie at oracle.com Thu Jan 12 11:50:34 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Jan 2017 12:50:34 +0100 Subject: RFR: JDK-8172577: Builds for OS X after build 149 does not include Java Mission Control.app In-Reply-To: <22bb9228-8172-5067-b877-807ed016c104@oracle.com> References: <22bb9228-8172-5067-b877-807ed016c104@oracle.com> Message-ID: <71740a17-98b4-6695-38b2-d1ffeb29d5d8@oracle.com> On 2017-01-11 17:40, Erik Joelsson wrote: > Hello, > > This patch fixes bug in the bundle logic, specifically the part that > tries to work around files with spaces in them. In one of my recent > changes in Bundles.gmk, I managed to break this completely. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172577 > > Webrev: http://cr.openjdk.java.net/~erikj/8172577/webrev.01/ > > /Erik > Looks good to me. /Magnus From Alan.Bateman at oracle.com Thu Jan 12 11:51:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Jan 2017 11:51:05 +0000 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: On 12/01/2017 10:43, Staffan Larsen wrote: > jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. > > Thanks, > /Staffan > > > diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js > +++ b/common/conf/jib-profiles.js > @@ -870,7 +870,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b04", > + build_number: "b05", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", This looks okay for infrastructure that uses this file but don't you need to bump the requiredVersion in each test root to force its usage in other contexts? -Alan From staffan.larsen at oracle.com Thu Jan 12 11:56:07 2017 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Jan 2017 12:56:07 +0100 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: <1A1EFC90-CB04-4BCE-BDE4-7B0A58AE4084@oracle.com> > On 12 Jan 2017, at 12:51, Alan Bateman wrote: > > > > On 12/01/2017 10:43, Staffan Larsen wrote: >> jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. >> >> Thanks, >> /Staffan >> >> >> diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js >> --- a/common/conf/jib-profiles.js >> +++ b/common/conf/jib-profiles.js >> @@ -870,7 +870,7 @@ >> jtreg: { >> server: "javare", >> revision: "4.2", >> - build_number: "b04", >> + build_number: "b05", >> checksum_file: "MD5_VALUES", >> file: "jtreg_bin-4.2.zip", >> environment_name: "JT_HOME", > This looks okay for infrastructure that uses this file but don't you need to bump the requiredVersion in each test root to force its usage in other contexts? I don?t know if there are any tests that rely on functionality in 4.2 b05. If there are, we need to bump requireVersion, yes. I only know that the infrastructure needs 4.2 b05. /Staffan From magnus.ihse.bursie at oracle.com Thu Jan 12 12:33:15 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Jan 2017 13:33:15 +0100 Subject: RFR: JDK-8172714 Remove unused and unexpanded variables from spec.gmk.in Message-ID: We do not expand the value of @BUILD_HOTSPOT@ and @THEPWDCMD@ anymore in the generated spec.gmk. No-one seems to be suffering from this (and I've double-checked with a grep) so we should just remove the declarations. Bug: https://bugs.openjdk.java.net/browse/JDK-8172714 Patch inline: diff --git a/common/autoconf/spec.gmk.in b/common/autoconf/spec.gmk.in --- a/common/autoconf/spec.gmk.in +++ b/common/autoconf/spec.gmk.in @@ -274,8 +274,6 @@ CONFIGURESUPPORT_OUTPUTDIR:=@CONFIGURESUPPORT_OUTPUTDIR@ BUILDJDK_OUTPUTDIR=$(BUILD_OUTPUT)/buildjdk -BUILD_HOTSPOT=@BUILD_HOTSPOT@ - BUILD_FAILURE_HANDLER := @BUILD_FAILURE_HANDLER@ ENABLE_GENERATE_CLASSLIST := @ENABLE_GENERATE_CLASSLIST@ @@ -642,7 +640,6 @@ NICE:=@NICE@ PATCH:=@PATCH@ PRINTF:=@PRINTF@ -PWD:=@THEPWDCMD@ RM:=@RM@ RMDIR:=@RMDIR@ SED:=@SED@ /Magnus From thomas.stuefe at gmail.com Thu Jan 12 13:04:03 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 14:04:03 +0100 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly Message-ID: Dear all, please take a look at this fix. This should prevent configure from using a grep which is not able to handle pattern lists with empty patterns. Bug: https://bugs.openjdk.java.net/browse/JDK-8172712 webrevs: http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ Background: https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused by a buggy grep (on AIX) and the easiest way to work around that bug would be to use the GNU version of grep. It was suggested in the orginal mail thread ( http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html) to check this in configure. This change implements this suggestion and checks if grep behaves correctly. Kind Regards, Thomas From thomas.stuefe at gmail.com Thu Jan 12 13:05:14 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 14:05:14 +0100 Subject: RFR(xxs): 8172579: 8168503 broke AIX build In-Reply-To: <788a126e-3780-4704-c095-cb298ed165ba@oracle.com> References: <788a126e-3780-4704-c095-cb298ed165ba@oracle.com> Message-ID: On Thu, Jan 12, 2017 at 10:32 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2017-01-12 09:56, Thomas St?fe wrote: > > Hi Volker, > > thanks for the hint. GNU grep works, so I close this as wontfix. > > You might want to add a test in configure that it is picking up a correct > grep. > > /Magnus > > Thanks, good suggestion, I filed and implemented https://bugs.openjdk.java.net/browse/JDK-8172712 for this. ..Thomas > ..Thomas > > On Wed, Jan 11, 2017 at 6:51 PM, Volker Simonis > wrote: > > > Hi Thomas, > > why not simply using GNU grep? We already insist for so many other tools > on the GNU version that this wouldn't be a big thing. > > And as far as I remember, GNU grep is already installed on most of our > machines anyway. You just have to place /opt/freeware/bin in front of your > PATH. > > Your fix is actually also fine, although it breaks the informal code > formatting rules, which require the indentation of wrapped strings. But it > is also quite sensitive and I'm sure this will break again in the future > (in this or in other places). > > By the way, why does it break for 'cds' if it didn't for 'jvmci'? I didn't > knew that we support 'cds' on AIX either? > > Regards, > Volker > > Thomas St?fe schrieb am Mi., 11. Jan. 2017 um > 16:09: > > > Dear all, > > > > please take a look at this tiny fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172579 > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8172579-colon- > 8168503-broke-AIX-build/webrev/common/autoconf/hotspot.m4.udiff.html > > > > JDK-8168503 exposed a bug in AIX grep. AIX grep, when called like this: > > "grep -Fx " is unable to handle empty patterns correctly. > > 8168503 added a line break in the definition of a variable: > > > > VALID_JVM_FEATURES="compiler1 compiler2 zero shark minimal dtrace jvmti > > jvmci \ > > - graal fprof vm-structs jni-check services management all-gcs nmt cds > > static-build aot" > > + graal fprof vm-structs jni-check services management all-gcs nmt cds > \ > > > > + static-build link-time-opt aot" > > > > > > So now, "cds" is followed by multiple spaces, which are later expanded to > > multiple newlines, and grep is unable to match the pattern immediately > > preceding these newlines (in this case, "cds"). This causes the > > HOTSPOT_VALIDATE_JVM_FEATURES > > function to fail with "Invalid JVM feature: cds". > > > > The error would also happened before when trying to match "jvmci", but so > > far we do not build jvmci on powerpc. > > > > The workaround for now is just to remove the superfluous spaces. > > > > I tried for some hours to find a better solution but could not find one > > which was small enough and worked on all platforms. > > > > I tried using sed to change multiple spaces to a single space, but did not > > get it to work correctly on AIX either. > > > > I thought about passing the pattern list as file to grep - which opposed > to > > passing the pattern in the command line works as expected - but refrained > > from this because creating temporary files is error prone. > > > > I attempted to change the whole NEEDLE/STACK expression to a loop checking > > each single feature with '=~' against the list of valid features, but this > > felt too intrusive. > > > > The proposed fix is not the most elegant one but the risk for other > > platforms is minimal and it works. > > > > Kind Regards, Thomas > > > > > From doko at ubuntu.com Thu Jan 12 13:36:30 2017 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 12 Jan 2017 14:36:30 +0100 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: <82e5a8b2-8cf8-49bf-bb73-e7d856c413db@ubuntu.com> On 12.01.2017 11:43, Staffan Larsen wrote: > jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. according to http://openjdk.java.net/jtreg/ https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ doesn't yet mention this new release. Matthias From magnus.ihse.bursie at oracle.com Thu Jan 12 13:36:37 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Jan 2017 14:36:37 +0100 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly In-Reply-To: References: Message-ID: Looks good to me. Since the closed generated-configure needs to be regenerated, I'll sponsor and push this patch. /Magnus On 2017-01-12 14:04, Thomas St?fe wrote: > Dear all, > > please take a look at this fix. This should prevent configure from using a > grep which is not able to handle pattern lists with empty patterns. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8172712 > > webrevs: > http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ > > Background: > > https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused > by a buggy grep (on AIX) and the easiest way to work around that bug would > be to use the GNU version of grep. It was suggested in the orginal mail > thread ( > http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html) > to check this in configure. > > This change implements this suggestion and checks if grep behaves correctly. > > Kind Regards, Thomas From magnus.ihse.bursie at oracle.com Thu Jan 12 13:42:22 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Jan 2017 14:42:22 +0100 Subject: RFR: JDK-8162750 -D__solaris__ added twice Message-ID: /common/autoconf/flags.m4 contains duplicated code to add -D__solaris__ to the JDK compiler flags when the target os is solaris. Probably a result of a merge error during development of the new hotspot build system. Bug: https://bugs.openjdk.java.net/browse/JDK-8162750 Patch inline: diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -815,11 +815,6 @@ $2CXXFLAGS_JDK="${$2CXXFLAGS_JDK} -D__solaris__" fi - if test "x$OPENJDK_TARGET_OS" = xsolaris; then - $2CFLAGS_JDK="${$2CFLAGS_JDK} -D__solaris__" - $2CXXFLAGS_JDK="${$2CXXFLAGS_JDK} -D__solaris__" - fi - $2CFLAGS_JDK="${$2CFLAGS_JDK} ${$2EXTRA_CFLAGS}" $2CXXFLAGS_JDK="${$2CXXFLAGS_JDK} ${$2EXTRA_CXXFLAGS}" $2LDFLAGS_JDK="${$2LDFLAGS_JDK} ${$2EXTRA_LDFLAGS}" /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 12 13:47:55 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Jan 2017 14:47:55 +0100 Subject: RFR: JDK-8170863 Always pass MAKE_ARGS to MAKE in Main.gmk Message-ID: <76c9bd2a-355a-a539-bbbb-1307b810efb8@oracle.com> In JDK-8170284, the hotspot build logic was better integrated with the top make level. However, the calls to make there was not provided with MAKE_ARGS. Bug: https://bugs.openjdk.java.net/browse/JDK-8170863 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8170863-always-pass-MAKE_ARGS/webrev.01 /Magnus From thomas.stuefe at gmail.com Thu Jan 12 13:59:25 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 14:59:25 +0100 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly In-Reply-To: References: Message-ID: Thank you Magnus! Patch is tested on AIX, Solaris, Linux and Windows, no issues. Kind Regards, Thomas On Thu, Jan 12, 2017 at 2:36 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > Looks good to me. > > Since the closed generated-configure needs to be regenerated, I'll sponsor > and push this patch. > > /Magnus > > > On 2017-01-12 14:04, Thomas St?fe wrote: > > Dear all, > > please take a look at this fix. This should prevent configure from using a > grep which is not able to handle pattern lists with empty patterns. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8172712 > > webrevs:http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ > > Background: > https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused > by a buggy grep (on AIX) and the easiest way to work around that bug would > be to use the GNU version of grep. It was suggested in the orginal mail > thread (http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html) > to check this in configure. > > This change implements this suggestion and checks if grep behaves correctly. > > Kind Regards, Thomas > > > From erik.joelsson at oracle.com Thu Jan 12 14:08:39 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Jan 2017 15:08:39 +0100 Subject: RFR: JDK-8172714 Remove unused and unexpanded variables from spec.gmk.in In-Reply-To: References: Message-ID: <860e8524-060b-1175-8ff5-4776de41f90f@oracle.com> Looks good. /Erik On 2017-01-12 13:33, Magnus Ihse Bursie wrote: > We do not expand the value of @BUILD_HOTSPOT@ and @THEPWDCMD@ anymore > in the generated spec.gmk. > > No-one seems to be suffering from this (and I've double-checked > with a grep) so we should just remove the declarations. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172714 > Patch inline: > diff --git a/common/autoconf/spec.gmk.in b/common/autoconf/spec.gmk.in > --- a/common/autoconf/spec.gmk.in > +++ b/common/autoconf/spec.gmk.in > @@ -274,8 +274,6 @@ > CONFIGURESUPPORT_OUTPUTDIR:=@CONFIGURESUPPORT_OUTPUTDIR@ > BUILDJDK_OUTPUTDIR=$(BUILD_OUTPUT)/buildjdk > > -BUILD_HOTSPOT=@BUILD_HOTSPOT@ > - > BUILD_FAILURE_HANDLER := @BUILD_FAILURE_HANDLER@ > > ENABLE_GENERATE_CLASSLIST := @ENABLE_GENERATE_CLASSLIST@ > @@ -642,7 +640,6 @@ > NICE:=@NICE@ > PATCH:=@PATCH@ > PRINTF:=@PRINTF@ > -PWD:=@THEPWDCMD@ > RM:=@RM@ > RMDIR:=@RMDIR@ > SED:=@SED@ > > /Magnus From erik.joelsson at oracle.com Thu Jan 12 14:09:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Jan 2017 15:09:13 +0100 Subject: RFR: JDK-8162750 -D__solaris__ added twice In-Reply-To: References: Message-ID: Looks good. /Erik On 2017-01-12 14:42, Magnus Ihse Bursie wrote: > /common/autoconf/flags.m4 contains duplicated code to add > -D__solaris__ to the JDK compiler flags when the target os is solaris. > > Probably a result of a merge error during development of the new > hotspot build system. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8162750 > Patch inline: > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -815,11 +815,6 @@ > $2CXXFLAGS_JDK="${$2CXXFLAGS_JDK} -D__solaris__" > fi > > - if test "x$OPENJDK_TARGET_OS" = xsolaris; then > - $2CFLAGS_JDK="${$2CFLAGS_JDK} -D__solaris__" > - $2CXXFLAGS_JDK="${$2CXXFLAGS_JDK} -D__solaris__" > - fi > - > $2CFLAGS_JDK="${$2CFLAGS_JDK} ${$2EXTRA_CFLAGS}" > $2CXXFLAGS_JDK="${$2CXXFLAGS_JDK} ${$2EXTRA_CXXFLAGS}" > $2LDFLAGS_JDK="${$2LDFLAGS_JDK} ${$2EXTRA_LDFLAGS}" > > /Magnus From erik.joelsson at oracle.com Thu Jan 12 14:11:53 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Jan 2017 15:11:53 +0100 Subject: RFR: JDK-8170863 Always pass MAKE_ARGS to MAKE in Main.gmk In-Reply-To: <76c9bd2a-355a-a539-bbbb-1307b810efb8@oracle.com> References: <76c9bd2a-355a-a539-bbbb-1307b810efb8@oracle.com> Message-ID: Looks good. Are you sure MAKE_ARGS should be added to bootcycle-images? I assume you have tested this. /Erik On 2017-01-12 14:47, Magnus Ihse Bursie wrote: > In JDK-8170284, the hotspot build logic was better integrated with the > top make level. However, the calls to make there was not provided with > MAKE_ARGS. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170863 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8170863-always-pass-MAKE_ARGS/webrev.01 > > /Magnus > From christoph.langer at sap.com Thu Jan 12 15:11:40 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Jan 2017 15:11:40 +0000 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: <82e5a8b2-8cf8-49bf-bb73-e7d856c413db@ubuntu.com> References: <82e5a8b2-8cf8-49bf-bb73-e7d856c413db@ubuntu.com> Message-ID: Hi, the tag in http://hg.openjdk.java.net/code-tools/jtreg still says jtreg4.2-b04. See: http://hg.openjdk.java.net/code-tools/jtreg/file/4b0cd55e7741/.hgtags Wouldn't that need some adoption first? Best regards Christoph > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Matthias Klose > Sent: Donnerstag, 12. Januar 2017 14:37 > To: Staffan Larsen ; build-dev at openjdk.java.net > build-dev ; jdk9-dev dev at openjdk.java.net> > Subject: Re: RFR: 8172709 Upgrade to jtreg 4.2 b05 > > On 12.01.2017 11:43, Staffan Larsen wrote: > > jtreg 4.2 b05 was recently promoted with some important fixes. Please > review the change below to upgrade jdk9-dev to the new version. I have run > jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not > see any new test failures. > > according to http://openjdk.java.net/jtreg/ > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > doesn't yet mention this new release. > > Matthias From jonathan.gibbons at oracle.com Thu Jan 12 15:23:05 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Jan 2017 07:23:05 -0800 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: <82e5a8b2-8cf8-49bf-bb73-e7d856c413db@ubuntu.com> Message-ID: b05 is not yet officially announced or tagged, although I'll get to that today. I'm not aware that any tests require any new functionality (yet), but as Staffan mentioned, there are fixes in the handling for timeout handling that are important for some systems using jtreg. -- Jon On 1/12/17 7:11 AM, Langer, Christoph wrote: > Hi, > > the tag in http://hg.openjdk.java.net/code-tools/jtreg still says jtreg4.2-b04. > > See: http://hg.openjdk.java.net/code-tools/jtreg/file/4b0cd55e7741/.hgtags > > Wouldn't that need some adoption first? > > Best regards > Christoph > >> -----Original Message----- >> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of >> Matthias Klose >> Sent: Donnerstag, 12. Januar 2017 14:37 >> To: Staffan Larsen ; build-dev at openjdk.java.net >> build-dev ; jdk9-dev > dev at openjdk.java.net> >> Subject: Re: RFR: 8172709 Upgrade to jtreg 4.2 b05 >> >> On 12.01.2017 11:43, Staffan Larsen wrote: >>> jtreg 4.2 b05 was recently promoted with some important fixes. Please >> review the change below to upgrade jdk9-dev to the new version. I have run >> jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not >> see any new test failures. >> >> according to http://openjdk.java.net/jtreg/ >> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >> doesn't yet mention this new release. >> >> Matthias From tim.bell at oracle.com Thu Jan 12 16:11:44 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 12 Jan 2017 08:11:44 -0800 Subject: RFR: JDK-8172714 Remove unused and unexpanded variables from spec.gmk.in In-Reply-To: <860e8524-060b-1175-8ff5-4776de41f90f@oracle.com> References: <860e8524-060b-1175-8ff5-4776de41f90f@oracle.com> Message-ID: Magnus: Looks good to me as well. Tim On 01/12/17 06:08, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2017-01-12 13:33, Magnus Ihse Bursie wrote: >> We do not expand the value of @BUILD_HOTSPOT@ and @THEPWDCMD@ anymore >> in the generated spec.gmk. >> >> No-one seems to be suffering from this (and I've double-checked >> with a grep) so we should just remove the declarations. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172714 >> Patch inline: >> diff --git a/common/autoconf/spec.gmk.in b/common/autoconf/spec.gmk.in >> --- a/common/autoconf/spec.gmk.in >> +++ b/common/autoconf/spec.gmk.in >> @@ -274,8 +274,6 @@ >> CONFIGURESUPPORT_OUTPUTDIR:=@CONFIGURESUPPORT_OUTPUTDIR@ >> BUILDJDK_OUTPUTDIR=$(BUILD_OUTPUT)/buildjdk >> >> -BUILD_HOTSPOT=@BUILD_HOTSPOT@ >> - >> BUILD_FAILURE_HANDLER := @BUILD_FAILURE_HANDLER@ >> >> ENABLE_GENERATE_CLASSLIST := @ENABLE_GENERATE_CLASSLIST@ >> @@ -642,7 +640,6 @@ >> NICE:=@NICE@ >> PATCH:=@PATCH@ >> PRINTF:=@PRINTF@ >> -PWD:=@THEPWDCMD@ >> RM:=@RM@ >> RMDIR:=@RMDIR@ >> SED:=@SED@ >> >> /Magnus > From mikael.vidstedt at oracle.com Thu Jan 12 17:29:59 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 12 Jan 2017 09:29:59 -0800 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly In-Reply-To: References: Message-ID: I also ran into this problem a couple of weeks ago with some other "misbehaving? grep. Thanks for adding this check! Cheers, Mikael > On Jan 12, 2017, at 5:04 AM, Thomas St?fe wrote: > > Dear all, > > please take a look at this fix. This should prevent configure from using a grep which is not able to handle pattern lists with empty patterns. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8172712 > > webrevs: > http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ > > Background: > > https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused by a buggy grep (on AIX) and the easiest way to work around that bug would be to use the GNU version of grep. It was suggested in the orginal mail thread (http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html ) to check this in configure. > > This change implements this suggestion and checks if grep behaves correctly. > > Kind Regards, Thomas From thomas.stuefe at gmail.com Thu Jan 12 20:02:37 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 20:02:37 +0000 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly In-Reply-To: References: Message-ID: Thank you! On Thu, 12 Jan 2017 at 18:30, Mikael Vidstedt wrote: > > I also ran into this problem a couple of weeks ago with some other > "misbehaving? grep. Thanks for adding this check! > > Cheers, > Mikael > > > On Jan 12, 2017, at 5:04 AM, Thomas St?fe wrote: > > Dear all, > > please take a look at this fix. This should prevent configure from using a > grep which is not able to handle pattern lists with empty patterns. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8172712 > > webrevs: > > http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ > > Background: > > https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused > by a buggy grep (on AIX) and the easiest way to work around that bug would > be to use the GNU version of grep. It was suggested in the orginal mail > thread ( > http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html) > to check this in configure. > > This change implements this suggestion and checks if grep behaves > correctly. > > Kind Regards, Thomas > > > > From trejkaz at trypticon.org Fri Jan 13 03:59:35 2017 From: trejkaz at trypticon.org (Trejkaz) Date: Fri, 13 Jan 2017 14:59:35 +1100 Subject: Building OpenJDK 8 on macOS 10.12 - Path provided in --with-xcode-path not being used to locate Xcode? Message-ID: Hi. I'm trying to build OpenJDK 8 on macOS 10.12, and having some trouble getting it to accept the path to Xcode. $ ./configure "--with-xcode-path=$HOME/DevEnv/Applications/Xcode4/Xcode.app" checking Determining if we need to set DEVELOPER_DIR... yes (/Users/tester/DevEnv/Applications/Xcode4/Xcode.app/Contents/Developer) checking for xcodebuild... /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild configure: error: Xcode 4 is required to build JDK 8, the version found was 8.2.1. Use --with-xcode-path to specify the location of Xcode 4 or make Xcode 4 active by using xcode-select. configure exiting with result code 1 >From the DEVELOPER_DIR line, it seems like the option has been accepted, but then it immediately ignores the setting for xcodebuild and fails with the version being wrong... TX From erik.joelsson at oracle.com Fri Jan 13 08:28:31 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Jan 2017 09:28:31 +0100 Subject: Building OpenJDK 8 on macOS 10.12 - Path provided in --with-xcode-path not being used to locate Xcode? In-Reply-To: References: Message-ID: Hello, I'm not a mac user myself so probably can't help you much, but just to make sure. Which forest have you cloned? You should clone either jdk8u/jdk8u or jdk8u/jdk8u-dev (depending on if you intend to do development work or not). If you cloned jdk8/jdk8 it's unlikely that you get it to build on any modern configuration. /Erik On 2017-01-13 04:59, Trejkaz wrote: > Hi. > > I'm trying to build OpenJDK 8 on macOS 10.12, and having some trouble > getting it to accept the path to Xcode. > > $ ./configure "--with-xcode-path=$HOME/DevEnv/Applications/Xcode4/Xcode.app" > > checking Determining if we need to set DEVELOPER_DIR... yes > (/Users/tester/DevEnv/Applications/Xcode4/Xcode.app/Contents/Developer) > checking for xcodebuild... > /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild > > configure: error: Xcode 4 is required to build JDK 8, the version > found was 8.2.1. Use --with-xcode-path to specify the location of > Xcode 4 or make Xcode 4 active by using xcode-select. > > configure exiting with result code 1 > > From the DEVELOPER_DIR line, it seems like the option has been > accepted, but then it immediately ignores the setting for xcodebuild > and fails with the version being wrong... > > TX From trejkaz at trypticon.org Fri Jan 13 13:19:39 2017 From: trejkaz at trypticon.org (Trejkaz) Date: Sat, 14 Jan 2017 00:19:39 +1100 Subject: Building OpenJDK 8 on macOS 10.12 - Path provided in --with-xcode-path not being used to locate Xcode? In-Reply-To: References: Message-ID: On Fri, Jan 13, 2017 at 7:28 PM, Erik Joelsson wrote: > Hello, > > I'm not a mac user myself so probably can't help you much, but just to make > sure. Which forest have you cloned? You should clone either jdk8u/jdk8u or > jdk8u/jdk8u-dev (depending on if you intend to do development work or not). > If you cloned jdk8/jdk8 it's unlikely that you get it to build on any modern > configuration. I cloned jdk8u-dev. Although the difference was not immediately obvious, I was following a guide which recommended that. TX From magnus.ihse.bursie at oracle.com Fri Jan 13 13:30:56 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 13 Jan 2017 14:30:56 +0100 Subject: Building OpenJDK 8 on macOS 10.12 - Path provided in --with-xcode-path not being used to locate Xcode? In-Reply-To: References: Message-ID: <1231a3a8-2fe9-09bb-235c-99e66be19203@oracle.com> Hi Trejkaz, Try adding --with-toolchain-path=$HOME/DevEnv/Applications/Xcode4/Xcode.app/Contents/Developer/usr/bin as well. /Magnus On 2017-01-13 04:59, Trejkaz wrote: > Hi. > > I'm trying to build OpenJDK 8 on macOS 10.12, and having some trouble > getting it to accept the path to Xcode. > > $ ./configure "--with-xcode-path=$HOME/DevEnv/Applications/Xcode4/Xcode.app" > > checking Determining if we need to set DEVELOPER_DIR... yes > (/Users/tester/DevEnv/Applications/Xcode4/Xcode.app/Contents/Developer) > checking for xcodebuild... > /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild > > configure: error: Xcode 4 is required to build JDK 8, the version > found was 8.2.1. Use --with-xcode-path to specify the location of > Xcode 4 or make Xcode 4 active by using xcode-select. > > configure exiting with result code 1 > > From the DEVELOPER_DIR line, it seems like the option has been > accepted, but then it immediately ignores the setting for xcodebuild > and fails with the version being wrong... > > TX From staffan.larsen at oracle.com Mon Jan 16 08:24:12 2017 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jan 2017 09:24:12 +0100 Subject: RFR: 8172842 Invoke lldb with --batch from failure handler Message-ID: When the failure handler invokes lldb to create a core it looks something like this: lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit' However if the attach command fails, the rest of the commands - including 'quit' - are not being run. This means the lldb process is hung. Adding '--batch' to the command line overcomes this problem. Thanks, /Staffan diff --git a/test/failure_handler/src/share/conf/mac.properties b/test/failure_handler/src/share/conf/mac.properties --- a/test/failure_handler/src/share/conf/mac.properties +++ b/test/failure_handler/src/share/conf/mac.properties @@ -64,7 +64,7 @@ native.core.app=bash native.core.delimiter=\0 native.core.args=-c\0gcore -o ./core.%p %p || \ - (DevToolsSecurity --status | grep -q enabled && lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') + (DevToolsSecurity --status | grep -q enabled && lldb --batch -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') native.core.params.timeout=3600000 ################################################################################ # environment info to gather From dmitry.samersoff at oracle.com Mon Jan 16 08:43:20 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 16 Jan 2017 11:43:20 +0300 Subject: RFR: 8172842 Invoke lldb with --batch from failure handler In-Reply-To: References: Message-ID: <27eebbb0-93b4-0aeb-f303-68b05c4c04b9@oracle.com> Staffan, Looks OK to me. -Dmitry On 2017-01-16 11:24, Staffan Larsen wrote: > When the failure handler invokes lldb to create a core it looks something like this: > > lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit' > > However if the attach command fails, the rest of the commands - including 'quit' - are not being run. This means the lldb process is hung. > > Adding '--batch' to the command line overcomes this problem. > > Thanks, > /Staffan > > > diff --git a/test/failure_handler/src/share/conf/mac.properties b/test/failure_handler/src/share/conf/mac.properties > --- a/test/failure_handler/src/share/conf/mac.properties > +++ b/test/failure_handler/src/share/conf/mac.properties > @@ -64,7 +64,7 @@ > native.core.app=bash > native.core.delimiter=\0 > native.core.args=-c\0gcore -o ./core.%p %p || \ > - (DevToolsSecurity --status | grep -q enabled && lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') > + (DevToolsSecurity --status | grep -q enabled && lldb --batch -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') > native.core.params.timeout=3600000 > ################################################################################ > # environment info to gather > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Mon Jan 16 10:34:46 2017 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jan 2017 11:34:46 +0100 Subject: RFR: 8172842 Invoke lldb with --batch from failure handler In-Reply-To: <27eebbb0-93b4-0aeb-f303-68b05c4c04b9@oracle.com> References: <27eebbb0-93b4-0aeb-f303-68b05c4c04b9@oracle.com> Message-ID: <8680624B-7C61-4406-9747-BE736FA93123@oracle.com> Thanks Dmitry! > On 16 Jan 2017, at 09:43, Dmitry Samersoff wrote: > > Staffan, > > Looks OK to me. > > -Dmitry > > > On 2017-01-16 11:24, Staffan Larsen wrote: >> When the failure handler invokes lldb to create a core it looks something like this: >> >> lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit' >> >> However if the attach command fails, the rest of the commands - including 'quit' - are not being run. This means the lldb process is hung. >> >> Adding '--batch' to the command line overcomes this problem. >> >> Thanks, >> /Staffan >> >> >> diff --git a/test/failure_handler/src/share/conf/mac.properties b/test/failure_handler/src/share/conf/mac.properties >> --- a/test/failure_handler/src/share/conf/mac.properties >> +++ b/test/failure_handler/src/share/conf/mac.properties >> @@ -64,7 +64,7 @@ >> native.core.app=bash >> native.core.delimiter=\0 >> native.core.args=-c\0gcore -o ./core.%p %p || \ >> - (DevToolsSecurity --status | grep -q enabled && lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') >> + (DevToolsSecurity --status | grep -q enabled && lldb --batch -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') >> native.core.params.timeout=3600000 >> ################################################################################ >> # environment info to gather >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From erik.joelsson at oracle.com Mon Jan 16 10:48:27 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Jan 2017 11:48:27 +0100 Subject: RFR: 8172842 Invoke lldb with --batch from failure handler In-Reply-To: References: Message-ID: <88f4eb1e-95db-22f6-a25f-91bfad3920f5@oracle.com> Looks good to me. /Erik On 2017-01-16 09:24, Staffan Larsen wrote: > When the failure handler invokes lldb to create a core it looks something like this: > > lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit' > > However if the attach command fails, the rest of the commands - including 'quit' - are not being run. This means the lldb process is hung. > > Adding '--batch' to the command line overcomes this problem. > > Thanks, > /Staffan > > > diff --git a/test/failure_handler/src/share/conf/mac.properties b/test/failure_handler/src/share/conf/mac.properties > --- a/test/failure_handler/src/share/conf/mac.properties > +++ b/test/failure_handler/src/share/conf/mac.properties > @@ -64,7 +64,7 @@ > native.core.app=bash > native.core.delimiter=\0 > native.core.args=-c\0gcore -o ./core.%p %p || \ > - (DevToolsSecurity --status | grep -q enabled && lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') > + (DevToolsSecurity --status | grep -q enabled && lldb --batch -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') > native.core.params.timeout=3600000 > ################################################################################ > # environment info to gather > From staffan.larsen at oracle.com Mon Jan 16 11:32:04 2017 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jan 2017 12:32:04 +0100 Subject: RFR: 8172842 Invoke lldb with --batch from failure handler In-Reply-To: <88f4eb1e-95db-22f6-a25f-91bfad3920f5@oracle.com> References: <88f4eb1e-95db-22f6-a25f-91bfad3920f5@oracle.com> Message-ID: Thanks Erik! > On 16 Jan 2017, at 11:48, Erik Joelsson wrote: > > Looks good to me. > > /Erik > > > On 2017-01-16 09:24, Staffan Larsen wrote: >> When the failure handler invokes lldb to create a core it looks something like this: >> >> lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit' >> >> However if the attach command fails, the rest of the commands - including 'quit' - are not being run. This means the lldb process is hung. >> >> Adding '--batch' to the command line overcomes this problem. >> >> Thanks, >> /Staffan >> >> >> diff --git a/test/failure_handler/src/share/conf/mac.properties b/test/failure_handler/src/share/conf/mac.properties >> --- a/test/failure_handler/src/share/conf/mac.properties >> +++ b/test/failure_handler/src/share/conf/mac.properties >> @@ -64,7 +64,7 @@ >> native.core.app=bash >> native.core.delimiter=\0 >> native.core.args=-c\0gcore -o ./core.%p %p || \ >> - (DevToolsSecurity --status | grep -q enabled && lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') >> + (DevToolsSecurity --status | grep -q enabled && lldb --batch -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit') >> native.core.params.timeout=3600000 >> ################################################################################ >> # environment info to gather >> > From magnus.ihse.bursie at oracle.com Tue Jan 17 13:16:25 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 17 Jan 2017 14:16:25 +0100 Subject: RFR: JDK-8170863 Always pass MAKE_ARGS to MAKE in Main.gmk In-Reply-To: References: <76c9bd2a-355a-a539-bbbb-1307b810efb8@oracle.com> Message-ID: On 2017-01-12 15:11, Erik Joelsson wrote: > Looks good. Are you sure MAKE_ARGS should be added to > bootcycle-images? I assume you have tested this. You think too highly of me. ;-) I had in fact not tested the bootcycle-image step. Now I have, and it does work. I beleive it's good to have it, so additional make flags will get passed to the second stage of the bootcycle build. If not, it's probably not a big loss, but I think it's better to have it. /Magnus > > /Erik > > > On 2017-01-12 14:47, Magnus Ihse Bursie wrote: >> In JDK-8170284, the hotspot build logic was better integrated with >> the top make level. However, the calls to make there was not provided >> with MAKE_ARGS. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170863 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8170863-always-pass-MAKE_ARGS/webrev.01 >> >> /Magnus >> > From chris.hegarty at oracle.com Wed Jan 18 12:11:50 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 18 Jan 2017 12:11:50 +0000 Subject: RFR [9] Remove add exports from ModuleSummary build Message-ID: After a recent change [1], I noticed a warning during compilation of the ModuleSummary build tool: warning: [options] module name in --add-exports option not found: jdk.jdeps It can be seen from the history of ModuleSummary.java in jake that at one point this class used types from com.sun.tools.classfile ( in the jdeps module ), but no longer does. The add exports can simply be removed, as it it not needed any more. diff --git a/make/ModuleTools.gmk b/make/ModuleTools.gmk --- a/make/ModuleTools.gmk +++ b/make/ModuleTools.gmk @@ -39,7 +39,6 @@ build.tools.jigsaw.GenGraphs TOOL_MODULESUMMARY := $(BUILD_JAVA) -esa -ea -cp $(TOOLS_CLASSES_DIR) \ - --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED \ build.tools.jigsaw.ModuleSummary TOOL_ADD_PACKAGES_ATTRIBUTE := $(BUILD_JAVA) $(JAVA_FLAGS_SMALL) \ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8171380 From magnus.ihse.bursie at oracle.com Wed Jan 18 12:27:55 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 18 Jan 2017 13:27:55 +0100 Subject: RFR [9] Remove add exports from ModuleSummary build In-Reply-To: References: Message-ID: On 2017-01-18 13:11, Chris Hegarty wrote: > After a recent change [1], I noticed a warning during compilation of > the ModuleSummary build tool: > > warning: [options] module name in --add-exports option not found: jdk.jdeps > > It can be seen from the history of ModuleSummary.java in jake that at > one point this class used types from com.sun.tools.classfile ( in the jdeps > module ), but no longer does. The add exports can simply be removed, > as it it not needed any more. > > > diff --git a/make/ModuleTools.gmk b/make/ModuleTools.gmk > --- a/make/ModuleTools.gmk > +++ b/make/ModuleTools.gmk > @@ -39,7 +39,6 @@ > build.tools.jigsaw.GenGraphs > > TOOL_MODULESUMMARY := $(BUILD_JAVA) -esa -ea -cp $(TOOLS_CLASSES_DIR) \ > - --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED \ > build.tools.jigsaw.ModuleSummary > > TOOL_ADD_PACKAGES_ATTRIBUTE := $(BUILD_JAVA) $(JAVA_FLAGS_SMALL) \ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8171380 Looks good to me. /Magnus From claes.redestad at oracle.com Wed Jan 18 12:30:37 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 18 Jan 2017 13:30:37 +0100 Subject: RFR [9] Remove add exports from ModuleSummary build In-Reply-To: References: Message-ID: +1 /Claes On 01/18/2017 01:27 PM, Magnus Ihse Bursie wrote: > On 2017-01-18 13:11, Chris Hegarty wrote: >> After a recent change [1], I noticed a warning during compilation of >> the ModuleSummary build tool: >> >> warning: [options] module name in --add-exports option not found: >> jdk.jdeps >> >> It can be seen from the history of ModuleSummary.java in jake that at >> one point this class used types from com.sun.tools.classfile ( in the >> jdeps >> module ), but no longer does. The add exports can simply be removed, >> as it it not needed any more. >> >> >> diff --git a/make/ModuleTools.gmk b/make/ModuleTools.gmk >> --- a/make/ModuleTools.gmk >> +++ b/make/ModuleTools.gmk >> @@ -39,7 +39,6 @@ >> build.tools.jigsaw.GenGraphs >> TOOL_MODULESUMMARY := $(BUILD_JAVA) -esa -ea -cp >> $(TOOLS_CLASSES_DIR) \ >> - --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED \ >> build.tools.jigsaw.ModuleSummary >> TOOL_ADD_PACKAGES_ATTRIBUTE := $(BUILD_JAVA) $(JAVA_FLAGS_SMALL) \ >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8171380 > > Looks good to me. > > /Magnus > From david.dehaven at oracle.com Wed Jan 18 17:22:41 2017 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 18 Jan 2017 09:22:41 -0800 Subject: Building OpenJDK 8 on macOS 10.12 - Path provided in --with-xcode-path not being used to locate Xcode? In-Reply-To: References: Message-ID: <69CD0600-2B76-41DF-B8AD-7BDB10625F42@oracle.com> > I'm trying to build OpenJDK 8 on macOS 10.12, and having some trouble > getting it to accept the path to Xcode. > > $ ./configure "--with-xcode-path=$HOME/DevEnv/Applications/Xcode4/Xcode.app" > > checking Determining if we need to set DEVELOPER_DIR... yes > (/Users/tester/DevEnv/Applications/Xcode4/Xcode.app/Contents/Developer) > checking for xcodebuild... > /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild > > configure: error: Xcode 4 is required to build JDK 8, the version > found was 8.2.1. Use --with-xcode-path to specify the location of > Xcode 4 or make Xcode 4 active by using xcode-select. > > configure exiting with result code 1 > > From the DEVELOPER_DIR line, it seems like the option has been > accepted, but then it immediately ignores the setting for xcodebuild > and fails with the version being wrong... Xcode 4 does not run on 10.12, or even 10.11. Did you have this working previously? Last time I tried this the toolchain was DOA on anything later than 10.10. -DrD- From david.dehaven at oracle.com Wed Jan 18 17:23:54 2017 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 18 Jan 2017 09:23:54 -0800 Subject: Building OpenJDK 8 on macOS 10.12 - Path provided in --with-xcode-path not being used to locate Xcode? In-Reply-To: <69CD0600-2B76-41DF-B8AD-7BDB10625F42@oracle.com> References: <69CD0600-2B76-41DF-B8AD-7BDB10625F42@oracle.com> Message-ID: <8655A6D7-40F7-41C9-B2D7-78208EABDEFA@oracle.com> >> I'm trying to build OpenJDK 8 on macOS 10.12, and having some trouble >> getting it to accept the path to Xcode. >> >> $ ./configure "--with-xcode-path=$HOME/DevEnv/Applications/Xcode4/Xcode.app" >> >> checking Determining if we need to set DEVELOPER_DIR... yes >> (/Users/tester/DevEnv/Applications/Xcode4/Xcode.app/Contents/Developer) >> checking for xcodebuild... >> /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild >> >> configure: error: Xcode 4 is required to build JDK 8, the version >> found was 8.2.1. Use --with-xcode-path to specify the location of >> Xcode 4 or make Xcode 4 active by using xcode-select. >> >> configure exiting with result code 1 >> >> From the DEVELOPER_DIR line, it seems like the option has been >> accepted, but then it immediately ignores the setting for xcodebuild >> and fails with the version being wrong... > > > Xcode 4 does not run on 10.12, or even 10.11. Did you have this working previously? Last time I tried this the toolchain was DOA on anything later than 10.10. To work around this I had to create a VM with 10.8... (which is legal as long as it's done on a Mac) -DrD- From henry.jen at oracle.com Wed Jan 18 17:57:00 2017 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 18 Jan 2017 09:57:00 -0800 Subject: RFR: 8160881: Remove jvisualvm from JDK9 Message-ID: Hi, Please review the webrev to remove jvisualvm from JDK9. http://cr.openjdk.java.net/~henryjen/jdk9/8160881/jdk/webrev/ Cheers, Henry From erik.joelsson at oracle.com Thu Jan 19 07:23:45 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Jan 2017 08:23:45 +0100 Subject: RFR: 8160881: Remove jvisualvm from JDK9 In-Reply-To: References: Message-ID: <0c1c390a-6151-5e83-c49c-1d19435702ae@oracle.com> Looks good. /Erik On 2017-01-18 18:57, Henry Jen wrote: > Hi, > > Please review the webrev to remove jvisualvm from JDK9. > > http://cr.openjdk.java.net/~henryjen/jdk9/8160881/jdk/webrev/ > > Cheers, > Henry > From magnus.ihse.bursie at oracle.com Thu Jan 19 10:15:02 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 19 Jan 2017 11:15:02 +0100 Subject: RFR: 8160881: Remove jvisualvm from JDK9 In-Reply-To: References: Message-ID: <3057e368-c030-58f5-bf43-56cd2be8e4e0@oracle.com> On 2017-01-18 18:57, Henry Jen wrote: > Hi, > > Please review the webrev to remove jvisualvm from JDK9. > > http://cr.openjdk.java.net/~henryjen/jdk9/8160881/jdk/webrev/ Looks good to me. /Magnus From mandy.chung at oracle.com Thu Jan 19 23:37:16 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jan 2017 15:37:16 -0800 Subject: Review request: JDK-8173085 Warning module name in --add-exports not found: jdk.jdeps when compiling for BUILD_JIGSAW_TOOLS Message-ID: <9B779595-F02F-4D94-B6C3-E80EA6D24181@oracle.com> JDK-8172973 removes the warning emitted at run-time but --add-exports specified at compile-time is not removed. Hence a javac warning is emitted. diff --git a/make/CompileModuleTools.gmk b/make/CompileModuleTools.gmk --- a/make/CompileModuleTools.gmk +++ b/make/CompileModuleTools.gmk @@ -37,6 +37,5 @@ build/tools/jigsaw, \ BIN := $(TOOLS_CLASSES_DIR), \ ADD_JAVAC_FLAGS := \ - --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED \ --add-exports java.base/jdk.internal.module=ALL-UNNAMED \ )) Mandy From jonathan.gibbons at oracle.com Thu Jan 19 23:46:59 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Jan 2017 15:46:59 -0800 Subject: Review request: JDK-8173085 Warning module name in --add-exports not found: jdk.jdeps when compiling for BUILD_JIGSAW_TOOLS In-Reply-To: <9B779595-F02F-4D94-B6C3-E80EA6D24181@oracle.com> References: <9B779595-F02F-4D94-B6C3-E80EA6D24181@oracle.com> Message-ID: <58814FF3.3050008@oracle.com> Looks OK to me. -- Jon On 01/19/2017 03:37 PM, Mandy Chung wrote: > JDK-8172973 removes the warning emitted at run-time but --add-exports specified at compile-time is not removed. Hence a javac warning is emitted. > > diff --git a/make/CompileModuleTools.gmk b/make/CompileModuleTools.gmk > --- a/make/CompileModuleTools.gmk > +++ b/make/CompileModuleTools.gmk > @@ -37,6 +37,5 @@ > build/tools/jigsaw, \ > BIN := $(TOOLS_CLASSES_DIR), \ > ADD_JAVAC_FLAGS := \ > - --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED \ > --add-exports java.base/jdk.internal.module=ALL-UNNAMED \ > )) > > Mandy From martinrb at google.com Fri Jan 20 04:09:13 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 Jan 2017 20:09:13 -0800 Subject: jdk-9+153 tarballs have packaging error Message-ID: I noticed I couldn't use an exploded jdk tarball because some files were not world readable. tar tvzf jdk-9-ea+153_linux-x64_bin.tar.gz ... -rw-r--r-- java_re/java_re 73955 2017-01-18 17:59 jdk-9/include/jni.h -rw-r--r-- java_re/java_re 824 2017-01-18 17:59 jdk-9/include/linux/jni_md.h -rw-r--r-- java_re/java_re 968 2017-01-18 17:59 jdk-9/include/linux/jawt_md.h -rw------- java_re/java_re 535839 2017-01-18 17:59 jdk-9/jmods/jdk.jshell.jmod -rw------- java_re/java_re 2116660 2017-01-18 17:59 jdk-9/jmods/jdk.plugin.jmod -rw------- java_re/java_re 119739 2017-01-18 17:59 jdk-9/jmods/java.logging.jmod -rw------- java_re/java_re 131409 2017-01-18 17:59 jdk-9/jmods/jdk.jdwp.agent.jmod -rw------- java_re/java_re 23723724 2017-01-18 17:59 jdk-9/jmods/javafx.web.jmod A final step in building files suitable for distribution is chmod -R a+rX From mandy.chung at oracle.com Fri Jan 20 06:43:57 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jan 2017 22:43:57 -0800 Subject: jdk-9+153 tarballs have packaging error In-Reply-To: References: Message-ID: <3E5AD6E8-EDC2-4DC2-B4D8-5063313B48BE@oracle.com> Thanks for the report. We also uncover this regression: https://bugs.openjdk.java.net/browse/JDK-8173096 Mandy > On Jan 19, 2017, at 8:09 PM, Martin Buchholz wrote: > > I noticed I couldn't use an exploded jdk tarball because some files were > not world readable. > tar tvzf jdk-9-ea+153_linux-x64_bin.tar.gz > ... > -rw-r--r-- java_re/java_re 73955 2017-01-18 17:59 jdk-9/include/jni.h > -rw-r--r-- java_re/java_re 824 2017-01-18 17:59 > jdk-9/include/linux/jni_md.h > -rw-r--r-- java_re/java_re 968 2017-01-18 17:59 > jdk-9/include/linux/jawt_md.h > -rw------- java_re/java_re 535839 2017-01-18 17:59 > jdk-9/jmods/jdk.jshell.jmod > -rw------- java_re/java_re 2116660 2017-01-18 17:59 > jdk-9/jmods/jdk.plugin.jmod > -rw------- java_re/java_re 119739 2017-01-18 17:59 > jdk-9/jmods/java.logging.jmod > -rw------- java_re/java_re 131409 2017-01-18 17:59 > jdk-9/jmods/jdk.jdwp.agent.jmod > -rw------- java_re/java_re 23723724 2017-01-18 17:59 > jdk-9/jmods/javafx.web.jmod > > A final step in building files suitable for distribution is > chmod -R a+rX From erik.joelsson at oracle.com Fri Jan 20 07:50:30 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 20 Jan 2017 08:50:30 +0100 Subject: Review request: JDK-8173085 Warning module name in --add-exports not found: jdk.jdeps when compiling for BUILD_JIGSAW_TOOLS In-Reply-To: <9B779595-F02F-4D94-B6C3-E80EA6D24181@oracle.com> References: <9B779595-F02F-4D94-B6C3-E80EA6D24181@oracle.com> Message-ID: <654b3ff5-0a84-13c1-e27e-6696f1badba6@oracle.com> Looks good to me. /Erik On 2017-01-20 00:37, Mandy Chung wrote: > JDK-8172973 removes the warning emitted at run-time but --add-exports specified at compile-time is not removed. Hence a javac warning is emitted. > > diff --git a/make/CompileModuleTools.gmk b/make/CompileModuleTools.gmk > --- a/make/CompileModuleTools.gmk > +++ b/make/CompileModuleTools.gmk > @@ -37,6 +37,5 @@ > build/tools/jigsaw, \ > BIN := $(TOOLS_CLASSES_DIR), \ > ADD_JAVAC_FLAGS := \ > - --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED \ > --add-exports java.base/jdk.internal.module=ALL-UNNAMED \ > )) > > Mandy From magnus.ihse.bursie at oracle.com Fri Jan 20 08:58:24 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 Jan 2017 09:58:24 +0100 Subject: RFR: JDK-8173107 Fix autoconf/spec.gmk mismatches Message-ID: <3901e53e-bdb2-e6e4-6afc-09679e0ffbfc@oracle.com> Over the course of jdk9 development, the variables in the configure script exported using AC_SUBST, the replacement patterns in spec.gmk.in and the usage of spec.gmk in the makefiles have diverged. Fixes: * Remove AC_SUBST for variables not exported or not used in make files. (BOOT_JDK_BITS, ZERO_ARCHFLAG, ZERO_ARCHDEF, INCLUDE_DTRACE, OPENJDK_*_OS_BUNDLE, OPENJDK_*_CPU_BUNDLE, LP64, ENABLE_JFR) * Include missing exports in spec.gmk.in (JDK_ARCH_ABI_PROP_NAME) * Make sure we always explicitly use AC_SUBST for exported variables (PNG_CFLAGS, PNG_LIBS, LCMS_CFLAGS, LCMS_LIBS) * Only use the pattern AC_SUBST(VARIABLE), to make sure the VARIABLE is accessible in configure as well as make. Bug: https://bugs.openjdk.java.net/browse/JDK-8173107 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8173107-fix-spec-gmk-mismatches/webrev.01 /Magnus From david.holmes at oracle.com Fri Jan 20 09:30:07 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Jan 2017 19:30:07 +1000 Subject: RFR: JDK-8173107 Fix autoconf/spec.gmk mismatches In-Reply-To: <3901e53e-bdb2-e6e4-6afc-09679e0ffbfc@oracle.com> References: <3901e53e-bdb2-e6e4-6afc-09679e0ffbfc@oracle.com> Message-ID: <5c2d6de2-449d-cc64-e355-dd8f7c34bacc@oracle.com> Hi Magnus, On 20/01/2017 6:58 PM, Magnus Ihse Bursie wrote: > Over the course of jdk9 development, the variables in the configure > script exported using AC_SUBST, the replacement patterns in spec.gmk.in > and the usage of spec.gmk in the makefiles have diverged. > > Fixes: > > * Remove AC_SUBST for variables not exported or not used in make files. > (BOOT_JDK_BITS, ZERO_ARCHFLAG, ZERO_ARCHDEF, INCLUDE_DTRACE, I'm not sure what purpose the whole --enable-dtrace section serves if we don't export or use INCLUDE_DTRACE ?? Thanks, David > OPENJDK_*_OS_BUNDLE, OPENJDK_*_CPU_BUNDLE, LP64, ENABLE_JFR) > * Include missing exports in spec.gmk.in (JDK_ARCH_ABI_PROP_NAME) > * Make sure we always explicitly use AC_SUBST for exported variables > (PNG_CFLAGS, PNG_LIBS, LCMS_CFLAGS, LCMS_LIBS) > * Only use the pattern AC_SUBST(VARIABLE), to make sure the VARIABLE is > accessible in configure as well as make. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173107 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8173107-fix-spec-gmk-mismatches/webrev.01 > > > /Magnus > From magnus.ihse.bursie at oracle.com Fri Jan 20 10:22:53 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 Jan 2017 11:22:53 +0100 Subject: RFR: JDK-8173107 Fix autoconf/spec.gmk mismatches In-Reply-To: <5c2d6de2-449d-cc64-e355-dd8f7c34bacc@oracle.com> References: <3901e53e-bdb2-e6e4-6afc-09679e0ffbfc@oracle.com> <5c2d6de2-449d-cc64-e355-dd8f7c34bacc@oracle.com> Message-ID: <692fab64-dbec-175f-710c-5656db9628e3@oracle.com> On 2017-01-20 10:30, David Holmes wrote: > Hi Magnus, > > On 20/01/2017 6:58 PM, Magnus Ihse Bursie wrote: >> Over the course of jdk9 development, the variables in the configure >> script exported using AC_SUBST, the replacement patterns in spec.gmk.in >> and the usage of spec.gmk in the makefiles have diverged. >> >> Fixes: >> >> * Remove AC_SUBST for variables not exported or not used in make files. >> (BOOT_JDK_BITS, ZERO_ARCHFLAG, ZERO_ARCHDEF, INCLUDE_DTRACE, > > I'm not sure what purpose the whole --enable-dtrace section serves if > we don't export or use INCLUDE_DTRACE ?? Ah, but we do use INCLUDE_DTRACE, not just in the make files. :-) INCLUDE_DTRACE is a local variable in hotspot.m4, which is used to enable the "dtrace" JVM feature. (The list of JVM features is how we communicate this from autoconf to the makefiles). The AC_SUBST(INCLUDE_DTRACE) should have been removed with the new hotspot build, at the same time as @INCLUDE_DTRACE@ in spec.gmk.in was removed. /Magnus > > Thanks, > David > >> OPENJDK_*_OS_BUNDLE, OPENJDK_*_CPU_BUNDLE, LP64, ENABLE_JFR) >> * Include missing exports in spec.gmk.in (JDK_ARCH_ABI_PROP_NAME) >> * Make sure we always explicitly use AC_SUBST for exported variables >> (PNG_CFLAGS, PNG_LIBS, LCMS_CFLAGS, LCMS_LIBS) >> * Only use the pattern AC_SUBST(VARIABLE), to make sure the VARIABLE is >> accessible in configure as well as make. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173107 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8173107-fix-spec-gmk-mismatches/webrev.01 >> >> >> >> /Magnus >> From magnus.ihse.bursie at oracle.com Fri Jan 20 11:44:33 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 Jan 2017 12:44:33 +0100 Subject: RFR: JDK-8173120 Preserve command line at build failure Message-ID: <88cc192c-30fa-3c33-1396-aa89f288100f@oracle.com> We have decorated most "typical" build command (such as a Java or native compilation) with ExecuteWithLog, which will save the command lines and output logs from all commands. It will also move the log files into an easy-to-find location. The command lines used to produce (or to reproduce) a failing command should also be moved in tandem. Bug: https://bugs.openjdk.java.net/browse/JDK-8173120 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8173120-save-failing-command-line/webrev.01 /Magnus From david.holmes at oracle.com Fri Jan 20 12:47:40 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Jan 2017 22:47:40 +1000 Subject: RFR: JDK-8173107 Fix autoconf/spec.gmk mismatches In-Reply-To: <692fab64-dbec-175f-710c-5656db9628e3@oracle.com> References: <3901e53e-bdb2-e6e4-6afc-09679e0ffbfc@oracle.com> <5c2d6de2-449d-cc64-e355-dd8f7c34bacc@oracle.com> <692fab64-dbec-175f-710c-5656db9628e3@oracle.com> Message-ID: <037b7cc6-95f9-a04f-095c-00b18dbab601@oracle.com> On 20/01/2017 8:22 PM, Magnus Ihse Bursie wrote: > On 2017-01-20 10:30, David Holmes wrote: >> Hi Magnus, >> >> On 20/01/2017 6:58 PM, Magnus Ihse Bursie wrote: >>> Over the course of jdk9 development, the variables in the configure >>> script exported using AC_SUBST, the replacement patterns in spec.gmk.in >>> and the usage of spec.gmk in the makefiles have diverged. >>> >>> Fixes: >>> >>> * Remove AC_SUBST for variables not exported or not used in make files. >>> (BOOT_JDK_BITS, ZERO_ARCHFLAG, ZERO_ARCHDEF, INCLUDE_DTRACE, >> >> I'm not sure what purpose the whole --enable-dtrace section serves if >> we don't export or use INCLUDE_DTRACE ?? > > Ah, but we do use INCLUDE_DTRACE, not just in the make files. :-) > > INCLUDE_DTRACE is a local variable in hotspot.m4, which is used to > enable the "dtrace" JVM feature. (The list of JVM features is how we > communicate this from autoconf to the makefiles). The Ah! Yes I missed that. > AC_SUBST(INCLUDE_DTRACE) should have been removed with the new hotspot > build, at the same time as @INCLUDE_DTRACE@ in spec.gmk.in was removed. Understood. The changes seem okay but the proof here is in the building. Not sure about things that affect s390 and zero for example. Hopefully those folk can chime in on that. Thanks, David > /Magnus > >> >> Thanks, >> David >> >>> OPENJDK_*_OS_BUNDLE, OPENJDK_*_CPU_BUNDLE, LP64, ENABLE_JFR) >>> * Include missing exports in spec.gmk.in (JDK_ARCH_ABI_PROP_NAME) >>> * Make sure we always explicitly use AC_SUBST for exported variables >>> (PNG_CFLAGS, PNG_LIBS, LCMS_CFLAGS, LCMS_LIBS) >>> * Only use the pattern AC_SUBST(VARIABLE), to make sure the VARIABLE is >>> accessible in configure as well as make. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173107 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8173107-fix-spec-gmk-mismatches/webrev.01 >>> >>> >>> >>> /Magnus >>> > From erik.joelsson at oracle.com Fri Jan 20 13:19:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 20 Jan 2017 14:19:48 +0100 Subject: RFR: JDK-8173120 Preserve command line at build failure In-Reply-To: <88cc192c-30fa-3c33-1396-aa89f288100f@oracle.com> References: <88cc192c-30fa-3c33-1396-aa89f288100f@oracle.com> Message-ID: <880a282e-f9f9-c2a6-efe0-644cebfd5dfd@oracle.com> Looks good. /Erik On 2017-01-20 12:44, Magnus Ihse Bursie wrote: > We have decorated most "typical" build command (such as a Java or > native compilation) with ExecuteWithLog, which will save the command > lines and output logs from all commands. It will also move the log > files into an easy-to-find location. > > The command lines used to produce (or to reproduce) a failing command > should also be moved in tandem. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173120 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8173120-save-failing-command-line/webrev.01 > > /Magnus From erik.joelsson at oracle.com Fri Jan 20 13:28:24 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 20 Jan 2017 14:28:24 +0100 Subject: RFR: JDK-8173107 Fix autoconf/spec.gmk mismatches In-Reply-To: <3901e53e-bdb2-e6e4-6afc-09679e0ffbfc@oracle.com> References: <3901e53e-bdb2-e6e4-6afc-09679e0ffbfc@oracle.com> Message-ID: Looks good. /Erik On 2017-01-20 09:58, Magnus Ihse Bursie wrote: > Over the course of jdk9 development, the variables in the configure > script exported using AC_SUBST, the replacement patterns in > spec.gmk.in and the usage of spec.gmk in the makefiles have diverged. > > Fixes: > > * Remove AC_SUBST for variables not exported or not used in make > files. (BOOT_JDK_BITS, ZERO_ARCHFLAG, ZERO_ARCHDEF, INCLUDE_DTRACE, > OPENJDK_*_OS_BUNDLE, OPENJDK_*_CPU_BUNDLE, LP64, ENABLE_JFR) > * Include missing exports in spec.gmk.in (JDK_ARCH_ABI_PROP_NAME) > * Make sure we always explicitly use AC_SUBST for exported variables > (PNG_CFLAGS, PNG_LIBS, LCMS_CFLAGS, LCMS_LIBS) > * Only use the pattern AC_SUBST(VARIABLE), to make sure the VARIABLE > is accessible in configure as well as make. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173107 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8173107-fix-spec-gmk-mismatches/webrev.01 > > /Magnus > From chris.hegarty at oracle.com Fri Jan 20 13:42:13 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 Jan 2017 13:42:13 +0000 Subject: Review request: JDK-8173085 Warning module name in --add-exports not found: jdk.jdeps when compiling for BUILD_JIGSAW_TOOLS In-Reply-To: <9B779595-F02F-4D94-B6C3-E80EA6D24181@oracle.com> References: <9B779595-F02F-4D94-B6C3-E80EA6D24181@oracle.com> Message-ID: <985d5057-b4df-5653-f17f-c350f6fa711a@oracle.com> On 19/01/17 23:37, Mandy Chung wrote: > JDK-8172973 removes the warning emitted at run-time but --add-exports specified at compile-time is not removed. Hence a javac warning is emitted. > > diff --git a/make/CompileModuleTools.gmk b/make/CompileModuleTools.gmk > --- a/make/CompileModuleTools.gmk > +++ b/make/CompileModuleTools.gmk > @@ -37,6 +37,5 @@ > build/tools/jigsaw, \ > BIN := $(TOOLS_CLASSES_DIR), \ > ADD_JAVAC_FLAGS := \ > - --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED \ > --add-exports java.base/jdk.internal.module=ALL-UNNAMED \ > )) Looks good. Thanks Mandy. -Chris. From xueming.shen at oracle.com Fri Jan 20 20:15:30 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 20 Jan 2017 12:15:30 -0800 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 Message-ID: <58826FE2.4050709@oracle.com> Hi, Please review the change to upgrade the zlib bundled in jdk repo from v1.2.8 to v1.2.11. jdk9 by default has been configured to build by using the native/ platform/os's zlib on all non-windows platform [1] So the change will only have effect on the Windows' binaries. issue: https://bugs.openjdk.java.net/browse/JDK-8173140 webrev: http://cr.openjdk.java.net/~sherman/8173140 As always, any source level changes, compared to the official zlib release, other than the copyright notes addition, is logged at http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html most are for removing the compiler warning. Compared ot 1.2.8 the gz* code are removed from the repo. as they are actually not used really by the jdk. (arguably, it appears the version number in directory path zlib-1.2.11 in the repo is not necessary. The make file changes would not be necessary if the path is simply src/java.base/share/native/libzip/zlib) Thanks, Sherman [1] https://bugs.openjdk.java.net/browse/JDK-8031767 From erik.joelsson at oracle.com Sat Jan 21 08:30:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Sat, 21 Jan 2017 09:30:17 +0100 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 In-Reply-To: <58826FE2.4050709@oracle.com> References: <58826FE2.4050709@oracle.com> Message-ID: <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> Hello, Build changes look ok. I'm in favor with dropping the version number from the path. There is a README that clearly states the current version and we don't keep multiple versions in the repo anyway. Doing so would also reduce repo meta data bloat from doing these upgrades in the future (since mercurial will not recognize the relationship between the removed and added files if they aren't in the same place). /Erik On 2017-01-20 21:15, Xueming Shen wrote: > Hi, > > Please review the change to upgrade the zlib bundled in jdk repo from > v1.2.8 > to v1.2.11. jdk9 by default has been configured to build by using the > native/ > platform/os's zlib on all non-windows platform [1] So the change will > only have > effect on the Windows' binaries. > > issue: https://bugs.openjdk.java.net/browse/JDK-8173140 > webrev: http://cr.openjdk.java.net/~sherman/8173140 > > As always, any source level changes, compared to the official zlib > release, other > than the copyright notes addition, is logged at > > http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html > > > most are for removing the compiler warning. Compared ot 1.2.8 the gz* > code > are removed from the repo. as they are actually not used really by the > jdk. > > (arguably, it appears the version number in directory path zlib-1.2.11 > in the > repo is not necessary. The make file changes would not be necessary if > the > path is simply src/java.base/share/native/libzip/zlib) > > Thanks, > Sherman > > [1] https://bugs.openjdk.java.net/browse/JDK-8031767 From thomas.stuefe at gmail.com Sat Jan 21 10:30:18 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 21 Jan 2017 11:30:18 +0100 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 In-Reply-To: <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> References: <58826FE2.4050709@oracle.com> <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> Message-ID: Hi, On Sat, Jan 21, 2017 at 9:30 AM, Erik Joelsson wrote: > Hello, > > Build changes look ok. I'm in favor with dropping the version number from > the path. There is a README that clearly states the current version and we > don't keep multiple versions in the repo anyway. Doing so would also reduce > repo meta data bloat from doing these upgrades in the future (since > mercurial will not recognize the relationship between the removed and added > files if they aren't in the same place). I second that. We also would be able to more easily see the diffs between one zlib version and the other. .Thomas > > > /Erik > > > > On 2017-01-20 21:15, Xueming Shen wrote: > >> Hi, >> >> Please review the change to upgrade the zlib bundled in jdk repo from >> v1.2.8 >> to v1.2.11. jdk9 by default has been configured to build by using the >> native/ >> platform/os's zlib on all non-windows platform [1] So the change will >> only have >> effect on the Windows' binaries. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8173140 >> webrev: http://cr.openjdk.java.net/~sherman/8173140 >> >> As always, any source level changes, compared to the official zlib >> release, other >> than the copyright notes addition, is logged at >> >> http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java. >> base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html >> >> most are for removing the compiler warning. Compared ot 1.2.8 the gz* code >> are removed from the repo. as they are actually not used really by the >> jdk. >> >> (arguably, it appears the version number in directory path zlib-1.2.11 in >> the >> repo is not necessary. The make file changes would not be necessary if the >> path is simply src/java.base/share/native/libzip/zlib) >> >> Thanks, >> Sherman >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8031767 >> > > From Alan.Bateman at oracle.com Sat Jan 21 13:12:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Jan 2017 13:12:04 +0000 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 In-Reply-To: <58826FE2.4050709@oracle.com> References: <58826FE2.4050709@oracle.com> Message-ID: <5becb596-babf-cdb1-d08c-8079182bd1c6@oracle.com> On 20/01/2017 20:15, Xueming Shen wrote: > Hi, > > Please review the change to upgrade the zlib bundled in jdk repo from > v1.2.8 > to v1.2.11. jdk9 by default has been configured to build by using the > native/ > platform/os's zlib on all non-windows platform [1] So the change will > only have > effect on the Windows' binaries. The upgrade looks okay to me. Erik's suggestion to drop the version from the location seems a good idea, that would at least allow us to see the diffs when there are upgrades. -Alan From kumar.x.srinivasan at oracle.com Sat Jan 21 19:10:19 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 21 Jan 2017 11:10:19 -0800 Subject: RFR: 8160881: Remove jvisualvm from JDK9 In-Reply-To: <3057e368-c030-58f5-bf43-56cd2be8e4e0@oracle.com> References: <3057e368-c030-58f5-bf43-56cd2be8e4e0@oracle.com> Message-ID: <5883B21B.1010301@oracle.com> Looks good > On 2017-01-18 18:57, Henry Jen wrote: >> Hi, >> >> Please review the webrev to remove jvisualvm from JDK9. >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8160881/jdk/webrev/ > > Looks good to me. > > /Magnus From xueming.shen at oracle.com Sat Jan 21 20:41:06 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 21 Jan 2017 12:41:06 -0800 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 In-Reply-To: <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> References: <58826FE2.4050709@oracle.com> <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> Message-ID: <5883C762.7060908@oracle.com> Erik, Alan Here is the webrev that dropped the version number from the name. http://cr.openjdk.java.net/~sherman/8173140/webrev Thanks, Sherman On 1/21/17, 12:30 AM, Erik Joelsson wrote: > Hello, > > Build changes look ok. I'm in favor with dropping the version number > from the path. There is a README that clearly states the current > version and we don't keep multiple versions in the repo anyway. Doing > so would also reduce repo meta data bloat from doing these upgrades in > the future (since mercurial will not recognize the relationship > between the removed and added files if they aren't in the same place). > > /Erik > > > On 2017-01-20 21:15, Xueming Shen wrote: >> Hi, >> >> Please review the change to upgrade the zlib bundled in jdk repo from >> v1.2.8 >> to v1.2.11. jdk9 by default has been configured to build by using the >> native/ >> platform/os's zlib on all non-windows platform [1] So the change will >> only have >> effect on the Windows' binaries. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8173140 >> webrev: http://cr.openjdk.java.net/~sherman/8173140 >> >> As always, any source level changes, compared to the official zlib >> release, other >> than the copyright notes addition, is logged at >> >> http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html >> >> >> most are for removing the compiler warning. Compared ot 1.2.8 the gz* >> code >> are removed from the repo. as they are actually not used really by >> the jdk. >> >> (arguably, it appears the version number in directory path >> zlib-1.2.11 in the >> repo is not necessary. The make file changes would not be necessary >> if the >> path is simply src/java.base/share/native/libzip/zlib) >> >> Thanks, >> Sherman >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8031767 > From Alan.Bateman at oracle.com Sun Jan 22 17:46:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 22 Jan 2017 17:46:04 +0000 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 In-Reply-To: <5883C762.7060908@oracle.com> References: <58826FE2.4050709@oracle.com> <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> <5883C762.7060908@oracle.com> Message-ID: On 21/01/2017 20:41, Xueming Shen wrote: > Erik, Alan > > Here is the webrev that dropped the version number from the name. > > http://cr.openjdk.java.net/~sherman/8173140/webrev Switching to zlib looks good although it's impossible to see the changes in this webrev because all the files show up as new. -Alan. From xueming.shen at oracle.com Sun Jan 22 19:27:21 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 22 Jan 2017 11:27:21 -0800 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 In-Reply-To: References: <58826FE2.4050709@oracle.com> <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> <5883C762.7060908@oracle.com> Message-ID: <58850799.5070506@oracle.com> On 1/22/17, 9:46 AM, Alan Bateman wrote: > > > On 21/01/2017 20:41, Xueming Shen wrote: >> Erik, Alan >> >> Here is the webrev that dropped the version number from the name. >> >> http://cr.openjdk.java.net/~sherman/8173140/webrev > Switching to zlib looks good although it's impossible to see the > changes in this webrev because all the files show up as new. > The assumption is the remove of the version tag can help us to easily get the diffs from the webrev directly in future upgrade. Here is the webrev with the diff by listing old and new files in a webrev list file. http://cr.openjdk.java.net/~sherman/8173140/webrev.diff wevrev failed to create the diffs for couple files, I wonder if it is because of the order I did the change (renamed the zlib.1.2.8->zlib first, then applied the file level change in the repo, or applied the file level changes and then rename the dir ) sherman From magnus.ihse.bursie at oracle.com Mon Jan 23 08:13:33 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 23 Jan 2017 09:13:33 +0100 Subject: RFR: JDK-8173107 Fix autoconf/spec.gmk mismatches In-Reply-To: <037b7cc6-95f9-a04f-095c-00b18dbab601@oracle.com> References: <3901e53e-bdb2-e6e4-6afc-09679e0ffbfc@oracle.com> <5c2d6de2-449d-cc64-e355-dd8f7c34bacc@oracle.com> <692fab64-dbec-175f-710c-5656db9628e3@oracle.com> <037b7cc6-95f9-a04f-095c-00b18dbab601@oracle.com> Message-ID: On 2017-01-20 13:47, David Holmes wrote: > On 20/01/2017 8:22 PM, Magnus Ihse Bursie wrote: >> On 2017-01-20 10:30, David Holmes wrote: >>> Hi Magnus, >>> >>> On 20/01/2017 6:58 PM, Magnus Ihse Bursie wrote: >>>> Over the course of jdk9 development, the variables in the configure >>>> script exported using AC_SUBST, the replacement patterns in >>>> spec.gmk.in >>>> and the usage of spec.gmk in the makefiles have diverged. >>>> >>>> Fixes: >>>> >>>> * Remove AC_SUBST for variables not exported or not used in make >>>> files. >>>> (BOOT_JDK_BITS, ZERO_ARCHFLAG, ZERO_ARCHDEF, INCLUDE_DTRACE, >>> >>> I'm not sure what purpose the whole --enable-dtrace section serves if >>> we don't export or use INCLUDE_DTRACE ?? >> >> Ah, but we do use INCLUDE_DTRACE, not just in the make files. :-) >> >> INCLUDE_DTRACE is a local variable in hotspot.m4, which is used to >> enable the "dtrace" JVM feature. (The list of JVM features is how we >> communicate this from autoconf to the makefiles). The > > Ah! Yes I missed that. > >> AC_SUBST(INCLUDE_DTRACE) should have been removed with the new hotspot >> build, at the same time as @INCLUDE_DTRACE@ in spec.gmk.in was removed. > > Understood. > > The changes seem okay but the proof here is in the building. Not sure > about things that affect s390 and zero for example. Hopefully those > folk can chime in on that. I just removed dead code. If that piece of code was needed, it has been broken for half a year or more. (And if it is needed, it just can't be re-enabled but needs to fit in the new hotspot build). /Magnus > > Thanks, > David > >> /Magnus >> >>> >>> Thanks, >>> David >>> >>>> OPENJDK_*_OS_BUNDLE, OPENJDK_*_CPU_BUNDLE, LP64, ENABLE_JFR) >>>> * Include missing exports in spec.gmk.in (JDK_ARCH_ABI_PROP_NAME) >>>> * Make sure we always explicitly use AC_SUBST for exported variables >>>> (PNG_CFLAGS, PNG_LIBS, LCMS_CFLAGS, LCMS_LIBS) >>>> * Only use the pattern AC_SUBST(VARIABLE), to make sure the >>>> VARIABLE is >>>> accessible in configure as well as make. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173107 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8173107-fix-spec-gmk-mismatches/webrev.01 >>>> >>>> >>>> >>>> >>>> /Magnus >>>> >> From erik.joelsson at oracle.com Mon Jan 23 08:14:56 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Jan 2017 09:14:56 +0100 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 In-Reply-To: <5883C762.7060908@oracle.com> References: <58826FE2.4050709@oracle.com> <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> <5883C762.7060908@oracle.com> Message-ID: Build changes look good. Thanks! /Erik On 2017-01-21 21:41, Xueming Shen wrote: > Erik, Alan > > Here is the webrev that dropped the version number from the name. > > http://cr.openjdk.java.net/~sherman/8173140/webrev > > Thanks, > Sherman > > On 1/21/17, 12:30 AM, Erik Joelsson wrote: >> Hello, >> >> Build changes look ok. I'm in favor with dropping the version number >> from the path. There is a README that clearly states the current >> version and we don't keep multiple versions in the repo anyway. Doing >> so would also reduce repo meta data bloat from doing these upgrades >> in the future (since mercurial will not recognize the relationship >> between the removed and added files if they aren't in the same place). >> >> /Erik >> >> >> On 2017-01-20 21:15, Xueming Shen wrote: >>> Hi, >>> >>> Please review the change to upgrade the zlib bundled in jdk repo >>> from v1.2.8 >>> to v1.2.11. jdk9 by default has been configured to build by using >>> the native/ >>> platform/os's zlib on all non-windows platform [1] So the change >>> will only have >>> effect on the Windows' binaries. >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8173140 >>> webrev: http://cr.openjdk.java.net/~sherman/8173140 >>> >>> As always, any source level changes, compared to the official zlib >>> release, other >>> than the copyright notes addition, is logged at >>> >>> http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html >>> >>> >>> most are for removing the compiler warning. Compared ot 1.2.8 the >>> gz* code >>> are removed from the repo. as they are actually not used really by >>> the jdk. >>> >>> (arguably, it appears the version number in directory path >>> zlib-1.2.11 in the >>> repo is not necessary. The make file changes would not be necessary >>> if the >>> path is simply src/java.base/share/native/libzip/zlib) >>> >>> Thanks, >>> Sherman >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8031767 >> > From Alan.Bateman at oracle.com Mon Jan 23 09:10:00 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Jan 2017 09:10:00 +0000 Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11 In-Reply-To: <58850799.5070506@oracle.com> References: <58826FE2.4050709@oracle.com> <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com> <5883C762.7060908@oracle.com> <58850799.5070506@oracle.com> Message-ID: <6bfbc784-fc96-c635-9e83-098dd5c1e438@oracle.com> On 22/01/2017 19:27, Xueming Shen wrote: > The assumption is the remove of the version tag can help us to easily > get the > diffs from the webrev directly in future upgrade. > > Here is the webrev with the diff by listing old and new files in a > webrev list file. > > http://cr.openjdk.java.net/~sherman/8173140/webrev.diff > > wevrev failed to create the diffs for couple files, I wonder if it is > because of the > order I did the change (renamed the zlib.1.2.8->zlib first, then > applied the file level > change in the repo, or applied the file level changes and then rename > the dir ) It might be although I haven't had problems with renames + edits like this. Anyway, the changes in the webrev look okay and for the next update then it should be a lot easier to see the changes. -Alan From mikeb at mycosystems.co.uk Mon Jan 23 10:34:10 2017 From: mikeb at mycosystems.co.uk (Mike Burton) Date: Mon, 23 Jan 2017 10:34:10 +0000 Subject: configure - gcc >4.6 needed for JDK9 build Message-ID: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> Hello, I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? Best Regards Mike Burton From chris.hegarty at oracle.com Tue Jan 24 14:08:20 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 Jan 2017 14:08:20 +0000 Subject: RFR [9] Warning notice for types in Incubator Modules Message-ID: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> As per the guidance in JEP 11 [1], the javadoc for types in incubator modules should have a clear and explicit warning notice. To that end, I?ve added a simple inline taglet that can be used to effectively inject a standard notice, and applied it to all public types in the HTTP module ( I?ll cleanup the line width formatting before pushing ). http://cr.openjdk.java.net/~chegar/incubator_taglet/ -Chris. P.S. this work is, somewhat, in preparation for when we move to a single documentation bundle [2]. [1] http://openjdk.java.net/jeps/11 [2] http://openjdk.java.net/jeps/299 From erik.joelsson at oracle.com Tue Jan 24 16:44:52 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Jan 2017 17:44:52 +0100 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> Message-ID: Hello, Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. /Erik On 2017-01-24 15:08, Chris Hegarty wrote: > As per the guidance in JEP 11 [1], the javadoc for types in > incubator modules should have a clear and explicit warning > notice. To that end, I?ve added a simple inline taglet that can > be used to effectively inject a standard notice, and applied it > to all public types in the HTTP module ( I?ll cleanup the line > width formatting before pushing ). > > http://cr.openjdk.java.net/~chegar/incubator_taglet/ > > -Chris. > > P.S. this work is, somewhat, in preparation for when we move > to a single documentation bundle [2]. > > [1] http://openjdk.java.net/jeps/11 > [2] http://openjdk.java.net/jeps/299 From michael.x.mcmahon at oracle.com Tue Jan 24 17:45:33 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Jan 2017 17:45:33 +0000 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> Message-ID: Hi Chris As regards the networking changes, they look fine to me. As discussed off list, I think the link generated by the @Incubating tag might possibly point to a new page in the docs bundle rather than directly to the JEP 11 page. But, that can be the subject of another change. Thanks, Michael. On 24/01/17 14:08, Chris Hegarty wrote: > As per the guidance in JEP 11 [1], the javadoc for types in > incubator modules should have a clear and explicit warning > notice. To that end, I?ve added a simple inline taglet that can > be used to effectively inject a standard notice, and applied it > to all public types in the HTTP module ( I?ll cleanup the line > width formatting before pushing ). > > http://cr.openjdk.java.net/~chegar/incubator_taglet/ > > -Chris. > > P.S. this work is, somewhat, in preparation for when we move > to a single documentation bundle [2]. > > [1] http://openjdk.java.net/jeps/11 > [2] http://openjdk.java.net/jeps/299 From kim.barrett at oracle.com Tue Jan 24 21:25:21 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 24 Jan 2017 16:25:21 -0500 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> Message-ID: <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> > On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: > > Hello, > > I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. > Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? > > Best Regards > > Mike Burton I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty sure there are folks still building with older versions. It would be helpful to know the details of the platform and the error messages that led to the conclusion that something more recent was required. From david.holmes at oracle.com Wed Jan 25 00:34:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Jan 2017 10:34:26 +1000 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> Message-ID: <4f47df83-160d-ef6c-f7fb-9dbc4df3f4fb@oracle.com> Hi Kim, On 25/01/2017 7:25 AM, Kim Barrett wrote: >> On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: >> >> Hello, >> >> I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. >> Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? >> >> Best Regards >> >> Mike Burton > > I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty > sure there are folks still building with older versions. It would be helpful to know the > details of the platform and the error messages that led to the conclusion that something > more recent was required. We may have "accidentally" moved on to gcc 4.8+. Even the ppc builds, which are still listed as using 4.1.2 on the wiki: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms are now using 4.8.5: http://cr.openjdk.java.net/~simonis/ppc-aix-port/ (look at a build log) So some breakage with earlier versions may have crept in. I thought I recalled a few issues but can't see any bug reports. David From mikeb at mycosystems.co.uk Wed Jan 25 08:34:25 2017 From: mikeb at mycosystems.co.uk (Mike Burton) Date: Wed, 25 Jan 2017 08:34:25 +0000 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> Message-ID: >> On 24 Jan 2017, at 21:25, Kim Barrett wrote: >> >> On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: >> >> Hello, >> >> I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. >> Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? >> >> Best Regards >> >> Mike Burton > > I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty > sure there are folks still building with older versions. It would be helpful to know the > details of the platform and the error messages that led to the conclusion that something > more recent was required. Platform is Ubuntu 14.04, error message below: === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status === End of repeated output === From chris.hegarty at oracle.com Wed Jan 25 12:51:16 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 Jan 2017 12:51:16 +0000 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> Message-ID: <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> > On 24 Jan 2017, at 16:44, Erik Joelsson wrote: > > Hello, > > Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. Updated in place http://cr.openjdk.java.net/~chegar/incubator_taglet/ -Chris. > /Erik > > > On 2017-01-24 15:08, Chris Hegarty wrote: >> As per the guidance in JEP 11 [1], the javadoc for types in >> incubator modules should have a clear and explicit warning >> notice. To that end, I?ve added a simple inline taglet that can >> be used to effectively inject a standard notice, and applied it >> to all public types in the HTTP module ( I?ll cleanup the line >> width formatting before pushing ). >> >> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >> >> -Chris. >> >> P.S. this work is, somewhat, in preparation for when we move >> to a single documentation bundle [2]. >> >> [1] http://openjdk.java.net/jeps/11 >> [2] http://openjdk.java.net/jeps/299 > From erik.joelsson at oracle.com Wed Jan 25 13:39:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 25 Jan 2017 14:39:48 +0100 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> Message-ID: <09f550c4-87e5-0129-229e-a312b7af90f9@oracle.com> Thanks, looks good now. /Erik On 2017-01-25 13:51, Chris Hegarty wrote: >> On 24 Jan 2017, at 16:44, Erik Joelsson wrote: >> >> Hello, >> >> Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. > Updated in place > http://cr.openjdk.java.net/~chegar/incubator_taglet/ > > -Chris. > >> /Erik >> >> >> On 2017-01-24 15:08, Chris Hegarty wrote: >>> As per the guidance in JEP 11 [1], the javadoc for types in >>> incubator modules should have a clear and explicit warning >>> notice. To that end, I?ve added a simple inline taglet that can >>> be used to effectively inject a standard notice, and applied it >>> to all public types in the HTTP module ( I?ll cleanup the line >>> width formatting before pushing ). >>> >>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>> >>> -Chris. >>> >>> P.S. this work is, somewhat, in preparation for when we move >>> to a single documentation bundle [2]. >>> >>> [1] http://openjdk.java.net/jeps/11 >>> [2] http://openjdk.java.net/jeps/299 From kim.barrett at oracle.com Wed Jan 25 19:13:52 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 25 Jan 2017 14:13:52 -0500 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: <4f47df83-160d-ef6c-f7fb-9dbc4df3f4fb@oracle.com> References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> <4f47df83-160d-ef6c-f7fb-9dbc4df3f4fb@oracle.com> Message-ID: > On Jan 24, 2017, at 7:34 PM, David Holmes wrote: > > Hi Kim, > > On 25/01/2017 7:25 AM, Kim Barrett wrote: >>> On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: >>> >>> Hello, >>> >>> I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. >>> Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? >>> >>> Best Regards >>> >>> Mike Burton >> >> I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty >> sure there are folks still building with older versions. It would be helpful to know the >> details of the platform and the error messages that led to the conclusion that something >> more recent was required. > > We may have "accidentally" moved on to gcc 4.8+. Even the ppc builds, which are still listed as using 4.1.2 on the wiki: > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > are now using 4.8.5: > > http://cr.openjdk.java.net/~simonis/ppc-aix-port/ (look at a build log) > > So some breakage with earlier versions may have crept in. I thought I recalled a few issues but can't see any bug reports. The PPC build from SAP was the one I was thinking of as still being around. And it does seem they?ve moved on too, which is useful to know. So yes, entirely possible something crept in if there isn?t frequent testing. From kim.barrett at oracle.com Wed Jan 25 21:53:26 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 25 Jan 2017 16:53:26 -0500 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> Message-ID: <2F01B031-EDA0-4C0C-8664-A38BD97370CE@oracle.com> > On Jan 25, 2017, at 3:34 AM, Mike Burton wrote: > > Platform is Ubuntu 14.04, error message below: > > === Output from failing command(s) repeated here === > * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > === End of repeated output === Thanks for the info. https://bugs.openjdk.java.net/browse/JDK-8173375 From joe.darcy at oracle.com Thu Jan 26 02:03:51 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 25 Jan 2017 18:03:51 -0800 Subject: JDK 10 RFR of JDK-8173383: Update JDK build to use -source and -target 10 Message-ID: <58895907.5070300@oracle.com> Hello, With the opening of the JDK 10 forests, the build should be updated to use the new source and target options (JDK-8028546: Add -source 10 and -target 10 to javac) Please review the changes for JDK-8173383: Update JDK build to use -source and -target 10 http://cr.openjdk.java.net/~darcy/8173383.0/ Patch below. Thanks, -Joe --- old/make/common/SetupJavaCompilers.gmk 2017-01-25 18:02:28.935118958 -0800 +++ new/make/common/SetupJavaCompilers.gmk 2017-01-25 18:02:28.843118954 -0800 @@ -69,7 +69,7 @@ $(eval $(call SetupJavaCompiler,GENERATE_JDKBYTECODE, \ JVM := $(JAVA_JAVAC), \ JAVAC := $(NEW_JAVAC), \ - FLAGS := -source 9 -target 9 \ + FLAGS := -source 10 -target 10 \ -encoding ascii -XDignore.symbol.file=true $(JAVAC_WARNINGS), \ SERVER_DIR := $(SJAVAC_SERVER_DIR), \ SERVER_JVM := $(SJAVAC_SERVER_JAVA))) @@ -79,7 +79,7 @@ $(eval $(call SetupJavaCompiler,GENERATE_JDKBYTECODE_NOWARNINGS, \ JVM := $(JAVA_JAVAC), \ JAVAC := $(NEW_JAVAC), \ - FLAGS := -source 9 -target 9 \ + FLAGS := -source 10 -target 10 \ -encoding ascii -XDignore.symbol.file=true $(DISABLE_WARNINGS), \ SERVER_DIR := $(SJAVAC_SERVER_DIR), \ SERVER_JVM := $(SJAVAC_SERVER_JAVA))) From david.holmes at oracle.com Thu Jan 26 04:07:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Jan 2017 14:07:03 +1000 Subject: JDK 10 RFR of JDK-8173383: Update JDK build to use -source and -target 10 In-Reply-To: <58895907.5070300@oracle.com> References: <58895907.5070300@oracle.com> Message-ID: <838643b1-b63c-2062-640d-70e198980657@oracle.com> Hi Joe, Changes look okay. So does javac already handle arbitrary source/target values? We need the usual set of "new release" updates to change JDK version as well. Where does that hide these days ?? And do we also need to update the boot JDK to be JDK 9? What else is needed for a new release to start? We really should have all this captured in a single bug report. Also wondering if JPRT will need any updates ... Thanks, David On 26/01/2017 12:03 PM, Joseph D. Darcy wrote: > Hello, > > With the opening of the JDK 10 forests, the build should be updated to > use the new source and target options (JDK-8028546: > Add -source 10 and -target 10 to javac) > > Please review the changes for > > JDK-8173383: Update JDK build to use -source and -target 10 > http://cr.openjdk.java.net/~darcy/8173383.0/ > > Patch below. > > Thanks, > > -Joe > > --- old/make/common/SetupJavaCompilers.gmk 2017-01-25 > 18:02:28.935118958 -0800 > +++ new/make/common/SetupJavaCompilers.gmk 2017-01-25 > 18:02:28.843118954 -0800 > @@ -69,7 +69,7 @@ > $(eval $(call SetupJavaCompiler,GENERATE_JDKBYTECODE, \ > JVM := $(JAVA_JAVAC), \ > JAVAC := $(NEW_JAVAC), \ > - FLAGS := -source 9 -target 9 \ > + FLAGS := -source 10 -target 10 \ > -encoding ascii -XDignore.symbol.file=true $(JAVAC_WARNINGS), \ > SERVER_DIR := $(SJAVAC_SERVER_DIR), \ > SERVER_JVM := $(SJAVAC_SERVER_JAVA))) > @@ -79,7 +79,7 @@ > $(eval $(call SetupJavaCompiler,GENERATE_JDKBYTECODE_NOWARNINGS, \ > JVM := $(JAVA_JAVAC), \ > JAVAC := $(NEW_JAVAC), \ > - FLAGS := -source 9 -target 9 \ > + FLAGS := -source 10 -target 10 \ > -encoding ascii -XDignore.symbol.file=true $(DISABLE_WARNINGS), \ > SERVER_DIR := $(SJAVAC_SERVER_DIR), \ > SERVER_JVM := $(SJAVAC_SERVER_JAVA))) > From joe.darcy at oracle.com Thu Jan 26 05:36:38 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 Jan 2017 21:36:38 -0800 Subject: JDK 10 RFR of JDK-8173383: Update JDK build to use -source and -target 10 In-Reply-To: <838643b1-b63c-2062-640d-70e198980657@oracle.com> References: <58895907.5070300@oracle.com> <838643b1-b63c-2062-640d-70e198980657@oracle.com> Message-ID: <779d7adf-999b-459c-4f09-df8cb88c88a9@oracle.com> Hi David, On 1/25/2017 8:07 PM, David Holmes wrote: > Hi Joe, > > Changes look okay. So does javac already handle arbitrary > source/target values? I'm working on the changeset for that. I need to make sure all the langtools tests pass before getting it out for review. > > We need the usual set of "new release" updates to change JDK version > as well. Where does that hide these days ?? At the start of JDK 9, I filed a number of bugs against JDK 10 and tagged them "jdk10-b01" but it is not an exhaustive list. I've started filing and tagging bug for "jdk11-b01". > > And do we also need to update the boot JDK to be JDK 9? Certainly at some point. A good number of refactorings need to wait until the boot JDK is upgraded. On the other hand, there is an argument for JDK 9 being a bit further along before using it for bootstrapping. > > What else is needed for a new release to start? We really should have > all this captured in a single bug report. > > Also wondering if JPRT will need any updates ... Some pieces of the infrastructure will likely need some updates... Thanks, -Joe > > Thanks, > David > > > On 26/01/2017 12:03 PM, Joseph D. Darcy wrote: >> Hello, >> >> With the opening of the JDK 10 forests, the build should be updated to >> use the new source and target options (JDK-8028546: >> Add -source 10 and -target 10 to javac) >> >> Please review the changes for >> >> JDK-8173383: Update JDK build to use -source and -target 10 >> http://cr.openjdk.java.net/~darcy/8173383.0/ >> >> Patch below. >> >> Thanks, >> >> -Joe >> >> --- old/make/common/SetupJavaCompilers.gmk 2017-01-25 >> 18:02:28.935118958 -0800 >> +++ new/make/common/SetupJavaCompilers.gmk 2017-01-25 >> 18:02:28.843118954 -0800 >> @@ -69,7 +69,7 @@ >> $(eval $(call SetupJavaCompiler,GENERATE_JDKBYTECODE, \ >> JVM := $(JAVA_JAVAC), \ >> JAVAC := $(NEW_JAVAC), \ >> - FLAGS := -source 9 -target 9 \ >> + FLAGS := -source 10 -target 10 \ >> -encoding ascii -XDignore.symbol.file=true $(JAVAC_WARNINGS), \ >> SERVER_DIR := $(SJAVAC_SERVER_DIR), \ >> SERVER_JVM := $(SJAVAC_SERVER_JAVA))) >> @@ -79,7 +79,7 @@ >> $(eval $(call SetupJavaCompiler,GENERATE_JDKBYTECODE_NOWARNINGS, \ >> JVM := $(JAVA_JAVAC), \ >> JAVAC := $(NEW_JAVAC), \ >> - FLAGS := -source 9 -target 9 \ >> + FLAGS := -source 10 -target 10 \ >> -encoding ascii -XDignore.symbol.file=true >> $(DISABLE_WARNINGS), \ >> SERVER_DIR := $(SJAVAC_SERVER_DIR), \ >> SERVER_JVM := $(SJAVAC_SERVER_JAVA))) >> From philip.race at oracle.com Thu Jan 26 05:43:00 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 25 Jan 2017 21:43:00 -0800 Subject: JDK 10 RFR of JDK-8173383: Update JDK build to use -source and -target 10 In-Reply-To: <779d7adf-999b-459c-4f09-df8cb88c88a9@oracle.com> References: <58895907.5070300@oracle.com> <838643b1-b63c-2062-640d-70e198980657@oracle.com> <779d7adf-999b-459c-4f09-df8cb88c88a9@oracle.com> Message-ID: <58898C64.9070803@oracle.com> I think that this has always waited until *at least* that previous JDK is GA. If you think about it there isn't really any such thing as JDK 9 (or at least Java SE 9) until then so it has to be so. Thus ask this again in August. -phil. On 1/25/17, 9:36 PM, joe darcy wrote: >> >> And do we also need to update the boot JDK to be JDK 9? > > Certainly at some point. A good number of refactorings need to wait > until the boot JDK is upgraded. On the other hand, there is an > argument for JDK 9 being a bit further along before using it for > bootstrapping. From magnus.ihse.bursie at oracle.com Thu Jan 26 11:45:36 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Jan 2017 12:45:36 +0100 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> Message-ID: <5e20457b-8b10-7b45-a3bc-f6b9b1a57502@oracle.com> On 2017-01-25 13:51, Chris Hegarty wrote: >> On 24 Jan 2017, at 16:44, Erik Joelsson wrote: >> >> Hello, >> >> Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. > Updated in place > http://cr.openjdk.java.net/~chegar/incubator_taglet/ It's not ideal that a top-level target has dependencies from the JDK repo, but since we have no or few pre-existing top-level tools, I understand if you hesitate to add a new framework for such tools. If we ever do introduce more such tools, I think we should move this along. I think the new -taglet options to the DEFAULT_JAVADOC_OPTIONS variable. As the documentation says, the DEFAULT_JAVADOC_TAGS is there to specify the ordering of tags in the output. Unless the -taglet options implicitly generates one or more -tag options in it's place, that's the wrong place to put it. If it does, perhaps a comment indicating this hidden behavior would be in place. In the line: "$$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) $$($1_PACKAGE_DEPS) $$($1_DEPS)", please use a double $ ($$) for all variables. While technically not necessary in this particular case, it's misleading and we've had our share of bugs due to single $ in eval'd macros. In the line: "docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS)", please remove the reference to BUILD_TOOLS_JDK. It is not needed. /Magnus > > -Chris. > >> /Erik >> >> >> On 2017-01-24 15:08, Chris Hegarty wrote: >>> As per the guidance in JEP 11 [1], the javadoc for types in >>> incubator modules should have a clear and explicit warning >>> notice. To that end, I?ve added a simple inline taglet that can >>> be used to effectively inject a standard notice, and applied it >>> to all public types in the HTTP module ( I?ll cleanup the line >>> width formatting before pushing ). >>> >>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>> >>> -Chris. >>> >>> P.S. this work is, somewhat, in preparation for when we move >>> to a single documentation bundle [2]. >>> >>> [1] http://openjdk.java.net/jeps/11 >>> [2] http://openjdk.java.net/jeps/299 From magnus.ihse.bursie at oracle.com Thu Jan 26 13:54:18 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Jan 2017 14:54:18 +0100 Subject: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp Message-ID: When fixing JDK-8081616 , it turned out that DISABLED_WARNINGS_gcc := unused-parameter seemed to be needed for libsctp in make/lib/Lib-jdk.sctp.gmk. This is not be needed anymore (and possibly never was). Bug: https://bugs.openjdk.java.net/browse/JDK-8081694 Patch inline: diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk --- a/make/lib/Lib-jdk.sctp.gmk +++ b/make/lib/Lib-jdk.sctp.gmk @@ -45,7 +45,6 @@ $(LIBJAVA_HEADER_FLAGS) \ -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ - DISABLED_WARNINGS_gcc := unused-parameter, \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ From erik.joelsson at oracle.com Thu Jan 26 13:56:41 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Jan 2017 14:56:41 +0100 Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10 Message-ID: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> The default major version for the jdk 10 repos needs to be updated from 9 to 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8029942 Patch: diff -r 07f6f1f4140e common/autoconf/version-numbers --- a/common/autoconf/version-numbers +++ b/common/autoconf/version-numbers @@ -25,7 +25,7 @@ # Default version numbers to use unless overridden by configure -DEFAULT_VERSION_MAJOR=9 +DEFAULT_VERSION_MAJOR=10 DEFAULT_VERSION_MINOR=0 DEFAULT_VERSION_SECURITY=0 DEFAULT_VERSION_PATCH=0 /Erik From erik.joelsson at oracle.com Thu Jan 26 13:57:44 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Jan 2017 14:57:44 +0100 Subject: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp In-Reply-To: References: Message-ID: <9eb56f3b-ad12-c179-3026-dde0031e8e31@oracle.com> Looks good. /Erik On 2017-01-26 14:54, Magnus Ihse Bursie wrote: > When fixing JDK-8081616 > , it turned out that > DISABLED_WARNINGS_gcc := unused-parameter > seemed to be needed for libsctp in make/lib/Lib-jdk.sctp.gmk. > > This is not be needed anymore (and possibly never was). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081694 > Patch inline: > diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk > --- a/make/lib/Lib-jdk.sctp.gmk > +++ b/make/lib/Lib-jdk.sctp.gmk > @@ -45,7 +45,6 @@ > $(LIBJAVA_HEADER_FLAGS) \ > -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ > -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ > - DISABLED_WARNINGS_gcc := unused-parameter, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > From philip.race at oracle.com Thu Jan 26 13:58:51 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 26 Jan 2017 05:58:51 -0800 Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10 In-Reply-To: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> References: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> Message-ID: <588A009B.9070905@oracle.com> +1 -phil. On 1/26/17, 5:56 AM, Erik Joelsson wrote: > The default major version for the jdk 10 repos needs to be updated > from 9 to 10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029942 > > Patch: > > diff -r 07f6f1f4140e common/autoconf/version-numbers > --- a/common/autoconf/version-numbers > +++ b/common/autoconf/version-numbers > @@ -25,7 +25,7 @@ > > # Default version numbers to use unless overridden by configure > > -DEFAULT_VERSION_MAJOR=9 > +DEFAULT_VERSION_MAJOR=10 > DEFAULT_VERSION_MINOR=0 > DEFAULT_VERSION_SECURITY=0 > DEFAULT_VERSION_PATCH=0 > > > /Erik > From chris.hegarty at oracle.com Thu Jan 26 14:28:34 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Jan 2017 14:28:34 +0000 Subject: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp In-Reply-To: References: Message-ID: <70B7CBFC-30D5-4E2E-9FE7-C64D08C47711@oracle.com> I?m not sure of the latest status of warnings in the build, but just to say, libstcp was always built with 0 warnings being emitted ( the JNI code has unused this/class parameters that cannot be removed ). If you remove this suppression won?t the compilation of code from libsctp now produce a warning for these cannot-be-removed unused parameters? Misleading development engineers trying to clean up warnings. -Chris. > On 26 Jan 2017, at 13:54, Magnus Ihse Bursie wrote: > > When fixing JDK-8081616 , it turned out that > DISABLED_WARNINGS_gcc := unused-parameter > seemed to be needed for libsctp in make/lib/Lib-jdk.sctp.gmk. > > This is not be needed anymore (and possibly never was). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081694 > Patch inline: > diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk > --- a/make/lib/Lib-jdk.sctp.gmk > +++ b/make/lib/Lib-jdk.sctp.gmk > @@ -45,7 +45,6 @@ > $(LIBJAVA_HEADER_FLAGS) \ > -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ > -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ > - DISABLED_WARNINGS_gcc := unused-parameter, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > From erik.joelsson at oracle.com Thu Jan 26 14:36:16 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Jan 2017 15:36:16 +0100 Subject: RFR: JDK-8170483: Remove modules_src_jake workaround for JavaFX transition to new module-info syntax Message-ID: <91239e9f-1f82-c352-43a4-148d6e6cd5c6@oracle.com> When the last jake->jdk9 push was done, a temporary workaround for dealing with Javafx was needed. Javafx has now been fully updated to only deliver the new format so the workaround should be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8170483 Webrev: http://cr.openjdk.java.net/~erikj/8170483/webrev.01/ /Erik From Alan.Bateman at oracle.com Thu Jan 26 14:38:00 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Jan 2017 14:38:00 +0000 Subject: RFR: JDK-8170483: Remove modules_src_jake workaround for JavaFX transition to new module-info syntax In-Reply-To: <91239e9f-1f82-c352-43a4-148d6e6cd5c6@oracle.com> References: <91239e9f-1f82-c352-43a4-148d6e6cd5c6@oracle.com> Message-ID: On 26/01/2017 14:36, Erik Joelsson wrote: > When the last jake->jdk9 push was done, a temporary workaround for > dealing with Javafx was needed. Javafx has now been fully updated to > only deliver the new format so the workaround should be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170483 > > Webrev: http://cr.openjdk.java.net/~erikj/8170483/webrev.01/ This looks okay to me. -Alan From magnus.ihse.bursie at oracle.com Thu Jan 26 15:36:40 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Jan 2017 16:36:40 +0100 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> Message-ID: <15D918DE-524D-414F-8AAD-2498CEE24430@oracle.com> This is an issue with gtest, which is a bit special. If you use --disable-gtest with configure, can you build successfully then? /Magnus > 25 jan. 2017 kl. 09:34 skrev Mike Burton : > > >>> On 24 Jan 2017, at 21:25, Kim Barrett wrote: >>> >>> On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: >>> >>> Hello, >>> >>> I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. >>> Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? >>> >>> Best Regards >>> >>> Mike Burton >> >> I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty >> sure there are folks still building with older versions. It would be helpful to know the >> details of the platform and the error messages that led to the conclusion that something >> more recent was required. > > Platform is Ubuntu 14.04, error message below: > > === Output from failing command(s) repeated here === > * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > === End of repeated output === > > From mikeb at mycosystems.co.uk Thu Jan 26 15:55:52 2017 From: mikeb at mycosystems.co.uk (Mike Burton) Date: Thu, 26 Jan 2017 15:55:52 +0000 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: <15D918DE-524D-414F-8AAD-2498CEE24430@oracle.com> References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> <15D918DE-524D-414F-8AAD-2498CEE24430@oracle.com> Message-ID: <14DC6D63-54AD-4E64-8C90-E5984C785327@mycosystems.co.uk> When I do `bash configure ?disable-gtest` it errors with: unrecognised options: ?disable-gtest Mike > On 26 Jan 2017, at 15:36, Magnus Ihse Bursie wrote: > > This is an issue with gtest, which is a bit special. > > If you use --disable-gtest with configure, can you build successfully then? > > /Magnus > >> 25 jan. 2017 kl. 09:34 skrev Mike Burton : >> >> >>>> On 24 Jan 2017, at 21:25, Kim Barrett wrote: >>>> >>>> On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: >>>> >>>> Hello, >>>> >>>> I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. >>>> Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? >>>> >>>> Best Regards >>>> >>>> Mike Burton >>> >>> I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty >>> sure there are folks still building with older versions. It would be helpful to know the >>> details of the platform and the error messages that led to the conclusion that something >>> more recent was required. >> >> Platform is Ubuntu 14.04, error message below: >> >> === Output from failing command(s) repeated here === >> * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: >> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC >> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value >> collect2: ld returned 1 exit status >> === End of repeated output === >> >> > From erik.joelsson at oracle.com Thu Jan 26 16:00:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Jan 2017 17:00:13 +0100 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: <14DC6D63-54AD-4E64-8C90-E5984C785327@mycosystems.co.uk> References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> <15D918DE-524D-414F-8AAD-2498CEE24430@oracle.com> <14DC6D63-54AD-4E64-8C90-E5984C785327@mycosystems.co.uk> Message-ID: <707ccdab-7f4c-1a07-d31f-ef9b98c5e085@oracle.com> The option is --disable-hotspot-gtest. /Erik On 2017-01-26 16:55, Mike Burton wrote: > When I do `bash configure ?disable-gtest` it errors with: > unrecognised options: ?disable-gtest > > Mike > > >> On 26 Jan 2017, at 15:36, Magnus Ihse Bursie wrote: >> >> This is an issue with gtest, which is a bit special. >> >> If you use --disable-gtest with configure, can you build successfully then? >> >> /Magnus >> >>> 25 jan. 2017 kl. 09:34 skrev Mike Burton : >>> >>> >>>>> On 24 Jan 2017, at 21:25, Kim Barrett wrote: >>>>> >>>>> On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: >>>>> >>>>> Hello, >>>>> >>>>> I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. >>>>> Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? >>>>> >>>>> Best Regards >>>>> >>>>> Mike Burton >>>> I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty >>>> sure there are folks still building with older versions. It would be helpful to know the >>>> details of the platform and the error messages that led to the conclusion that something >>>> more recent was required. >>> Platform is Ubuntu 14.04, error message below: >>> >>> === Output from failing command(s) repeated here === >>> * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: >>> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC >>> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value >>> collect2: ld returned 1 exit status >>> === End of repeated output === >>> >>> From iris.clark at oracle.com Thu Jan 26 17:11:28 2017 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 26 Jan 2017 09:11:28 -0800 (PST) Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10 In-Reply-To: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> References: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> Message-ID: Hi, Erik. Your change looks good. Thanks, iris -----Original Message----- From: Erik Joelsson Sent: Thursday, January 26, 2017 5:57 AM To: build-dev Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10 The default major version for the jdk 10 repos needs to be updated from 9 to 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8029942 Patch: diff -r 07f6f1f4140e common/autoconf/version-numbers --- a/common/autoconf/version-numbers +++ b/common/autoconf/version-numbers @@ -25,7 +25,7 @@ # Default version numbers to use unless overridden by configure -DEFAULT_VERSION_MAJOR=9 +DEFAULT_VERSION_MAJOR=10 DEFAULT_VERSION_MINOR=0 DEFAULT_VERSION_SECURITY=0 DEFAULT_VERSION_PATCH=0 /Erik From mikeb at mycosystems.co.uk Thu Jan 26 17:33:22 2017 From: mikeb at mycosystems.co.uk (Mike Burton) Date: Thu, 26 Jan 2017 17:33:22 +0000 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: <707ccdab-7f4c-1a07-d31f-ef9b98c5e085@oracle.com> References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> <15D918DE-524D-414F-8AAD-2498CEE24430@oracle.com> <14DC6D63-54AD-4E64-8C90-E5984C785327@mycosystems.co.uk> <707ccdab-7f4c-1a07-d31f-ef9b98c5e085@oracle.com> Message-ID: I get the same error as before, eventually: 1. First of all failed writing to failure-logs/ This seems to happen on every clean? build, could it be fixed? I needed to mkdir -p /home/openjdk/dev/jdk9/build/linux-x86_64-normal-server-release/make-support/failure-logs 2. The error from 1. was: /home/openjdk/dev/jdk9/jdk/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c: In function 'ProcessPath': /home/openjdk/dev/jdk9/jdk/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c:846:42: error: 'params[0]' may be used uninitialized in this function [-Werror=uninitialized] /home/openjdk/dev/jdk9/jdk/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c:786:12: note: 'params[0]' was declared here /home/openjdk/dev/jdk9/jdk/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c: At top level: cc1: error: unrecognized command line option "-Wno-maybe-uninitialized" [-Werror] cc1: all warnings being treated as errors make[3]: *** [/home/openjdk/dev/jdk9/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt/ProcessPath.o] Error 1 make[2]: *** [java.desktop-libs] Error 1 3. So I tried `bash configure --disable-warnings-as-errors` Then `make clean images` errored as before: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [/home/openjdk/dev/jdk9/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/libjvm.so] Error 1 make[2]: *** [hotspot-server-libs] Error 1 ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-server-release' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value Mike > On 26 Jan 2017, at 16:00, Erik Joelsson wrote: > > The option is --disable-hotspot-gtest. > > /Erik > > > On 2017-01-26 16:55, Mike Burton wrote: >> When I do `bash configure ?disable-gtest` it errors with: >> unrecognised options: ?disable-gtest >> >> Mike >> >> >>> On 26 Jan 2017, at 15:36, Magnus Ihse Bursie wrote: >>> >>> This is an issue with gtest, which is a bit special. >>> >>> If you use --disable-gtest with configure, can you build successfully then? >>> >>> /Magnus >>> >>>> 25 jan. 2017 kl. 09:34 skrev Mike Burton : >>>> >>>> >>>>>> On 24 Jan 2017, at 21:25, Kim Barrett wrote: >>>>>> >>>>>> On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. >>>>>> Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Mike Burton >>>>> I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty >>>>> sure there are folks still building with older versions. It would be helpful to know the >>>>> details of the platform and the error messages that led to the conclusion that something >>>>> more recent was required. >>>> Platform is Ubuntu 14.04, error message below: >>>> >>>> === Output from failing command(s) repeated here === >>>> * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: >>>> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC >>>> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value >>>> collect2: ld returned 1 exit status >>>> === End of repeated output === >>>> >>>> > From aph at redhat.com Thu Jan 26 17:36:15 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Jan 2017 17:36:15 +0000 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> <15D918DE-524D-414F-8AAD-2498CEE24430@oracle.com> <14DC6D63-54AD-4E64-8C90-E5984C785327@mycosystems.co.uk> <707ccdab-7f4c-1a07-d31f-ef9b98c5e085@oracle.com> Message-ID: <5e53ef96-382d-42a5-b915-d473dd5d4a44@redhat.com> On 26/01/17 17:33, Mike Burton wrote: > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value Your static libstdc++ has been compiled without -fPIC. Compiler without static libstdc++ and you'll be fine. Andrew. From mandy.chung at oracle.com Thu Jan 26 18:24:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 Jan 2017 10:24:52 -0800 Subject: RFR: JDK-8170483: Remove modules_src_jake workaround for JavaFX transition to new module-info syntax In-Reply-To: <91239e9f-1f82-c352-43a4-148d6e6cd5c6@oracle.com> References: <91239e9f-1f82-c352-43a4-148d6e6cd5c6@oracle.com> Message-ID: <52B3AE0F-F075-49AF-A699-AF019E002CBC@oracle.com> > On Jan 26, 2017, at 6:36 AM, Erik Joelsson wrote: > > When the last jake->jdk9 push was done, a temporary workaround for dealing with Javafx was needed. Javafx has now been fully updated to only deliver the new format so the workaround should be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170483 > > Webrev: http://cr.openjdk.java.net/~erikj/8170483/webrev.01/ +1 thanks Mandy From mikeb at mycosystems.co.uk Thu Jan 26 19:16:46 2017 From: mikeb at mycosystems.co.uk (Mike Burton) Date: Thu, 26 Jan 2017 19:16:46 +0000 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: <5e53ef96-382d-42a5-b915-d473dd5d4a44@redhat.com> References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> <15D918DE-524D-414F-8AAD-2498CEE24430@oracle.com> <14DC6D63-54AD-4E64-8C90-E5984C785327@mycosystems.co.uk> <707ccdab-7f4c-1a07-d31f-ef9b98c5e085@oracle.com> <5e53ef96-382d-42a5-b915-d473dd5d4a44@redhat.com> Message-ID: <16E5BBDE-7CCF-4A08-88E4-7D9AEA8BF69E@mycosystems.co.uk> OK so I tried bash configure --with-stdc++lib=dynamic --disable-warnings-as-errors --disable-hotspot-gtest make clean images And it worked OK. Mike > On 26 Jan 2017, at 17:36, Andrew Haley wrote: > > On 26/01/17 17:33, Mike Burton wrote: >> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC >> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value > > Your static libstdc++ has been compiled without -fPIC. Compiler without static > libstdc++ and you'll be fine. > > Andrew. > From david.holmes at oracle.com Fri Jan 27 00:26:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2017 10:26:41 +1000 Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10 In-Reply-To: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> References: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> Message-ID: Hi Erik, As now discovered the version can't be updated until quite a few changes are made in hotspot due to deprecated/obsolete option handling. https://bugs.openjdk.java.net/browse/JDK-8173421 I would suggest that this bug be taken over by hotspot team (maybe me :) ) and that everything is pushed to jdk10/dev instead of jdk10/hs so that we can get this off the ground. Thanks, David On 26/01/2017 11:56 PM, Erik Joelsson wrote: > The default major version for the jdk 10 repos needs to be updated from > 9 to 10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029942 > > Patch: > > diff -r 07f6f1f4140e common/autoconf/version-numbers > --- a/common/autoconf/version-numbers > +++ b/common/autoconf/version-numbers > @@ -25,7 +25,7 @@ > > # Default version numbers to use unless overridden by configure > > -DEFAULT_VERSION_MAJOR=9 > +DEFAULT_VERSION_MAJOR=10 > DEFAULT_VERSION_MINOR=0 > DEFAULT_VERSION_SECURITY=0 > DEFAULT_VERSION_PATCH=0 > > > /Erik > From volker.simonis at gmail.com Fri Jan 27 09:42:45 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 27 Jan 2017 10:42:45 +0100 Subject: configure - gcc >4.6 needed for JDK9 build In-Reply-To: References: <6CED951D-5B52-4BCF-946F-11D93043CDCE@mycosystems.co.uk> <42B41E0D-D734-4BE6-856F-2B2E4AF4B8AF@oracle.com> <4f47df83-160d-ef6c-f7fb-9dbc4df3f4fb@oracle.com> Message-ID: On Wed, Jan 25, 2017 at 8:13 PM, Kim Barrett wrote: >> On Jan 24, 2017, at 7:34 PM, David Holmes wrote: >> >> Hi Kim, >> >> On 25/01/2017 7:25 AM, Kim Barrett wrote: >>>> On Jan 23, 2017, at 5:34 AM, Mike Burton wrote: >>>> >>>> Hello, >>>> >>>> I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck on lost a fair bit of time, failing to build JDK9. Then we found that updating gcc from 4.6 to 4.8 fixed it. >>>> Could the `configure` script be updated (by running get-source.sh) so as to check for minimum required gcc version? >>>> >>>> Best Regards >>>> >>>> Mike Burton >>> >>> I don?t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. I?m pretty >>> sure there are folks still building with older versions. It would be helpful to know the >>> details of the platform and the error messages that led to the conclusion that something >>> more recent was required. >> >> We may have "accidentally" moved on to gcc 4.8+. Even the ppc builds, which are still listed as using 4.1.2 on the wiki: >> >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >> >> are now using 4.8.5: >> >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/ (look at a build log) >> >> So some breakage with earlier versions may have crept in. I thought I recalled a few issues but can't see any bug reports. > > The PPC build from SAP was the one I was thinking of as still being around. > And it does seem they?ve moved on too, which is useful to know. > So yes, entirely possible something crept in if there isn?t frequent testing. > You're right. I've updated https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms to match our current settings. Thanks, Volker From erik.joelsson at oracle.com Fri Jan 27 12:01:37 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 27 Jan 2017 13:01:37 +0100 Subject: RFR: JDK-8167977: generated javadoc bundles should use --no-frames Message-ID: <7ce18047-fe0e-ecdb-5017-8e5c6f80b761@oracle.com> Hello, Please review this change to javadoc generation, adding the new --no-frames option to the command line. Bug: https://bugs.openjdk.java.net/browse/JDK-8167977 Patch: diff -r b88023f46daa make/Javadoc.gmk --- a/make/Javadoc.gmk +++ b/make/Javadoc.gmk @@ -186,7 +186,7 @@ # DEFAULT_JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords -notimestamp \ - -serialwarn -encoding ISO-8859-1 -breakiterator --system none + -serialwarn -encoding ISO-8859-1 -breakiterator --system none --no-frames ################################################################################ # Setup make rules for running javadoc. /Erik From erik.joelsson at oracle.com Fri Jan 27 12:46:54 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 27 Jan 2017 13:46:54 +0100 Subject: RFR: JDK-8173476: Provide lldb from devkit when running tests on macosx Message-ID: <231ddd49-7153-b8e2-c2dd-f29a7dab18fa@oracle.com> When running tests on Macosx, the failurehandle will attempt to use lldb to create dumps on timeouts. This logic requires an lldb that isn't too old. In our lab we have several instances of too old lldb on the machines. To fix this, we can add lldb from the devkit to the path when running tests, through Jib. The patch also corrects the path added by the bootjdk to actually add the bin dir on not the JAVA_HOME dir. Bug: https://bugs.openjdk.java.net/browse/JDK-8173476 Webrev: http://cr.openjdk.java.net/~erikj/8173476/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Fri Jan 27 14:15:16 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 27 Jan 2017 15:15:16 +0100 Subject: RFR: JDK-8167977: generated javadoc bundles should use --no-frames In-Reply-To: <7ce18047-fe0e-ecdb-5017-8e5c6f80b761@oracle.com> References: <7ce18047-fe0e-ecdb-5017-8e5c6f80b761@oracle.com> Message-ID: On 2017-01-27 13:01, Erik Joelsson wrote: > Hello, > > Please review this change to javadoc generation, adding the new > --no-frames option to the command line. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167977 > > Patch: > > diff -r b88023f46daa make/Javadoc.gmk > --- a/make/Javadoc.gmk > +++ b/make/Javadoc.gmk > @@ -186,7 +186,7 @@ > # > > DEFAULT_JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords > -notimestamp \ > - -serialwarn -encoding ISO-8859-1 -breakiterator --system none > + -serialwarn -encoding ISO-8859-1 -breakiterator --system none > --no-frames > > ################################################################################ > > # Setup make rules for running javadoc. Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Fri Jan 27 14:16:45 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 27 Jan 2017 15:16:45 +0100 Subject: RFR: JDK-8173476: Provide lldb from devkit when running tests on macosx In-Reply-To: <231ddd49-7153-b8e2-c2dd-f29a7dab18fa@oracle.com> References: <231ddd49-7153-b8e2-c2dd-f29a7dab18fa@oracle.com> Message-ID: <09e444b2-ee09-839f-a74d-b86faad413d7@oracle.com> On 2017-01-27 13:46, Erik Joelsson wrote: > When running tests on Macosx, the failurehandle will attempt to use > lldb to create dumps on timeouts. This logic requires an lldb that > isn't too old. In our lab we have several instances of too old lldb on > the machines. To fix this, we can add lldb from the devkit to the path > when running tests, through Jib. > > The patch also corrects the path added by the bootjdk to actually add > the bin dir on not the JAVA_HOME dir. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173476 > > Webrev: http://cr.openjdk.java.net/~erikj/8173476/webrev.01/ Looks good to me. /Magnus From tim.bell at oracle.com Fri Jan 27 15:30:28 2017 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 27 Jan 2017 07:30:28 -0800 Subject: RFR: JDK-8173476: Provide lldb from devkit when running tests on macosx In-Reply-To: <231ddd49-7153-b8e2-c2dd-f29a7dab18fa@oracle.com> References: <231ddd49-7153-b8e2-c2dd-f29a7dab18fa@oracle.com> Message-ID: Erik: > When running tests on Macosx, the failurehandle will attempt to use lldb > to create dumps on timeouts. This logic requires an lldb that isn't too > old. In our lab we have several instances of too old lldb on the > machines. To fix this, we can add lldb from the devkit to the path when > running tests, through Jib. > > The patch also corrects the path added by the bootjdk to actually add > the bin dir on not the JAVA_HOME dir. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173476 > > Webrev: http://cr.openjdk.java.net/~erikj/8173476/webrev.01/ Looks good. Thanks for fixing this. /Tim From magnus.ihse.bursie at oracle.com Mon Jan 30 08:08:54 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 30 Jan 2017 09:08:54 +0100 Subject: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp In-Reply-To: <70B7CBFC-30D5-4E2E-9FE7-C64D08C47711@oracle.com> References: <70B7CBFC-30D5-4E2E-9FE7-C64D08C47711@oracle.com> Message-ID: <82751234-4147-5ad0-53e4-0a8dcb079048@oracle.com> On 2017-01-26 15:28, Chris Hegarty wrote: > I?m not sure of the latest status of warnings in the build, but > just to say, libstcp was always built with 0 warnings being > emitted ( the JNI code has unused this/class parameters > that cannot be removed ). If you remove this suppression > won?t the compilation of code from libsctp now produce a > warning for these cannot-be-removed unused parameters? > Misleading development engineers trying to clean up > warnings. We have a global -Wno-unused-parameter for gcc. This is a common scenario, of functions following a formal pattern even if they don't need all parameters, so it does not really make sense to ever have it enabled. /Magnus > > -Chris. > >> On 26 Jan 2017, at 13:54, Magnus Ihse Bursie wrote: >> >> When fixing JDK-8081616 , it turned out that >> DISABLED_WARNINGS_gcc := unused-parameter >> seemed to be needed for libsctp in make/lib/Lib-jdk.sctp.gmk. >> >> This is not be needed anymore (and possibly never was). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8081694 >> Patch inline: >> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >> --- a/make/lib/Lib-jdk.sctp.gmk >> +++ b/make/lib/Lib-jdk.sctp.gmk >> @@ -45,7 +45,6 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >> - DISABLED_WARNINGS_gcc := unused-parameter, \ >> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >> LDFLAGS := $(LDFLAGS_JDKLIB) \ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> From chris.hegarty at oracle.com Mon Jan 30 10:38:49 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Jan 2017 10:38:49 +0000 Subject: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp In-Reply-To: <82751234-4147-5ad0-53e4-0a8dcb079048@oracle.com> References: <70B7CBFC-30D5-4E2E-9FE7-C64D08C47711@oracle.com> <82751234-4147-5ad0-53e4-0a8dcb079048@oracle.com> Message-ID: <98ce88be-e784-b3ef-1cba-fbff4ad66e14@oracle.com> On 30/01/17 08:08, Magnus Ihse Bursie wrote: > On 2017-01-26 15:28, Chris Hegarty wrote: >> I?m not sure of the latest status of warnings in the build, but >> just to say, libstcp was always built with 0 warnings being >> emitted ( the JNI code has unused this/class parameters >> that cannot be removed ). If you remove this suppression >> won?t the compilation of code from libsctp now produce a >> warning for these cannot-be-removed unused parameters? >> Misleading development engineers trying to clean up >> warnings. > > We have a global -Wno-unused-parameter for gcc. This is a common > scenario, of functions following a formal pattern even if they don't > need all parameters, so it does not really make sense to ever have it > enabled. In which case, I happy with this change. -Chris. > /Magnus > >> >> -Chris. >> >>> On 26 Jan 2017, at 13:54, Magnus Ihse Bursie wrote: >>> >>> When fixing JDK-8081616 , it turned out that >>> DISABLED_WARNINGS_gcc := unused-parameter >>> seemed to be needed for libsctp in make/lib/Lib-jdk.sctp.gmk. >>> >>> This is not be needed anymore (and possibly never was). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081694 >>> Patch inline: >>> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >>> --- a/make/lib/Lib-jdk.sctp.gmk >>> +++ b/make/lib/Lib-jdk.sctp.gmk >>> @@ -45,7 +45,6 @@ >>> $(LIBJAVA_HEADER_FLAGS) \ >>> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >>> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >>> - DISABLED_WARNINGS_gcc := unused-parameter, \ >>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>> > From chris.hegarty at oracle.com Mon Jan 30 10:58:43 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Jan 2017 10:58:43 +0000 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <5e20457b-8b10-7b45-a3bc-f6b9b1a57502@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> <5e20457b-8b10-7b45-a3bc-f6b9b1a57502@oracle.com> Message-ID: Magnus, On 26/01/17 11:45, Magnus Ihse Bursie wrote: > On 2017-01-25 13:51, Chris Hegarty wrote: >>> On 24 Jan 2017, at 16:44, Erik Joelsson wrote: >>> >>> Hello, >>> >>> Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. >> Updated in place >> http://cr.openjdk.java.net/~chegar/incubator_taglet/ > > It's not ideal that a top-level target has dependencies from the JDK > repo, but since we have no or few pre-existing top-level tools, I > understand if you hesitate to add a new framework for such tools. If we > ever do introduce more such tools, I think we should move this along. Ok. > I think the new -taglet options to the DEFAULT_JAVADOC_OPTIONS variable. > As the documentation says, the DEFAULT_JAVADOC_TAGS is there to specify > the ordering of tags in the output. Unless the -taglet options > implicitly generates one or more -tag options in it's place, It's an inline tag, so by definition has no order. > that's the > wrong place to put it. If it does, perhaps a comment indicating this > hidden behavior would be in place. It seemed best to keep all tag related options together, rather then spreading them across multiple variables. > In the line: "$$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) > $$($1_PACKAGE_DEPS) $$($1_DEPS)", please use a double $ ($$) for all > variables. While technically not necessary in this particular case, it's > misleading How so? > and we've had our share of bugs due to single $ in eval'd macros. Will this specific variable cause a problem, if so how? > In the line: "docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS)", please > remove the reference to BUILD_TOOLS_JDK. It is not needed. Why is this not needed. -Chris. > /Magnus > > >> >> -Chris. >> >>> /Erik >>> >>> >>> On 2017-01-24 15:08, Chris Hegarty wrote: >>>> As per the guidance in JEP 11 [1], the javadoc for types in >>>> incubator modules should have a clear and explicit warning >>>> notice. To that end, I?ve added a simple inline taglet that can >>>> be used to effectively inject a standard notice, and applied it >>>> to all public types in the HTTP module ( I?ll cleanup the line >>>> width formatting before pushing ). >>>> >>>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>>> >>>> -Chris. >>>> >>>> P.S. this work is, somewhat, in preparation for when we move >>>> to a single documentation bundle [2]. >>>> >>>> [1] http://openjdk.java.net/jeps/11 >>>> [2] http://openjdk.java.net/jeps/299 > From erik.joelsson at oracle.com Mon Jan 30 11:29:14 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 30 Jan 2017 12:29:14 +0100 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> <5e20457b-8b10-7b45-a3bc-f6b9b1a57502@oracle.com> Message-ID: <54390255-64d6-0e79-8f2a-114e1b7f0ebb@oracle.com> Hello, On 2017-01-30 11:58, Chris Hegarty wrote: > Magnus, > > On 26/01/17 11:45, Magnus Ihse Bursie wrote: >> On 2017-01-25 13:51, Chris Hegarty wrote: >>>> On 24 Jan 2017, at 16:44, Erik Joelsson >>>> wrote: >>>> >>>> Hello, >>>> >>>> Build changes look good except for one thing. In Javadoc.gmk, the >>>> dependency on $(BUILD_TOOLS_JDK) needs to be set for >>>> $$($1_INDEX_FILE) (on line 317), where the actual recipes are >>>> created. Setting it on the phony docs-javadoc target will not help >>>> incremental builds. >>> Updated in place >>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >> >> It's not ideal that a top-level target has dependencies from the JDK >> repo, but since we have no or few pre-existing top-level tools, I >> understand if you hesitate to add a new framework for such tools. If we >> ever do introduce more such tools, I think we should move this along. > > Ok. > >> I think the new -taglet options to the DEFAULT_JAVADOC_OPTIONS variable. >> As the documentation says, the DEFAULT_JAVADOC_TAGS is there to specify >> the ordering of tags in the output. Unless the -taglet options >> implicitly generates one or more -tag options in it's place, > > It's an inline tag, so by definition has no order. > >> that's the >> wrong place to put it. If it does, perhaps a comment indicating this >> hidden behavior would be in place. > > It seemed best to keep all tag related options together, > rather then spreading them across multiple variables. > >> In the line: "$$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) >> $$($1_PACKAGE_DEPS) $$($1_DEPS)", please use a double $ ($$) for all >> variables. While technically not necessary in this particular case, it's >> misleading > > How so? > >> and we've had our share of bugs due to single $ in eval'd macros. > > Will this specific variable cause a problem, if so how? > No, this variable will not cause a problem, but we have sort of agreed (though I have been a bit slack about it) to be consistent with all variable references inside macro bodies that will be eval'd. The trouble starts if the value of such a variable contains something that make has a special interpretation for, like a ':' or a ',' or a '$'. Then the eval will re-interpret those and weird, very hard to debug errors, start appearing. >> In the line: "docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS)", please >> remove the reference to BUILD_TOOLS_JDK. It is not needed. > > Why is this not needed. > So we have these targets: * docs-javadoc, which is a named phony target which we use as part of the external API for the Javadoc.gmk makefile. * For each call to the SetupJavadoc macro, we have $$($1_INDEX_FILE) (which evaluates to something like build/linux-x64/images/docs/api/index.html). This is a specific file being generated by a recipe. All of these are added to the TARGETS variable through which all of them are set as prerequisites to docs-javadoc. * The targets in $(BUILD_TOOLS_JDK) represents the files generated by building the tools. We add these files as prerequisites to each of the index files so that if the build tool has changed, the javadoc will get regenerated. This is what we want to achieve for proper incremental behavior. Building the tools has no inherent value in itself, as they are not part of the product, they are only needed to generate proper javadocs. As such, it is conceptually wrong (as well as redundant) to also add the tools as prerequisites to the docs-javadoc target, because this target symbolizes building all the javadoc. Each of those javadoc runs do require the tools however, so each of those javadoc runs need to have the tools as prerequisites. I had missed that you didn't remove that change in your updated review btw. /Erik > -Chris. > >> /Magnus >> >> >>> >>> -Chris. >>> >>>> /Erik >>>> >>>> >>>> On 2017-01-24 15:08, Chris Hegarty wrote: >>>>> As per the guidance in JEP 11 [1], the javadoc for types in >>>>> incubator modules should have a clear and explicit warning >>>>> notice. To that end, I?ve added a simple inline taglet that can >>>>> be used to effectively inject a standard notice, and applied it >>>>> to all public types in the HTTP module ( I?ll cleanup the line >>>>> width formatting before pushing ). >>>>> >>>>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>>>> >>>>> -Chris. >>>>> >>>>> P.S. this work is, somewhat, in preparation for when we move >>>>> to a single documentation bundle [2]. >>>>> >>>>> [1] http://openjdk.java.net/jeps/11 >>>>> [2] http://openjdk.java.net/jeps/299 >> From mikeb at mycosystems.co.uk Mon Jan 30 15:28:13 2017 From: mikeb at mycosystems.co.uk (Mike Burton) Date: Mon, 30 Jan 2017 15:28:13 +0000 Subject: make doesn't create failure-logs directory Message-ID: <7970D99C-C6DF-4081-BEB0-67ED0C762F6D@mycosystems.co.uk> While looking at JDK-8173375 I found that `make` does not create the directory `build/linux-x86_64-normal-server-release/make-support/failure-logs` during a failed build. I couldn?t find reference to this in build-dev archives so maybe a new bug? Mike Burton From chris.hegarty at oracle.com Mon Jan 30 16:20:34 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Jan 2017 16:20:34 +0000 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <54390255-64d6-0e79-8f2a-114e1b7f0ebb@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> <5e20457b-8b10-7b45-a3bc-f6b9b1a57502@oracle.com> <54390255-64d6-0e79-8f2a-114e1b7f0ebb@oracle.com> Message-ID: <6e58d8d7-11ca-db0d-f049-8112e63974bb@oracle.com> Thanks Erik and Magnus, Since this is already pushed, I propose to file a new issue to push these cleanups. diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk --- a/make/Javadoc.gmk +++ b/make/Javadoc.gmk @@ -314,7 +314,7 @@ $1_INDEX_FILE := $$(JAVADOC_OUTPUTDIR)/$$($1_OUTPUT_DIRNAME)/index.html # Rule for actually running javadoc - $$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) $$($1_PACKAGE_DEPS) $$($1_DEPS) + $$($1_INDEX_FILE): $$(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) $$($1_PACKAGE_DEPS) $$($1_DEPS) $$(call LogWarn, Generating Javadoc from $$(words $$($1_PACKAGES)) package(s) for $$($1_OUTPUT_DIRNAME)) $$(call MakeDir, $$(@D)) ifneq ($$($1_PACKAGES_FILE), ) @@ -743,7 +743,7 @@ ################################################################################ -docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS) +docs-javadoc: $(TARGETS) docs-copy: $(COPY_TARGETS) -Chris. On 30/01/17 11:29, Erik Joelsson wrote: > Hello, > > On 2017-01-30 11:58, Chris Hegarty wrote: >> Magnus, >> >> On 26/01/17 11:45, Magnus Ihse Bursie wrote: >>> On 2017-01-25 13:51, Chris Hegarty wrote: >>>>> On 24 Jan 2017, at 16:44, Erik Joelsson >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Build changes look good except for one thing. In Javadoc.gmk, the >>>>> dependency on $(BUILD_TOOLS_JDK) needs to be set for >>>>> $$($1_INDEX_FILE) (on line 317), where the actual recipes are >>>>> created. Setting it on the phony docs-javadoc target will not help >>>>> incremental builds. >>>> Updated in place >>>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>> >>> It's not ideal that a top-level target has dependencies from the JDK >>> repo, but since we have no or few pre-existing top-level tools, I >>> understand if you hesitate to add a new framework for such tools. If we >>> ever do introduce more such tools, I think we should move this along. >> >> Ok. >> >>> I think the new -taglet options to the DEFAULT_JAVADOC_OPTIONS variable. >>> As the documentation says, the DEFAULT_JAVADOC_TAGS is there to specify >>> the ordering of tags in the output. Unless the -taglet options >>> implicitly generates one or more -tag options in it's place, >> >> It's an inline tag, so by definition has no order. >> >>> that's the >>> wrong place to put it. If it does, perhaps a comment indicating this >>> hidden behavior would be in place. >> >> It seemed best to keep all tag related options together, >> rather then spreading them across multiple variables. >> >>> In the line: "$$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) >>> $$($1_PACKAGE_DEPS) $$($1_DEPS)", please use a double $ ($$) for all >>> variables. While technically not necessary in this particular case, it's >>> misleading >> >> How so? >> >>> and we've had our share of bugs due to single $ in eval'd macros. >> >> Will this specific variable cause a problem, if so how? >> > No, this variable will not cause a problem, but we have sort of agreed > (though I have been a bit slack about it) to be consistent with all > variable references inside macro bodies that will be eval'd. The trouble > starts if the value of such a variable contains something that make has > a special interpretation for, like a ':' or a ',' or a '$'. Then the > eval will re-interpret those and weird, very hard to debug errors, start > appearing. >>> In the line: "docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS)", please >>> remove the reference to BUILD_TOOLS_JDK. It is not needed. >> >> Why is this not needed. >> > So we have these targets: > > * docs-javadoc, which is a named phony target which we use as part of > the external API for the Javadoc.gmk makefile. > * For each call to the SetupJavadoc macro, we have $$($1_INDEX_FILE) > (which evaluates to something like > build/linux-x64/images/docs/api/index.html). This is a specific file > being generated by a recipe. All of these are added to the TARGETS > variable through which all of them are set as prerequisites to > docs-javadoc. > * The targets in $(BUILD_TOOLS_JDK) represents the files generated by > building the tools. We add these files as prerequisites to each of the > index files so that if the build tool has changed, the javadoc will get > regenerated. This is what we want to achieve for proper incremental > behavior. > > Building the tools has no inherent value in itself, as they are not part > of the product, they are only needed to generate proper javadocs. As > such, it is conceptually wrong (as well as redundant) to also add the > tools as prerequisites to the docs-javadoc target, because this target > symbolizes building all the javadoc. Each of those javadoc runs do > require the tools however, so each of those javadoc runs need to have > the tools as prerequisites. > > I had missed that you didn't remove that change in your updated review btw. > > /Erik > >> -Chris. >> >>> /Magnus >>> >>> >>>> >>>> -Chris. >>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-01-24 15:08, Chris Hegarty wrote: >>>>>> As per the guidance in JEP 11 [1], the javadoc for types in >>>>>> incubator modules should have a clear and explicit warning >>>>>> notice. To that end, I?ve added a simple inline taglet that can >>>>>> be used to effectively inject a standard notice, and applied it >>>>>> to all public types in the HTTP module ( I?ll cleanup the line >>>>>> width formatting before pushing ). >>>>>> >>>>>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>>>>> >>>>>> -Chris. >>>>>> >>>>>> P.S. this work is, somewhat, in preparation for when we move >>>>>> to a single documentation bundle [2]. >>>>>> >>>>>> [1] http://openjdk.java.net/jeps/11 >>>>>> [2] http://openjdk.java.net/jeps/299 >>> > From mandy.chung at oracle.com Mon Jan 30 23:42:14 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2017 15:42:14 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module Message-ID: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> java.management is the module for JMX and JMX remote API and java.lang.management. JDK management agent provides the JDK-specific out-of-the-box monitoring and management support and it?s cleaner for it to live in its own module. It is proposed to move it to a new module named `jdk.management.agent`. This change involves: 1) renaming of sun.management.Agent along with 3 other classes in sun.management package to jdk.internal.agent package 2) move sun.management.resources to jdk.internal.agent.resources 3) move sun.management.jmxremote and sun.management.jdp packages to jdk.management.agent module 4) move the configuration files under conf/management 5) sun/management/jmxremote/ConnectorBootstrap.java is updated to replace the use of the ClassLogger API with System.Logger. 6) change hotspot VM to add `jdk.management.agent` when -Dcom.sun.management.* system property is set as well as the Agent class rename Daniel is working on JDK-8173607 [1] that conflicts with this patch and require merges/coordination. We propose to integrate these changes to jdk9/dev unless there is any objection concerning that this trivial hotspot change might cause any issue. I have submitted a RBT on hotspot_runtime and hotspot_serviceability in addition to PIT test runs. thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From mandy.chung at oracle.com Mon Jan 30 23:48:18 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2017 15:48:18 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> Message-ID: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html Mandy > On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: > > java.management is the module for JMX and JMX remote API and > java.lang.management. JDK management agent provides the JDK-specific > out-of-the-box monitoring and management support and it?s cleaner > for it to live in its own module. It is proposed to move it > to a new module named `jdk.management.agent`. > > This change involves: > 1) renaming of sun.management.Agent along with 3 other classes > in sun.management package to jdk.internal.agent package > > 2) move sun.management.resources to jdk.internal.agent.resources > > 3) move sun.management.jmxremote and sun.management.jdp packages > to jdk.management.agent module > > 4) move the configuration files under conf/management > > 5) sun/management/jmxremote/ConnectorBootstrap.java is updated > to replace the use of the ClassLogger API with System.Logger. > > 6) change hotspot VM to add `jdk.management.agent` when > -Dcom.sun.management.* system property is set as well as > the Agent class rename > > Daniel is working on JDK-8173607 [1] that conflicts with this > patch and require merges/coordination. > > We propose to integrate these changes to jdk9/dev unless > there is any objection concerning that this trivial hotspot change > might cause any issue. I have submitted a RBT on hotspot_runtime > and hotspot_serviceability in addition to PIT test runs. > > thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From david.holmes at oracle.com Tue Jan 31 07:00:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2017 17:00:38 +1000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> Hi Mandy, On 31/01/2017 9:48 AM, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html This all seems okay. But we have quite a few hotspot tests that include: @modules java.management/sun.management that would seem to need updating as well. Thanks, David ----- > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From erik.joelsson at oracle.com Tue Jan 31 08:20:00 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 31 Jan 2017 09:20:00 +0100 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Hello Mandy, In Lib-jdk.management.agent.gmk: OPENJDK_TARGET_OS and OPENJDK_TARGET_OS_TYPE are both "windows" on Windows platforms, so no need to treat Windows differently when defining the src dirs. The -DPSAPI_VERSION=1 seems to be copied from Lib-jdk.management.gmk and/or Lib-jdk.attach.gmk, but was not applied to the library from which the native src for this new lib was copied from. I just wonder if this is actually needed for this new library? Please remove the "LANG := C" parameter, it no longer has a meaning but it keeps reappearing due to copy pasting of old make code. Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? /Erik On 2017-01-31 00:48, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From mandy.chung at oracle.com Tue Jan 31 14:57:40 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 06:57:40 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> Message-ID: <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> > On Jan 30, 2017, at 11:00 PM, David Holmes wrote: > > Hi Mandy, > > On 31/01/2017 9:48 AM, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > This all seems okay. > Thanks for the review. > But we have quite a few hotspot tests that include: > > @modules java.management/sun.management > Only 4 classes in the java.management/sun.management are moved to jdk.management.agent/jdk.internal.agent. From my grep on hotspot tests, no test uses those renamed classes. Mandy > that would seem to need updating as well. > > Thanks, > David > ----- > >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >> From daniel.fuchs at oracle.com Tue Jan 31 15:35:30 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 31 Jan 2017 15:35:30 +0000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> Hi Mandy, Looks good to me in general. Suggestion: FileLoginModule.java 112 private static final String PASSWORD_FILE_NAME = "jmxremote.password"; Maybe the constant could be public, then it could be referred to by ConnectorBootstrap? I see that com.sun.jmx.remote.internal is already being exported to jdk.management.agent. FileSystem.java: I wonder if this functionality should have remained in java.management. It doesn't have any type to any specific protocol - and it seems to be something that anyone using the FileLoginModule above might also need. ConnectorBootstrap.java: I would normally discourage creating helper methods (such as config()) in a class that doesn't implement System.Logger, as that will make the 'config' method appear as the source of the log message (rather than the method that calls config()). In this specific case I don't think it matters much though. It's probably better to keep it like this so as not distract reviewers from the meaningful changes, and we can clean that up any time later in a separate changeset (and possibly not before 10). best regards, -- daniel On 30/01/17 23:48, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From mandy.chung at oracle.com Tue Jan 31 16:04:27 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 08:04:27 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Message-ID: > On Jan 31, 2017, at 12:20 AM, Erik Joelsson wrote: > > Hello Mandy, > > In Lib-jdk.management.agent.gmk: > > OPENJDK_TARGET_OS and OPENJDK_TARGET_OS_TYPE are both "windows" on Windows platforms, so no need to treat Windows differently when defining the src dirs. > Good to know. Thanks. > The -DPSAPI_VERSION=1 seems to be copied from Lib-jdk.management.gmk and/or Lib-jdk.attach.gmk, but was not applied to the library from which the native src for this new lib was copied from. I just wonder if this is actually needed for this new library? I was also wondering it and now track it down. jdk.management.agent doesn?t use PS api. I will take it out. > > Please remove the "LANG := C" parameter, it no longer has a meaning but it keeps reappearing due to copy pasting of old make code. > > Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? > Good catch. I updated Lib-jdk.management.agent.gmk with: LIBS := $(JDKLIB_LIBS), \ LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib, \ We should examine the native code in both java.management and jdk.management and I suspect the makefile would need cleanup. Are you okay to follow up the makefile as a separate issue? As the native code in jdk.management.agent, it can be converted to use NIO 2 and hope to get to it in a near future so that jdk.management.agent will have java code only. Mandy > /Erik > > > On 2017-01-31 00:48, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From mandy.chung at oracle.com Tue Jan 31 16:22:25 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 08:22:25 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> Message-ID: > On Jan 31, 2017, at 7:35 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Looks good to me in general. > > Suggestion: FileLoginModule.java > > 112 private static final String PASSWORD_FILE_NAME = "jmxremote.password"; > > Maybe the constant could be public, then it could be > referred to by ConnectorBootstrap? > I see that com.sun.jmx.remote.internal is already > being exported to jdk.management.agent. > You meant com.sun.jmx.remote.security. I?d leave these 2 constants as is. Some future closer look to the relationship between FileLoginModule and ConnectorBootstrap may help to determine if future clean up should be done. > FileSystem.java: > > I wonder if this functionality should have remained in > java.management. It doesn't have any type to any specific > protocol - and it seems to be something that anyone using > the FileLoginModule above might also need. > That was added for the management agent and solely internal. We should look into converting the native code with NIO 2. No one should depend on it. > ConnectorBootstrap.java: > > I would normally discourage creating helper methods > (such as config()) in a class that doesn't implement > System.Logger, as that will make the 'config' method > appear as the source of the log message (rather than > the method that calls config()). > In this specific case I don't think it matters much > though. It's probably better to keep it like this so > as not distract reviewers from the meaningful changes, > and we can clean that up any time later in a separate > changeset (and possibly not before 10). > This is just an expedient way to remove the dependency to ClassLogger since the source method isn?t significant in this case. Thanks for the review. Mandy > > best regards, > > -- daniel > > On 30/01/17 23:48, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >> > From erik.joelsson at oracle.com Tue Jan 31 16:44:41 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 31 Jan 2017 17:44:41 +0100 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Message-ID: <108c0107-83cc-e763-5f76-723aeae2b8ff@oracle.com> On 2017-01-31 17:04, Mandy Chung wrote: > >> On Jan 31, 2017, at 12:20 AM, Erik Joelsson wrote: >> >> Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? >> > Good catch. I updated Lib-jdk.management.agent.gmk with: > > LIBS := $(JDKLIB_LIBS), \ > LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib, \ > > We should examine the native code in both java.management and jdk.management and I suspect the makefile would need cleanup. Are you okay to follow up the makefile as a separate issue? As the native code in jdk.management.agent, it can be converted to use NIO 2 and hope to get to it in a near future so that jdk.management.agent will have java code only. The adjustment proposed here is fine with me. /Erik From daniel.fuchs at oracle.com Tue Jan 31 18:26:49 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 31 Jan 2017 18:26:49 +0000 Subject: RFR: 8173607: JMX RMI connector should be in its own module Message-ID: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> Hi, Please find below a patch for: 8173607: JMX RMI connector should be in its own module https://bugs.openjdk.java.net/browse/JDK-8173607 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 This patch makes it possible to remove the requires transitive java.rmi from the java.management module. For convenience here is the HTML module-level API documentation produced by javadoc for the new java.management.rmi module: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05/java.management.rmi-summary.html The patch has some temporary hacks (mainly ConnectorBootstrap.java) that we will be able to revert when JDK-8173608 Separate JDK management agent from java.management module is pushed. The changes were mainly mechanical except for: ConnectorBootstrap.java: see above JMXConnectorFactory.java/JMXConnectorServerFactory.java: ServiceLoader is now used to load the default RMI Connector provider as a service. There should however be no observable behavior change to existing application. ProxyRef.java, Unmarshal.java: are moved to a new com.sun.jmx.remote.internal.rmi package in the new module. ClientNotifForwarder.java: is modified to no longer depend on java.rmi.UnmarshalException - NotSerializableException is used instead RMIConnector.java: fetchNotif is updated to throw NotSerializableException instead of UnmarshalException The PRef serialization bytes are updated to accomodate the new ProxyRef package name. Some further cleanup of java.base and java.rmi module-info.java should become possible once JDK-8173608 is in (as well as moving RMIExporter to java.management.rmi - which is not possible yet). Further cleanup of @modules in tests might become possible as well. Note: JCK tests for api/javax_management and api/java_lang/management are passing with this change. best regards, -- daniel From david.holmes at oracle.com Tue Jan 31 20:45:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Feb 2017 06:45:45 +1000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> Message-ID: <3ca0cbec-75d9-0517-6ede-5bcd46f377e1@oracle.com> On 1/02/2017 12:57 AM, Mandy Chung wrote: > >> On Jan 30, 2017, at 11:00 PM, David Holmes wrote: >> >> Hi Mandy, >> >> On 31/01/2017 9:48 AM, Mandy Chung wrote: >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> This all seems okay. >> > > Thanks for the review. > >> But we have quite a few hotspot tests that include: >> >> @modules java.management/sun.management >> > > Only 4 classes in the java.management/sun.management are moved to jdk.management.agent/jdk.internal.agent. > > From my grep on hotspot tests, no test uses those renamed classes. Ah I see. Thanks for clarifying. David > Mandy > >> that would seem to need updating as well. >> >> Thanks, >> David >> ----- >> >>> Mandy >>> >>>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>>> >>>> java.management is the module for JMX and JMX remote API and >>>> java.lang.management. JDK management agent provides the JDK-specific >>>> out-of-the-box monitoring and management support and it?s cleaner >>>> for it to live in its own module. It is proposed to move it >>>> to a new module named `jdk.management.agent`. >>>> >>>> This change involves: >>>> 1) renaming of sun.management.Agent along with 3 other classes >>>> in sun.management package to jdk.internal.agent package >>>> >>>> 2) move sun.management.resources to jdk.internal.agent.resources >>>> >>>> 3) move sun.management.jmxremote and sun.management.jdp packages >>>> to jdk.management.agent module >>>> >>>> 4) move the configuration files under conf/management >>>> >>>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>>> to replace the use of the ClassLogger API with System.Logger. >>>> >>>> 6) change hotspot VM to add `jdk.management.agent` when >>>> -Dcom.sun.management.* system property is set as well as >>>> the Agent class rename >>>> >>>> Daniel is working on JDK-8173607 [1] that conflicts with this >>>> patch and require merges/coordination. >>>> >>>> We propose to integrate these changes to jdk9/dev unless >>>> there is any objection concerning that this trivial hotspot change >>>> might cause any issue. I have submitted a RBT on hotspot_runtime >>>> and hotspot_serviceability in addition to PIT test runs. >>>> >>>> thanks >>>> Mandy >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >>> > From mark.reinhold at oracle.com Tue Jan 31 23:03:00 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 31 Jan 2017 15:03:00 -0800 Subject: New lead for the JDK 6 Project: Andrew Brygin In-Reply-To: <20170106153028.GA5354@spin> References: <20170106153028.GA5354@spin> Message-ID: <20170131150300.241554750@eggemoggin.niobe.net> 2017/1/6 7:30:28 -0800, tim.bell at oracle.com: > Andrew Haley has resigned as lead for the JDK 6 Project [1]. > > Under the bylaws for Project Roles [2], a new Project Lead may be > nominated by the Group Leads of the Project's sponsoring groups. > > The Build Infrastructure Group is sponsor of the project. As Group > Leader, I would like to nominate Andrew Brygin [3] to be the new > Project Lead. > > The Build Infrastructure Group is the only sponsoring group for this > project. I believe that makes the nomination automatically approved. So recorded. - Mark