From magnus.ihse.bursie at oracle.com Tue Oct 1 08:15:49 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 1 Oct 2019 10:15:49 +0200 Subject: RFR: JDK-8231594: Configure fails on some Linux systems In-Reply-To: References: <7472c794-8c8d-6747-7713-9e251066fa4d@oracle.com> <1e238bdc-5e47-2053-b2c3-01910d45419c@oracle.com> <52b699ee-fe92-5efa-2292-ff79055354a5@oracle.com> Message-ID: On 2019-09-30 17:23, Erik Joelsson wrote: > Uploaded new webrev in place with a comment explaining this. I see. Thanks for adding this as a comment in the code. Looks good to me. (But as always I'm still worried that meddling with these path functions will break unexpectedly somewhere else...) /Magnus > > /Erik > > On 2019-09-30 08:02, Erik Joelsson wrote: >> On 2019-09-30 02:41, Magnus Ihse Bursie wrote: >>> On 2019-09-28 00:37, Erik Joelsson wrote: >>>> In my recent change JDK-8206125, I introduced a bash conditional >>>> that checks if a string starts with ~. That check seems to fail on >>>> some Linux systems unless the ~ is quoted. >>> Do you need the check? The old code, prior to JDK-8206125, >>> unconditionally made the eval. Maybe that was a safer route? This >>> feels a bit shaky, and the old code has (afaik) been working okay. >>> >> The check prior to JDK-8206125 only applied to Unix platforms, but in >> that change I made it also apply to Windows. At the point where it's >> called, we may still have spaces in the path, and the eval does not >> work with spaces. If we add quotes to handle spaces in the eval, then >> any ~ will not be evaluated. Basically we have to choose between >> supporting spaces or ~ in any one fixup call. By adding the >> conditional, we get to do so on Windows. >> >> /Erik >> >>> /Magnus >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231594 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8231594/webrev.01 >>>> >>>> /Erik >>>> >>> From erik.joelsson at oracle.com Tue Oct 1 21:37:56 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Oct 2019 14:37:56 -0700 Subject: RFR: JDK-8231505: Bump required boot jdk version to 13 Message-ID: <0c24ada5-b11b-6895-ddba-711c2a32a9de@oracle.com> With the release of JDK 13 it is now time to update the required boot jdk version for JDK 14 (to 13). This patch changes the configure requirements as well as bumps the version used for Jib builds at Oracle. Bug: https://bugs.openjdk.java.net/browse/JDK-8231505 Webrev: http://cr.openjdk.java.net/~erikj/8231505/webrev.01/ /Erik From joe.darcy at oracle.com Tue Oct 1 21:45:55 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 1 Oct 2019 14:45:55 -0700 Subject: RFR: JDK-8231505: Bump required boot jdk version to 13 In-Reply-To: <0c24ada5-b11b-6895-ddba-711c2a32a9de@oracle.com> References: <0c24ada5-b11b-6895-ddba-711c2a32a9de@oracle.com> Message-ID: <12368828-db3b-f9d8-f333-c855f452c813@oracle.com> Looks good; cheers, -Joe On 10/1/2019 2:37 PM, Erik Joelsson wrote: > With the release of JDK 13 it is now time to update the required boot > jdk version for JDK 14 (to 13). This patch changes the configure > requirements as well as bumps the version used for Jib builds at Oracle. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231505 > > Webrev: http://cr.openjdk.java.net/~erikj/8231505/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Wed Oct 2 07:28:59 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Oct 2019 09:28:59 +0200 Subject: RFR: JDK-8231505: Bump required boot jdk version to 13 In-Reply-To: <0c24ada5-b11b-6895-ddba-711c2a32a9de@oracle.com> References: <0c24ada5-b11b-6895-ddba-711c2a32a9de@oracle.com> Message-ID: On 2019-10-01 23:37, Erik Joelsson wrote: > With the release of JDK 13 it is now time to update the required boot > jdk version for JDK 14 (to 13). This patch changes the configure > requirements as well as bumps the version used for Jib builds at Oracle. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231505 > > Webrev: http://cr.openjdk.java.net/~erikj/8231505/webrev.01/ Looks good to me. /Magnus > > /Erik > From magnus.ihse.bursie at oracle.com Wed Oct 2 09:06:49 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Oct 2019 11:06:49 +0200 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system Message-ID: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> From the bug report: We should prefix LC_ALL=C for most, maybe all, tools we use when building. This probably means we should run "export LC_ALL=C" early in the configure script as well. --- The fix itself is trivial. While I know we've had several issues regarding localization, I could not find any specific instances now that I was looking for them. I searched JBS for a while but could not dig up anything that was reproducible. So, unfortunately, I have been unable to verify that this solves any actual problems. That being said, I believe this is a prudent fix that should have been in place long time ago. But if anyone can give me a concrete example that breaks so that I can verify that this helps, please let me know. Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 /Magnus From naoto.sato at oracle.com Wed Oct 2 13:36:58 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 2 Oct 2019 06:36:58 -0700 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system In-Reply-To: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> References: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> Message-ID: <32a86706-3552-d4c0-4d8c-5b95168e056c@oracle.com> Hi Magnus, Looks good to me. Although I cannot provide any reproducible problematic instance, there have been instances where native tools, such as `date` command had produced localized date, and the build failed to parse it in US format. Anyways, it is a good preventive measure to me. Naoto On 10/2/19 2:06 AM, Magnus Ihse Bursie wrote: > From the bug report: > We should prefix LC_ALL=C for most, maybe all, tools we use when building. > > This probably means we should run "export LC_ALL=C" early in the > configure script as well. > --- > > The fix itself is trivial. While I know we've had several issues > regarding localization, I could not find any specific instances now that > I was looking for them. I searched JBS for a while but could not dig up > anything that was reproducible. So, unfortunately, I have been unable to > verify that this solves any actual problems. That being said, I believe > this is a prudent fix that should have been in place long time ago. But > if anyone can give me a concrete example that breaks so that I can > verify that this helps, please let me know. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Oct 2 15:40:19 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Oct 2019 08:40:19 -0700 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system In-Reply-To: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> References: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> Message-ID: <9442650b-c98f-bc3b-6b7e-e9fc0c34b73d@oracle.com> Hello Magnus, The change looks good, but should perhaps also include removal of the few scattered specific instances of LANG=C and LC_ALL=C in the makefiles: make/common/JavaCompilation.gmk:??? export LC_ALL=C ; ( $(CAT) $$< && $(ECHO) "" ) \ make/autoconf/basics.m4:? DATE_WHEN_CONFIGURED=`LANG=C date` Also compare.sh has a bunch which could be replaced with one export at the top. I would expect a full round of builds-infra to be run for this, as well as explicit compare builds as subtle things could be changing. /Erik On 2019-10-02 02:06, Magnus Ihse Bursie wrote: > From the bug report: > We should prefix LC_ALL=C for most, maybe all, tools we use when > building. > > This probably means we should run "export LC_ALL=C" early in the > configure script as well. > --- > > The fix itself is trivial. While I know we've had several issues > regarding localization, I could not find any specific instances now > that I was looking for them. I searched JBS for a while but could not > dig up anything that was reproducible. So, unfortunately, I have been > unable to verify that this solves any actual problems. That being > said, I believe this is a prudent fix that should have been in place > long time ago. But if anyone can give me a concrete example that > breaks so that I can verify that this helps, please let me know. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 > > /Magnus From martinrb at google.com Wed Oct 2 15:45:53 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Oct 2019 08:45:53 -0700 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system In-Reply-To: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> References: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> Message-ID: I recall years ago running into troubles with regex character ranges, e.g. https://unix.stackexchange.com/questions/15980/does-should-lc-collate-affect-character-ranges but my build script wrapper has been setting LC_ALL=C for a long time, and I set LC_COLLATE=C in my normal use shell environment (do regular humans care deeply about getting localized collation order?) On Wed, Oct 2, 2019 at 2:09 AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > From the bug report: > We should prefix LC_ALL=C for most, maybe all, tools we use when building. > > This probably means we should run "export LC_ALL=C" early in the > configure script as well. > --- > > The fix itself is trivial. While I know we've had several issues > regarding localization, I could not find any specific instances now that > I was looking for them. I searched JBS for a while but could not dig up > anything that was reproducible. So, unfortunately, I have been unable to > verify that this solves any actual problems. That being said, I believe > this is a prudent fix that should have been in place long time ago. But > if anyone can give me a concrete example that breaks so that I can > verify that this helps, please let me know. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 > > /Magnus > From jan.lahoda at oracle.com Thu Oct 3 09:57:34 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 3 Oct 2019 11:57:34 +0200 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API Message-ID: Hi, This is a continuation of Joe's patch from here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html APIs associated with preview features are split into two groups: essential and non-essential. These are marked with an JDK-internal annotation, PreviewFeature, and a tag in the javadoc, @preview. The javac follows the PreviewFeature annotation, and produces either warnings or errors for the usages of such APIs. For the @preview tag, there is a taglet in the JDK build that adds the content of the tag into the documentation. The first part of the @preview's text goes into the summary, the second part goes into the detailed description. For build, a tricky problem is that the jdk.compiler module uses the PreviewFeature annotation as well, but that is not in the bootstrap JDK. So, for the intermediate langtools build, the PreviewFeature annotation is copied from java.base. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ Javadoc with the change: http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html See for example: http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html JBS: https://bugs.openjdk.java.net/browse/JDK-8226585 CSR: https://bugs.openjdk.java.net/browse/JDK-8231411 Feedback is welcome! Thanks, Jan From erik.joelsson at oracle.com Thu Oct 3 16:06:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 Oct 2019 09:06:00 -0700 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: References: Message-ID: Hello Jan, The build change looks ok, but I would recommend this construct for copying the file instead: $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ ??? FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \ ??? DEST := $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, \ )) TARGETS += $(COPY_PREVIEW_FEATURES) Then you automatically get all the corner case handling we have implemented over the years for logging, making directories and copying files. Your version is still correct for this case though. /Erik On 2019-10-03 02:57, Jan Lahoda wrote: > Hi, > > This is a continuation of Joe's patch from here: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html > > > APIs associated with preview features are split into two groups: > essential and non-essential. These are marked with an JDK-internal > annotation, PreviewFeature, and a tag in the javadoc, @preview. The > javac follows the PreviewFeature annotation, and produces either > warnings or errors for the usages of such APIs. For the @preview tag, > there is a taglet in the JDK build that adds the content of the tag > into the documentation. The first part of the @preview's text goes > into the summary, the second part goes into the detailed description. > > For build, a tricky problem is that the jdk.compiler module uses the > PreviewFeature annotation as well, but that is not in the bootstrap > JDK. So, for the intermediate langtools build, the PreviewFeature > annotation is copied from java.base. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ > > Javadoc with the change: > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html > > See for example: > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html > > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html > > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8226585 > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8231411 > > Feedback is welcome! > > Thanks, > ??? Jan From joe.darcy at oracle.com Fri Oct 4 05:08:20 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 3 Oct 2019 22:08:20 -0700 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: References: Message-ID: Hi Jan, For future work, consider having a "Preview Methods" tag alongside static, instance, deprecated, etc. Cheers, -Joe On 10/3/2019 2:57 AM, Jan Lahoda wrote: > Hi, > > This is a continuation of Joe's patch from here: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html > > > APIs associated with preview features are split into two groups: > essential and non-essential. These are marked with an JDK-internal > annotation, PreviewFeature, and a tag in the javadoc, @preview. The > javac follows the PreviewFeature annotation, and produces either > warnings or errors for the usages of such APIs. For the @preview tag, > there is a taglet in the JDK build that adds the content of the tag > into the documentation. The first part of the @preview's text goes > into the summary, the second part goes into the detailed description. > > For build, a tricky problem is that the jdk.compiler module uses the > PreviewFeature annotation as well, but that is not in the bootstrap > JDK. So, for the intermediate langtools build, the PreviewFeature > annotation is copied from java.base. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ > > Javadoc with the change: > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html > > See for example: > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html > > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html > > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8226585 > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8231411 > > Feedback is welcome! > > Thanks, > ??? Jan From magnus.ihse.bursie at oracle.com Fri Oct 4 11:37:23 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 4 Oct 2019 13:37:23 +0200 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system In-Reply-To: <9442650b-c98f-bc3b-6b7e-e9fc0c34b73d@oracle.com> References: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> <9442650b-c98f-bc3b-6b7e-e9fc0c34b73d@oracle.com> Message-ID: On 2019-10-02 17:40, Erik Joelsson wrote: > Hello Magnus, > > The change looks good, but should perhaps also include removal of the > few scattered specific instances of LANG=C and LC_ALL=C in the makefiles: > > make/common/JavaCompilation.gmk:??? export LC_ALL=C ; ( $(CAT) $$< && > $(ECHO) "" ) \ > > make/autoconf/basics.m4:? DATE_WHEN_CONFIGURED=`LANG=C date` > > Also compare.sh has a bunch which could be replaced with one export at > the top. Ok, here's an updated version where I've deleted all other LC_* and LANG assignments in the build system. FWIW, I found a few instances in test code, but I did not change that. http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.02 > I would expect a full round of builds-infra to be run for this, as > well as explicit compare builds as subtle things could be changing. Yes, of course. My original patch has already made the rounds on the builds-infra test suite without any issues, but I'll do a rerun with this second version of the patch as well. /Magnus > > /Erik > > On 2019-10-02 02:06, Magnus Ihse Bursie wrote: >> From the bug report: >> We should prefix LC_ALL=C for most, maybe all, tools we use when >> building. >> >> This probably means we should run "export LC_ALL=C" early in the >> configure script as well. >> --- >> >> The fix itself is trivial. While I know we've had several issues >> regarding localization, I could not find any specific instances now >> that I was looking for them. I searched JBS for a while but could not >> dig up anything that was reproducible. So, unfortunately, I have been >> unable to verify that this solves any actual problems. That being >> said, I believe this is a prudent fix that should have been in place >> long time ago. But if anyone can give me a concrete example that >> breaks so that I can verify that this helps, please let me know. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 >> >> /Magnus From magnus.ihse.bursie at oracle.com Fri Oct 4 11:52:51 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 4 Oct 2019 13:52:51 +0200 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system In-Reply-To: References: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> Message-ID: <66489a62-3b7e-8cef-dea3-55da6163cc54@oracle.com> On 2019-10-02 17:45, Martin Buchholz wrote: > I recall years ago running into troubles with regex character ranges, > e.g. > https://unix.stackexchange.com/questions/15980/does-should-lc-collate-affect-character-ranges > but my build script wrapper has been setting LC_ALL=C for a long time, > and I set LC_COLLATE=C in my normal use shell environment Hah, that's a funny (i.e. very unexpected, and not particularly funny at all) side effect of localization. :) We're doing quite a lot of "a-z" in the build systems; we should probably change them to "[[:lower:]]". > (do regular humans care deeply about getting localized collation order?) But oh yes! I'd *hate* it for my ??? to be sorted anywhere but after xyz. Probably just as much as the Germans would hate to *not* have the ?, ? and ? sorted alongside the a, o and u. You're just having the perspective of privilege from US-ASCII being considered the universal default. ;-) /Magnus > > On Wed, Oct 2, 2019 at 2:09 AM Magnus Ihse Bursie > > > wrote: > > ?From the bug report: > We should prefix LC_ALL=C for most, maybe all, tools we use when > building. > > This probably means we should run "export LC_ALL=C" early in the > configure script as well. > --- > > The fix itself is trivial. While I know we've had several issues > regarding localization, I could not find any specific instances > now that > I was looking for them. I searched JBS for a while but could not > dig up > anything that was reproducible. So, unfortunately, I have been > unable to > verify that this solves any actual problems. That being said, I > believe > this is a prudent fix that should have been in place long time > ago. But > if anyone can give me a concrete example that breaks so that I can > verify that this helps, please let me know. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Fri Oct 4 13:16:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Oct 2019 06:16:49 -0700 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system In-Reply-To: References: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> <9442650b-c98f-bc3b-6b7e-e9fc0c34b73d@oracle.com> Message-ID: On 2019-10-04 04:37, Magnus Ihse Bursie wrote: > On 2019-10-02 17:40, Erik Joelsson wrote: >> Hello Magnus, >> >> The change looks good, but should perhaps also include removal of the >> few scattered specific instances of LANG=C and LC_ALL=C in the >> makefiles: >> >> make/common/JavaCompilation.gmk:??? export LC_ALL=C ; ( $(CAT) $$< && >> $(ECHO) "" ) \ >> >> make/autoconf/basics.m4:? DATE_WHEN_CONFIGURED=`LANG=C date` >> >> Also compare.sh has a bunch which could be replaced with one export >> at the top. > Ok, here's an updated version where I've deleted all other LC_* and > LANG assignments in the build system. FWIW, I found a few instances in > test code, but I did not change that. > > http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.02 > The removal in RunTestPrebuilt.gmk reminded me that we do not run configure before running tests, and in that situation spec.gmk.in is not used either. The same export needs to be added somewhere in the run-test-prebuilt chain of invocations. >> I would expect a full round of builds-infra to be run for this, as >> well as explicit compare builds as subtle things could be changing. > Yes, of course. My original patch has already made the rounds on the > builds-infra test suite without any issues, but I'll do a rerun with > this second version of the patch as well. > Thanks! /Erik > /Magnus >> >> /Erik >> >> On 2019-10-02 02:06, Magnus Ihse Bursie wrote: >>> From the bug report: >>> We should prefix LC_ALL=C for most, maybe all, tools we use when >>> building. >>> >>> This probably means we should run "export LC_ALL=C" early in the >>> configure script as well. >>> --- >>> >>> The fix itself is trivial. While I know we've had several issues >>> regarding localization, I could not find any specific instances now >>> that I was looking for them. I searched JBS for a while but could >>> not dig up anything that was reproducible. So, unfortunately, I have >>> been unable to verify that this solves any actual problems. That >>> being said, I believe this is a prudent fix that should have been in >>> place long time ago. But if anyone can give me a concrete example >>> that breaks so that I can verify that this helps, please let me know. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 >>> >>> /Magnus > From dean.long at oracle.com Fri Oct 4 19:29:21 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Oct 2019 12:29:21 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed Message-ID: https://bugs.openjdk.java.net/browse/JDK-8231902 http://cr.openjdk.java.net/~dlong/8231902/webrev/ A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output.? The simple fix is to create an empty file in the directory. dl From vladimir.kozlov at oracle.com Fri Oct 4 20:03:31 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 4 Oct 2019 13:03:31 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: References: Message-ID: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> Good. Thanks Vladimir > On Oct 4, 2019, at 12:29 PM, dean.long at oracle.com wrote: > > https://bugs.openjdk.java.net/browse/JDK-8231902 > http://cr.openjdk.java.net/~dlong/8231902/webrev/ > > A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output. The simple fix is to create an empty file in the directory. > > dl From erik.joelsson at oracle.com Fri Oct 4 20:08:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Oct 2019 13:08:49 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> References: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> Message-ID: <0cda922a-806a-bc0a-853a-290d445212c4@oracle.com> See comment I put in the bug. /Erik On 2019-10-04 13:03, Vladimir Kozlov wrote: > Good. > > Thanks > Vladimir > >> On Oct 4, 2019, at 12:29 PM, dean.long at oracle.com wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8231902 >> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >> >> A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output. The simple fix is to create an empty file in the directory. >> >> dl From dean.long at oracle.com Fri Oct 4 22:09:53 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Oct 2019 15:09:53 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: References: Message-ID: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> Here's an alternative version with $(NAWK) usage suggested by Erik Joelsson: http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ dl On 10/4/19 12:29 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8231902 > http://cr.openjdk.java.net/~dlong/8231902/webrev/ > > A recent upstream Graal change causes the META-INF/providers directory > to contain only a single file, causing the $(GREP) command to not > prepend the filename to the output.? The simple fix is to create an > empty file in the directory. > > dl From dean.long at oracle.com Fri Oct 4 22:47:52 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Oct 2019 15:47:52 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> References: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> Message-ID: <3ae4de07-95ec-b8f1-b27f-e0e8bfb80c12@oracle.com> Thanks Vladimir. dl On 10/4/19 1:03 PM, Vladimir Kozlov wrote: > Good. > > Thanks > Vladimir > >> On Oct 4, 2019, at 12:29 PM, dean.long at oracle.com wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8231902 >> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >> >> A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output. The simple fix is to create an empty file in the directory. >> >> dl From magnus.ihse.bursie at oracle.com Mon Oct 7 08:49:48 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 7 Oct 2019 10:49:48 +0200 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> References: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> Message-ID: <6faea9f8-df75-45bd-6f4b-50006a475dd8@oracle.com> On 2019-10-05 00:09, dean.long at oracle.com wrote: > Here's an alternative version with $(NAWK) usage suggested by Erik > Joelsson: > > http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ This one looks good to me. /Magnus > > dl > > On 10/4/19 12:29 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231902 >> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >> >> A recent upstream Graal change causes the META-INF/providers >> directory to contain only a single file, causing the $(GREP) command >> to not prepend the filename to the output.? The simple fix is to >> create an empty file in the directory. >> >> dl > From jan.lahoda at oracle.com Mon Oct 7 10:40:08 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 7 Oct 2019 12:40:08 +0200 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: References: Message-ID: <78308536-1708-46b9-d657-9babbf55daec@oracle.com> Hi Joe, Thanks for the suggestion, but I don't think we can do it using Taglets - as far as I know, Taglets cannot add tabs to the method listing. We would either need to modify javadoc, or (maybe) have a special doclet for JDK documentation. Jan On 04. 10. 19 7:08, Joe Darcy wrote: > Hi Jan, > > For future work, consider having a "Preview Methods" tag alongside > static, instance, deprecated, etc. > > Cheers, > > -Joe > > On 10/3/2019 2:57 AM, Jan Lahoda wrote: >> Hi, >> >> This is a continuation of Joe's patch from here: >> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >> >> >> APIs associated with preview features are split into two groups: >> essential and non-essential. These are marked with an JDK-internal >> annotation, PreviewFeature, and a tag in the javadoc, @preview. The >> javac follows the PreviewFeature annotation, and produces either >> warnings or errors for the usages of such APIs. For the @preview tag, >> there is a taglet in the JDK build that adds the content of the tag >> into the documentation. The first part of the @preview's text goes >> into the summary, the second part goes into the detailed description. >> >> For build, a tricky problem is that the jdk.compiler module uses the >> PreviewFeature annotation as well, but that is not in the bootstrap >> JDK. So, for the intermediate langtools build, the PreviewFeature >> annotation is copied from java.base. >> >> Proposed webrev: >> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >> >> Javadoc with the change: >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >> >> See for example: >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >> >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >> >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8226585 >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8231411 >> >> Feedback is welcome! >> >> Thanks, >> ??? Jan From erik.joelsson at oracle.com Mon Oct 7 15:20:57 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Oct 2019 08:20:57 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> References: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> Message-ID: <994c7bcf-1632-fe1a-fad3-a58d17371730@oracle.com> Looks good! Thanks! /Erik On 2019-10-04 15:09, dean.long at oracle.com wrote: > Here's an alternative version with $(NAWK) usage suggested by Erik > Joelsson: > > http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ > > dl > > On 10/4/19 12:29 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231902 >> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >> >> A recent upstream Graal change causes the META-INF/providers >> directory to contain only a single file, causing the $(GREP) command >> to not prepend the filename to the output.? The simple fix is to >> create an empty file in the directory. >> >> dl > From dean.long at oracle.com Mon Oct 7 20:20:38 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 7 Oct 2019 13:20:38 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <994c7bcf-1632-fe1a-fad3-a58d17371730@oracle.com> References: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> <994c7bcf-1632-fe1a-fad3-a58d17371730@oracle.com> Message-ID: <3691e3fc-5167-dff5-334b-6f4a0604aa20@oracle.com> Thanks Magnus and Erik! dl On 10/7/19 8:20 AM, Erik Joelsson wrote: > Looks good! Thanks! > > /Erik > > On 2019-10-04 15:09, dean.long at oracle.com wrote: >> Here's an alternative version with $(NAWK) usage suggested by Erik >> Joelsson: >> >> http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ >> >> dl >> >> On 10/4/19 12:29 PM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8231902 >>> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >>> >>> A recent upstream Graal change causes the META-INF/providers >>> directory to contain only a single file, causing the $(GREP) command >>> to not prepend the filename to the output.? The simple fix is to >>> create an empty file in the directory. >>> >>> dl >> From jan.lahoda at oracle.com Tue Oct 8 15:27:10 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 8 Oct 2019 17:27:10 +0200 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: References: Message-ID: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> Thanks for the new code Erik! A new webrev/patch that includes this better way of copying is here: http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ Any feedback is welcome! Thanks, Jan On 03. 10. 19 18:06, Erik Joelsson wrote: > Hello Jan, > > The build change looks ok, but I would recommend this construct for > copying the file instead: > > $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ > ??? FILES := > $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \ > ??? DEST := > $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, > \ > )) > > TARGETS += $(COPY_PREVIEW_FEATURES) > > Then you automatically get all the corner case handling we have > implemented over the years for logging, making directories and copying > files. Your version is still correct for this case though. > > /Erik > > On 2019-10-03 02:57, Jan Lahoda wrote: >> Hi, >> >> This is a continuation of Joe's patch from here: >> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >> >> >> APIs associated with preview features are split into two groups: >> essential and non-essential. These are marked with an JDK-internal >> annotation, PreviewFeature, and a tag in the javadoc, @preview. The >> javac follows the PreviewFeature annotation, and produces either >> warnings or errors for the usages of such APIs. For the @preview tag, >> there is a taglet in the JDK build that adds the content of the tag >> into the documentation. The first part of the @preview's text goes >> into the summary, the second part goes into the detailed description. >> >> For build, a tricky problem is that the jdk.compiler module uses the >> PreviewFeature annotation as well, but that is not in the bootstrap >> JDK. So, for the intermediate langtools build, the PreviewFeature >> annotation is copied from java.base. >> >> Proposed webrev: >> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >> >> Javadoc with the change: >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >> >> See for example: >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >> >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >> >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8226585 >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8231411 >> >> Feedback is welcome! >> >> Thanks, >> ??? Jan From erik.joelsson at oracle.com Tue Oct 8 16:04:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 Oct 2019 09:04:17 -0700 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> Message-ID: Build changes look good. /Erik On 2019-10-08 08:27, Jan Lahoda wrote: > Thanks for the new code Erik! > > A new webrev/patch that includes this better way of copying is here: > http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ > > Any feedback is welcome! > > Thanks, > ??? Jan > > On 03. 10. 19 18:06, Erik Joelsson wrote: >> Hello Jan, >> >> The build change looks ok, but I would recommend this construct for >> copying the file instead: >> >> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >> ???? FILES := >> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, >> \ >> ???? DEST := >> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, >> \ >> )) >> >> TARGETS += $(COPY_PREVIEW_FEATURES) >> >> Then you automatically get all the corner case handling we have >> implemented over the years for logging, making directories and >> copying files. Your version is still correct for this case though. >> >> /Erik >> >> On 2019-10-03 02:57, Jan Lahoda wrote: >>> Hi, >>> >>> This is a continuation of Joe's patch from here: >>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >>> >>> >>> APIs associated with preview features are split into two groups: >>> essential and non-essential. These are marked with an JDK-internal >>> annotation, PreviewFeature, and a tag in the javadoc, @preview. The >>> javac follows the PreviewFeature annotation, and produces either >>> warnings or errors for the usages of such APIs. For the @preview >>> tag, there is a taglet in the JDK build that adds the content of the >>> tag into the documentation. The first part of the @preview's text >>> goes into the summary, the second part goes into the detailed >>> description. >>> >>> For build, a tricky problem is that the jdk.compiler module uses the >>> PreviewFeature annotation as well, but that is not in the bootstrap >>> JDK. So, for the intermediate langtools build, the PreviewFeature >>> annotation is copied from java.base. >>> >>> Proposed webrev: >>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>> >>> Javadoc with the change: >>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>> >>> See for example: >>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >>> >>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >>> >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>> >>> Feedback is welcome! >>> >>> Thanks, >>> ??? Jan From erik.joelsson at oracle.com Tue Oct 8 19:24:23 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 Oct 2019 12:24:23 -0700 Subject: RFR: JDK-8231974: Build fails if no common legal notices are present Message-ID: <9f8fb466-bdbb-1368-dee2-6fa743de3a86@oracle.com> In certain Oracle build configurations, the common legal output directory is never created, because there are no legal files to put in it. This should not make the build fail. This patch makes adding the --legal-notices parameter to jmod optional. Bug: https://bugs.openjdk.java.net/browse/JDK-8231974 Webrev: http://cr.openjdk.java.net/~erikj/8231974/webrev.01/ /Erik From david.holmes at oracle.com Wed Oct 9 02:21:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Oct 2019 12:21:18 +1000 Subject: RFR: JDK-8231974: Build fails if no common legal notices are present In-Reply-To: <9f8fb466-bdbb-1368-dee2-6fa743de3a86@oracle.com> References: <9f8fb466-bdbb-1368-dee2-6fa743de3a86@oracle.com> Message-ID: Looks good to me. Thanks, David On 9/10/2019 5:24 am, Erik Joelsson wrote: > In certain Oracle build configurations, the common legal output > directory is never created, because there are no legal files to put in > it. This should not make the build fail. This patch makes adding the > --legal-notices parameter to jmod optional. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231974 > > Webrev: http://cr.openjdk.java.net/~erikj/8231974/webrev.01/ > > /Erik > From mandy.chung at oracle.com Wed Oct 9 05:01:55 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Oct 2019 22:01:55 -0700 Subject: RFR: JDK-8231974: Build fails if no common legal notices are present In-Reply-To: <9f8fb466-bdbb-1368-dee2-6fa743de3a86@oracle.com> References: <9f8fb466-bdbb-1368-dee2-6fa743de3a86@oracle.com> Message-ID: <323a38f5-202d-41aa-2e96-3e24865d7524@oracle.com> Looks okay to me. Mandy On 10/8/19 12:24 PM, Erik Joelsson wrote: > In certain Oracle build configurations, the common legal output > directory is never created, because there are no legal files to put in > it. This should not make the build fail. This patch makes adding the > --legal-notices parameter to jmod optional. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231974 > > Webrev: http://cr.openjdk.java.net/~erikj/8231974/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Wed Oct 9 07:35:08 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 9 Oct 2019 09:35:08 +0200 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system In-Reply-To: References: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> <9442650b-c98f-bc3b-6b7e-e9fc0c34b73d@oracle.com> Message-ID: On 2019-10-04 15:16, Erik Joelsson wrote: > On 2019-10-04 04:37, Magnus Ihse Bursie wrote: >> On 2019-10-02 17:40, Erik Joelsson wrote: >>> Hello Magnus, >>> >>> The change looks good, but should perhaps also include removal of >>> the few scattered specific instances of LANG=C and LC_ALL=C in the >>> makefiles: >>> >>> make/common/JavaCompilation.gmk:??? export LC_ALL=C ; ( $(CAT) $$< >>> && $(ECHO) "" ) \ >>> >>> make/autoconf/basics.m4:? DATE_WHEN_CONFIGURED=`LANG=C date` >>> >>> Also compare.sh has a bunch which could be replaced with one export >>> at the top. >> Ok, here's an updated version where I've deleted all other LC_* and >> LANG assignments in the build system. FWIW, I found a few instances >> in test code, but I did not change that. >> >> http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.02 >> > The removal in RunTestPrebuilt.gmk reminded me that we do not run > configure before running tests, and in that situation spec.gmk.in is > not used either. The same export needs to be added somewhere in the > run-test-prebuilt chain of invocations. Good catch! Here's an updated webrev; the only change is in RunTestsPrebuiltSpec.gmk: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.03 (Third times's a charm...) > >>> I would expect a full round of builds-infra to be run for this, as >>> well as explicit compare builds as subtle things could be changing. >> Yes, of course. My original patch has already made the rounds on the >> builds-infra test suite without any issues, but I'll do a rerun with >> this second version of the patch as well. >> > Thanks! It turned out that I had forgotten how to properly run COMPARE_BUILD on our build system, so while I did test that it built fine even on esoteric platforms and combinations using builds-infra, I did not in fact verify that there was no changes. :-/ When I reran this properly, I found two mismatches, one on macOS and one on Windows. I pinpointed the macOS issue, and Erik helped me with the Windows issue (thanks Erik!). Both of them turned out to be real (if minor) problems we had, where the build output on those platform were different due to the lack of LC_ALL. So this does indeed confirm that this patch helps! :-) /Magnus > > /Erik > >> /Magnus >>> >>> /Erik >>> >>> On 2019-10-02 02:06, Magnus Ihse Bursie wrote: >>>> From the bug report: >>>> We should prefix LC_ALL=C for most, maybe all, tools we use when >>>> building. >>>> >>>> This probably means we should run "export LC_ALL=C" early in the >>>> configure script as well. >>>> --- >>>> >>>> The fix itself is trivial. While I know we've had several issues >>>> regarding localization, I could not find any specific instances now >>>> that I was looking for them. I searched JBS for a while but could >>>> not dig up anything that was reproducible. So, unfortunately, I >>>> have been unable to verify that this solves any actual problems. >>>> That being said, I believe this is a prudent fix that should have >>>> been in place long time ago. But if anyone can give me a concrete >>>> example that breaks so that I can verify that this helps, please >>>> let me know. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 >>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 >>>> >>>> /Magnus >> From magnus.ihse.bursie at oracle.com Wed Oct 9 08:39:08 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 9 Oct 2019 10:39:08 +0200 Subject: RFR: JDK-8231974: Build fails if no common legal notices are present In-Reply-To: <9f8fb466-bdbb-1368-dee2-6fa743de3a86@oracle.com> References: <9f8fb466-bdbb-1368-dee2-6fa743de3a86@oracle.com> Message-ID: LGTM. /Magnus > 8 okt. 2019 kl. 21:24 skrev Erik Joelsson : > > In certain Oracle build configurations, the common legal output directory is never created, because there are no legal files to put in it. This should not make the build fail. This patch makes adding the --legal-notices parameter to jmod optional. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231974 > > Webrev: http://cr.openjdk.java.net/~erikj/8231974/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Wed Oct 9 08:42:56 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 9 Oct 2019 10:42:56 +0200 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> Message-ID: <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> I can?t see how the compilation is dependent on the copy being finished. Since Erik contributed this it will probably be correct :) but I?d appreciate an explanation on how this dependency is guaranteed. Or maybe I?m misunderstanding what this is supposed to do? /Magnus > 8 okt. 2019 kl. 17:27 skrev Jan Lahoda : > > Thanks for the new code Erik! > > A new webrev/patch that includes this better way of copying is here: > http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ > > Any feedback is welcome! > > Thanks, > Jan > >> On 03. 10. 19 18:06, Erik Joelsson wrote: >> Hello Jan, >> The build change looks ok, but I would recommend this construct for copying the file instead: >> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >> FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \ >> DEST := $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, \ >> )) >> TARGETS += $(COPY_PREVIEW_FEATURES) >> Then you automatically get all the corner case handling we have implemented over the years for logging, making directories and copying files. Your version is still correct for this case though. >> /Erik >>> On 2019-10-03 02:57, Jan Lahoda wrote: >>> Hi, >>> >>> This is a continuation of Joe's patch from here: >>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >>> >>> APIs associated with preview features are split into two groups: essential and non-essential. These are marked with an JDK-internal annotation, PreviewFeature, and a tag in the javadoc, @preview. The javac follows the PreviewFeature annotation, and produces either warnings or errors for the usages of such APIs. For the @preview tag, there is a taglet in the JDK build that adds the content of the tag into the documentation. The first part of the @preview's text goes into the summary, the second part goes into the detailed description. >>> >>> For build, a tricky problem is that the jdk.compiler module uses the PreviewFeature annotation as well, but that is not in the bootstrap JDK. So, for the intermediate langtools build, the PreviewFeature annotation is copied from java.base. >>> >>> Proposed webrev: >>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>> >>> Javadoc with the change: >>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>> >>> See for example: >>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>> >>> Feedback is welcome! >>> >>> Thanks, >>> Jan From erik.joelsson at oracle.com Wed Oct 9 15:41:22 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 Oct 2019 08:41:22 -0700 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> Message-ID: Oh, you are absolutely correct, the dependency is missing. We need something like this inside "define SetupInterimModule": $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES) /Erik On 2019-10-09 01:42, Magnus Ihse Bursie wrote: > I can?t see how the compilation is dependent on the copy being finished. Since Erik contributed this it will probably be correct :) but I?d appreciate an explanation on how this dependency is guaranteed. > > Or maybe I?m misunderstanding what this is supposed to do? > > /Magnus > >> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda : >> >> Thanks for the new code Erik! >> >> A new webrev/patch that includes this better way of copying is here: >> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ >> >> Any feedback is welcome! >> >> Thanks, >> Jan >> >>> On 03. 10. 19 18:06, Erik Joelsson wrote: >>> Hello Jan, >>> The build change looks ok, but I would recommend this construct for copying the file instead: >>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >>> FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \ >>> DEST := $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, \ >>> )) >>> TARGETS += $(COPY_PREVIEW_FEATURES) >>> Then you automatically get all the corner case handling we have implemented over the years for logging, making directories and copying files. Your version is still correct for this case though. >>> /Erik >>>> On 2019-10-03 02:57, Jan Lahoda wrote: >>>> Hi, >>>> >>>> This is a continuation of Joe's patch from here: >>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >>>> >>>> APIs associated with preview features are split into two groups: essential and non-essential. These are marked with an JDK-internal annotation, PreviewFeature, and a tag in the javadoc, @preview. The javac follows the PreviewFeature annotation, and produces either warnings or errors for the usages of such APIs. For the @preview tag, there is a taglet in the JDK build that adds the content of the tag into the documentation. The first part of the @preview's text goes into the summary, the second part goes into the detailed description. >>>> >>>> For build, a tricky problem is that the jdk.compiler module uses the PreviewFeature annotation as well, but that is not in the bootstrap JDK. So, for the intermediate langtools build, the PreviewFeature annotation is copied from java.base. >>>> >>>> Proposed webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>>> >>>> Javadoc with the change: >>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>>> >>>> See for example: >>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>>> >>>> CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>>> >>>> Feedback is welcome! >>>> >>>> Thanks, >>>> Jan From erik.joelsson at oracle.com Wed Oct 9 15:57:46 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 Oct 2019 08:57:46 -0700 Subject: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system In-Reply-To: <66489a62-3b7e-8cef-dea3-55da6163cc54@oracle.com> References: <42b700af-9f30-efb4-6b78-2aada4f9f137@oracle.com> <66489a62-3b7e-8cef-dea3-55da6163cc54@oracle.com> Message-ID: <336bc59f-adec-0c3c-c915-333d25d638e2@oracle.com> Looks good. /Erik On 2019-10-04 04:52, Magnus Ihse Bursie wrote: > On 2019-10-02 17:45, Martin Buchholz wrote: >> I recall years ago running into troubles with regex character ranges, >> e.g. >> https://unix.stackexchange.com/questions/15980/does-should-lc-collate-affect-character-ranges >> >> but my build script wrapper has been setting LC_ALL=C for a long time, >> and I set LC_COLLATE=C in my normal use shell environment > Hah, that's a funny (i.e. very unexpected, and not particularly funny > at all) side effect of localization. :) We're doing quite a lot of > "a-z" in the build systems; we should probably change them to > "[[:lower:]]". >> (do regular humans care deeply about getting localized collation order?) > But oh yes! I'd *hate* it for my ??? to be sorted anywhere but after > xyz. Probably just as much as the Germans would hate to *not* have the > ?, ? and ? sorted alongside the a, o and u. You're just having the > perspective of privilege from US-ASCII being considered the universal > default. ;-) > > /Magnus >> >> On Wed, Oct 2, 2019 at 2:09 AM Magnus Ihse Bursie >> > > wrote: >> >> ??? ?From the bug report: >> ??? We should prefix LC_ALL=C for most, maybe all, tools we use when >> ??? building. >> >> ??? This probably means we should run "export LC_ALL=C" early in the >> ??? configure script as well. >> ??? --- >> >> ??? The fix itself is trivial. While I know we've had several issues >> ??? regarding localization, I could not find any specific instances >> ??? now that >> ??? I was looking for them. I searched JBS for a while but could not >> ??? dig up >> ??? anything that was reproducible. So, unfortunately, I have been >> ??? unable to >> ??? verify that this solves any actual problems. That being said, I >> ??? believe >> ??? this is a prudent fix that should have been in place long time >> ??? ago. But >> ??? if anyone can give me a concrete example that breaks so that I can >> ??? verify that this helps, please let me know. >> >> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8065704 >> ??? WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8065704-LC_ALL/webrev.01 >> >> ??? /Magnus >> > From christoph.langer at sap.com Thu Oct 10 12:16:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 12:16:25 +0000 Subject: [11u] RFR: 8212028: Use run-test makefile framework for testing in Oracle's Mach5 Message-ID: Hi, please help reviewing this backport of a build infrastructure change to jdk11u. One reason for doing this is parity with Oracle's 11.0.6 but the patch also contains some test improvements which will help stabilizing 11u testing. This mainly means increasing some test timeouts for a few tests that tend to timeout on slow or busy test hardware. The patch mostly applies, apart from these two rejects: make/RunTests.gmk: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028-RunTests.gmk.rej make/RunTestsPrebuilt.gmk: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028-RunTestsPrebuilt.gmk.rej So, when reviewing, please have the most thorough look at these places. I ran the fix through our nightly tests and didn't find regressions. I'm planning to push backport JDK-8213005 together with this change, as it fixes a regression for it. Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/28375a1de254 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/ Thanks Christoph From sgehwolf at redhat.com Thu Oct 10 13:14:32 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Oct 2019 15:14:32 +0200 Subject: [11u] RFR: 8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: References: Message-ID: <944b97e0ea1b85db6b6a3c9cb36ef3ac3973b728.camel@redhat.com> Hi Christoph, On Thu, 2019-10-10 at 12:16 +0000, Langer, Christoph wrote: > Hi, > > please help reviewing this backport of a build infrastructure change to jdk11u. > > One reason for doing this is parity with Oracle's 11.0.6 but the patch also contains some test improvements which will help stabilizing 11u testing. This mainly means increasing some test timeouts for a few tests that tend to timeout on slow or busy test hardware. > > The patch mostly applies, apart from these two rejects: > make/RunTests.gmk: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028-RunTests.gmk.rej > make/RunTestsPrebuilt.gmk: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028-RunTestsPrebuilt.gmk.rej > So, when reviewing, please have the most thorough look at these places. > > I ran the fix through our nightly tests and didn't find regressions. I'm planning to push backport JDK-8213005 together with this change, as it fixes a regression for it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/28375a1de254 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/ 222 langtools_JTREG_MAX_MEM := 768m 223 224 langtools_JTREG_MAX_MEM := 768m Lines 222 and 224 in RunTests.gmk are duplicates. Otherwise seems fine. Thanks, Severin From christoph.langer at sap.com Thu Oct 10 13:47:40 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 13:47:40 +0000 Subject: [11u] RFR: 8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <944b97e0ea1b85db6b6a3c9cb36ef3ac3973b728.camel@redhat.com> References: <944b97e0ea1b85db6b6a3c9cb36ef3ac3973b728.camel@redhat.com> Message-ID: Hi Severin, good catch, thank you. Adjusted webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.1/ Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 10. Oktober 2019 15:15 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; build-dev > Subject: Re: [11u] RFR: 8212028: Use run-test makefile framework for testing > in Oracle's Mach5 > > Hi Christoph, > > On Thu, 2019-10-10 at 12:16 +0000, Langer, Christoph wrote: > > Hi, > > > > please help reviewing this backport of a build infrastructure change to > jdk11u. > > > > One reason for doing this is parity with Oracle's 11.0.6 but the patch also > contains some test improvements which will help stabilizing 11u testing. This > mainly means increasing some test timeouts for a few tests that tend to > timeout on slow or busy test hardware. > > > > The patch mostly applies, apart from these two rejects: > > make/RunTests.gmk: > http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028- > RunTests.gmk.rej > > make/RunTestsPrebuilt.gmk: > http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028- > RunTestsPrebuilt.gmk.rej > > So, when reviewing, please have the most thorough look at these places. > > > > I ran the fix through our nightly tests and didn't find regressions. I'm > planning to push backport JDK-8213005 together with this change, as it fixes a > regression for it. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/28375a1de254 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u- > dev.0/ > > 222 langtools_JTREG_MAX_MEM := 768m > 223 > 224 langtools_JTREG_MAX_MEM := 768m > > Lines 222 and 224 in RunTests.gmk are duplicates. > > Otherwise seems fine. > > Thanks, > Severin From maurizio.cimadamore at oracle.com Thu Oct 10 15:54:21 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Oct 2019 16:54:21 +0100 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: References: Message-ID: The javac changes looks good. I guess I would have preferred to move the check for preview from Check to Preview, and also create a tighter integration between PreviewFeature.Feature and javac's Feature enum, so that we could generate tight error messages, but I guess we can also do that as a followup. Maurizio On 03/10/2019 10:57, Jan Lahoda wrote: > Hi, > > This is a continuation of Joe's patch from here: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html > > > APIs associated with preview features are split into two groups: > essential and non-essential. These are marked with an JDK-internal > annotation, PreviewFeature, and a tag in the javadoc, @preview. The > javac follows the PreviewFeature annotation, and produces either > warnings or errors for the usages of such APIs. For the @preview tag, > there is a taglet in the JDK build that adds the content of the tag > into the documentation. The first part of the @preview's text goes > into the summary, the second part goes into the detailed description. > > For build, a tricky problem is that the jdk.compiler module uses the > PreviewFeature annotation as well, but that is not in the bootstrap > JDK. So, for the intermediate langtools build, the PreviewFeature > annotation is copied from java.base. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ > > Javadoc with the change: > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html > > See for example: > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html > > http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html > > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8226585 > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8231411 > > Feedback is welcome! > > Thanks, > ??? Jan From jorn.vernee at oracle.com Wed Oct 9 14:00:15 2019 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Wed, 9 Oct 2019 16:00:15 +0200 Subject: VS install found through --with-tools-dir value is discarded Message-ID: <342bd880-b8bd-d721-f321-7958a54a7610@oracle.com> Hi, I was testing with different versions of Visual Studio to try and nail down the source of a deprecation warning. I was using the --with-tools-dir config option to quickly switch between installations but noticed the VS install that was being found through that method was being discarded, leading to a failed configuration. The fix is pretty simple: http://cr.openjdk.java.net/~jvernee/vs_tools_dir/webrev.00/ The TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT macro sets the VS_ENV_CMD? var, and skips doing anything when it is already set. So, previously, by setting it to an empty string _after_ the check for --with-tools-dir any VS install that's found with that method is always discarded, or otherwise overwritten when another method for finding a VS installation also works. With that fix selecting the VS installation works as expected. On a side note; I noticed that the hostx86 toolchain is preferred over the hostx64 version in VS 2017+, due to the order of values in VCVARSFILES in TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT. Is there any particular reason for this? I'd expect the x64 toolchain would be preferred on x64 platforms. Jorn From erik.joelsson at oracle.com Thu Oct 10 17:52:06 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Oct 2019 10:52:06 -0700 Subject: VS install found through --with-tools-dir value is discarded In-Reply-To: <342bd880-b8bd-d721-f321-7958a54a7610@oracle.com> References: <342bd880-b8bd-d721-f321-7958a54a7610@oracle.com> Message-ID: <5402c03c-e82b-81c0-a3f9-aff9fe48ab3b@oracle.com> Hello Jorn, On 2019-10-09 07:00, Jorn Vernee wrote: > Hi, > > I was testing with different versions of Visual Studio to try and nail > down the source of a deprecation warning. I was using the > --with-tools-dir config option to quickly switch between installations > but noticed the VS install that was being found through that method > was being discarded, leading to a failed configuration. > > The fix is pretty simple: > http://cr.openjdk.java.net/~jvernee/vs_tools_dir/webrev.00/ > > The TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT macro sets the > VS_ENV_CMD? var, and skips doing anything when it is already set. So, > previously, by setting it to an empty string _after_ the check for > --with-tools-dir any VS install that's found with that method is > always discarded, or otherwise overwritten when another method for > finding a VS installation also works. > Looks good, thanks for fixing it! > With that fix selecting the VS installation works as expected. > > On a side note; I noticed that the hostx86 toolchain is preferred over > the hostx64 version in VS 2017+, due to the order of values in > VCVARSFILES in TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT. Is there > any particular reason for this? I'd expect the x64 toolchain would be > preferred on x64 platforms. > Hm, I think I agree. I'm probably responsible for that choice and I think I was just trying to be conservative with changes. Would you mind changing it and see if it has any effect on performance? /Erik > Jorn > From erik.joelsson at oracle.com Thu Oct 10 18:27:30 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Oct 2019 11:27:30 -0700 Subject: RFR: JDK-8232133: Change to GCC 8.3 for building on Linux at Oracle Message-ID: <0f00d6e3-e420-a81f-bac0-d3736fc40ef2@oracle.com> Updating defaults in devkit creator makefiles. Also remembering to update building.md this time. Webrev: http://cr.openjdk.java.net/~erikj/8232133/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8232133 /Erik From erik.joelsson at oracle.com Thu Oct 10 18:31:08 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Oct 2019 11:31:08 -0700 Subject: RFR: JDK-8232134: Change to Visual Studio 2017 15.9.16 for building on Windows at Oracle Message-ID: <8599a0fd-4e47-52da-ee8e-6bf6595dca27@oracle.com> Removed some hard coded version values from the creator script which are now generated dynamically instead anyway. Also updating the building doc. Webrev: http://cr.openjdk.java.net/~erikj/8232134/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8232134 /Erik From kim.barrett at oracle.com Thu Oct 10 22:25:56 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Oct 2019 18:25:56 -0400 Subject: RFR: JDK-8232133: Change to GCC 8.3 for building on Linux at Oracle In-Reply-To: <0f00d6e3-e420-a81f-bac0-d3736fc40ef2@oracle.com> References: <0f00d6e3-e420-a81f-bac0-d3736fc40ef2@oracle.com> Message-ID: <8BE6DE4E-1A3C-4DD6-A452-11558136C77F@oracle.com> > On Oct 10, 2019, at 2:27 PM, Erik Joelsson wrote: > > Updating defaults in devkit creator makefiles. Also remembering to update building.md this time. > > Webrev: http://cr.openjdk.java.net/~erikj/8232133/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232133 > > /Erik doc/building.md 341 The JDK is currently known to be able to compile with at least version 7.4 of 342 gcc. Maybe things like the above should get cleaned up while you are here. Other than that, looks good to me. I don?t need another webrev for version updates like that mentioned above. From david.holmes at oracle.com Thu Oct 10 23:30:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2019 09:30:49 +1000 Subject: RFR: JDK-8232133: Change to GCC 8.3 for building on Linux at Oracle In-Reply-To: <0f00d6e3-e420-a81f-bac0-d3736fc40ef2@oracle.com> References: <0f00d6e3-e420-a81f-bac0-d3736fc40ef2@oracle.com> Message-ID: <033ac0cc-944d-b2d3-1899-4e25c98d954a@oracle.com> Hi Erik, On 11/10/2019 4:27 am, Erik Joelsson wrote: > Updating defaults in devkit creator makefiles. Also remembering to > update building.md this time. > > Webrev: http://cr.openjdk.java.net/~erikj/8232133/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232133 Seems okay. I'm somewhat surprised this is such a small update from 8.2 to 8.3 - hardly seems worthwhile. I assume we will jump 9.x next time? Thanks, David > /Erik > From magnus.ihse.bursie at oracle.com Fri Oct 11 07:02:17 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Oct 2019 00:02:17 -0700 (PDT) Subject: RFR: JDK-8232133: Change to GCC 8.3 for building on Linux at Oracle In-Reply-To: <0f00d6e3-e420-a81f-bac0-d3736fc40ef2@oracle.com> References: <0f00d6e3-e420-a81f-bac0-d3736fc40ef2@oracle.com> Message-ID: <8A894947-9C7F-4C96-B54E-36D9236FC66B@oracle.com> > 10 okt. 2019 kl. 20:27 skrev Erik Joelsson : > > Updating defaults in devkit creator makefiles. Also remembering to update building.md this time. > > Webrev: http://cr.openjdk.java.net/~erikj/8232133/webrev.01/ Looks good to me. /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232133 > > /Erik > From magnus.ihse.bursie at oracle.com Fri Oct 11 07:04:28 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Oct 2019 09:04:28 +0200 Subject: RFR: JDK-8232134: Change to Visual Studio 2017 15.9.16 for building on Windows at Oracle In-Reply-To: <8599a0fd-4e47-52da-ee8e-6bf6595dca27@oracle.com> References: <8599a0fd-4e47-52da-ee8e-6bf6595dca27@oracle.com> Message-ID: > 10 okt. 2019 kl. 20:31 skrev Erik Joelsson : > > Removed some hard coded version values from the creator script which are now generated dynamically instead anyway. Also updating the building doc. > > Webrev: http://cr.openjdk.java.net/~erikj/8232134/webrev.01/ Looks good to me. /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232134 > > /Erik > From magnus.ihse.bursie at oracle.com Fri Oct 11 07:06:58 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Oct 2019 09:06:58 +0200 Subject: VS install found through --with-tools-dir value is discarded In-Reply-To: <342bd880-b8bd-d721-f321-7958a54a7610@oracle.com> References: <342bd880-b8bd-d721-f321-7958a54a7610@oracle.com> Message-ID: <80B12E28-3F58-429D-BB36-82411E0F380F@oracle.com> > 9 okt. 2019 kl. 16:00 skrev Jorn Vernee : > > Hi, > > I was testing with different versions of Visual Studio to try and nail down the source of a deprecation warning. I was using the --with-tools-dir config option to quickly switch between installations but noticed the VS install that was being found through that method was being discarded, leading to a failed configuration. > > The fix is pretty simple: http://cr.openjdk.java.net/~jvernee/vs_tools_dir/webrev.00/ Thank you for the fix! Consider it reviewed. Would you mind open a JBS issue for it and push the fix? /Magnus > > The TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT macro sets the VS_ENV_CMD var, and skips doing anything when it is already set. So, previously, by setting it to an empty string _after_ the check for --with-tools-dir any VS install that's found with that method is always discarded, or otherwise overwritten when another method for finding a VS installation also works. > > With that fix selecting the VS installation works as expected. > > On a side note; I noticed that the hostx86 toolchain is preferred over the hostx64 version in VS 2017+, due to the order of values in VCVARSFILES in TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT. Is there any particular reason for this? I'd expect the x64 toolchain would be preferred on x64 platforms. > > Jorn > From sgehwolf at redhat.com Fri Oct 11 08:04:07 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Oct 2019 10:04:07 +0200 Subject: [11u] RFR: 8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: References: <944b97e0ea1b85db6b6a3c9cb36ef3ac3973b728.camel@redhat.com> Message-ID: <1ef3f2176ca444c7cf8f3c54b835d084bc51afa5.camel@redhat.com> On Thu, 2019-10-10 at 13:47 +0000, Langer, Christoph wrote: > Adjusted webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.1/ Seems OK to me. Thanks, Severin From jorn.vernee at oracle.com Fri Oct 11 11:59:24 2019 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 11 Oct 2019 13:59:24 +0200 Subject: VS install found through --with-tools-dir value is discarded In-Reply-To: <5402c03c-e82b-81c0-a3f9-aff9fe48ab3b@oracle.com> References: <342bd880-b8bd-d721-f321-7958a54a7610@oracle.com> <5402c03c-e82b-81c0-a3f9-aff9fe48ab3b@oracle.com> Message-ID: I ran the `clean images` targets with the different toolchains but didn't really notice any significant difference. FWIW, for older versions of VS the x64 toolchain does seem to be preferred: ??????? VCVARSFILES="vc/bin/amd64/vcvars64.bat vc/bin/x86_amd64/vcvarsx86_amd64.bat \ ??????????? VC/Auxiliary/Build/vcvarsx86_amd64.bat VC/Auxiliary/Build/vcvars64.bat" (The last 2 paths are for the newer version) Using the x64 toolchain might be useful for preventing crashes due to running out of memory. I've run into a compiler/linker crash a couple of times in? the past, though I'm not sure they were caused by OOM, that seems the most likely to me. Jorn On 10/10/2019 19:52, Erik Joelsson wrote: > Hello Jorn, > > On 2019-10-09 07:00, Jorn Vernee wrote: >> Hi, >> >> I was testing with different versions of Visual Studio to try and >> nail down the source of a deprecation warning. I was using the >> --with-tools-dir config option to quickly switch between >> installations but noticed the VS install that was being found through >> that method was being discarded, leading to a failed configuration. >> >> The fix is pretty simple: >> http://cr.openjdk.java.net/~jvernee/vs_tools_dir/webrev.00/ >> >> The TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT macro sets the >> VS_ENV_CMD? var, and skips doing anything when it is already set. So, >> previously, by setting it to an empty string _after_ the check for >> --with-tools-dir any VS install that's found with that method is >> always discarded, or otherwise overwritten when another method for >> finding a VS installation also works. >> > Looks good, thanks for fixing it! >> With that fix selecting the VS installation works as expected. >> >> On a side note; I noticed that the hostx86 toolchain is preferred >> over the hostx64 version in VS 2017+, due to the order of values in >> VCVARSFILES in TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT. Is there >> any particular reason for this? I'd expect the x64 toolchain would be >> preferred on x64 platforms. >> > Hm, I think I agree. I'm probably responsible for that choice and I > think I was just trying to be conservative with changes. Would you > mind changing it and see if it has any effect on performance? > > /Erik > >> Jorn >> From jorn.vernee at oracle.com Fri Oct 11 12:09:52 2019 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 11 Oct 2019 14:09:52 +0200 Subject: VS install found through --with-tools-dir value is discarded In-Reply-To: <80B12E28-3F58-429D-BB36-82411E0F380F@oracle.com> References: <342bd880-b8bd-d721-f321-7958a54a7610@oracle.com> <80B12E28-3F58-429D-BB36-82411E0F380F@oracle.com> Message-ID: <249e29fe-d65a-99a7-7b52-35d6f84657dc@oracle.com> Hi Magnus, I've created a JBS ticket for it: https://bugs.openjdk.java.net/browse/JDK-8232167 But, I'm not a committer on the jdk project, so I would need a sponsor. Could you push the patch? Thanks, Jorn On 11/10/2019 09:06, Magnus Ihse Bursie wrote: >> 9 okt. 2019 kl. 16:00 skrev Jorn Vernee : >> >> Hi, >> >> I was testing with different versions of Visual Studio to try and nail down the source of a deprecation warning. I was using the --with-tools-dir config option to quickly switch between installations but noticed the VS install that was being found through that method was being discarded, leading to a failed configuration. >> >> The fix is pretty simple: http://cr.openjdk.java.net/~jvernee/vs_tools_dir/webrev.00/ > Thank you for the fix! Consider it reviewed. Would you mind open a JBS issue for it and push the fix? > > /Magnus > >> The TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT macro sets the VS_ENV_CMD var, and skips doing anything when it is already set. So, previously, by setting it to an empty string _after_ the check for --with-tools-dir any VS install that's found with that method is always discarded, or otherwise overwritten when another method for finding a VS installation also works. >> >> With that fix selecting the VS installation works as expected. >> >> On a side note; I noticed that the hostx86 toolchain is preferred over the hostx64 version in VS 2017+, due to the order of values in VCVARSFILES in TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT. Is there any particular reason for this? I'd expect the x64 toolchain would be preferred on x64 platforms. >> >> Jorn >> From erik.joelsson at oracle.com Fri Oct 11 13:39:41 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Oct 2019 06:39:41 -0700 Subject: RFR: JDK-8232133: Change to GCC 8.3 for building on Linux at Oracle In-Reply-To: <8BE6DE4E-1A3C-4DD6-A452-11558136C77F@oracle.com> References: <0f00d6e3-e420-a81f-bac0-d3736fc40ef2@oracle.com> <8BE6DE4E-1A3C-4DD6-A452-11558136C77F@oracle.com> Message-ID: <19527085-fbde-254c-c888-34465490ece9@oracle.com> On 2019-10-10 15:25, Kim Barrett wrote: >> On Oct 10, 2019, at 2:27 PM, Erik Joelsson wrote: >> >> Updating defaults in devkit creator makefiles. Also remembering to update building.md this time. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8232133/webrev.01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232133 >> >> /Erik > doc/building.md > 341 The JDK is currently known to be able to compile with at least version 7.4 of > 342 gcc. > > Maybe things like the above should get cleaned up while you are here. > > Other than that, looks good to me. I don?t need another webrev for version updates > like that mentioned above. Thanks! I've updated that line to 8.3. /Erik From erik.joelsson at oracle.com Fri Oct 11 14:10:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Oct 2019 07:10:48 -0700 Subject: VS install found through --with-tools-dir value is discarded In-Reply-To: <249e29fe-d65a-99a7-7b52-35d6f84657dc@oracle.com> References: <342bd880-b8bd-d721-f321-7958a54a7610@oracle.com> <80B12E28-3F58-429D-BB36-82411E0F380F@oracle.com> <249e29fe-d65a-99a7-7b52-35d6f84657dc@oracle.com> Message-ID: <697b5e4c-c948-1f9a-185a-d27676ff6085@oracle.com> Done. /Erik On 2019-10-11 05:09, Jorn Vernee wrote: > Hi Magnus, > > I've created a JBS ticket for it: > https://bugs.openjdk.java.net/browse/JDK-8232167 > > But, I'm not a committer on the jdk project, so I would need a > sponsor. Could you push the patch? > > Thanks, > Jorn > > On 11/10/2019 09:06, Magnus Ihse Bursie wrote: >>> 9 okt. 2019 kl. 16:00 skrev Jorn Vernee : >>> >>> Hi, >>> >>> I was testing with different versions of Visual Studio to try and >>> nail down the source of a deprecation warning. I was using the >>> --with-tools-dir config option to quickly switch between >>> installations but noticed the VS install that was being found >>> through that method was being discarded, leading to a failed >>> configuration. >>> >>> The fix is pretty simple: >>> http://cr.openjdk.java.net/~jvernee/vs_tools_dir/webrev.00/ >> Thank you for the fix! Consider it reviewed. Would you mind open a >> JBS issue for it and push the fix? >> >> /Magnus >> >>> The TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT macro sets the >>> VS_ENV_CMD? var, and skips doing anything when it is already set. >>> So, previously, by setting it to an empty string _after_ the check >>> for --with-tools-dir any VS install that's found with that method is >>> always discarded, or otherwise overwritten when another method for >>> finding a VS installation also works. >>> >>> With that fix selecting the VS installation works as expected. >>> >>> On a side note; I noticed that the hostx86 toolchain is preferred >>> over the hostx64 version in VS 2017+, due to the order of values in >>> VCVARSFILES in TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT. Is there >>> any particular reason for this? I'd expect the x64 toolchain would >>> be preferred on x64 platforms. >>> >>> Jorn >>> From magnus.ihse.bursie at oracle.com Mon Oct 14 08:37:57 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 Oct 2019 10:37:57 +0200 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Message-ID: On 2019-10-11 15:38, Yasumasa Suenaga wrote: > Hi, > > Christos commented to B-1. Thanks! > clang defines __GNU_C__ , but stringop-truncation is not supported. > > So I updated Plan B-1. It works fine on my Fedora30 box. > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B-1. Use #pragma > http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.02/ > > ? C. Set -Wno-stringop-truncation in globally > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ Please note that if you chose to go with route C, you need to get this reviewed on build-dev (as all changes in the makefiles are). The patch as currently suggested is not acceptable; the built-in functions for testing compiler version needs to be used, as a minimum. /Magnus > > > Of course I will push the change to submit repo before sending review > request. > > > Thanks, > > Yasumasa > > > On 2019/10/11 15:55, Yasumasa Suenaga wrote: >> Hi, >> >> Thanks for a lot advises! >> >> We have following solutions for this issue. >> I'd like to send RFR again with much consented patch in early next week. >> >> >> ?? A. Use memcpy() >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ?? B-1. Use #pragma >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ >> >> ?? C. Set -Wno-stringop-truncation in globally >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ >> >> >> If we fix with C, I will send RFR to hotspot-dev and build-dev. >> Plan C also fixes other stringop-truncation problems such as >> JDK-8220074. >> Thus it affects all of JDK code, but it would be useful if >> stringop-truncation >> should be disabled in JDK build process. >> >> >> Comments are welcome. >> >> Yasumasa >> >> >> On 2019/10/11 10:34, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I want to get conclusion of this discussion. >>> >>> I understand the fix of macroAssembler_x86.hpp is ok, but we have >>> not yet had conclusion >>> how we should fix diagnosticArgument.cpp . >>> >>> I think we can fix diagnosticArgument.cpp as following: >>> >>> >>> ?? A. Use memcpy() >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ?? B. Add -Wno-stringop-truncation to >>> make/hotspot/lib/JvmOverrideFiles.gmk >>> ??????? This option will be added diagnosticArgument.cpp only. >>> >>> ?? C. Set -Wno-stringop-truncation in globally >>> ??????? make/hotspot/lib/CompileJvm.gmk >>> >>> >>> I prefer to fix like A because it affects minimally. >>> Some issues might be found out by stringop-truncation in future. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>>> wrote: >>>>> >>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>> ?From JBS: >>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>>> truncated before terminating nul copying as many bytes from a >>>>>> string as its length [-Wstringop-truncation] >>>>>> ?? 154 | strncpy(buf, str, len); >>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>> I assume this means that in all cases the "len" value is seen to >>>>>> be derived from strlen, and therefore strncpy is always copying >>>>>> one byte short of \0, and this is most likely not what the user >>>>>> wants. I seem to >>>>> >>>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>>> expected/required pattern for this. >>>>> >>>>>> recall another recent similar fix that was done by switching to >>>>>> using memcpy instead. >>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>> >>>>> >>>>> Seems to me that strncpy and memcpy are semantically equivalent >>>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>>> inclined to use the: >>>>> >>>>> #pragma GCC diagnostic push >>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>> >>>>> solution. >>>>> >>>>> YMMV. >>>> >>>> We've run into and discussed problems with -Wstringop-truncation >>>> before.? (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>> relatively recent warning option (introduced in gcc8, and included in >>>> -Wall), and seems to have a considerable bug tail: >>>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>> resolved associated bugs. >>>> >>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>> this warning while it is so buggy. >>>> From magnus.ihse.bursie at oracle.com Tue Oct 15 10:19:59 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Oct 2019 12:19:59 +0200 Subject: RFR: JDK-8223998 Missing MakeDir in ExecuteWithLog Message-ID: <25fa8f9d-24db-522c-830c-0da3262666a9@oracle.com> The ExecuteWithLog macro in make/MakeBase.gmk has logic to handle the case where the command to run returns an error. Part of the error handling is copying the resulting log file to the failure-logs directory. However, that directory may not exist, so the copy may fail. Also, in the LogCmdlines call at the start of the macro "Executing" is misspelled. Bug: https://bugs.openjdk.java.net/browse/JDK-8223998 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8223998-missing-makedir-in-executewithlog/webrev.01 /Magnus From tim.bell at oracle.com Tue Oct 15 12:26:12 2019 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 15 Oct 2019 05:26:12 -0700 Subject: RFR: JDK-8223998 Missing MakeDir in ExecuteWithLog In-Reply-To: <25fa8f9d-24db-522c-830c-0da3262666a9@oracle.com> References: <25fa8f9d-24db-522c-830c-0da3262666a9@oracle.com> Message-ID: <9c450731-daaf-918f-d482-1ab7c99605d6@oracle.com> Magnus: > Bug: https://bugs.openjdk.java.net/browse/JDK-8223998 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8223998-missing-makedir-in-executewithlog/webrev.01 Looks good. Tim From magnus.ihse.bursie at oracle.com Tue Oct 15 12:47:38 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Oct 2019 14:47:38 +0200 Subject: RFR: JDK-8213239 Configure cannot handle command overrides with arguments Message-ID: When overriding a tool for configure, any options passed to that tool is lost. For instance, NICE="nice -n0" would result in NICE being just "nice". With this fix, if you send in an override like NICE="/usr/bin/nice -n0", it will verify that /usr/bin/nice exists and is executable (as before), and then it will use NICE verbatim. For an override like NICE="nice -n0" without a path, we will search the path for "nice" (just like with no override at all), and then we will append the "-n0" arguments to it. This allows for users to add arguments to tools, but still let configure find them using standard methods. Bug: https://bugs.openjdk.java.net/browse/JDK-8213239 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8213239-handle-configure-overrides-with-arguments/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Oct 15 15:25:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Oct 2019 08:25:04 -0700 Subject: RFR: JDK-8223998 Missing MakeDir in ExecuteWithLog In-Reply-To: <25fa8f9d-24db-522c-830c-0da3262666a9@oracle.com> References: <25fa8f9d-24db-522c-830c-0da3262666a9@oracle.com> Message-ID: <2cdbbbbb-2111-634f-ba53-7a04716a3dd8@oracle.com> Looks good. /Erik On 2019-10-15 03:19, Magnus Ihse Bursie wrote: > The ExecuteWithLog macro in make/MakeBase.gmk has logic to handle the > case where the command to run returns an error. Part of the error > handling is copying the resulting log file to the failure-logs > directory. However, that directory may not exist, so the copy may fail. > > Also, in the LogCmdlines call at the start of the macro "Executing" is > misspelled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223998 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8223998-missing-makedir-in-executewithlog/webrev.01 > > /Magnus From erik.joelsson at oracle.com Tue Oct 15 15:35:56 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Oct 2019 08:35:56 -0700 Subject: RFR: JDK-8213239 Configure cannot handle command overrides with arguments In-Reply-To: References: Message-ID: <1721a119-c2c6-9008-9f2e-48d1c4a6dddf@oracle.com> Looks good. /Erik On 2019-10-15 05:47, Magnus Ihse Bursie wrote: > When overriding a tool for configure, any options passed to that tool > is lost. For instance, NICE="nice -n0" would result in NICE being just > "nice". > > With this fix, if you send in an override like NICE="/usr/bin/nice > -n0", it will verify that /usr/bin/nice exists and is executable (as > before), and then it will use NICE verbatim. For an override like > NICE="nice -n0" without a path, we will search the path for "nice" > (just like with no override at all), and then we will append the "-n0" > arguments to it. This allows for users to add arguments to tools, but > still let configure find them using standard methods. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213239 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8213239-handle-configure-overrides-with-arguments/webrev.01 > > /Magnus From jan.lahoda at oracle.com Wed Oct 16 12:50:56 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 16 Oct 2019 14:50:56 +0200 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> Message-ID: <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> Hi, An updated patch is here: http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/ Changes in the update: -added the dependency into the makefiles -loosened the handling of essential preview APIs when --enable-preview and @SuppressWarnings is applied - there is no warning for the essential APIs (as there is no warning in such a case for non-essential APIs). This is per the discussion in the CSR: https://bugs.openjdk.java.net/browse/JDK-8231411 Any comments/feedback on this? Thanks! Jan On 09. 10. 19 17:41, Erik Joelsson wrote: > Oh, you are absolutely correct, the dependency is missing. > > We need something like this inside "define SetupInterimModule": > > $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES) > > /Erik > > On 2019-10-09 01:42, Magnus Ihse Bursie wrote: >> I can?t see how the compilation is dependent on the copy being >> finished. Since Erik contributed this it will probably be correct :) >> but I?d appreciate an explanation on how this dependency is guaranteed. >> >> Or maybe I?m misunderstanding what this is supposed to do? >> >> /Magnus >> >>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda : >>> >>> Thanks for the new code Erik! >>> >>> A new webrev/patch that includes this better way of copying is here: >>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> ??? Jan >>> >>>> On 03. 10. 19 18:06, Erik Joelsson wrote: >>>> Hello Jan, >>>> The build change looks ok, but I would recommend this construct for >>>> copying the file instead: >>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >>>> ???? FILES := >>>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, >>>> \ >>>> ???? DEST := >>>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, >>>> \ >>>> )) >>>> TARGETS += $(COPY_PREVIEW_FEATURES) >>>> Then you automatically get all the corner case handling we have >>>> implemented over the years for logging, making directories and >>>> copying files. Your version is still correct for this case though. >>>> /Erik >>>>> On 2019-10-03 02:57, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> This is a continuation of Joe's patch from here: >>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >>>>> >>>>> >>>>> APIs associated with preview features are split into two groups: >>>>> essential and non-essential. These are marked with an JDK-internal >>>>> annotation, PreviewFeature, and a tag in the javadoc, @preview. The >>>>> javac follows the PreviewFeature annotation, and produces either >>>>> warnings or errors for the usages of such APIs. For the @preview >>>>> tag, there is a taglet in the JDK build that adds the content of >>>>> the tag into the documentation. The first part of the @preview's >>>>> text goes into the summary, the second part goes into the detailed >>>>> description. >>>>> >>>>> For build, a tricky problem is that the jdk.compiler module uses >>>>> the PreviewFeature annotation as well, but that is not in the >>>>> bootstrap JDK. So, for the intermediate langtools build, the >>>>> PreviewFeature annotation is copied from java.base. >>>>> >>>>> Proposed webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>>>> >>>>> Javadoc with the change: >>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>>>> >>>>> See for example: >>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >>>>> >>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >>>>> >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>>>> >>>>> CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>>>> >>>>> Feedback is welcome! >>>>> >>>>> Thanks, >>>>> ???? Jan From erik.joelsson at oracle.com Wed Oct 16 12:55:12 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Oct 2019 05:55:12 -0700 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> Message-ID: Build change looks good now. /Erik On 2019-10-16 05:50, Jan Lahoda wrote: > Hi, > > An updated patch is here: > http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/ > > Changes in the update: > -added the dependency into the makefiles > -loosened the handling of essential preview APIs when --enable-preview > and @SuppressWarnings is applied - there is no warning for the > essential APIs (as there is no warning in such a case for > non-essential APIs). This is per the discussion in the CSR: > https://bugs.openjdk.java.net/browse/JDK-8231411 > > Any comments/feedback on this? > > Thanks! > ??? Jan > > On 09. 10. 19 17:41, Erik Joelsson wrote: >> Oh, you are absolutely correct, the dependency is missing. >> >> We need something like this inside "define SetupInterimModule": >> >> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES) >> >> /Erik >> >> On 2019-10-09 01:42, Magnus Ihse Bursie wrote: >>> I can?t see how the compilation is dependent on the copy being >>> finished. Since Erik contributed this it will probably be correct :) >>> but I?d appreciate an explanation on how this dependency is guaranteed. >>> >>> Or maybe I?m misunderstanding what this is supposed to do? >>> >>> /Magnus >>> >>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda : >>>> >>>> Thanks for the new code Erik! >>>> >>>> A new webrev/patch that includes this better way of copying is here: >>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ >>>> >>>> Any feedback is welcome! >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>>> On 03. 10. 19 18:06, Erik Joelsson wrote: >>>>> Hello Jan, >>>>> The build change looks ok, but I would recommend this construct >>>>> for copying the file instead: >>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >>>>> ???? FILES := >>>>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, >>>>> \ >>>>> ???? DEST := >>>>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, >>>>> \ >>>>> )) >>>>> TARGETS += $(COPY_PREVIEW_FEATURES) >>>>> Then you automatically get all the corner case handling we have >>>>> implemented over the years for logging, making directories and >>>>> copying files. Your version is still correct for this case though. >>>>> /Erik >>>>>> On 2019-10-03 02:57, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> This is a continuation of Joe's patch from here: >>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >>>>>> >>>>>> >>>>>> APIs associated with preview features are split into two groups: >>>>>> essential and non-essential. These are marked with an >>>>>> JDK-internal annotation, PreviewFeature, and a tag in the >>>>>> javadoc, @preview. The javac follows the PreviewFeature >>>>>> annotation, and produces either warnings or errors for the usages >>>>>> of such APIs. For the @preview tag, there is a taglet in the JDK >>>>>> build that adds the content of the tag into the documentation. >>>>>> The first part of the @preview's text goes into the summary, the >>>>>> second part goes into the detailed description. >>>>>> >>>>>> For build, a tricky problem is that the jdk.compiler module uses >>>>>> the PreviewFeature annotation as well, but that is not in the >>>>>> bootstrap JDK. So, for the intermediate langtools build, the >>>>>> PreviewFeature annotation is copied from java.base. >>>>>> >>>>>> Proposed webrev: >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>>>>> >>>>>> Javadoc with the change: >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>>>>> >>>>>> See for example: >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >>>>>> >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >>>>>> >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>>>>> >>>>>> CSR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>>>>> >>>>>> Feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> ???? Jan From alex.buckley at oracle.com Wed Oct 16 17:45:08 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Oct 2019 10:45:08 -0700 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> Message-ID: <07d16fc4-42a9-8f6f-992f-3ebc83e3e777@oracle.com> On 10/16/2019 5:50 AM, Jan Lahoda wrote: > -loosened the handling of essential preview APIs when --enable-preview > and @SuppressWarnings is applied - there is no warning for the essential > APIs (as there is no warning in such a case for non-essential APIs). > This is per the discussion in the CSR: > https://bugs.openjdk.java.net/browse/JDK-8231411 Thank you for implementing this change so quickly. Per the discussion in the CSR, I have updated JEP 12 to allow suppression in the case above (see http://openjdk.java.net/jeps/12#Relationship-to-Java-SE-APIs / second list / fourth bullet) and also the JLS RFE (JDK-8231433). The interesting takeaway is that use of a preview language feature generates a non-suppressible warning (scan JEP 12 for "This message cannot be turned off") while use of an essential API element associated with a preview language feature generates a suppressible warning. Alex From erik.joelsson at oracle.com Thu Oct 17 18:02:15 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Oct 2019 11:02:15 -0700 Subject: RFR: JDK-8232572: Add hooks for custom output dir in Bundles.gmk Message-ID: <2eca0103-f752-d70d-7454-7d42c9ad1338@oracle.com> Our custom distribution packaging logic needs to be able to override the output directory of bundles. This patch adds an OUTPUT_DIR parameter to the SetupBundles macro. It also adds logging of the bundles being created. The added % in the filter makes it possible to extend specific product bundles under make targets that start with "product-bundles". Webrev: http://cr.openjdk.java.net/~erikj/8232572/webrev.jdk14.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8232572 /Erik From erik.joelsson at oracle.com Thu Oct 17 18:02:20 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Oct 2019 11:02:20 -0700 Subject: RFR: JDK-8232569: Use test image from different jib profile for testing Message-ID: Building and publishing a test image for every Jib build profile is a waste of resources. We need to be able to specify a test image from a different profile at test time when running "run-test-prebuilt". This patch takes the concept used for the -jcov profiles and makes it more general. Webrev: http://cr.openjdk.java.net/~erikj/8232569/webrev.jdk14.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8232569 /Erik From david.holmes at oracle.com Fri Oct 18 09:38:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2019 19:38:35 +1000 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> Hi Leo, cc'ing build-dev. I think there is a process you need to follow to remove VM features from the build system. And build folk need to check all build changes anyway. Thanks, David On 18/10/2019 6:20 pm, Leo Korinth wrote: > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad files > are correct, if someone can test those architectures, that would be great. > > Please take an extra look at > CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before > (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to > remove all traces of CMS. I guess there are much more to cleanup, and > suggestions of more to remove are welcomed. I think more complicated > cleanups should be dealt with in separate enhancements. > > Not fully addressed in code, but an issue that has to be dealt with, how > do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be > obsoleted, though I do not know if we have any precedence obsoleting -X > options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option > UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > ? http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > ? tier 1-5. > > Thanks, > Leo From maurizio.cimadamore at oracle.com Fri Oct 18 12:05:45 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Oct 2019 13:05:45 +0100 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> Message-ID: <68ee0609-3b98-85ec-97f8-1cc2ced8aa04@oracle.com> Looks good - but I suggest garbage collecting the isEssentialAPI() from the @PreviewFeature annotation, as the new behavior effectively removes any distinctions between the two (unless I miss something). Maurizio On 16/10/2019 13:50, Jan Lahoda wrote: > Hi, > > An updated patch is here: > http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/ > > Changes in the update: > -added the dependency into the makefiles > -loosened the handling of essential preview APIs when --enable-preview > and @SuppressWarnings is applied - there is no warning for the > essential APIs (as there is no warning in such a case for > non-essential APIs). This is per the discussion in the CSR: > https://bugs.openjdk.java.net/browse/JDK-8231411 > > Any comments/feedback on this? > > Thanks! > ??? Jan > > On 09. 10. 19 17:41, Erik Joelsson wrote: >> Oh, you are absolutely correct, the dependency is missing. >> >> We need something like this inside "define SetupInterimModule": >> >> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES) >> >> /Erik >> >> On 2019-10-09 01:42, Magnus Ihse Bursie wrote: >>> I can?t see how the compilation is dependent on the copy being >>> finished. Since Erik contributed this it will probably be correct :) >>> but I?d appreciate an explanation on how this dependency is guaranteed. >>> >>> Or maybe I?m misunderstanding what this is supposed to do? >>> >>> /Magnus >>> >>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda : >>>> >>>> Thanks for the new code Erik! >>>> >>>> A new webrev/patch that includes this better way of copying is here: >>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ >>>> >>>> Any feedback is welcome! >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>>> On 03. 10. 19 18:06, Erik Joelsson wrote: >>>>> Hello Jan, >>>>> The build change looks ok, but I would recommend this construct >>>>> for copying the file instead: >>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >>>>> ???? FILES := >>>>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, >>>>> \ >>>>> ???? DEST := >>>>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, >>>>> \ >>>>> )) >>>>> TARGETS += $(COPY_PREVIEW_FEATURES) >>>>> Then you automatically get all the corner case handling we have >>>>> implemented over the years for logging, making directories and >>>>> copying files. Your version is still correct for this case though. >>>>> /Erik >>>>>> On 2019-10-03 02:57, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> This is a continuation of Joe's patch from here: >>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >>>>>> >>>>>> >>>>>> APIs associated with preview features are split into two groups: >>>>>> essential and non-essential. These are marked with an >>>>>> JDK-internal annotation, PreviewFeature, and a tag in the >>>>>> javadoc, @preview. The javac follows the PreviewFeature >>>>>> annotation, and produces either warnings or errors for the usages >>>>>> of such APIs. For the @preview tag, there is a taglet in the JDK >>>>>> build that adds the content of the tag into the documentation. >>>>>> The first part of the @preview's text goes into the summary, the >>>>>> second part goes into the detailed description. >>>>>> >>>>>> For build, a tricky problem is that the jdk.compiler module uses >>>>>> the PreviewFeature annotation as well, but that is not in the >>>>>> bootstrap JDK. So, for the intermediate langtools build, the >>>>>> PreviewFeature annotation is copied from java.base. >>>>>> >>>>>> Proposed webrev: >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>>>>> >>>>>> Javadoc with the change: >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>>>>> >>>>>> See for example: >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >>>>>> >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >>>>>> >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>>>>> >>>>>> CSR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>>>>> >>>>>> Feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> ???? Jan From jan.lahoda at oracle.com Fri Oct 18 12:38:07 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Oct 2019 14:38:07 +0200 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: <68ee0609-3b98-85ec-97f8-1cc2ced8aa04@oracle.com> References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> <68ee0609-3b98-85ec-97f8-1cc2ced8aa04@oracle.com> Message-ID: <6B0AC83B-213C-4B61-A4A3-0771A9DCF68A@oracle.com> 18. ??jna 2019 14:05:45 SEL?, Maurizio Cimadamore napsal: >Looks good - but I suggest garbage collecting the isEssentialAPI() from > >the @PreviewFeature annotation, as the new behavior effectively removes > >any distinctions between the two (unless I miss something). I am afraid there is still a distinction between them - when --enable-preview is not specified, use of essential APIs will lead to a compile time warning, while use of non essential API (reflection, typically) only produces warnings. Jan > >Maurizio > >On 16/10/2019 13:50, Jan Lahoda wrote: >> Hi, >> >> An updated patch is here: >> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/ >> >> Changes in the update: >> -added the dependency into the makefiles >> -loosened the handling of essential preview APIs when >--enable-preview >> and @SuppressWarnings is applied - there is no warning for the >> essential APIs (as there is no warning in such a case for >> non-essential APIs). This is per the discussion in the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8231411 >> >> Any comments/feedback on this? >> >> Thanks! >> ??? Jan >> >> On 09. 10. 19 17:41, Erik Joelsson wrote: >>> Oh, you are absolutely correct, the dependency is missing. >>> >>> We need something like this inside "define SetupInterimModule": >>> >>> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES) >>> >>> /Erik >>> >>> On 2019-10-09 01:42, Magnus Ihse Bursie wrote: >>>> I can?t see how the compilation is dependent on the copy being >>>> finished. Since Erik contributed this it will probably be correct >:) >>>> but I?d appreciate an explanation on how this dependency is >guaranteed. >>>> >>>> Or maybe I?m misunderstanding what this is supposed to do? >>>> >>>> /Magnus >>>> >>>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda : >>>>> >>>>> Thanks for the new code Erik! >>>>> >>>>> A new webrev/patch that includes this better way of copying is >here: >>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ >>>>> >>>>> Any feedback is welcome! >>>>> >>>>> Thanks, >>>>> ??? Jan >>>>> >>>>>> On 03. 10. 19 18:06, Erik Joelsson wrote: >>>>>> Hello Jan, >>>>>> The build change looks ok, but I would recommend this construct >>>>>> for copying the file instead: >>>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >>>>>> ???? FILES := >>>>>> >$(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, > >>>>>> \ >>>>>> ???? DEST := >>>>>> >$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, > >>>>>> \ >>>>>> )) >>>>>> TARGETS += $(COPY_PREVIEW_FEATURES) >>>>>> Then you automatically get all the corner case handling we have >>>>>> implemented over the years for logging, making directories and >>>>>> copying files. Your version is still correct for this case >though. >>>>>> /Erik >>>>>>> On 2019-10-03 02:57, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This is a continuation of Joe's patch from here: >>>>>>> >https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html > >>>>>>> >>>>>>> >>>>>>> APIs associated with preview features are split into two groups: > >>>>>>> essential and non-essential. These are marked with an >>>>>>> JDK-internal annotation, PreviewFeature, and a tag in the >>>>>>> javadoc, @preview. The javac follows the PreviewFeature >>>>>>> annotation, and produces either warnings or errors for the >usages >>>>>>> of such APIs. For the @preview tag, there is a taglet in the JDK > >>>>>>> build that adds the content of the tag into the documentation. >>>>>>> The first part of the @preview's text goes into the summary, the > >>>>>>> second part goes into the detailed description. >>>>>>> >>>>>>> For build, a tricky problem is that the jdk.compiler module uses > >>>>>>> the PreviewFeature annotation as well, but that is not in the >>>>>>> bootstrap JDK. So, for the intermediate langtools build, the >>>>>>> PreviewFeature annotation is copied from java.base. >>>>>>> >>>>>>> Proposed webrev: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>>>>>> >>>>>>> Javadoc with the change: >>>>>>> >http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>>>>>> >>>>>>> See for example: >>>>>>> >http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html > >>>>>>> >>>>>>> >http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html > >>>>>>> >>>>>>> >>>>>>> JBS: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>>>>>> >>>>>>> CSR: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>>>>>> >>>>>>> Feedback is welcome! >>>>>>> >>>>>>> Thanks, >>>>>>> ???? Jan From erik.joelsson at oracle.com Fri Oct 18 12:54:41 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Oct 2019 05:54:41 -0700 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> Message-ID: <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> Hello Leo, When removing a JVM feature from the VALID_JVM_FEATURES list, it needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated here means removed here, but configure will still accept the argument (with a warning). Otherwise build changes look good. /Erik On 2019-10-18 02:38, David Holmes wrote: > Hi Leo, > > cc'ing build-dev. I think there is a process you need to follow to > remove VM features from the build system. And build folk need to check > all build changes anyway. > > Thanks, > David > > On 18/10/2019 6:20 pm, Leo Korinth wrote: >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad >> files are correct, if someone can test those architectures, that >> would be great. >> >> Please take an extra look at >> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >> (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal >> to remove all traces of CMS. I guess there are much more to cleanup, >> and suggestions of more to remove are welcomed. I think more >> complicated cleanups should be dealt with in separate enhancements. >> >> Not fully addressed in code, but an issue that has to be dealt with, >> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option >> should be obsoleted, though I do not know if we have any precedence >> obsoleting -X options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >> UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >> UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> ?? tier 1-5. >> >> Thanks, >> Leo From maurizio.cimadamore at oracle.com Fri Oct 18 13:08:20 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Oct 2019 14:08:20 +0100 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: <6B0AC83B-213C-4B61-A4A3-0771A9DCF68A@oracle.com> References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> <68ee0609-3b98-85ec-97f8-1cc2ced8aa04@oracle.com> <6B0AC83B-213C-4B61-A4A3-0771A9DCF68A@oracle.com> Message-ID: <214762ca-2826-9304-6eff-d1389b816deb@oracle.com> Sorry, I got the table in the CSR completely mixed up. So, the new behavior only really changes the fact that essential API warnings are now suppressible when using --enable-preview. I now see the relevant difference in Check.java. Looks good Maurizio On 18/10/2019 13:38, Jan Lahoda wrote: > > 18. ??jna 2019 14:05:45 SEL?, Maurizio Cimadamore napsal: >> Looks good - but I suggest garbage collecting the isEssentialAPI() from >> >> the @PreviewFeature annotation, as the new behavior effectively removes >> >> any distinctions between the two (unless I miss something). > I am afraid there is still a distinction between them - when --enable-preview is not specified, use of essential APIs will lead to a compile time warning, while use of non essential API (reflection, typically) only produces warnings. > > Jan > >> Maurizio >> >> On 16/10/2019 13:50, Jan Lahoda wrote: >>> Hi, >>> >>> An updated patch is here: >>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/ >>> >>> Changes in the update: >>> -added the dependency into the makefiles >>> -loosened the handling of essential preview APIs when >> --enable-preview >>> and @SuppressWarnings is applied - there is no warning for the >>> essential APIs (as there is no warning in such a case for >>> non-essential APIs). This is per the discussion in the CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>> >>> Any comments/feedback on this? >>> >>> Thanks! >>> ??? Jan >>> >>> On 09. 10. 19 17:41, Erik Joelsson wrote: >>>> Oh, you are absolutely correct, the dependency is missing. >>>> >>>> We need something like this inside "define SetupInterimModule": >>>> >>>> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES) >>>> >>>> /Erik >>>> >>>> On 2019-10-09 01:42, Magnus Ihse Bursie wrote: >>>>> I can?t see how the compilation is dependent on the copy being >>>>> finished. Since Erik contributed this it will probably be correct >> :) >>>>> but I?d appreciate an explanation on how this dependency is >> guaranteed. >>>>> Or maybe I?m misunderstanding what this is supposed to do? >>>>> >>>>> /Magnus >>>>> >>>>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda : >>>>>> >>>>>> Thanks for the new code Erik! >>>>>> >>>>>> A new webrev/patch that includes this better way of copying is >> here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ >>>>>> >>>>>> Any feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> ??? Jan >>>>>> >>>>>>> On 03. 10. 19 18:06, Erik Joelsson wrote: >>>>>>> Hello Jan, >>>>>>> The build change looks ok, but I would recommend this construct >>>>>>> for copying the file instead: >>>>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >>>>>>> ???? FILES := >>>>>>> >> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, >> >>>>>>> \ >>>>>>> ???? DEST := >>>>>>> >> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, >> >>>>>>> \ >>>>>>> )) >>>>>>> TARGETS += $(COPY_PREVIEW_FEATURES) >>>>>>> Then you automatically get all the corner case handling we have >>>>>>> implemented over the years for logging, making directories and >>>>>>> copying files. Your version is still correct for this case >> though. >>>>>>> /Erik >>>>>>>> On 2019-10-03 02:57, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is a continuation of Joe's patch from here: >>>>>>>> >> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >> >>>>>>>> >>>>>>>> APIs associated with preview features are split into two groups: >>>>>>>> essential and non-essential. These are marked with an >>>>>>>> JDK-internal annotation, PreviewFeature, and a tag in the >>>>>>>> javadoc, @preview. The javac follows the PreviewFeature >>>>>>>> annotation, and produces either warnings or errors for the >> usages >>>>>>>> of such APIs. For the @preview tag, there is a taglet in the JDK >>>>>>>> build that adds the content of the tag into the documentation. >>>>>>>> The first part of the @preview's text goes into the summary, the >>>>>>>> second part goes into the detailed description. >>>>>>>> >>>>>>>> For build, a tricky problem is that the jdk.compiler module uses >>>>>>>> the PreviewFeature annotation as well, but that is not in the >>>>>>>> bootstrap JDK. So, for the intermediate langtools build, the >>>>>>>> PreviewFeature annotation is copied from java.base. >>>>>>>> >>>>>>>> Proposed webrev: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>>>>>>> >>>>>>>> Javadoc with the change: >>>>>>>> >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>>>>>>> See for example: >>>>>>>> >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >> >>>>>>>> >> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >> >>>>>>>> >>>>>>>> JBS: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>>>>>>> >>>>>>>> CSR: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>>>>>>> >>>>>>>> Feedback is welcome! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> ???? Jan From tim.bell at oracle.com Fri Oct 18 15:00:40 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 18 Oct 2019 08:00:40 -0700 Subject: RFR: JDK-8232572: Add hooks for custom output dir in Bundles.gmk In-Reply-To: <2eca0103-f752-d70d-7454-7d42c9ad1338@oracle.com> References: <2eca0103-f752-d70d-7454-7d42c9ad1338@oracle.com> Message-ID: <6e488b4a-7954-06a9-08d2-790796f70d0b@oracle.com> Erik: > Our custom distribution packaging logic needs to be able to override the > output directory of bundles. This patch adds an OUTPUT_DIR parameter to > the SetupBundles macro. It also adds logging of the bundles being > created. The added % in the filter makes it possible to extend specific > product bundles under make targets that start with "product-bundles". > > Webrev: http://cr.openjdk.java.net/~erikj/8232572/webrev.jdk14.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232572 Looks good. Tim From tim.bell at oracle.com Fri Oct 18 15:13:56 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 18 Oct 2019 08:13:56 -0700 Subject: RFR: JDK-8232569: Use test image from different jib profile for testing In-Reply-To: References: Message-ID: <31dcd184-5396-ba4b-ef58-57613c40306f@oracle.com> Erik: > Building and publishing a test image for every Jib build profile is a > waste of resources. We need to be able to specify a test image from a > different profile at test time when running "run-test-prebuilt". This > patch takes the concept used for the -jcov profiles and makes it more > general. > > Webrev: http://cr.openjdk.java.net/~erikj/8232569/webrev.jdk14.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232569 Looks good. Tim From jonathan.gibbons at oracle.com Fri Oct 18 22:12:15 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 18 Oct 2019 15:12:15 -0700 Subject: RFR: JDK-8232639: Change module graph images to use SVG instead of PNG format. Message-ID: Please review a small change in the build, to use .svg files instead of .png files, for the generated module graph images. The underlying generator, GraphViz, already supports .svg output. In the proposed patch, the filename is changed in the generator tool, and all references to "png" in make/Docs.gmk are converted to "svg". -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8232639 Webrev: http://cr.openjdk.java.net/~jjg/8232639/webrev.00/index.html Sample API docs: http://cr.openjdk.java.net/~jjg/8232639/api.00/api/index.html From mandy.chung at oracle.com Sat Oct 19 00:36:56 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Oct 2019 17:36:56 -0700 Subject: RFR: JDK-8232639: Change module graph images to use SVG instead of PNG format. In-Reply-To: References: Message-ID: <73f3d9e4-77da-8408-2c4e-14408dd528bb@oracle.com> Looks good to me. Mandy On 10/18/19 3:12 PM, Jonathan Gibbons wrote: > Please review a small change in the build, to use .svg files instead > of .png files, > for the generated module graph images. > > The underlying generator, GraphViz, already supports .svg output. > > In the proposed patch, the filename is changed in the generator tool, > and all references to "png" in make/Docs.gmk are converted to "svg". > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8232639 > Webrev: http://cr.openjdk.java.net/~jjg/8232639/webrev.00/index.html > Sample API docs: > http://cr.openjdk.java.net/~jjg/8232639/api.00/api/index.html > > > From fw at deneb.enyo.de Sat Oct 19 10:24:53 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 19 Oct 2019 12:24:53 +0200 Subject: Closed vs open builds Message-ID: <87a79xvxqi.fsf@mid.deneb.enyo.de> Is there a makefile flag to distinguish between closed (Oracle-internal/proprietary) and open builds? I want to fix some oversight in building the documentation (where content derived from open builds is incorrectly labeled as closed), and it would be nice to control the new behavior with such a flag. From magnus.ihse.bursie at oracle.com Mon Oct 21 06:51:44 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2019 08:51:44 +0200 Subject: Closed vs open builds In-Reply-To: <87a79xvxqi.fsf@mid.deneb.enyo.de> References: <87a79xvxqi.fsf@mid.deneb.enyo.de> Message-ID: On 2019-10-19 12:24, Florian Weimer wrote: > Is there a makefile flag to distinguish between closed > (Oracle-internal/proprietary) and open builds? Well, there is a configure option, --enable-openjdk-only, but it's a bit of an anachronism. The current idea is that we make closed builds by having the proper additional configure and makefiles present, which pulls them in. > > I want to fix some oversight in building the documentation (where > content derived from open builds is incorrectly labeled as closed), > and it would be nice to control the new behavior with such a flag. Hm? I'm not sure what this means, but that sounds like a proper bug that should be fixed without reference to closed sources. If you have just OpenJDK checked out, with no closed sources present, the build should just create an open build without issues. Are you talking about the documentation in doc/*.md? /Magnus From magnus.ihse.bursie at oracle.com Mon Oct 21 06:53:07 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2019 08:53:07 +0200 Subject: RFR: JDK-8232639: Change module graph images to use SVG instead of PNG format. In-Reply-To: References: Message-ID: <43304fbc-8536-077a-f321-7b619ab30b85@oracle.com> On 2019-10-19 00:12, Jonathan Gibbons wrote: > Please review a small change in the build, to use .svg files instead > of .png files, > for the generated module graph images. > > The underlying generator, GraphViz, already supports .svg output. > > In the proposed patch, the filename is changed in the generator tool, > and all references to "png" in make/Docs.gmk are converted to "svg". > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8232639 > Webrev: http://cr.openjdk.java.net/~jjg/8232639/webrev.00/index.html Looks good to me. Nice fix. SVG FTW! /Magnus > Sample API docs: > http://cr.openjdk.java.net/~jjg/8232639/api.00/api/index.html > > > From fw at deneb.enyo.de Mon Oct 21 07:20:12 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 21 Oct 2019 09:20:12 +0200 Subject: Closed vs open builds In-Reply-To: (Magnus Ihse Bursie's message of "Mon, 21 Oct 2019 08:51:44 +0200") References: <87a79xvxqi.fsf@mid.deneb.enyo.de> Message-ID: <87blua7efn.fsf@mid.deneb.enyo.de> * Magnus Ihse Bursie: >> I want to fix some oversight in building the documentation (where >> content derived from open builds is incorrectly labeled as closed), >> and it would be nice to control the new behavior with such a flag. > Hm? I'm not sure what this means, but that sounds like a proper bug that > should be fixed without reference to closed sources. If you have just > OpenJDK checked out, with no closed sources present, the build should > just create an open build without issues. Are you talking about the > documentation in doc/*.md? It's about this setting in make/Docs.gmk: # $1 - Relative prefix to COPYRIGHT_URL COPYRIGHT_BOTTOM = \ Copyright \ © 1993, $(COPYRIGHT_YEAR), $(FULL_COMPANY_NAME), \ $(COMPANY_ADDRESS).
All rights reserved. \ Use is subject to license terms and the \ documentation redistribution policy. \ $(DRAFT_MARKER_STR) JAVADOC_BOTTOM := \ Report a bug or suggest an enhancement
\ For further API reference and developer documentation see the \ Java SE \ Documentation, which contains more detailed, \ developer-targeted descriptions with conceptual overviews, definitions \ of terms, workarounds, and working code examples.
\ Java is a trademark or registered trademark of $(FULL_COMPANY_NAME) in \ the US and other countries.
\ $(call COPYRIGHT_BOTTOM, {@docroot}/../) I'm hoping that we can all agree that the documentation redistribution policy does not apply to open builds. So the built documentation for open builds should not refer to it. From per.liden at oracle.com Mon Oct 21 07:43:10 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 21 Oct 2019 09:43:10 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> Message-ID: <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> Hi Erik, On 10/18/19 2:54 PM, Erik Joelsson wrote: > Hello Leo, > > When removing a JVM feature from the VALID_JVM_FEATURES list, it needs > to be added to the DEPRECATED_JVM_FEATURES list. Deprecated here means > removed here, but configure will still accept the argument (with a > warning). Are we really treating the list of JVM feature as a public/stable API, or is there some other reason for this? Would the plan be to remove it from the DEPRECATED_JVM_FEATURES in JDK 15? cheers, Per > > Otherwise build changes look good. > > /Erik > > On 2019-10-18 02:38, David Holmes wrote: >> Hi Leo, >> >> cc'ing build-dev. I think there is a process you need to follow to >> remove VM features from the build system. And build folk need to check >> all build changes anyway. >> >> Thanks, >> David >> >> On 18/10/2019 6:20 pm, Leo Korinth wrote: >>> Hi, >>> >>> Here is a patch that removes the CMS GC. >>> >>> I have neither tested arm nor ppc; I hope my changes to those .ad >>> files are correct, if someone can test those architectures, that >>> would be great. >>> >>> Please take an extra look at >>> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >>> (but never called), It is now called (and hopefully correct). >>> >>> I have tried to remove most parts of CMS. I have not made it a goal >>> to remove all traces of CMS. I guess there are much more to cleanup, >>> and suggestions of more to remove are welcomed. I think more >>> complicated cleanups should be dealt with in separate enhancements. >>> >>> Not fully addressed in code, but an issue that has to be dealt with, >>> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option >>> should be obsoleted, though I do not know if we have any precedence >>> obsoleting -X options. >>> >>> My patch prints: >>> >>> $ java -Xconcgc -jar Notepad.jar >>> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >>> UseConcMarkSweepGC >>> >>> I guess that is not enough for being obsolete, compare with: >>> >>> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >>> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >>> UseConcMarkSweepGC; support was removed in 14.0 >>> >>> Bug: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >>> >>> Webrev: >>> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >>> >>> Testing: >>> ?? tier 1-5. >>> >>> Thanks, >>> Leo From magnus.ihse.bursie at oracle.com Mon Oct 21 09:43:30 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2019 11:43:30 +0200 Subject: Closed vs open builds In-Reply-To: <87blua7efn.fsf@mid.deneb.enyo.de> References: <87a79xvxqi.fsf@mid.deneb.enyo.de> <87blua7efn.fsf@mid.deneb.enyo.de> Message-ID: <7aed6f41-1374-b7da-dd20-234c78632d0c@oracle.com> On 2019-10-21 09:20, Florian Weimer wrote: > * Magnus Ihse Bursie: > >>> I want to fix some oversight in building the documentation (where >>> content derived from open builds is incorrectly labeled as closed), >>> and it would be nice to control the new behavior with such a flag. >> Hm? I'm not sure what this means, but that sounds like a proper bug that >> should be fixed without reference to closed sources. If you have just >> OpenJDK checked out, with no closed sources present, the build should >> just create an open build without issues. Are you talking about the >> documentation in doc/*.md? > It's about this setting in make/Docs.gmk: > > # $1 - Relative prefix to COPYRIGHT_URL > COPYRIGHT_BOTTOM = \ > Copyright \ > © 1993, $(COPYRIGHT_YEAR), $(FULL_COMPANY_NAME), \ > $(COMPANY_ADDRESS).
All rights reserved. \ > Use is subject to license terms and the \ > documentation redistribution policy. \ > $(DRAFT_MARKER_STR) > > JAVADOC_BOTTOM := \ > Report a bug or suggest an enhancement
\ > For further API reference and developer documentation see the \ > Java SE \ > Documentation, which contains more detailed, \ > developer-targeted descriptions with conceptual overviews, definitions \ > of terms, workarounds, and working code examples.
\ > Java is a trademark or registered trademark of $(FULL_COMPANY_NAME) in \ > the US and other countries.
\ > $(call COPYRIGHT_BOTTOM, {@docroot}/../) > > I'm hoping that we can all agree that the documentation redistribution > policy does not apply to open builds. Actually, I'm not at all sure that we can agree on that. Ifaik the legal conditions around documentation is murky (to me, at least) at best. Before going any further on an actual patch I suggest you get clarification on the legal implications. /Magnus > So the built documentation for > open builds should not refer to it. From magnus.ihse.bursie at oracle.com Mon Oct 21 09:46:15 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2019 11:46:15 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> Message-ID: On 2019-10-21 09:43, Per Liden wrote: > Hi Erik, > > On 10/18/19 2:54 PM, Erik Joelsson wrote: >> Hello Leo, >> >> When removing a JVM feature from the VALID_JVM_FEATURES list, it >> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >> here means removed here, but configure will still accept the argument >> (with a warning). > > Are we really treating the list of JVM feature as a public/stable API, > or is there some other reason for this? Would the plan be to remove it > from the DEPRECATED_JVM_FEATURES in JDK 15? Note that this is an issue for building only. A feature listed as deprecated in the build will not propagate outside the build system. We are basically treating the configure command line arguments as a "stable API". The intention is that a command line on a build script should not cause a build failure due to an unknown argument. We have traditionally had 2-3 major releases before removing deprecated command line options. /Magnus > > cheers, > Per > >> >> Otherwise build changes look good. >> >> /Erik >> >> On 2019-10-18 02:38, David Holmes wrote: >>> Hi Leo, >>> >>> cc'ing build-dev. I think there is a process you need to follow to >>> remove VM features from the build system. And build folk need to >>> check all build changes anyway. >>> >>> Thanks, >>> David >>> >>> On 18/10/2019 6:20 pm, Leo Korinth wrote: >>>> Hi, >>>> >>>> Here is a patch that removes the CMS GC. >>>> >>>> I have neither tested arm nor ppc; I hope my changes to those .ad >>>> files are correct, if someone can test those architectures, that >>>> would be great. >>>> >>>> Please take an extra look at >>>> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy >>>> before (but never called), It is now called (and hopefully correct). >>>> >>>> I have tried to remove most parts of CMS. I have not made it a goal >>>> to remove all traces of CMS. I guess there are much more to >>>> cleanup, and suggestions of more to remove are welcomed. I think >>>> more complicated cleanups should be dealt with in separate >>>> enhancements. >>>> >>>> Not fully addressed in code, but an issue that has to be dealt >>>> with, how do I obsolete -Xconcgc and -Xnoconcgc? I believe the >>>> option should be obsoleted, though I do not know if we have any >>>> precedence obsoleting -X options. >>>> >>>> My patch prints: >>>> >>>> $ java -Xconcgc -jar Notepad.jar >>>> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >>>> UseConcMarkSweepGC >>>> >>>> I guess that is not enough for being obsolete, compare with: >>>> >>>> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >>>> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >>>> UseConcMarkSweepGC; support was removed in 14.0 >>>> >>>> Bug: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >>>> >>>> Webrev: >>>> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >>>> >>>> Testing: >>>> ?? tier 1-5. >>>> >>>> Thanks, >>>> Leo From erik.joelsson at oracle.com Mon Oct 21 15:45:30 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Oct 2019 08:45:30 -0700 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> Message-ID: <94194567-430c-97df-2e96-fe895123311a@oracle.com> On 2019-10-21 02:46, Magnus Ihse Bursie wrote: > On 2019-10-21 09:43, Per Liden wrote: >> Hi Erik, >> >> On 10/18/19 2:54 PM, Erik Joelsson wrote: >>> Hello Leo, >>> >>> When removing a JVM feature from the VALID_JVM_FEATURES list, it >>> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >>> here means removed here, but configure will still accept the >>> argument (with a warning). >> >> Are we really treating the list of JVM feature as a public/stable >> API, or is there some other reason for this? Would the plan be to >> remove it from the DEPRECATED_JVM_FEATURES in JDK 15? > > Note that this is an issue for building only. A feature listed as > deprecated in the build will not propagate outside the build system. > > We are basically treating the configure command line arguments as a > "stable API". The intention is that a command line on a build script > should not cause a build failure due to an unknown argument. We have > traditionally had 2-3 major releases before removing deprecated > command line options. > We (or at least I) have been a bit lazy with removing the deprecated args. I wouldn't mind being a bit more aggressive. /Erik From mark.reinhold at oracle.com Tue Oct 22 03:22:53 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 21 Oct 2019 20:22:53 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options Message-ID: <20191021202253.825695282@eggemoggin.niobe.net> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ This change implements jlink plugins, and associated changes in the VM and libraries, to support the following new jlink options: - --vendor-bug-url= overrides the vendor bug URL baked into the build. The value of the system property "java.vendor.url.bug" will be . - --vendor-vm-bug-url= overrides the vendor VM bug URL baked into the build. This value will be displayed in VM error logs. - --vendor-version= overrides the vendor version string baked into the build, if any. The value of the system property "java.vendor.version" will be . This value will be displayed in the output of java --version. - --add-options= prepends the specified string, which may include whitespace, before any other options when invoking the VM in the resulting image. The vendor-information plugins work by using the JDK?s internal ASM library to redefine static fields in the java.lang.VersionProps class. The VM reads the vendor-version and vendor-vm-bug-url strings from that class during startup. The add-options plugin works by storing the requested options in an internal resource, /java.base/jdk/internal/vm/options. The VM loads that resource from the lib/modules jimage file during startup and prepends any options found there to those given on the command line. Passes tier1-3 and JCK on {linux,macos,windows}-x64. Thanks, - Mark From magnus.ihse.bursie at oracle.com Tue Oct 22 07:17:52 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 09:17:52 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot Message-ID: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> The -Wextra option to gcc enables a bunch of useful warnings. Some of them, but not all, can be individually enabled or disabled. All other libraries in OpenJDK are compiled with -Wextra, but not Hotspot. Enabling -Wextra triggers a couple of warnings that can be individually disabled. (The idea here is not to just permanently disable those warnings (unless that makes sense), but to look at these warnings one at a time and see how they can be addressed.) My trial runs with -Wextra has already found a couple of real issues (fixed in JDK-8213414). I have tested that this compiles without warnings on gcc 4.8, 5.5, 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, aarch64 and arm32 with gcc 8.3. Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 /Magnus From david.holmes at oracle.com Tue Oct 22 07:36:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2019 17:36:13 +1000 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> Message-ID: <74b45837-3ba0-9bb9-0336-69cccc77adcc@oracle.com> Hi Magnus, On 22/10/2019 5:17 pm, Magnus Ihse Bursie wrote: > The -Wextra option to gcc enables a bunch of useful warnings. Some of > them, but not all, can be individually enabled or disabled. All other > libraries in OpenJDK are compiled with -Wextra, but not Hotspot. > Enabling -Wextra triggers a couple of warnings that can be individually > disabled. (The idea here is not to just permanently disable those > warnings (unless that makes sense), but to look at these warnings one at > a time and see how they can be addressed.) > > My trial runs with -Wextra has already found a couple of real issues > (fixed in JDK-8213414). > > I have tested that this compiles without warnings on gcc 4.8, 5.5, 6.5, > 7.4 and 8.3 on x64. I have also tried building zero on x64, aarch64 and > arm32 with gcc 8.3. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 I'm somewhat surprised that this isn't triggering more warnings, but if not then that is a good thing. :) I wouldn't be surprised if gcc 9.x causes something else pop up. Fix seems fine. Thanks, David > > /Magnus From fujie at loongson.cn Tue Oct 22 07:44:05 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 22 Oct 2019 15:44:05 +0800 Subject: RFR(trivial): 8232768: Configuration with --disable-cds --enable-generate-classlist should be reported as an error Message-ID: <55b2eb8e-99c5-8029-55a4-89904470a86b@loongson.cn> Hi all, May I get reviews for this one-line change? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232768 Webrev: http://cr.openjdk.java.net/~jiefu/8232768/webrev.00/ This kind of configuration, with both --disable-cds and --enable-generate-classlist, will fail. The failure is caused by -XX:DumpLoadedClassList [1], which doesn't work as expected when cds is disabled. It might be better to produce an error. Thanks a lot. Best regards, Jie [1] http://hg.openjdk.java.net/jdk/jdk/file/ca620b06b5c9/make/GenerateLinkOptData.gmk#l68 From magnus.ihse.bursie at oracle.com Tue Oct 22 08:28:02 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 10:28:02 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <74b45837-3ba0-9bb9-0336-69cccc77adcc@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> <74b45837-3ba0-9bb9-0336-69cccc77adcc@oracle.com> Message-ID: <3eccb4dd-1721-431e-d491-416850b43ec5@oracle.com> On 2019-10-22 09:36, David Holmes wrote: > Hi Magnus, > > On 22/10/2019 5:17 pm, Magnus Ihse Bursie wrote: >> The -Wextra option to gcc enables a bunch of useful warnings. Some of >> them, but not all, can be individually enabled or disabled. All other >> libraries in OpenJDK are compiled with -Wextra, but not Hotspot. >> Enabling -Wextra triggers a couple of warnings that can be >> individually disabled. (The idea here is not to just permanently >> disable those warnings (unless that makes sense), but to look at >> these warnings one at a time and see how they can be addressed.) >> >> My trial runs with -Wextra has already found a couple of real issues >> (fixed in JDK-8213414). >> >> I have tested that this compiles without warnings on gcc 4.8, 5.5, >> 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, >> aarch64 and arm32 with gcc 8.3. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 > > > I'm somewhat surprised that this isn't triggering more warnings, but > if not then that is a good thing. :) I wouldn't be surprised if gcc > 9.x causes something else pop up. That is because I enabled it in a personal branch a long time ago, and have spent like the last year or so trying to fix the individual problems to prepare for this patch. ;-) I wouldn't count on gcc 9 bringing in anything new to -Wextra. In general, gcc is *extremely* conservative about changing -Wextra nowadays. Virtually all new warnings that are added are added as indivudual warnings with explicit names to be turned on or turned off. Only after a long vetting process does any of these gets added to -Wextra. I think the last time anything was added to -Wextra was in like gcc 6..? So the -Wextra is in a way a bit of a legacy system in gcc for handling warnings. /Magnus > > Fix seems fine. > > Thanks, > David > >> >> /Magnus From magnus.ihse.bursie at oracle.com Tue Oct 22 09:35:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 11:35:26 +0200 Subject: RFR: JDK-8232770 Enable more warnings on solaris studio Message-ID: As a part of the ongoing process of cleaning up and improving our handling of warnings, the time has now come to the solstudio compiler. (I know this is not the most relevant of compilers, but I actually started out with the warning cleanup project on solstudio, since it's a simple, but limited, compiler in terms of options. So this is an old personal branch that I'm finally bringing in to mainline.) Just as we have done with gcc (-Wall -Wextra), we should increase the general warning levels on solstudio, and then -- if needed -- disable individual warnings. Warnings should be disabled on a per-library level if they indicate real issues that should be fixed, or globally if they are deemed not relevant for the project as a whole. (Unfortunately, for solstudio, some warnings that really should be fixed applied to just about every library, and for sanity's sake I had to disable them globally.) I also deemed a few warnings that had previously been individually disabled, to be dumb enough (or at least unsuitable to us) to warrant global disabling. I intend to open separate bugs on the owners of the native libraries where new warnings have been disabled, since I believe they point to real bugs, or at least sloppy programming practices, and should be addressed. Bug: https://bugs.openjdk.java.net/browse/JDK-8232770 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8232770-enable-more-solstudio-warnings/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Oct 22 09:37:35 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 11:37:35 +0200 Subject: RFR: JDK-8226585: Improve javac messages for using a preview API In-Reply-To: References: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com> <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com> <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com> Message-ID: On 2019-10-16 14:55, Erik Joelsson wrote: > Build change looks good now. I agree. /Magnus > > /Erik > > On 2019-10-16 05:50, Jan Lahoda wrote: >> Hi, >> >> An updated patch is here: >> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/ >> >> Changes in the update: >> -added the dependency into the makefiles >> -loosened the handling of essential preview APIs when >> --enable-preview and @SuppressWarnings is applied - there is no >> warning for the essential APIs (as there is no warning in such a case >> for non-essential APIs). This is per the discussion in the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8231411 >> >> Any comments/feedback on this? >> >> Thanks! >> ??? Jan >> >> On 09. 10. 19 17:41, Erik Joelsson wrote: >>> Oh, you are absolutely correct, the dependency is missing. >>> >>> We need something like this inside "define SetupInterimModule": >>> >>> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES) >>> >>> /Erik >>> >>> On 2019-10-09 01:42, Magnus Ihse Bursie wrote: >>>> I can?t see how the compilation is dependent on the copy being >>>> finished. Since Erik contributed this it will probably be correct >>>> :) but I?d appreciate an explanation on how this dependency is >>>> guaranteed. >>>> >>>> Or maybe I?m misunderstanding what this is supposed to do? >>>> >>>> /Magnus >>>> >>>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda : >>>>> >>>>> Thanks for the new code Erik! >>>>> >>>>> A new webrev/patch that includes this better way of copying is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/ >>>>> >>>>> Any feedback is welcome! >>>>> >>>>> Thanks, >>>>> ??? Jan >>>>> >>>>>> On 03. 10. 19 18:06, Erik Joelsson wrote: >>>>>> Hello Jan, >>>>>> The build change looks ok, but I would recommend this construct >>>>>> for copying the file instead: >>>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ >>>>>> ???? FILES := >>>>>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, >>>>>> \ >>>>>> ???? DEST := >>>>>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, >>>>>> \ >>>>>> )) >>>>>> TARGETS += $(COPY_PREVIEW_FEATURES) >>>>>> Then you automatically get all the corner case handling we have >>>>>> implemented over the years for logging, making directories and >>>>>> copying files. Your version is still correct for this case though. >>>>>> /Erik >>>>>>> On 2019-10-03 02:57, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This is a continuation of Joe's patch from here: >>>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html >>>>>>> >>>>>>> >>>>>>> APIs associated with preview features are split into two groups: >>>>>>> essential and non-essential. These are marked with an >>>>>>> JDK-internal annotation, PreviewFeature, and a tag in the >>>>>>> javadoc, @preview. The javac follows the PreviewFeature >>>>>>> annotation, and produces either warnings or errors for the >>>>>>> usages of such APIs. For the @preview tag, there is a taglet in >>>>>>> the JDK build that adds the content of the tag into the >>>>>>> documentation. The first part of the @preview's text goes into >>>>>>> the summary, the second part goes into the detailed description. >>>>>>> >>>>>>> For build, a tricky problem is that the jdk.compiler module uses >>>>>>> the PreviewFeature annotation as well, but that is not in the >>>>>>> bootstrap JDK. So, for the intermediate langtools build, the >>>>>>> PreviewFeature annotation is copied from java.base. >>>>>>> >>>>>>> Proposed webrev: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/ >>>>>>> >>>>>>> Javadoc with the change: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html >>>>>>> >>>>>>> See for example: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html >>>>>>> >>>>>>> >>>>>>> JBS: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585 >>>>>>> >>>>>>> CSR: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411 >>>>>>> >>>>>>> Feedback is welcome! >>>>>>> >>>>>>> Thanks, >>>>>>> ???? Jan From magnus.ihse.bursie at oracle.com Tue Oct 22 09:42:20 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 11:42:20 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <94194567-430c-97df-2e96-fe895123311a@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> <94194567-430c-97df-2e96-fe895123311a@oracle.com> Message-ID: <1e791bf2-1a08-4b4c-754b-23a0fd9ad991@oracle.com> On 2019-10-21 17:45, Erik Joelsson wrote: > On 2019-10-21 02:46, Magnus Ihse Bursie wrote: >> On 2019-10-21 09:43, Per Liden wrote: >>> Hi Erik, >>> >>> On 10/18/19 2:54 PM, Erik Joelsson wrote: >>>> Hello Leo, >>>> >>>> When removing a JVM feature from the VALID_JVM_FEATURES list, it >>>> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >>>> here means removed here, but configure will still accept the >>>> argument (with a warning). >>> >>> Are we really treating the list of JVM feature as a public/stable >>> API, or is there some other reason for this? Would the plan be to >>> remove it from the DEPRECATED_JVM_FEATURES in JDK 15? >> >> Note that this is an issue for building only. A feature listed as >> deprecated in the build will not propagate outside the build system. >> >> We are basically treating the configure command line arguments as a >> "stable API". The intention is that a command line on a build script >> should not cause a build failure due to an unknown argument. We have >> traditionally had 2-3 major releases before removing deprecated >> command line options. >> > We (or at least I) have been a bit lazy with removing the deprecated > args. I wouldn't mind being a bit more aggressive. Be my guest. :-) As long as it stays for at least one major release (even with the new 6 month release cadence), I'm ok with removing deprecated arguments. Otoh, there's very little impact in the current deprecation system, so it does not really matter if it lingers a bit more. /Magnus > > /Erik > > From magnus.ihse.bursie at oracle.com Tue Oct 22 09:45:41 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 11:45:41 +0200 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: On 2019-10-22 05:22, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ Build changes look good. /Magnus > > This change implements jlink plugins, and associated changes in the VM > and libraries, to support the following new jlink options: > > - --vendor-bug-url= overrides the vendor bug URL baked > into the build. The value of the system property "java.vendor.url.bug" > will be . > > - --vendor-vm-bug-url= overrides the vendor VM bug > URL baked into the build. This value will be displayed in VM error > logs. > > - --vendor-version= overrides the vendor version string > baked into the build, if any. The value of the system property > "java.vendor.version" will be . This value will be > displayed in the output of java --version. > > - --add-options= prepends the specified string, > which may include whitespace, before any other options when invoking > the VM in the resulting image. > > The vendor-information plugins work by using the JDK?s internal ASM > library to redefine static fields in the java.lang.VersionProps class. > The VM reads the vendor-version and vendor-vm-bug-url strings from that > class during startup. > > The add-options plugin works by storing the requested options in an > internal resource, /java.base/jdk/internal/vm/options. The VM loads that > resource from the lib/modules jimage file during startup and prepends any > options found there to those given on the command line. > > Passes tier1-3 and JCK on {linux,macos,windows}-x64. > > Thanks, > - Mark From magnus.ihse.bursie at oracle.com Tue Oct 22 09:54:06 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 11:54:06 +0200 Subject: RFR(trivial): 8232768: Configuration with --disable-cds --enable-generate-classlist should be reported as an error In-Reply-To: <55b2eb8e-99c5-8029-55a4-89904470a86b@loongson.cn> References: <55b2eb8e-99c5-8029-55a4-89904470a86b@loongson.cn> Message-ID: <6c5c3113-26b8-f139-36c4-07dac760a7d5@oracle.com> On 2019-10-22 09:44, Jie Fu wrote: > Hi all, > > May I get reviews for this one-line change? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232768 > Webrev: http://cr.openjdk.java.net/~jiefu/8232768/webrev.00/ > > This kind of configuration, with both --disable-cds and > --enable-generate-classlist, will fail. > The failure is caused by -XX:DumpLoadedClassList [1], which doesn't > work as expected when cds is disabled. > > It might be better to produce an error. I'm not sure I agree with this fix. Checking the code, we make an effort to determine if we should warn the user: ? # Check if it's likely that it's possible to generate the classlist. Depending ? # on exact jvm configuration it could be possible anyway. ? if test "x$ENABLE_CDS" = "xtrue" && (HOTSPOT_CHECK_JVM_VARIANT(server) || HOTSPOT_CHECK_JVM_VARIANT(client) || HOTSPOT_CHECK_JVM_FEATURE(cds)); then Only if the user *explicitly* sets --enable-generate-classlist, the warning is printed. The comment clearly states that this might be possible anyway, given the circumstances, so I believe a warning, and not an error, is the right thing here. The user explicitly requests generate-classlist. We warn that it might not work, but we allow it since it can work in cases we don't really know about. If it is the case that generate-classlist *never* will work with CDS disabled (this sounds reasonable, but I don't know if this really is the case), and you want to catch this, then I suggest you restructure the code so you catch the CDS && generate-classlist case separately, and give a fatal error for that, and then keep the current check for jvm variants/features and let it keep producing a warning for that. /Magnus > > Thanks a lot. > Best regards, > Jie > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/ca620b06b5c9/make/GenerateLinkOptData.gmk#l68 > > From fujie at loongson.cn Tue Oct 22 12:52:32 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 22 Oct 2019 20:52:32 +0800 Subject: RFR(trivial): 8232768: Configuration with --disable-cds --enable-generate-classlist should be reported as an error In-Reply-To: <6c5c3113-26b8-f139-36c4-07dac760a7d5@oracle.com> References: <55b2eb8e-99c5-8029-55a4-89904470a86b@loongson.cn> <6c5c3113-26b8-f139-36c4-07dac760a7d5@oracle.com> Message-ID: Hi Magnus, Thanks for your review and valuable comments. It is the second case since the VM will report an error for DumpLoadedClassList when CDS is disabled. So generate-classlist *never* will work with CDS disabled. Updated: http://cr.openjdk.java.net/~jiefu/8232768/webrev.01/ Please review it and give me some advice. Thanks a lot. Best regards, Jie On 2019/10/22 ??5:54, Magnus Ihse Bursie wrote: > On 2019-10-22 09:44, Jie Fu wrote: >> Hi all, >> >> May I get reviews for this one-line change? >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232768 >> Webrev: http://cr.openjdk.java.net/~jiefu/8232768/webrev.00/ >> >> This kind of configuration, with both --disable-cds and >> --enable-generate-classlist, will fail. >> The failure is caused by -XX:DumpLoadedClassList [1], which doesn't >> work as expected when cds is disabled. >> >> It might be better to produce an error. > I'm not sure I agree with this fix. Checking the code, we make an > effort to determine if we should warn the user: > > ? # Check if it's likely that it's possible to generate the classlist. > Depending > ? # on exact jvm configuration it could be possible anyway. > ? if test "x$ENABLE_CDS" = "xtrue" && > (HOTSPOT_CHECK_JVM_VARIANT(server) || > HOTSPOT_CHECK_JVM_VARIANT(client) || HOTSPOT_CHECK_JVM_FEATURE(cds)); > then > > Only if the user *explicitly* sets --enable-generate-classlist, the > warning is printed. The comment clearly states that this might be > possible anyway, given the circumstances, so I believe a warning, and > not an error, is the right thing here. The user explicitly requests > generate-classlist. We warn that it might not work, but we allow it > since it can work in cases we don't really know about. > > If it is the case that generate-classlist *never* will work with CDS > disabled (this sounds reasonable, but I don't know if this really is > the case), and you want to catch this, then I suggest you restructure > the code so you catch the CDS && generate-classlist case separately, > and give a fatal error for that, and then keep the current check for > jvm variants/features and let it keep producing a warning for that. > > /Magnus >> >> Thanks a lot. >> Best regards, >> Jie >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/ca620b06b5c9/make/GenerateLinkOptData.gmk#l68 >> >> > From Alan.Bateman at oracle.com Tue Oct 22 14:15:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Oct 2019 15:15:10 +0100 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: On 22/10/2019 04:22, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ I've read through the code for the new jlink plugins and the changes to VersionProps and it looks good. An alternative for VersionProps would have been to generate a helper class at link time rather than extending the static initilizer to set the fields. That would allow the VENDOR* fields to be final (but I don't think it makes too much difference and it may be a bit more complicated due to having 4 plugins contributing code). The need for a plugin per CLI option may be motivation to explore (in the future) having a single plugin expose multiple options. -Alan From erik.joelsson at oracle.com Tue Oct 22 16:11:06 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Oct 2019 09:11:06 -0700 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> Message-ID: <28c2db67-bdd4-b8b0-7ac3-29fcde6d66e1@oracle.com> Looks good. /Erik On 2019-10-22 00:17, Magnus Ihse Bursie wrote: > The -Wextra option to gcc enables a bunch of useful warnings. Some of > them, but not all, can be individually enabled or disabled. All other > libraries in OpenJDK are compiled with -Wextra, but not Hotspot. > Enabling -Wextra triggers a couple of warnings that can be > individually disabled. (The idea here is not to just permanently > disable those warnings (unless that makes sense), but to look at these > warnings one at a time and see how they can be addressed.) > > My trial runs with -Wextra has already found a couple of real issues > (fixed in JDK-8213414). > > I have tested that this compiles without warnings on gcc 4.8, 5.5, > 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, > aarch64 and arm32 with gcc 8.3. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 > > /Magnus From erik.joelsson at oracle.com Tue Oct 22 16:13:37 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Oct 2019 09:13:37 -0700 Subject: RFR: JDK-8232770 Enable more warnings on solaris studio In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-10-22 02:35, Magnus Ihse Bursie wrote: > As a part of the ongoing process of cleaning up and improving our > handling of warnings, the time has now come to the solstudio compiler. > (I know this is not the most relevant of compilers, but I actually > started out with the warning cleanup project on solstudio, since it's > a simple, but limited, compiler in terms of options. So this is an old > personal branch that I'm finally bringing in to mainline.) > > Just as we have done with gcc (-Wall -Wextra), we should increase the > general warning levels on solstudio, and then -- if needed -- disable > individual warnings. Warnings should be disabled on a per-library > level if they indicate real issues that should be fixed, or globally > if they are deemed not relevant for the project as a whole. > (Unfortunately, for solstudio, some warnings that really should be > fixed applied to just about every library, and for sanity's sake I had > to disable them globally.) > > I also deemed a few warnings that had previously been individually > disabled, to be dumb enough (or at least unsuitable to us) to warrant > global disabling. > > I intend to open separate bugs on the owners of the native libraries > where new warnings have been disabled, since I believe they point to > real bugs, or at least sloppy programming practices, and should be > addressed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232770 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8232770-enable-more-solstudio-warnings/webrev.01 > > /Magnus From leo.korinth at oracle.com Tue Oct 22 16:30:06 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 22 Oct 2019 18:30:06 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <94194567-430c-97df-2e96-fe895123311a@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> <94194567-430c-97df-2e96-fe895123311a@oracle.com> Message-ID: <0f7294d8-4d8c-348d-37c6-2a5f5a32f26d@oracle.com> Hi! I will add "cmsgc" like so: DEPRECATED_JVM_FEATURES="trace cmsgc" Should I file a reminder bug for later removal of that feature (I guess not)? If I should, at what version should it be removed? Thanks for finding this! /Leo On 21/10/2019 17:45, Erik Joelsson wrote: > On 2019-10-21 02:46, Magnus Ihse Bursie wrote: >> On 2019-10-21 09:43, Per Liden wrote: >>> Hi Erik, >>> >>> On 10/18/19 2:54 PM, Erik Joelsson wrote: >>>> Hello Leo, >>>> >>>> When removing a JVM feature from the VALID_JVM_FEATURES list, it >>>> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >>>> here means removed here, but configure will still accept the >>>> argument (with a warning). >>> >>> Are we really treating the list of JVM feature as a public/stable >>> API, or is there some other reason for this? Would the plan be to >>> remove it from the DEPRECATED_JVM_FEATURES in JDK 15? >> >> Note that this is an issue for building only. A feature listed as >> deprecated in the build will not propagate outside the build system. >> >> We are basically treating the configure command line arguments as a >> "stable API". The intention is that a command line on a build script >> should not cause a build failure due to an unknown argument. We have >> traditionally had 2-3 major releases before removing deprecated >> command line options. >> > We (or at least I) have been a bit lazy with removing the deprecated > args. I wouldn't mind being a bit more aggressive. > > /Erik > > From vladimir.kozlov at oracle.com Tue Oct 22 16:38:42 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Oct 2019 09:38:42 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: <6b0b5b46-a5af-adc2-4119-7991f76d2350@oracle.com> HotSpot changes seem fine to me. Thanks, Vladimir On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > This change implements jlink plugins, and associated changes in the VM > and libraries, to support the following new jlink options: > > - --vendor-bug-url= overrides the vendor bug URL baked > into the build. The value of the system property "java.vendor.url.bug" > will be . > > - --vendor-vm-bug-url= overrides the vendor VM bug > URL baked into the build. This value will be displayed in VM error > logs. > > - --vendor-version= overrides the vendor version string > baked into the build, if any. The value of the system property > "java.vendor.version" will be . This value will be > displayed in the output of java --version. > > - --add-options= prepends the specified string, > which may include whitespace, before any other options when invoking > the VM in the resulting image. > > The vendor-information plugins work by using the JDK?s internal ASM > library to redefine static fields in the java.lang.VersionProps class. > The VM reads the vendor-version and vendor-vm-bug-url strings from that > class during startup. > > The add-options plugin works by storing the requested options in an > internal resource, /java.base/jdk/internal/vm/options. The VM loads that > resource from the lib/modules jimage file during startup and prepends any > options found there to those given on the command line. > > Passes tier1-3 and JCK on {linux,macos,windows}-x64. > > Thanks, > - Mark > From erik.joelsson at oracle.com Tue Oct 22 16:44:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Oct 2019 09:44:04 -0700 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <0f7294d8-4d8c-348d-37c6-2a5f5a32f26d@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> <94194567-430c-97df-2e96-fe895123311a@oracle.com> <0f7294d8-4d8c-348d-37c6-2a5f5a32f26d@oracle.com> Message-ID: On 2019-10-22 09:30, Leo Korinth wrote: > Hi! > > I will add "cmsgc" like so: DEPRECATED_JVM_FEATURES="trace cmsgc" > Yes, exactly. Thanks! > Should I file a reminder bug for later removal of that feature (I > guess not)? If I should, at what version should it be removed? > > Thanks for finding this! > No need for a bug. We do these in bulk. /Erik > /Leo > > > On 21/10/2019 17:45, Erik Joelsson wrote: >> On 2019-10-21 02:46, Magnus Ihse Bursie wrote: >>> On 2019-10-21 09:43, Per Liden wrote: >>>> Hi Erik, >>>> >>>> On 10/18/19 2:54 PM, Erik Joelsson wrote: >>>>> Hello Leo, >>>>> >>>>> When removing a JVM feature from the VALID_JVM_FEATURES list, it >>>>> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >>>>> here means removed here, but configure will still accept the >>>>> argument (with a warning). >>>> >>>> Are we really treating the list of JVM feature as a public/stable >>>> API, or is there some other reason for this? Would the plan be to >>>> remove it from the DEPRECATED_JVM_FEATURES in JDK 15? >>> >>> Note that this is an issue for building only. A feature listed as >>> deprecated in the build will not propagate outside the build system. >>> >>> We are basically treating the configure command line arguments as a >>> "stable API". The intention is that a command line on a build script >>> should not cause a build failure due to an unknown argument. We have >>> traditionally had 2-3 major releases before removing deprecated >>> command line options. >>> >> We (or at least I) have been a bit lazy with removing the deprecated >> args. I wouldn't mind being a bit more aggressive. >> >> /Erik >> >> From bob.vandette at oracle.com Tue Oct 22 17:31:55 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 22 Oct 2019 13:31:55 -0400 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE? - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); This will require some minor changes to jvmFlags.hpp 34 struct JVMFlag { 35 enum Flags { 36 // latest value origin 37 DEFAULT = 0, 38 COMMAND_LINE = 1, 39 ENVIRON_VAR = 2, 40 CONFIG_FILE = 3, 41 MANAGEMENT = 4, 42 ERGONOMIC = 5, 43 ATTACH_ON_DEMAND = 6, 44 INTERNAL = 7, + 45 RESOURCE = 8, 46 - 47 LAST_VALUE_ORIGIN = INTERNAL, + 47 LAST_VALUE_ORIGIN = RESOURCE, Bob. > On Oct 21, 2019, at 11:22 PM, mark.reinhold at oracle.com wrote: > > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > This change implements jlink plugins, and associated changes in the VM > and libraries, to support the following new jlink options: > > - --vendor-bug-url= overrides the vendor bug URL baked > into the build. The value of the system property "java.vendor.url.bug" > will be . > > - --vendor-vm-bug-url= overrides the vendor VM bug > URL baked into the build. This value will be displayed in VM error > logs. > > - --vendor-version= overrides the vendor version string > baked into the build, if any. The value of the system property > "java.vendor.version" will be . This value will be > displayed in the output of java --version. > > - --add-options= prepends the specified string, > which may include whitespace, before any other options when invoking > the VM in the resulting image. > > The vendor-information plugins work by using the JDK?s internal ASM > library to redefine static fields in the java.lang.VersionProps class. > The VM reads the vendor-version and vendor-vm-bug-url strings from that > class during startup. > > The add-options plugin works by storing the requested options in an > internal resource, /java.base/jdk/internal/vm/options. The VM loads that > resource from the lib/modules jimage file during startup and prepends any > options found there to those given on the command line. > > Passes tier1-3 and JCK on {linux,macos,windows}-x64. > > Thanks, > - Mark From mark.reinhold at oracle.com Tue Oct 22 19:22:32 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Oct 2019 12:22:32 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: <20191022122232.395077958@eggemoggin.niobe.net> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: > In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE? > > - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); > + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); > > This will require some minor changes to jvmFlags.hpp > > 34 struct JVMFlag { > 35 enum Flags { > 36 // latest value origin > 37 DEFAULT = 0, > 38 COMMAND_LINE = 1, > 39 ENVIRON_VAR = 2, > 40 CONFIG_FILE = 3, > 41 MANAGEMENT = 4, > 42 ERGONOMIC = 5, > 43 ATTACH_ON_DEMAND = 6, > 44 INTERNAL = 7, > > + 45 RESOURCE = 8, > > 46 > > - 47 LAST_VALUE_ORIGIN = INTERNAL, > + 47 LAST_VALUE_ORIGIN = RESOURCE, Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin to handle the RESOURCE case (which is easy). Is ?RESOURCE? the best name here? Sounds awfully generic. How about ?JIMAGE? or ?JIMAGE_RESOURCE?? - Mark From mark.reinhold at oracle.com Tue Oct 22 19:25:17 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Oct 2019 12:25:17 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: <20191022122517.305808697@eggemoggin.niobe.net> 2019/10/22 7:15:10 -0700, alan.bateman at oracle.com: > On 22/10/2019 04:22, mark.reinhold at oracle.com wrote: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > I've read through the code for the new jlink plugins and the changes to > VersionProps and it looks good. > > An alternative for VersionProps would have been to generate a helper > class at link time rather than extending the static initilizer to set > the fields. That would allow the VENDOR* fields to be final (but I don't > think it makes too much difference and it may be a bit more complicated > due to having 4 plugins contributing code). Yes, that would?ve been more complex, and the finality of these fields isn?t critical. > The need for a plugin per CLI option may be motivation to explore (in > the future) having a single plugin expose multiple options. Agreed. Thanks, - Mark From bob.vandette at oracle.com Tue Oct 22 19:43:42 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 22 Oct 2019 15:43:42 -0400 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191022122232.395077958@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> Message-ID: <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> > On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: > > 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >> In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE? >> >> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >> >> This will require some minor changes to jvmFlags.hpp >> >> 34 struct JVMFlag { >> 35 enum Flags { >> 36 // latest value origin >> 37 DEFAULT = 0, >> 38 COMMAND_LINE = 1, >> 39 ENVIRON_VAR = 2, >> 40 CONFIG_FILE = 3, >> 41 MANAGEMENT = 4, >> 42 ERGONOMIC = 5, >> 43 ATTACH_ON_DEMAND = 6, >> 44 INTERNAL = 7, >> >> + 45 RESOURCE = 8, >> >> 46 >> >> - 47 LAST_VALUE_ORIGIN = INTERNAL, >> + 47 LAST_VALUE_ORIGIN = RESOURCE, > > Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin > to handle the RESOURCE case (which is easy). > > Is ?RESOURCE? the best name here? Sounds awfully generic. How about > ?JIMAGE? or ?JIMAGE_RESOURCE?? JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. Bob. > > - Mark From kim.barrett at oracle.com Tue Oct 22 20:25:17 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Oct 2019 16:25:17 -0400 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> Message-ID: <15D893D4-F940-47A8-AB8B-49DD8DC3B006@oracle.com> > On Oct 22, 2019, at 3:17 AM, Magnus Ihse Bursie wrote: > > I have tested that this compiles without warnings on gcc 4.8, 5.5, 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, aarch64 and arm32 with gcc 8.3. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 Change looks good. I remain somewhat leary of omnibus warning options in a code base like this, which is large and needs to support multiple compiler versions on multiple platforms. But at least most can be disabled if needed. Note that gcc9 adds: -Wdeprecated-copy Warn that the implicit declaration of a copy constructor or copy assignment operator is deprecated if the class has a user-provided copy constructor or copy assignment operator, in C++11 and up. This warning is enabled by -Wextra. With -Wdeprecated-copy-dtor, also deprecate if the class has a user-provided destructor. -Wredundant-move This warning warns about redundant calls to std::move; that is, when a move operation would have been performed even without the std::move call. Neither of these are an issue for us yet, because we're not yet using C++11 or later. But I expect -Wdeprecated-copy to cause problems for that update, and we might need to (temporarily) globally disable it as part of JEP 347. It's annoying that some of its warnings have no associated -Wno-xxx, in particular the one about mixing integral types and enum types in conditional expressions, because of the history of our code base and because it's perfectly well-formed usage. But apparently we don't have any of those right now. > On Oct 22, 2019, at 4:28 AM, Magnus Ihse Bursie wrote: > I wouldn't count on gcc 9 bringing in anything new to -Wextra. In general, gcc is *extremely* conservative about changing -Wextra nowadays. Virtually all new warnings that are added are added as indivudual warnings with explicit names to be turned on or turned off. Only after a long vetting process does any of these gets added to -Wextra. I think the last time anything was added to -Wextra was in like gcc 6..? So the -Wextra is in a way a bit of a legacy system in gcc for handling warnings. This depends on what you mean by additions or changes to -Wextra. As mentioned above, gcc9 adds two new warnings, but they can be individually controlled. The set of warnings only provided by -Wextra and not individually controlled has indeed not changed in a long time. I checked, and gcc4.9 and gcc9.2 have the same set of those. From erik.joelsson at oracle.com Tue Oct 22 21:07:42 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Oct 2019 14:07:42 -0700 Subject: RFR: JDK-8232834: RunTest sometimes fails to produce valid exitcode.txt Message-ID: When RunTest.gmk runs jtreg tests, it prints the exitcode of jtreg into a file named exitcode.txt. Soemtimes, this fails and the exitcode.txt file is left empty. This is causing trouble in automated testing where the surrounding framework is expecting to check the result in that file. I believe this is caused by a race in bash. We have seen similar races before and there is even a comment about it in the documentation for the ExecuteWithLog macro. If there is redirect of stdout in a command executed by ExecuteWithLog, that command must be surrounded by parens to run in a subshell. I first discovered this solution in JDK-8158629. This patch puts parens around the jtreg and other test framework calls in RunTest.gmk. Webrev: http://cr.openjdk.java.net/~erikj/8232834/webrev.jdk14.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8232834 /Erik From mandy.chung at oracle.com Tue Oct 22 21:12:18 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Oct 2019 14:12:18 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > Looks good to me.? One minor comment: AddResourcePlugin isn't really a FILTER, probably best to add a new category for new resource file.?? jlink hardcodes the order of the categories that determines the order of the plugins to be executed (I see the existing implementation could be cleaned up in the future). ? I think we didn't want to the options resource to be filtered by --exclude-resources plugin and so the add-options plugin should run after all filter plugins. Mandy From magnus.ihse.bursie at oracle.com Tue Oct 22 21:14:35 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 23:14:35 +0200 Subject: RFR(trivial): 8232768: Configuration with --disable-cds --enable-generate-classlist should be reported as an error In-Reply-To: References: <55b2eb8e-99c5-8029-55a4-89904470a86b@loongson.cn> <6c5c3113-26b8-f139-36c4-07dac760a7d5@oracle.com> Message-ID: <3b5d36d1-92d5-a852-62e8-91565716b80d@oracle.com> On 2019-10-22 14:52, Jie Fu wrote: > Hi Magnus, > > Thanks for your review and valuable comments. > It is the second case since the VM will report an error for > DumpLoadedClassList when CDS is disabled. > So generate-classlist *never* will work with CDS disabled. > > Updated: http://cr.openjdk.java.net/~jiefu/8232768/webrev.01/ This looks good to me. Do you need a sponsor for the patch? /Magnus > > Please review it and give me some advice. > > Thanks a lot. > Best regards, > Jie > > On 2019/10/22 ??5:54, Magnus Ihse Bursie wrote: >> On 2019-10-22 09:44, Jie Fu wrote: >>> Hi all, >>> >>> May I get reviews for this one-line change? >>> >>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232768 >>> Webrev: http://cr.openjdk.java.net/~jiefu/8232768/webrev.00/ >>> >>> This kind of configuration, with both --disable-cds and >>> --enable-generate-classlist, will fail. >>> The failure is caused by -XX:DumpLoadedClassList [1], which doesn't >>> work as expected when cds is disabled. >>> >>> It might be better to produce an error. >> I'm not sure I agree with this fix. Checking the code, we make an >> effort to determine if we should warn the user: >> >> ? # Check if it's likely that it's possible to generate the >> classlist. Depending >> ? # on exact jvm configuration it could be possible anyway. >> ? if test "x$ENABLE_CDS" = "xtrue" && >> (HOTSPOT_CHECK_JVM_VARIANT(server) || >> HOTSPOT_CHECK_JVM_VARIANT(client) || HOTSPOT_CHECK_JVM_FEATURE(cds)); >> then >> >> Only if the user *explicitly* sets --enable-generate-classlist, the >> warning is printed. The comment clearly states that this might be >> possible anyway, given the circumstances, so I believe a warning, and >> not an error, is the right thing here. The user explicitly requests >> generate-classlist. We warn that it might not work, but we allow it >> since it can work in cases we don't really know about. >> >> If it is the case that generate-classlist *never* will work with CDS >> disabled (this sounds reasonable, but I don't know if this really is >> the case), and you want to catch this, then I suggest you restructure >> the code so you catch the CDS && generate-classlist case separately, >> and give a fatal error for that, and then keep the current check for >> jvm variants/features and let it keep producing a warning for that. >> >> /Magnus >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/ca620b06b5c9/make/GenerateLinkOptData.gmk#l68 >>> >>> >> > From mark.reinhold at oracle.com Tue Oct 22 22:36:28 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Oct 2019 15:36:28 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> Message-ID: <20191022153628.417897318@eggemoggin.niobe.net> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>> In arguments.cpp, could you use a new JVMFlag to declare options >>> that came from this resource as RESOURCE? >>> >>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>> >>> This will require some minor changes to jvmFlags.hpp >>> >>> ... >> >> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >> to handle the RESOURCE case (which is easy). >> >> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >> ?JIMAGE? or ?JIMAGE_RESOURCE?? > > JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. JIMAGE_RESOURCE it is, then. Relative patch below; original webrev updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). - Mark ---- # HG changeset patch # Parent efca1844245ad7351418ef41efc86c5055ac3edf Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp --- a/src/hotspot/share/runtime/arguments.cpp +++ b/src/hotspot/share/runtime/arguments.cpp @@ -2203,7 +2203,7 @@ set_mode_flags(_mixed); // Parse args structure generated from java.base vm options resource - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE); if (result != JNI_OK) { return result; } diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp --- a/src/hotspot/share/runtime/flags/jvmFlag.cpp +++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp @@ -697,6 +697,8 @@ st->print("attach"); break; case INTERNAL: st->print("internal"); break; + case JIMAGE_RESOURCE: + st->print("jimage"); break; } st->print("}"); } diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp --- a/src/hotspot/share/runtime/flags/jvmFlag.hpp +++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp @@ -44,8 +44,9 @@ ERGONOMIC = 5, ATTACH_ON_DEMAND = 6, INTERNAL = 7, + JIMAGE_RESOURCE = 8, - LAST_VALUE_ORIGIN = INTERNAL, + LAST_VALUE_ORIGIN = JIMAGE_RESOURCE, VALUE_ORIGIN_BITS = 4, VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS), From mark.reinhold at oracle.com Tue Oct 22 22:37:38 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Oct 2019 15:37:38 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: <20191022153738.224816243@eggemoggin.niobe.net> 2019/10/22 14:12:18 -0700, mandy.chung at oracle.com: > On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > Looks good to me. One minor comment: > > AddResourcePlugin isn't really a FILTER, probably best to add a new > category for new resource file. jlink hardcodes the order of the > categories that determines the order of the plugins to be executed (I > see the existing implementation could be cleaned up in the future). I > think we didn't want to the options resource to be filtered by > --exclude-resources plugin and so the add-options plugin should run > after all filter plugins. Good point -- that makes sense. Relative patch below; original webrev updated in place. Thanks, - Mark ---- # HG changeset patch # Parent 43f160bda3c7a2a7009df91afa37469760d42333 Addendum 2 (jlink ADDER): 8232080: jlink plugins for vendor information and run-time options diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java @@ -50,6 +50,7 @@ static { CATEGORIES_ORDER.add(Category.FILTER); + CATEGORIES_ORDER.add(Category.ADDER); CATEGORIES_ORDER.add(Category.TRANSFORMER); CATEGORIES_ORDER.add(Category.MODULEINFO_TRANSFORMER); CATEGORIES_ORDER.add(Category.SORTER); diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java @@ -58,7 +58,7 @@ @Override public Category getType() { - return Category.FILTER; + return Category.ADDER; } @Override diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java @@ -39,6 +39,7 @@ * Order of categories matches the plugin sort order. *
    *
  1. FILTER: Filter in/out resources or files.
    2. + *
  2. ADDER: Add resources or files.
    3. *
  3. TRANSFORMER: Transform resources or files(eg: refactoring, bytecode * manipulation).
    4. *
  4. MODULEINFO_TRANSFORMER: Transform only module-info.class
    5. @@ -52,6 +53,7 @@ */ public enum Category { FILTER("FILTER"), + ADDER("ADDER"), TRANSFORMER("TRANSFORMER"), MODULEINFO_TRANSFORMER("MODULEINFO_TRANSFORMER"), SORTER("SORTER"), From bob.vandette at oracle.com Tue Oct 22 22:42:51 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 22 Oct 2019 18:42:51 -0400 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191022153628.417897318@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> Message-ID: <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com> Hotspot changes look good to me. Bob. > On Oct 22, 2019, at 6:36 PM, mark.reinhold at oracle.com wrote: > > 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>>> In arguments.cpp, could you use a new JVMFlag to declare options >>>> that came from this resource as RESOURCE? >>>> >>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>>> >>>> This will require some minor changes to jvmFlags.hpp >>>> >>>> ... >>> >>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >>> to handle the RESOURCE case (which is easy). >>> >>> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >>> ?JIMAGE? or ?JIMAGE_RESOURCE?? >> >> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. > > JIMAGE_RESOURCE it is, then. Relative patch below; original webrev > updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). > > - Mark > > > ---- > > # HG changeset patch > # Parent efca1844245ad7351418ef41efc86c5055ac3edf > Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options > > diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp > --- a/src/hotspot/share/runtime/arguments.cpp > +++ b/src/hotspot/share/runtime/arguments.cpp > @@ -2203,7 +2203,7 @@ > set_mode_flags(_mixed); > > // Parse args structure generated from java.base vm options resource > - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); > + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE); > if (result != JNI_OK) { > return result; > } > diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp > --- a/src/hotspot/share/runtime/flags/jvmFlag.cpp > +++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp > @@ -697,6 +697,8 @@ > st->print("attach"); break; > case INTERNAL: > st->print("internal"); break; > + case JIMAGE_RESOURCE: > + st->print("jimage"); break; > } > st->print("}"); > } > diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp > --- a/src/hotspot/share/runtime/flags/jvmFlag.hpp > +++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp > @@ -44,8 +44,9 @@ > ERGONOMIC = 5, > ATTACH_ON_DEMAND = 6, > INTERNAL = 7, > + JIMAGE_RESOURCE = 8, > > - LAST_VALUE_ORIGIN = INTERNAL, > + LAST_VALUE_ORIGIN = JIMAGE_RESOURCE, > VALUE_ORIGIN_BITS = 4, > VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS), > From vladimir.kozlov at oracle.com Tue Oct 22 22:44:55 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Oct 2019 15:44:55 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com> Message-ID: <8B9D1BE8-531E-433A-AC6B-FE8088AD11C2@oracle.com> +1 Thanks Vladimir > On Oct 22, 2019, at 3:42 PM, Bob Vandette wrote: > > Hotspot changes look good to me. > > Bob. > > >> On Oct 22, 2019, at 6:36 PM, mark.reinhold at oracle.com wrote: >> >> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >>>>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >>>>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>>>> In arguments.cpp, could you use a new JVMFlag to declare options >>>>> that came from this resource as RESOURCE? >>>>> >>>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>>>> >>>>> This will require some minor changes to jvmFlags.hpp >>>>> >>>>> ... >>>> >>>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >>>> to handle the RESOURCE case (which is easy). >>>> >>>> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >>>> ?JIMAGE? or ?JIMAGE_RESOURCE?? >>> >>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. >> >> JIMAGE_RESOURCE it is, then. Relative patch below; original webrev >> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). >> >> - Mark >> >> >> ---- >> >> # HG changeset patch >> # Parent efca1844245ad7351418ef41efc86c5055ac3edf >> Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options >> >> diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp >> --- a/src/hotspot/share/runtime/arguments.cpp >> +++ b/src/hotspot/share/runtime/arguments.cpp >> @@ -2203,7 +2203,7 @@ >> set_mode_flags(_mixed); >> >> // Parse args structure generated from java.base vm options resource >> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE); >> if (result != JNI_OK) { >> return result; >> } >> diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp >> --- a/src/hotspot/share/runtime/flags/jvmFlag.cpp >> +++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp >> @@ -697,6 +697,8 @@ >> st->print("attach"); break; >> case INTERNAL: >> st->print("internal"); break; >> + case JIMAGE_RESOURCE: >> + st->print("jimage"); break; >> } >> st->print("}"); >> } >> diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp >> --- a/src/hotspot/share/runtime/flags/jvmFlag.hpp >> +++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp >> @@ -44,8 +44,9 @@ >> ERGONOMIC = 5, >> ATTACH_ON_DEMAND = 6, >> INTERNAL = 7, >> + JIMAGE_RESOURCE = 8, >> >> - LAST_VALUE_ORIGIN = INTERNAL, >> + LAST_VALUE_ORIGIN = JIMAGE_RESOURCE, >> VALUE_ORIGIN_BITS = 4, >> VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS), >> > From fujie at loongson.cn Tue Oct 22 22:48:01 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 23 Oct 2019 06:48:01 +0800 Subject: RFR(trivial): 8232768: Configuration with --disable-cds --enable-generate-classlist should be reported as an error In-Reply-To: <3b5d36d1-92d5-a852-62e8-91565716b80d@oracle.com> References: <55b2eb8e-99c5-8029-55a4-89904470a86b@loongson.cn> <6c5c3113-26b8-f139-36c4-07dac760a7d5@oracle.com> <3b5d36d1-92d5-a852-62e8-91565716b80d@oracle.com> Message-ID: <2664a2d0-57b0-7037-2013-7d5bc19b4365@loongson.cn> Hi Magnus, Thank you very much. Yes, I need a sponsor. Thanks a lot. Best regards, Jie On 2019/10/23 ??5:14, Magnus Ihse Bursie wrote: > > > On 2019-10-22 14:52, Jie Fu wrote: >> Hi Magnus, >> >> Thanks for your review and valuable comments. >> It is the second case since the VM will report an error for >> DumpLoadedClassList when CDS is disabled. >> So generate-classlist *never* will work with CDS disabled. >> >> Updated: http://cr.openjdk.java.net/~jiefu/8232768/webrev.01/ > This looks good to me. Do you need a sponsor for the patch? > > /Magnus >> >> Please review it and give me some advice. >> >> Thanks a lot. >> Best regards, >> Jie >> >> On 2019/10/22 ??5:54, Magnus Ihse Bursie wrote: >>> On 2019-10-22 09:44, Jie Fu wrote: >>>> Hi all, >>>> >>>> May I get reviews for this one-line change? >>>> >>>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232768 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8232768/webrev.00/ >>>> >>>> This kind of configuration, with both --disable-cds and >>>> --enable-generate-classlist, will fail. >>>> The failure is caused by -XX:DumpLoadedClassList [1], which doesn't >>>> work as expected when cds is disabled. >>>> >>>> It might be better to produce an error. >>> I'm not sure I agree with this fix. Checking the code, we make an >>> effort to determine if we should warn the user: >>> >>> ? # Check if it's likely that it's possible to generate the >>> classlist. Depending >>> ? # on exact jvm configuration it could be possible anyway. >>> ? if test "x$ENABLE_CDS" = "xtrue" && >>> (HOTSPOT_CHECK_JVM_VARIANT(server) || >>> HOTSPOT_CHECK_JVM_VARIANT(client) || >>> HOTSPOT_CHECK_JVM_FEATURE(cds)); then >>> >>> Only if the user *explicitly* sets --enable-generate-classlist, the >>> warning is printed. The comment clearly states that this might be >>> possible anyway, given the circumstances, so I believe a warning, >>> and not an error, is the right thing here. The user explicitly >>> requests generate-classlist. We warn that it might not work, but we >>> allow it since it can work in cases we don't really know about. >>> >>> If it is the case that generate-classlist *never* will work with CDS >>> disabled (this sounds reasonable, but I don't know if this really is >>> the case), and you want to catch this, then I suggest you >>> restructure the code so you catch the CDS && generate-classlist case >>> separately, and give a fatal error for that, and then keep the >>> current check for jvm variants/features and let it keep producing a >>> warning for that. >>> >>> /Magnus >>>> >>>> Thanks a lot. >>>> Best regards, >>>> Jie >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk/jdk/file/ca620b06b5c9/make/GenerateLinkOptData.gmk#l68 >>>> >>>> >>> >> > From mandy.chung at oracle.com Tue Oct 22 23:30:52 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Oct 2019 16:30:52 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191022153738.224816243@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022153738.224816243@eggemoggin.niobe.net> Message-ID: <1934b0f7-10a9-7374-a479-31087363db75@oracle.com> On 10/22/19 3:37 PM, mark.reinhold at oracle.com wrote: > 2019/10/22 14:12:18 -0700, mandy.chung at oracle.com: >> On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote: >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ >> Looks good to me. One minor comment: >> >> AddResourcePlugin isn't really a FILTER, probably best to add a new >> category for new resource file. jlink hardcodes the order of the >> categories that determines the order of the plugins to be executed (I >> see the existing implementation could be cleaned up in the future). I >> think we didn't want to the options resource to be filtered by >> --exclude-resources plugin and so the add-options plugin should run >> after all filter plugins. > Good point -- that makes sense. > > Relative patch below; original webrev updated in place. Looks good. Mandy From magnus.ihse.bursie at oracle.com Wed Oct 23 07:42:50 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Oct 2019 09:42:50 +0200 Subject: RFR: JDK-8232834: RunTest sometimes fails to produce valid exitcode.txt In-Reply-To: References: Message-ID: On 2019-10-22 23:07, Erik Joelsson wrote: > When RunTest.gmk runs jtreg tests, it prints the exitcode of jtreg > into a file named exitcode.txt. Soemtimes, this fails and the > exitcode.txt file is left empty. This is causing trouble in automated > testing where the surrounding framework is expecting to check the > result in that file. > > I believe this is caused by a race in bash. We have seen similar races > before and there is even a comment about it in the documentation for > the ExecuteWithLog macro. If there is redirect of stdout in a command > executed by ExecuteWithLog, that command must be surrounded by parens > to run in a subshell. I first discovered this solution in JDK-8158629. Yikes! It's not the first time, yes. Do you think it would make sense to put in the extra parenthesis in the ExecuteWithLog itself? I guess the main problem with this is that we incur an extra shell invocation for each call, even if it's not needed. Normally this would not be even noticeable, but on Windows it might..? Otoh, being race free is more important, and leaving the responsibility for this to the caller of ExecuteWithLog is just too easy to get wrong, as we have seen multiple times. > > This patch puts parens around the jtreg and other test framework calls > in RunTest.gmk. > > Webrev: http://cr.openjdk.java.net/~erikj/8232834/webrev.jdk14.01/ Looks good to me. Even if we decide to change ExecuteWithLog itself later on, I think it makes sense to fix this here and now. /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232834 > > /Erik > From magnus.ihse.bursie at oracle.com Wed Oct 23 08:06:53 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Oct 2019 10:06:53 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <15D893D4-F940-47A8-AB8B-49DD8DC3B006@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> <15D893D4-F940-47A8-AB8B-49DD8DC3B006@oracle.com> Message-ID: <6e1a5bff-349c-0605-fdff-284ec9a44ff6@oracle.com> On 2019-10-22 22:25, Kim Barrett wrote: >> On Oct 22, 2019, at 3:17 AM, Magnus Ihse Bursie wrote: >> >> I have tested that this compiles without warnings on gcc 4.8, 5.5, 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, aarch64 and arm32 with gcc 8.3. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 > Change looks good. Thanks. > > I remain somewhat leary of omnibus warning options in a code base like > this, which is large and needs to support multiple compiler versions > on multiple platforms. But at least most can be disabled if needed. It's a three-edged sword. I like the concept of saying to the compiler "Here's my code, give it your best shot to find issues with it", and then explicitly telling it "well, no, that's not really a problem, ignore it". And if we really had to specify *each and every* warnings that a compiler should check for, the command lines would be excruciatingly long. On the other hand, if the set of warnings change between compiler versions, we have a harder time keeping the code warning free. Once again, if the warnings are reasonable, fixing issues is a good thing (and they could even have been avoided by writing good code in the first place :-)). But sometimes they are over-zealous and it is just an annoyance to fix. But then again, even for an individual, specified warning, the conditions for when and how it applies can change between compiler versions, so the same situation is really always present, even if it's on a "less likely" scale. > > Note that gcc9 adds: > -Wdeprecated-copy > Warn that the implicit declaration of a copy constructor or copy > assignment operator is deprecated if the class has a user-provided > copy constructor or copy assignment operator, in C++11 and up. This > warning is enabled by -Wextra. With -Wdeprecated-copy-dtor, also > deprecate if the class has a user-provided destructor. > > -Wredundant-move > This warning warns about redundant calls to std::move; that is, when a > move operation would have been performed even without the std::move > call. > > Neither of these are an issue for us yet, because we're not yet using > C++11 or later. But I expect -Wdeprecated-copy to cause problems for > that update, and we might need to (temporarily) globally disable it as > part of JEP 347. > > It's annoying that some of its warnings have no associated -Wno-xxx, > in particular the one about mixing integral types and enum types in > conditional expressions, because of the history of our code base and > because it's perfectly well-formed usage. But apparently we don't have > any of those right now. > >> On Oct 22, 2019, at 4:28 AM, Magnus Ihse Bursie wrote: >> I wouldn't count on gcc 9 bringing in anything new to -Wextra. In general, gcc is *extremely* conservative about changing -Wextra nowadays. Virtually all new warnings that are added are added as indivudual warnings with explicit names to be turned on or turned off. Only after a long vetting process does any of these gets added to -Wextra. I think the last time anything was added to -Wextra was in like gcc 6..? So the -Wextra is in a way a bit of a legacy system in gcc for handling warnings. > This depends on what you mean by additions or changes to -Wextra. As > mentioned above, gcc9 adds two new warnings, but they can be > individually controlled. The set of warnings only provided by -Wextra > and not individually controlled has indeed not changed in a long time. > I checked, and gcc4.9 and gcc9.2 have the same set of those. > Yes, new warnings can be individually disabled. It's a shame that not all -Wextra warnings can be, but unless we're prepared to submit a patch to gcc, I assume we're in no position to complain. :-) /Magnus From erik.joelsson at oracle.com Wed Oct 23 12:41:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Oct 2019 05:41:48 -0700 Subject: RFR: JDK-8232834: RunTest sometimes fails to produce valid exitcode.txt In-Reply-To: References: Message-ID: On 2019-10-23 00:42, Magnus Ihse Bursie wrote: > On 2019-10-22 23:07, Erik Joelsson wrote: >> When RunTest.gmk runs jtreg tests, it prints the exitcode of jtreg >> into a file named exitcode.txt. Soemtimes, this fails and the >> exitcode.txt file is left empty. This is causing trouble in automated >> testing where the surrounding framework is expecting to check the >> result in that file. >> >> I believe this is caused by a race in bash. We have seen similar >> races before and there is even a comment about it in the >> documentation for the ExecuteWithLog macro. If there is redirect of >> stdout in a command executed by ExecuteWithLog, that command must be >> surrounded by parens to run in a subshell. I first discovered this >> solution in JDK-8158629. > Yikes! It's not the first time, yes. Do you think it would make sense > to put in the extra parenthesis in the ExecuteWithLog itself? I guess > the main problem with this is that we incur an extra shell invocation > for each call, even if it's not needed. Normally this would not be > even noticeable, but on Windows it might..? Otoh, being race free is > more important, and leaving the responsibility for this to the caller > of ExecuteWithLog is just too easy to get wrong, as we have seen > multiple times. Yes, I've been torn about this. On Windows I made measurable build speed improvements some years ago by minimizing the extra shell invocations for compile commands, so I didn't like the idea of introducing an unconditional extra shell. Another option could be to scan the input for '[<>]' in ExecuteWithLog and only add it if found. It will certainly make the ExecuteWithLog body convoluted but may be a better solution. >> >> This patch puts parens around the jtreg and other test framework >> calls in RunTest.gmk. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8232834/webrev.jdk14.01/ > Looks good to me. Even if we decide to change ExecuteWithLog itself > later on, I think it makes sense to fix this here and now. > Thanks! /Erik From mark.reinhold at oracle.com Wed Oct 23 19:07:11 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Oct 2019 12:07:11 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191022153628.417897318@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> Message-ID: <20191023120711.232005374@eggemoggin.niobe.net> 2019/10/22 15:36:28 -0700, mark.reinhold at oracle.com: > 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>>> In arguments.cpp, could you use a new JVMFlag to declare options >>>> that came from this resource as RESOURCE? >>>> >>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>>> >>>> This will require some minor changes to jvmFlags.hpp >>>> >>>> ... >>> >>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >>> to handle the RESOURCE case (which is easy). >>> >>> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >>> ?JIMAGE? or ?JIMAGE_RESOURCE?? >> >> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. > > JIMAGE_RESOURCE it is, then. Relative patch below; original webrev > updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). Addendum: To keep things sane for JFR and the serviceability agent, I had to propagate this change through to those subsystems. Relative patch below; original webrev updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). Okay? - Mark ---- # HG changeset patch # Parent d3f05e3b0d76e1a74a10cee180d8953d3045b6c8 Addendum 3 (propagate JIMAGE_RESOURCE): 8232080: jlink plugins for vendor information and run-time options diff --git a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp --- a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp +++ b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp @@ -134,6 +134,7 @@ case JVMFlag::ERGONOMIC: return "Ergonomic"; case JVMFlag::ATTACH_ON_DEMAND: return "Attach on demand"; case JVMFlag::INTERNAL: return "Internal"; + case JVMFlag::JIMAGE_RESOURCE: return "JImage resource"; default: ShouldNotReachHere(); return ""; } } diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp --- a/src/hotspot/share/runtime/vmStructs.cpp +++ b/src/hotspot/share/runtime/vmStructs.cpp @@ -2612,6 +2612,7 @@ declare_constant(JVMFlag::ERGONOMIC) \ declare_constant(JVMFlag::ATTACH_ON_DEMAND) \ declare_constant(JVMFlag::INTERNAL) \ + declare_constant(JVMFlag::JIMAGE_RESOURCE) \ declare_constant(JVMFlag::VALUE_ORIGIN_MASK) \ declare_constant(JVMFlag::ORIG_COMMAND_LINE) diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java @@ -35,7 +35,8 @@ MANAGEMENT ("Management"), ERGONOMIC ("Ergonomic"), ATTACH_ON_DEMAND ("Attach on demand"), - INTERNAL ("Internal"); + INTERNAL ("Internal"), + JIMAGE_RESOURCE ("JImage"); private final String value; diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java @@ -114,6 +114,7 @@ public static int Flags_ERGONOMIC; public static int Flags_ATTACH_ON_DEMAND; public static int Flags_INTERNAL; + public static int Flags_JIMAGE_RESOURCE; private static int Flags_VALUE_ORIGIN_MASK; private static int Flags_ORIG_COMMAND_LINE; /** This is only present in a non-core build */ @@ -200,6 +201,8 @@ return "attach"; } else if (origin == Flags_INTERNAL) { return "internal"; + } else if (origin == Flags_JIMAGE_RESOURCE) { + return "jimage"; } else { throw new IllegalStateException( "Unknown flag origin " + origin + " is detected in " + name); @@ -484,6 +487,7 @@ Flags_ERGONOMIC = db.lookupIntConstant("JVMFlag::ERGONOMIC").intValue(); Flags_ATTACH_ON_DEMAND = db.lookupIntConstant("JVMFlag::ATTACH_ON_DEMAND").intValue(); Flags_INTERNAL = db.lookupIntConstant("JVMFlag::INTERNAL").intValue(); + Flags_JIMAGE_RESOURCE = db.lookupIntConstant("JVMFlag::JIMAGE").intValue(); Flags_VALUE_ORIGIN_MASK = db.lookupIntConstant("JVMFlag::VALUE_ORIGIN_MASK").intValue(); Flags_ORIG_COMMAND_LINE = db.lookupIntConstant("JVMFlag::ORIG_COMMAND_LINE").intValue(); oopSize = db.lookupIntConstant("oopSize").intValue(); From bob.vandette at oracle.com Wed Oct 23 19:37:56 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 23 Oct 2019 15:37:56 -0400 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191023120711.232005374@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> <20191023120711.232005374@eggemoggin.niobe.net> Message-ID: > On Oct 23, 2019, at 3:07 PM, mark.reinhold at oracle.com wrote: > > 2019/10/22 15:36:28 -0700, mark.reinhold at oracle.com: >> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >>>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >>>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>>>> In arguments.cpp, could you use a new JVMFlag to declare options >>>>> that came from this resource as RESOURCE? >>>>> >>>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>>>> >>>>> This will require some minor changes to jvmFlags.hpp >>>>> >>>>> ... >>>> >>>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >>>> to handle the RESOURCE case (which is easy). >>>> >>>> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >>>> ?JIMAGE? or ?JIMAGE_RESOURCE?? >>> >>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. >> >> JIMAGE_RESOURCE it is, then. Relative patch below; original webrev >> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). > > Addendum: To keep things sane for JFR and the serviceability agent, > I had to propagate this change through to those subsystems. > > Relative patch below; original webrev updated in place > (https://cr.openjdk.java.net/~mr/rev/8232080/). > > Okay? Looks good. I?m sure you did this but I scanned the entire JDK sources and didn?t see any other uses of JVMFlag:: that would need to be updated. Bob. > > - Mark > > ---- > > # HG changeset patch > # Parent d3f05e3b0d76e1a74a10cee180d8953d3045b6c8 > Addendum 3 (propagate JIMAGE_RESOURCE): 8232080: jlink plugins for vendor information and run-time options > > diff --git a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp > --- a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp > +++ b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp > @@ -134,6 +134,7 @@ > case JVMFlag::ERGONOMIC: return "Ergonomic"; > case JVMFlag::ATTACH_ON_DEMAND: return "Attach on demand"; > case JVMFlag::INTERNAL: return "Internal"; > + case JVMFlag::JIMAGE_RESOURCE: return "JImage resource"; > default: ShouldNotReachHere(); return ""; > } > } > diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp > --- a/src/hotspot/share/runtime/vmStructs.cpp > +++ b/src/hotspot/share/runtime/vmStructs.cpp > @@ -2612,6 +2612,7 @@ > declare_constant(JVMFlag::ERGONOMIC) \ > declare_constant(JVMFlag::ATTACH_ON_DEMAND) \ > declare_constant(JVMFlag::INTERNAL) \ > + declare_constant(JVMFlag::JIMAGE_RESOURCE) \ > declare_constant(JVMFlag::VALUE_ORIGIN_MASK) \ > declare_constant(JVMFlag::ORIG_COMMAND_LINE) > > diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java > +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java > @@ -35,7 +35,8 @@ > MANAGEMENT ("Management"), > ERGONOMIC ("Ergonomic"), > ATTACH_ON_DEMAND ("Attach on demand"), > - INTERNAL ("Internal"); > + INTERNAL ("Internal"), > + JIMAGE_RESOURCE ("JImage"); > > private final String value; > > diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java > +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java > @@ -114,6 +114,7 @@ > public static int Flags_ERGONOMIC; > public static int Flags_ATTACH_ON_DEMAND; > public static int Flags_INTERNAL; > + public static int Flags_JIMAGE_RESOURCE; > private static int Flags_VALUE_ORIGIN_MASK; > private static int Flags_ORIG_COMMAND_LINE; > /** This is only present in a non-core build */ > @@ -200,6 +201,8 @@ > return "attach"; > } else if (origin == Flags_INTERNAL) { > return "internal"; > + } else if (origin == Flags_JIMAGE_RESOURCE) { > + return "jimage"; > } else { > throw new IllegalStateException( > "Unknown flag origin " + origin + " is detected in " + name); > @@ -484,6 +487,7 @@ > Flags_ERGONOMIC = db.lookupIntConstant("JVMFlag::ERGONOMIC").intValue(); > Flags_ATTACH_ON_DEMAND = db.lookupIntConstant("JVMFlag::ATTACH_ON_DEMAND").intValue(); > Flags_INTERNAL = db.lookupIntConstant("JVMFlag::INTERNAL").intValue(); > + Flags_JIMAGE_RESOURCE = db.lookupIntConstant("JVMFlag::JIMAGE").intValue(); > Flags_VALUE_ORIGIN_MASK = db.lookupIntConstant("JVMFlag::VALUE_ORIGIN_MASK").intValue(); > Flags_ORIG_COMMAND_LINE = db.lookupIntConstant("JVMFlag::ORIG_COMMAND_LINE").intValue(); > oopSize = db.lookupIntConstant("oopSize").intValue(); From mark.reinhold at oracle.com Wed Oct 23 20:25:52 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Oct 2019 13:25:52 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> <20191023120711.232005374@eggemoggin.niobe.net> Message-ID: <20191023132552.159905052@eggemoggin.niobe.net> 2019/10/23 12:37:56 -0700, bob.vandette at oracle.com: >> On Oct 23, 2019, at 3:07 PM, mark.reinhold at oracle.com wrote: >> ... >> >> Addendum: To keep things sane for JFR and the serviceability agent, >> I had to propagate this change through to those subsystems. >> >> Relative patch below; original webrev updated in place >> (https://cr.openjdk.java.net/~mr/rev/8232080/). >> >> Okay? > > Looks good. I?m sure you did this but I scanned the entire JDK > sources and didn?t see any other uses of JVMFlag:: that would need to > be updated. Yep, I did that, and didn?t see anything else either. Thanks, - Mark From dmitry.markov at oracle.com Fri Oct 25 10:27:40 2019 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 25 Oct 2019 11:27:40 +0100 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests Message-ID: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> Hello, Could you review the fix for jdk14, please? bug: https://bugs.openjdk.java.net/browse/JDK-8232880 webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail. Test documentation should be updated with some notes regarding this. Thanks, Dmitry From erik.joelsson at oracle.com Fri Oct 25 13:00:39 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Oct 2019 06:00:39 -0700 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> Message-ID: <373b10c2-e80b-e6b5-a443-ac6a6f919f03@oracle.com> Looks good. I would put in a "the" before "operating system". /Erik On 2019-10-25 03:27, Dmitry Markov wrote: > Hello, > > Could you review the fix for jdk14, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8232880 > webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ > > Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail. > Test documentation should be updated with some notes regarding this. > > Thanks, > Dmitry > From dmitry.markov at oracle.com Fri Oct 25 13:45:46 2019 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 25 Oct 2019 14:45:46 +0100 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: <373b10c2-e80b-e6b5-a443-ac6a6f919f03@oracle.com> References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> <373b10c2-e80b-e6b5-a443-ac6a6f919f03@oracle.com> Message-ID: Thank you for the review, Erik! I will update the fix as you suggested before push if you do not mind. Thanks, Dmitry > On 25 Oct 2019, at 14:00, Erik Joelsson wrote: > > Looks good. I would put in a "the" before "operating system". > > /Erik > > On 2019-10-25 03:27, Dmitry Markov wrote: >> Hello, >> >> Could you review the fix for jdk14, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8232880 >> webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ >> >> Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail. >> Test documentation should be updated with some notes regarding this. >> >> Thanks, >> Dmitry >> From erik.joelsson at oracle.com Fri Oct 25 13:48:35 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Oct 2019 06:48:35 -0700 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> <373b10c2-e80b-e6b5-a443-ac6a6f919f03@oracle.com> Message-ID: <47041539-02c4-e00b-571b-ac75caafb850@oracle.com> No need for new webrev. /Erik On 2019-10-25 06:45, Dmitry Markov wrote: > Thank you for the review, Erik! > I will update the fix as you suggested before push if you do not mind. > > Thanks, > Dmitry > >> On 25 Oct 2019, at 14:00, Erik Joelsson wrote: >> >> Looks good. I would put in a "the" before "operating system". >> >> /Erik >> >> On 2019-10-25 03:27, Dmitry Markov wrote: >>> Hello, >>> >>> Could you review the fix for jdk14, please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8232880 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ >>> >>> Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail. >>> Test documentation should be updated with some notes regarding this. >>> >>> Thanks, >>> Dmitry >>> From alexey.ivanov at oracle.com Fri Oct 25 15:42:57 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 25 Oct 2019 16:42:57 +0100 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> Message-ID: Hi Dmitry, Apple uses macOS to refer to its operating system, so should we also use it instead of former OS X? For HTML version, I would suggest using the following markup Ctrl +F1 for the keyboard shortcut. [1] I think using 
     elements for instructions on how to disable 
the shortcut is incorrect. In fact, it does not require any special markup.


What about this text?

    Some client UI tests devoted to tooltips may fail on macOS platform. 
The tests use Ctrl +F1 key sequence to 
show/hide a tooltip. However, this key combination is reserved by the 
operating system. To run these tests correctly, the default global 
shortcut should be disabled: choose Apple menu > System Preferences, 
click Keyboard, then click Shortcuts; deselect "Turn keyboard access 
on/of" property.
    

I copied the way Apple uses in its documentation to refer to commands.

On 25/10/2019 11:27, Dmitry Markov wrote:
> Hello,
>
> Could you review the fix for jdk14, please?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8232880
> webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/
>
> Some Client UI tests use the following key sequence to show/hide 
> tooltip message: ?CTRL? + ?F1". However this key combination is 
> reserved by operating system on OS X platform. As a results the tests 
> fail.
> Test documentation should be updated with some notes regarding this.
>
> Thanks,
> Dmitry
>

[1] https://www.w3.org/TR/html52/textlevel-semantics.html#the-kbd-element

-- 
Regards,
Alexey


From erik.joelsson at oracle.com  Fri Oct 25 15:52:54 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 25 Oct 2019 08:52:54 -0700
Subject:  RFR 8232880: Update test documentation with additional
 settings for client UI tooltip tests
In-Reply-To: 
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 
Message-ID: 

On 2019-10-25 08:42, Alexey Ivanov wrote:
> Hi Dmitry,
>
> Apple uses macOS to refer to its operating system, so should we also 
> use it instead of former OS X?
>
> For HTML version, I would suggest using the following markup 
> Ctrl +F1 for the keyboard shortcut. [1]
>
The HTML is generated from the markup and should not be edited by hand.

/Erik

> I think using 
     elements for instructions on how to disable 
> the shortcut is incorrect. In fact, it does not require any special 
> markup.
>
>
> What about this text?
> 
    Some client UI tests devoted to tooltips may fail on macOS 
> platform. The tests use Ctrl +F1 key 
> sequence to show/hide a tooltip. However, this key combination is 
> reserved by the operating system. To run these tests correctly, the 
> default global shortcut should be disabled: choose Apple menu > 
> System Preferences, click Keyboard, then click Shortcuts; deselect 
> "Turn keyboard access on/of" property.
    
>
> I copied the way Apple uses in its documentation to refer to commands.
>
> On 25/10/2019 11:27, Dmitry Markov wrote:
>> Hello,
>>
>> Could you review the fix for jdk14, please?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8232880
>> webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/
>>
>> Some Client UI tests use the following key sequence to show/hide 
>> tooltip message: ?CTRL? + ?F1". However this key combination is 
>> reserved by operating system on OS X platform. As a results the tests 
>> fail.
>> Test documentation should be updated with some notes regarding this.
>>
>> Thanks,
>> Dmitry
>>
>
> [1] https://www.w3.org/TR/html52/textlevel-semantics.html#the-kbd-element
>


From alexey.ivanov at oracle.com  Fri Oct 25 15:58:54 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 25 Oct 2019 16:58:54 +0100
Subject:  RFR 8232880: Update test documentation with additional
 settings for client UI tooltip tests
In-Reply-To: 
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 
 
Message-ID: <18fe58a5-003f-a98f-8cab-784f2dd0a9bb@oracle.com>

Got it!
Then I'd just drop the quotes from the key names:
- `?CTRL? + ?F1?`
+ `Ctrl + F1`

On 25/10/2019 16:52, Erik Joelsson wrote:
> The HTML is generated from the markup and should not be edited by hand.
>
> /Erik 
-- 
Regards,
Alexey


From Sergey.Bylokhov at oracle.com  Fri Oct 25 23:55:34 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Oct 2019 16:55:34 -0700
Subject: RFR 8232880: Update test documentation with additional settings
 for client UI tooltip tests
In-Reply-To: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
Message-ID: <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>

Hi, Dmitry.

I suggest to make this block more generic, and describe the  "### Client UI - Tests".
It would be useful to mention that the tests in this category use different key combinations,
which might be registered as a system shortcuts, and it could cause a test failure. It is suggested
to disable these shortcuts:
  - macOS config location.....
  - Linux config location.....
  - On window some other application may have global shortcuts....

As an example of such issue you can provide CTRL+F1 which is used....


On 10/25/19 3:27 am, Dmitry Markov wrote:
> Hello,
> 
> Could you review the fix for jdk14, please?
> 
> 	bug: https://bugs.openjdk.java.net/browse/JDK-8232880 
> 	webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ 
> 
> Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail.
> Test documentation should be updated with some notes regarding this.
> 
> Thanks,
> Dmitry
> 


-- 
Best regards, Sergey.


From dmitry.markov at oracle.com  Mon Oct 28 17:23:50 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 28 Oct 2019 17:23:50 +0000
Subject: RFR 8232880: Update test documentation with additional settings
 for client UI tooltip tests
In-Reply-To: <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
Message-ID: <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>

Hi Alexey, Erik, Sergey,
Thank you for your feedback. I have updated the fix based on your suggestions: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.01/ 
Can you take a look, please?

Thanks,
Dmitry

> On 26 Oct 2019, at 00:55, Sergey Bylokhov  wrote:
> 
> Hi, Dmitry.
> 
> I suggest to make this block more generic, and describe the  "### Client UI - Tests".
> It would be useful to mention that the tests in this category use different key combinations,
> which might be registered as a system shortcuts, and it could cause a test failure. It is suggested
> to disable these shortcuts:
> - macOS config location.....
> - Linux config location.....
> - On window some other application may have global shortcuts....
> 
> As an example of such issue you can provide CTRL+F1 which is used....
> 
> 
> On 10/25/19 3:27 am, Dmitry Markov wrote:
>> Hello,
>> Could you review the fix for jdk14, please?
>> 	bug: https://bugs.openjdk.java.net/browse/JDK-8232880 
>> 	webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ 
>> Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail.
>> Test documentation should be updated with some notes regarding this.
>> Thanks,
>> Dmitry
> 
> 
> -- 
> Best regards, Sergey.



From erik.joelsson at oracle.com  Mon Oct 28 20:46:59 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 28 Oct 2019 13:46:59 -0700
Subject: RFR: JDK-8232748: Build static versions of certain JDK libraries
Message-ID: 

Certain downstream consumers of the JDK need to link to parts of it 
statically. To support this usecase, this patch adds a set of optional 
make targets that produce static native libraries for a selection of 
modules. These static libraries do not end up in the main JDK 
distribution but are instead packaged in a separate bundle that can be 
optionally overlayed on top of a JDK bundle. The new targets are only 
built when requested and are not added as dependencies on any existing 
target.

Webrev: http://cr.openjdk.java.net/~erikj/8232748/webrev.01

Bug: https://bugs.openjdk.java.net/browse/JDK-8232748

/Erik




From hoffmann at mountainminds.com  Wed Oct 23 17:59:41 2019
From: hoffmann at mountainminds.com (Marc Hoffmann)
Date: Wed, 23 Oct 2019 19:59:41 +0200
Subject: Fixing compiler warnings in src/demo/share/jfc 
Message-ID: <0663E469-9C0C-4B56-AE27-A318B6583556@mountainminds.com>

MOTIVATION

As a developer of the JaCoCo code coverage library I do lots of JDK builds. JDK
builds are simple, fast and produce minimal log output. Nice! What annoys me
though are plenty of compiler warnings at the end of the build caused by the
example code in src/demo/share/jfc

FIX

I propose a series of 3 patches (based on each other) which fixes all compiler
warnings for the demos:

patch1.txt - Fix compiler warnings in demos: raw types
patch2.txt - Fix compiler warnings in demos: deprecated APIs
patch3.txt - Fix compiler warnings in demos: deprecated Applet APIs

While patch 1 & 2 do not change functionality patch 3 actually removes the
Applet versions of some of the demos. The java main versions of the same demos
are still intact.

The patches are based on changeset 56699:70e6b0d8db13.

They have been tested from this clone: https://github.com/marchof/jdk/tree/fix-compiler-warnings-in-demos

RESULT

All compiler warnings on demo code during JDK build are removed

TESTING

I haven't found any automated tests so I manually launched all the demos. From
what I can say they are still functional.

SCOPE

I applied minimal changes to remove compiler warnings only. There are many more
cleanup opportunities in the demo code. Also there is (dead?) code in
src/demo/share/java2d which has similar issues. Both are not on scope of these
patches.

NEXT STEPS

I?m have no experience with OpenJDK patches. If you?re interested in getting these warnings fixed please
let me know how I can submit these patches properly.

-------------- next part --------------
diff --git a/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java b/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java
index d5a0477..64af243 100644
--- a/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java
+++ b/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java
@@ -136,7 +136,7 @@
     private JRadioButton openRadioButton;
     private JRadioButton saveRadioButton;
     private JRadioButton customButton;
-    private JComboBox lafComboBox;
+    private JComboBox lafComboBox;
     private JRadioButton justFilesRadioButton;
     private JRadioButton justDirectoriesRadioButton;
     private JRadioButton bothFilesAndDirectoriesRadioButton;
@@ -292,7 +292,7 @@
         showButton.setMnemonic('s');
 
         // Create laf combo box
-        lafComboBox = new JComboBox(supportedLaFs.toArray());
+        lafComboBox = new JComboBox<>(supportedLaFs.toArray(new SupportedLaF[0]));
         lafComboBox.setSelectedItem(nimbusLaF);
         lafComboBox.setEditable(false);
         lafComboBox.addActionListener(optionListener);
@@ -729,7 +729,7 @@
                     frame.pack();
                 } catch (UnsupportedLookAndFeelException exc) {
                     // This should not happen because we already checked
-                    ((DefaultComboBoxModel) lafComboBox.getModel()).
+                    ((DefaultComboBoxModel) lafComboBox.getModel()).
                             removeElement(supportedLaF);
                 }
             }
diff --git a/src/demo/share/jfc/Font2DTest/Font2DTest.java b/src/demo/share/jfc/Font2DTest/Font2DTest.java
index f01f983..de3b1ae 100644
--- a/src/demo/share/jfc/Font2DTest/Font2DTest.java
+++ b/src/demo/share/jfc/Font2DTest/Font2DTest.java
@@ -67,7 +67,6 @@
 import java.io.File;
 import java.io.FileInputStream;
 import java.io.FileOutputStream;
-import java.util.EnumSet;
 import java.util.StringTokenizer;
 import java.util.BitSet;
 import javax.swing.*;
@@ -101,8 +100,8 @@
     private final ChoiceV2 transformMenu;
     private final ChoiceV2 transformMenuG2;
     private final ChoiceV2 methodsMenu;
-    private final JComboBox antiAliasMenu;
-    private final JComboBox fracMetricsMenu;
+    private final JComboBox antiAliasMenu;
+    private final JComboBox fracMetricsMenu;
 
     private final JSlider contrastSlider;
 
@@ -151,10 +150,10 @@
         methodsMenu = new ChoiceV2( this );
 
         antiAliasMenu =
-            new JComboBox(EnumSet.allOf(FontPanel.AAValues.class).toArray());
+            new JComboBox<>(FontPanel.AAValues.values());
         antiAliasMenu.addActionListener(this);
         fracMetricsMenu =
-            new JComboBox(EnumSet.allOf(FontPanel.FMValues.class).toArray());
+            new JComboBox<>(FontPanel.FMValues.values());
         fracMetricsMenu.addActionListener(this);
 
         contrastSlider = new JSlider(JSlider.HORIZONTAL, 100, 250,
@@ -467,7 +466,7 @@
         int style = fontStyles[styleMenu.getSelectedIndex()];
         Font f;
         for (int i = 0; i < listCount; i++) {
-            String fontName = (String)fontMenu.getItemAt(i);
+            String fontName = fontMenu.getItemAt(i);
             f = new Font(fontName, style, size);
             if ((rm.getSelectedIndex() != RangeMenu.SURROGATES_AREA_INDEX) &&
                 canDisplayRange(f, rangeStart, rangeEnd)) {
@@ -905,7 +904,7 @@
                                 parseUserText( userTextArea.getText() ), null );
         }
         else if ( source instanceof JComboBox ) {
-            JComboBox c = (JComboBox) source;
+            JComboBox c = (JComboBox) source;
 
             /// RangeMenu handles actions by itself and then calls fireRangeChanged,
             /// so it is not listed or handled here
@@ -1070,7 +1069,7 @@
         }
     }
 
-    private final class ChoiceV2 extends JComboBox {
+    private final class ChoiceV2 extends JComboBox {
 
         private BitSet bitSet = null;
 
@@ -1141,7 +1140,7 @@
             this.choice = choice;
         }
 
-        public Component getListCellRendererComponent(JList list,
+        public Component getListCellRendererComponent(JList list,
                                                       Object value,
                                                       int index,
                                                       boolean isSelected,
diff --git a/src/demo/share/jfc/Font2DTest/FontPanel.java b/src/demo/share/jfc/Font2DTest/FontPanel.java
index 973b80d..d98ccd5 100644
--- a/src/demo/share/jfc/Font2DTest/FontPanel.java
+++ b/src/demo/share/jfc/Font2DTest/FontPanel.java
@@ -434,7 +434,7 @@
         private int canvasInset_X = 5, canvasInset_Y = 5;
 
         /// LineBreak'ed TextLayout vector
-        private Vector lineBreakTLs = null;
+        private Vector lineBreakTLs = null;
 
         /// Whether the current draw command requested is for printing
         private boolean isPrinting = false;
@@ -800,7 +800,7 @@
                 if ( textToUse == FILE_TEXT ) {
                     if ( !isPrinting )
                       f2dt.fireChangeStatus( "LineBreaking Text... Please Wait", false );
-                    lineBreakTLs = new Vector();
+                    lineBreakTLs = new Vector<>();
                     for ( int i = 0; i < fileText.length; i++ ) {
                         AttributedString as =
                           new AttributedString( fileText[i], g2.getFont().getAttributes() );
@@ -929,7 +929,7 @@
                 float xPos, yPos = (float) canvasInset_Y;
                 g2.drawRect( 0, 0, w - 1, h - 1 );
                 for ( int i = drawStart; i <= drawEnd; i++ ) {
-                    TextLayout oneLine = (TextLayout) lineBreakTLs.elementAt( i );
+                    TextLayout oneLine = lineBreakTLs.elementAt( i );
                     xPos =
                       oneLine.isLeftToRight() ?
                       canvasInset_X : ( (float) w - oneLine.getAdvance() - canvasInset_X );
@@ -992,9 +992,9 @@
             /// Back up metrics and other drawing info before printing modifies it
             int backupDrawStart = drawStart, backupDrawEnd = drawEnd;
             int backupNumCharAcross = numCharAcross, backupNumCharDown = numCharDown;
-            Vector backupLineBreakTLs = null;
+            Vector backupLineBreakTLs = null;
             if ( textToUse == FILE_TEXT )
-              backupLineBreakTLs = (Vector) lineBreakTLs.clone();
+              backupLineBreakTLs = new Vector<>(lineBreakTLs);
 
             printPageNumber = pageIndex;
             isPrinting = true;
@@ -1246,7 +1246,7 @@
        }
        public static Object getValue(int ordinal) {
            if (valArray == null) {
-               valArray = (FMValues[])EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
+               valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
            }
            for (int i=0;i implements ActionListener {
 
     private static final int[][] UNICODE_RANGES = getUnicodeRanges();
     private static final String[] UNICODE_RANGE_NAMES = getUnicodeRangeNames();
@@ -181,7 +181,7 @@
         Object source = e.getSource();
 
         if ( source instanceof JComboBox ) {
-                String rangeName = (String)((JComboBox)source).getSelectedItem();
+                String rangeName = (String)((JComboBox)source).getSelectedItem();
 
                 if ( rangeName.equals("Custom...") ) {
                     useCustomRange = true;
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/GlobalControls.java b/src/demo/share/jfc/J2Ddemo/java2d/GlobalControls.java
index 6432e3e..4a75387 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/GlobalControls.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/GlobalControls.java
@@ -63,7 +63,7 @@
         "USHORT_x555_RGB", "BYTE_GRAY", "USHORT_GRAY",
         "BYTE_BINARY", "BYTE_INDEXED", "BYTE_BINARY 2 bit", "BYTE_BINARY 4 bit",
         "INT_RGBx", "USHORT_555x_RGB" };
-    public final JComboBox screenCombo;
+    public final JComboBox screenCombo;
     public TextureChooser texturechooser;
     public JCheckBox aliasCB, renderCB, toolBarCB;
     public JCheckBox compositeCB, textureCB;
@@ -83,7 +83,7 @@
         textureCB = createCheckBox("Texture", false, 2);
         compositeCB = createCheckBox("AlphaComposite", false, 3);
 
-        screenCombo = new JComboBox();
+        screenCombo = new JComboBox<>();
         screenCombo.setPreferredSize(new Dimension(120, 18));
         screenCombo.setLightWeightPopupEnabled(true);
         screenCombo.setFont(font);
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/Tools.java b/src/demo/share/jfc/J2Ddemo/java2d/Tools.java
index 8f4dff7..62a6009 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/Tools.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/Tools.java
@@ -94,7 +94,7 @@
     protected boolean focus;
     public JToggleButton toggleB;
     public JButton printB;
-    public JComboBox screenCombo;
+    public JComboBox screenCombo;
     public JToggleButton renderB, aliasB;
     public JToggleButton textureB, compositeB;
     public JButton startStopB;
@@ -167,7 +167,7 @@
             toolbar.setPreferredSize(new Dimension(6*25, 26));
         }
 
-        screenCombo = new JComboBox();
+        screenCombo = new JComboBox<>();
         screenCombo.setPreferredSize(new Dimension(100, 18));
         screenCombo.setFont(font);
         for (String name : GlobalControls.screenNames) {
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/Areas.java b/src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/Areas.java
index 80ec808..4023d2c 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/Areas.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/Areas.java
@@ -151,7 +151,6 @@
 
         Areas demo;
         JToolBar toolbar;
-        JComboBox combo;
 
         public DemoControls(Areas demo) {
             super(demo.name);
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/demos/Images/ImageOps.java b/src/demo/share/jfc/J2Ddemo/java2d/demos/Images/ImageOps.java
index 69ac8e0..95dfdd3 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/demos/Images/ImageOps.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/demos/Images/ImageOps.java
@@ -188,20 +188,20 @@
     static class DemoControls extends CustomControls implements ActionListener {
 
         ImageOps demo;
-        JComboBox imgCombo, opsCombo;
+        JComboBox imgCombo, opsCombo;
         Font font = new Font(Font.SERIF, Font.PLAIN, 10);
 
         @SuppressWarnings("LeakingThisInConstructor")
         public DemoControls(ImageOps demo) {
             super(demo.name);
             this.demo = demo;
-            add(imgCombo = new JComboBox());
+            add(imgCombo = new JComboBox<>());
             imgCombo.setFont(font);
             for (String name : ImageOps.imgName) {
                 imgCombo.addItem(name);
             }
             imgCombo.addActionListener(this);
-            add(opsCombo = new JComboBox());
+            add(opsCombo = new JComboBox<>());
             opsCombo.setFont(font);
             for (String name : ImageOps.opsName) {
                 opsCombo.addItem(name);
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/Balls.java b/src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/Balls.java
index 84d0c08..799d02a 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/Balls.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/Balls.java
@@ -71,7 +71,7 @@
     private boolean active;
     protected Ball[] balls = new Ball[colors.length];
     protected boolean clearToggle;
-    protected JComboBox combo;
+    protected JComboBox combo;
 
     public Balls() {
         setBackground(WHITE);
@@ -279,7 +279,7 @@
             addTool("B", demo.balls[4].isSelected);
             addTool("I", demo.balls[5].isSelected);
             addTool("V", demo.balls[6].isSelected);
-            add(combo = new JComboBox());
+            add(combo = new JComboBox<>());
             combo.addItem("10");
             combo.addItem("20");
             combo.addItem("30");
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/BezierScroller.java b/src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/BezierScroller.java
index 3e9e4ed..e361653 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/BezierScroller.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/BezierScroller.java
@@ -60,7 +60,6 @@
 import java2d.AnimatingControlsSurface;
 import java2d.CustomControls;
 import javax.swing.AbstractButton;
-import javax.swing.JComboBox;
 import javax.swing.JToggleButton;
 import javax.swing.JToolBar;
 
@@ -320,7 +319,6 @@
 
         BezierScroller demo;
         JToolBar toolbar;
-        JComboBox combo;
 
         public DemoControls(BezierScroller demo) {
             super(demo.name);
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/GradAnim.java b/src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/GradAnim.java
index dbf3ee7..3eb1725 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/GradAnim.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/GradAnim.java
@@ -266,13 +266,13 @@
     class DemoControls extends CustomControls implements ActionListener {
 
         GradAnim demo;
-        JComboBox combo;
+        JComboBox combo;
 
         @SuppressWarnings("LeakingThisInConstructor")
         public DemoControls(GradAnim demo) {
             super(demo.name);
             this.demo = demo;
-            combo = new JComboBox();
+            combo = new JComboBox<>();
             combo.addActionListener(this);
             combo.addItem("2-color GradientPaint");
             combo.addItem("3-color LinearGradientPaint");
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/TextureAnim.java b/src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/TextureAnim.java
index 6e97e20..304ccfe 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/TextureAnim.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/TextureAnim.java
@@ -299,7 +299,7 @@
 
         TextureAnim demo;
         JToolBar toolbar;
-        JComboBox combo;
+        JComboBox combo;
         JMenu menu;
         JMenuItem[] menuitems;
         int iconSize = 20;
@@ -318,7 +318,7 @@
             addTool("RO", "rotate", false);
             addTool("SX", "shear x", false);
             addTool("SY", "shear y", false);
-            add(combo = new JComboBox());
+            add(combo = new JComboBox<>());
             combo.addActionListener(this);
             combo.addItem("8");
             combo.addItem("16");
diff --git a/src/demo/share/jfc/Metalworks/MetalworksPrefs.java b/src/demo/share/jfc/Metalworks/MetalworksPrefs.java
index 36626ee..063a549 100644
--- a/src/demo/share/jfc/Metalworks/MetalworksPrefs.java
+++ b/src/demo/share/jfc/Metalworks/MetalworksPrefs.java
@@ -162,7 +162,7 @@
 
         JPanel protoPanel = new JPanel();
         JLabel protoLabel = new JLabel("Protocol");
-        JComboBox protocol = new JComboBox();
+        JComboBox protocol = new JComboBox<>();
         protocol.addItem("SMTP");
         protocol.addItem("IMAP");
         protocol.addItem("Other...");
@@ -171,7 +171,7 @@
 
         JPanel attachmentPanel = new JPanel();
         JLabel attachmentLabel = new JLabel("Attachments");
-        JComboBox attach = new JComboBox();
+        JComboBox attach = new JComboBox<>();
         attach.addItem("Download Always");
         attach.addItem("Ask size > 1 Meg");
         attach.addItem("Ask size > 5 Meg");
diff --git a/src/demo/share/jfc/Notepad/ElementTreePanel.java b/src/demo/share/jfc/Notepad/ElementTreePanel.java
index e1bac63..114c0a0 100644
--- a/src/demo/share/jfc/Notepad/ElementTreePanel.java
+++ b/src/demo/share/jfc/Notepad/ElementTreePanel.java
@@ -115,7 +115,7 @@
 
                 if (as != null) {
                     StringBuilder retBuffer = new StringBuilder("[");
-                    Enumeration names = as.getAttributeNames();
+                    Enumeration names = as.getAttributeNames();
 
                     while (names.hasMoreElements()) {
                         Object nextName = names.nextElement();
diff --git a/src/demo/share/jfc/Stylepad/Stylepad.java b/src/demo/share/jfc/Stylepad/Stylepad.java
index 872e0a4..6468757 100644
--- a/src/demo/share/jfc/Stylepad/Stylepad.java
+++ b/src/demo/share/jfc/Stylepad/Stylepad.java
@@ -255,8 +255,8 @@
         w.loadDocument();
     }
 
-    JComboBox createFamilyChoices() {
-        JComboBox b = new JComboBox();
+    JComboBox createFamilyChoices() {
+        JComboBox b = new JComboBox<>();
         String[] fontNames = GraphicsEnvironment.getLocalGraphicsEnvironment().
                 getAvailableFontFamilyNames();
         for (String fontName : fontNames) {
diff --git a/src/demo/share/jfc/SwingSet2/ButtonDemo.java b/src/demo/share/jfc/SwingSet2/ButtonDemo.java
index 0ba9574..c5e8c7a 100644
--- a/src/demo/share/jfc/SwingSet2/ButtonDemo.java
+++ b/src/demo/share/jfc/SwingSet2/ButtonDemo.java
@@ -61,12 +61,12 @@
     JPanel radioButtonPanel = new JPanel();
     JPanel toggleButtonPanel = new JPanel();
 
-    Vector buttons = new Vector();
-    Vector checkboxes = new Vector();
-    Vector radiobuttons = new Vector();
-    Vector togglebuttons = new Vector();
+    Vector buttons = new Vector<>();
+    Vector checkboxes = new Vector<>();
+    Vector radiobuttons = new Vector<>();
+    Vector togglebuttons = new Vector<>();
 
-    Vector currentControls = buttons;
+    Vector currentControls = buttons;
 
     JButton button;
     JCheckBox check;
@@ -466,12 +466,12 @@
                     String command = cb.getActionCommand();
                     if(command == "Enabled") {
                         for(int i = 0; i < currentControls.size(); i++) {
-                            c = (Component) currentControls.elementAt(i);
+                            c = currentControls.elementAt(i);
                             c.setEnabled(cb.isSelected());
                             c.invalidate();
                         }
                     } else if(command == "PaintBorder") {
-                        c = (Component) currentControls.elementAt(0);
+                        c = currentControls.elementAt(0);
                         if(c instanceof AbstractButton) {
                             for(int i = 0; i < currentControls.size(); i++) {
                                 b = (AbstractButton) currentControls.elementAt(i);
@@ -480,7 +480,7 @@
                             }
                         }
                     } else if(command == "PaintFocus") {
-                        c = (Component) currentControls.elementAt(0);
+                        c = currentControls.elementAt(0);
                         if(c instanceof AbstractButton) {
                             for(int i = 0; i < currentControls.size(); i++) {
                                 b = (AbstractButton) currentControls.elementAt(i);
@@ -489,7 +489,7 @@
                             }
                         }
                     } else if(command == "ContentFilled") {
-                        c = (Component) currentControls.elementAt(0);
+                        c = currentControls.elementAt(0);
                         if(c instanceof AbstractButton) {
                             for(int i = 0; i < currentControls.size(); i++) {
                                 b = (AbstractButton) currentControls.elementAt(i);
@@ -549,7 +549,7 @@
         }
     }
 
-    public Vector getCurrentControls() {
+    public Vector getCurrentControls() {
         return currentControls;
     }
 }
diff --git a/src/demo/share/jfc/SwingSet2/ComboBoxDemo.java b/src/demo/share/jfc/SwingSet2/ComboBoxDemo.java
index faed889..c2fe267 100644
--- a/src/demo/share/jfc/SwingSet2/ComboBoxDemo.java
+++ b/src/demo/share/jfc/SwingSet2/ComboBoxDemo.java
@@ -57,13 +57,13 @@
     Face face;
     JLabel faceLabel;
 
-    JComboBox hairCB;
-    JComboBox eyesCB;
-    JComboBox mouthCB;
+    JComboBox hairCB;
+    JComboBox eyesCB;
+    JComboBox mouthCB;
 
-    JComboBox presetCB;
+    JComboBox presetCB;
 
-    Hashtable parts = new Hashtable();
+    Hashtable parts = new Hashtable<>();
 
     /**
      * main method allows us to run as a standalone demo.
@@ -111,28 +111,28 @@
 
         JLabel l = (JLabel) comboBoxPanel.add(new JLabel(getString("ComboBoxDemo.presets")));
         l.setAlignmentX(JLabel.LEFT_ALIGNMENT);
-        presetCB = (JComboBox) comboBoxPanel.add(createPresetComboBox());
+        presetCB = (JComboBox) comboBoxPanel.add(createPresetComboBox());
         presetCB.setAlignmentX(JComboBox.LEFT_ALIGNMENT);
         l.setLabelFor(presetCB);
         comboBoxPanel.add(Box.createRigidArea(VGAP30));
 
         l = (JLabel) comboBoxPanel.add(new JLabel(getString("ComboBoxDemo.hair_description")));
         l.setAlignmentX(JLabel.LEFT_ALIGNMENT);
-        hairCB = (JComboBox) comboBoxPanel.add(createHairComboBox());
+        hairCB = (JComboBox) comboBoxPanel.add(createHairComboBox());
         hairCB.setAlignmentX(JComboBox.LEFT_ALIGNMENT);
         l.setLabelFor(hairCB);
         comboBoxPanel.add(Box.createRigidArea(VGAP15));
 
         l = (JLabel) comboBoxPanel.add(new JLabel(getString("ComboBoxDemo.eyes_description")));
         l.setAlignmentX(JLabel.LEFT_ALIGNMENT);
-        eyesCB = (JComboBox) comboBoxPanel.add(createEyesComboBox());
+        eyesCB = (JComboBox) comboBoxPanel.add(createEyesComboBox());
         eyesCB.setAlignmentX(JComboBox.LEFT_ALIGNMENT);
         l.setLabelFor(eyesCB);
         comboBoxPanel.add(Box.createRigidArea(VGAP15));
 
         l = (JLabel) comboBoxPanel.add(new JLabel(getString("ComboBoxDemo.mouth_description")));
         l.setAlignmentX(JLabel.LEFT_ALIGNMENT);
-        mouthCB = (JComboBox) comboBoxPanel.add(createMouthComboBox());
+        mouthCB = (JComboBox) comboBoxPanel.add(createMouthComboBox());
         mouthCB.setAlignmentX(JComboBox.LEFT_ALIGNMENT);
         l.setLabelFor(mouthCB);
         comboBoxPanel.add(Box.createRigidArea(VGAP15));
@@ -217,36 +217,36 @@
         return face;
     }
 
-    JComboBox createHairComboBox() {
-        JComboBox cb = new JComboBox();
+    JComboBox createHairComboBox() {
+        JComboBox cb = new JComboBox<>();
         fillComboBox(cb);
         cb.addActionListener(this);
         return cb;
     }
 
-    JComboBox createEyesComboBox() {
-        JComboBox cb = new JComboBox();
+    JComboBox createEyesComboBox() {
+        JComboBox cb = new JComboBox<>();
         fillComboBox(cb);
         cb.addActionListener(this);
         return cb;
     }
 
-    JComboBox createNoseComboBox() {
-        JComboBox cb = new JComboBox();
+    JComboBox createNoseComboBox() {
+        JComboBox cb = new JComboBox<>();
         fillComboBox(cb);
         cb.addActionListener(this);
         return cb;
     }
 
-    JComboBox createMouthComboBox() {
-        JComboBox cb = new JComboBox();
+    JComboBox createMouthComboBox() {
+        JComboBox cb = new JComboBox<>();
         fillComboBox(cb);
         cb.addActionListener(this);
         return cb;
     }
 
-    JComboBox createPresetComboBox() {
-        JComboBox cb = new JComboBox();
+    JComboBox createPresetComboBox() {
+        JComboBox cb = new JComboBox<>();
         cb.addItem(getString("ComboBoxDemo.preset1"));
         cb.addItem(getString("ComboBoxDemo.preset2"));
         cb.addItem(getString("ComboBoxDemo.preset3"));
@@ -261,7 +261,7 @@
         return cb;
     }
 
-    void fillComboBox(JComboBox cb) {
+    void fillComboBox(JComboBox cb) {
         cb.addItem(getString("ComboBoxDemo.brent"));
         cb.addItem(getString("ComboBoxDemo.georges"));
         cb.addItem(getString("ComboBoxDemo.hans"));
@@ -279,15 +279,15 @@
 
     public void actionPerformed(ActionEvent e) {
         if(e.getSource() == hairCB) {
-            String name = (String) parts.get((String) hairCB.getSelectedItem());
+            String name = (String) parts.get(hairCB.getSelectedItem());
             face.setHair((ImageIcon) parts.get(name + "hair"));
             faceLabel.repaint();
         } else if(e.getSource() == eyesCB) {
-            String name = (String) parts.get((String) eyesCB.getSelectedItem());
+            String name = (String) parts.get(eyesCB.getSelectedItem());
             face.setEyes((ImageIcon) parts.get(name + "eyes"));
             faceLabel.repaint();
         } else if(e.getSource() == mouthCB) {
-            String name = (String) parts.get((String) mouthCB.getSelectedItem());
+            String name = (String) parts.get(mouthCB.getSelectedItem());
             face.setMouth((ImageIcon) parts.get(name + "mouth"));
             faceLabel.repaint();
         } else if(e.getSource() == presetCB) {
diff --git a/src/demo/share/jfc/SwingSet2/DirectionPanel.java b/src/demo/share/jfc/SwingSet2/DirectionPanel.java
index 1411aaf..9a18f64 100644
--- a/src/demo/share/jfc/SwingSet2/DirectionPanel.java
+++ b/src/demo/share/jfc/SwingSet2/DirectionPanel.java
@@ -92,9 +92,9 @@
     }
 
     public void setSelection( String selection  ) {
-        Enumeration e = group.getElements();
+        Enumeration e = group.getElements();
         while( e.hasMoreElements() ) {
-            JRadioButton b = (JRadioButton)e.nextElement();
+        	AbstractButton b = e.nextElement();
             if( b.getActionCommand().equals(selection) ) {
                b.setSelected(true);
             }
diff --git a/src/demo/share/jfc/SwingSet2/ExampleFileView.java b/src/demo/share/jfc/SwingSet2/ExampleFileView.java
index 9e66705..7090c67 100644
--- a/src/demo/share/jfc/SwingSet2/ExampleFileView.java
+++ b/src/demo/share/jfc/SwingSet2/ExampleFileView.java
@@ -59,9 +59,9 @@
  * @author Jeff Dinkins
  */
 public class ExampleFileView extends FileView {
-    private Hashtable icons = new Hashtable(5);
-    private Hashtable fileDescriptions = new Hashtable(5);
-    private Hashtable typeDescriptions = new Hashtable(5);
+    private Hashtable icons = new Hashtable<>(5);
+    private Hashtable fileDescriptions = new Hashtable<>(5);
+    private Hashtable typeDescriptions = new Hashtable<>(5);
 
     /**
      * The name of the file.  Do nothing special here. Let
@@ -85,7 +85,7 @@
      * @see FileView#getDescription
      */
     public String getDescription(File f) {
-        return (String) fileDescriptions.get(f);
+        return fileDescriptions.get(f);
     };
 
     /**
@@ -111,7 +111,7 @@
      * @see FileView#getTypeDescription
      */
     public String getTypeDescription(File f) {
-        return (String) typeDescriptions.get(getExtension(f));
+        return typeDescriptions.get(getExtension(f));
     }
 
     /**
@@ -149,7 +149,7 @@
         Icon icon = null;
         String extension = getExtension(f);
         if(extension != null) {
-            icon = (Icon) icons.get(extension);
+            icon = icons.get(extension);
         }
         return icon;
     }
diff --git a/src/demo/share/jfc/SwingSet2/LayoutControlPanel.java b/src/demo/share/jfc/SwingSet2/LayoutControlPanel.java
index b6d4ff9..d3794d6 100644
--- a/src/demo/share/jfc/SwingSet2/LayoutControlPanel.java
+++ b/src/demo/share/jfc/SwingSet2/LayoutControlPanel.java
@@ -104,7 +104,7 @@
         // Make sure the controls' text position and label alignment match
         // the initial value of the associated direction panel.
         for(int i = 0; i < demo.getCurrentControls().size(); i++) {
-            Component c = (Component) demo.getCurrentControls().elementAt(i);
+            Component c = demo.getCurrentControls().elementAt(i);
             setPosition(c, RIGHT, CENTER);
             setAlignment(c,CENTER,CENTER);
         }
@@ -173,7 +173,7 @@
             }
 
             for(int i = 0; i < demo.getCurrentControls().size(); i++) {
-                Component c = (Component) demo.getCurrentControls().elementAt(i);
+                Component c = demo.getCurrentControls().elementAt(i);
                 int hPos, vPos, hAlign, vAlign;
                 if( c instanceof AbstractButton ) {
                    hPos = ((AbstractButton)c).getHorizontalTextPosition();
@@ -228,7 +228,7 @@
                     hPos = RIGHT; vPos = BOTTOM;
             }
             for(int i = 0; i < demo.getCurrentControls().size(); i++) {
-                Component c = (Component) demo.getCurrentControls().elementAt(i);
+                Component c = demo.getCurrentControls().elementAt(i);
                 setPosition(c, hPos, vPos);
             }
             demo.invalidate();
@@ -267,7 +267,7 @@
                     hPos = RIGHT; vPos = BOTTOM;
             }
             for(int i = 0; i < demo.getCurrentControls().size(); i++) {
-                Component c = (Component) demo.getCurrentControls().elementAt(i);
+                Component c = demo.getCurrentControls().elementAt(i);
                 setAlignment(c,hPos,vPos);
                 c.invalidate();
             }
diff --git a/src/demo/share/jfc/SwingSet2/ListDemo.java b/src/demo/share/jfc/SwingSet2/ListDemo.java
index 2e4d2e1..0352bc3 100644
--- a/src/demo/share/jfc/SwingSet2/ListDemo.java
+++ b/src/demo/share/jfc/SwingSet2/ListDemo.java
@@ -59,7 +59,7 @@
  * @author Jeff Dinkins
  */
 public class ListDemo extends DemoModule {
-    JList list;
+    JList list;
 
     JPanel prefixList;
     JPanel suffixList;
@@ -69,7 +69,7 @@
 
     GeneratedListModel listModel;
 
-    Vector checkboxes = new Vector();
+    Vector checkboxes = new Vector<>();
 
     /**
      * main method allows us to run as a standalone demo.
@@ -103,7 +103,7 @@
         centerPanel.add(Box.createRigidArea(HGAP30));
 
         // Create the list
-        list = new JList();
+        list = new JList<>();
         list.setCellRenderer(new CompanyLogoListCellRenderer());
         listModel = new GeneratedListModel(this);
         list.setModel(listModel);
@@ -293,12 +293,12 @@
     }
 
 
-    class GeneratedListModel extends AbstractListModel {
+    class GeneratedListModel extends AbstractListModel {
         ListDemo demo;
         Permuter permuter;
 
-        public Vector prefix = new Vector();
-        public Vector suffix = new Vector();
+        public Vector prefix = new Vector<>();
+        public Vector suffix = new Vector<>();
 
         public GeneratedListModel (ListDemo demo) {
             this.demo = demo;
@@ -337,7 +337,7 @@
             return prefix.size() * suffix.size();
         }
 
-        public Object getElementAt(int index) {
+        public String getElementAt(int index) {
             if(permuter == null) {
                 update();
             }
@@ -363,7 +363,7 @@
 
     class CompanyLogoListCellRenderer extends DefaultListCellRenderer {
        public Component getListCellRendererComponent(
-            JList list,
+            JList list,
             Object value,
             int index,
             boolean isSelected,
diff --git a/src/demo/share/jfc/SwingSet2/OptionPaneDemo.java b/src/demo/share/jfc/SwingSet2/OptionPaneDemo.java
index da8c145..c60d4b8 100644
--- a/src/demo/share/jfc/SwingSet2/OptionPaneDemo.java
+++ b/src/demo/share/jfc/SwingSet2/OptionPaneDemo.java
@@ -163,7 +163,7 @@
                 message[0] = getString("OptionPaneDemo.componentmessage");
                 message[1] = new JTextField(getString("OptionPaneDemo.componenttextfield"));
 
-                JComboBox cb = new JComboBox();
+                JComboBox cb = new JComboBox<>();
                 cb.addItem(getString("OptionPaneDemo.component_cb1"));
                 cb.addItem(getString("OptionPaneDemo.component_cb2"));
                 cb.addItem(getString("OptionPaneDemo.component_cb3"));
diff --git a/src/demo/share/jfc/SwingSet2/SliderDemo.java b/src/demo/share/jfc/SwingSet2/SliderDemo.java
index fe4061f..15bd7c4 100644
--- a/src/demo/share/jfc/SwingSet2/SliderDemo.java
+++ b/src/demo/share/jfc/SwingSet2/SliderDemo.java
@@ -164,7 +164,9 @@
         s.setPaintLabels( true );
         s.setSnapToTicks( true );
 
-        s.getLabelTable().put(new Integer(11), new JLabel(new Integer(11).toString(), JLabel.CENTER));
+        @SuppressWarnings("unchecked")
+		Dictionary labelTable = s.getLabelTable();
+        labelTable.put(new Integer(11), new JLabel(new Integer(11).toString(), JLabel.CENTER));
         s.setLabelTable( s.getLabelTable() );
 
         s.getAccessibleContext().setAccessibleName(getString("SliderDemo.minorticks"));
diff --git a/src/demo/share/jfc/SwingSet2/SwingSet2.java b/src/demo/share/jfc/SwingSet2/SwingSet2.java
index 8f421b0..6a710b1 100644
--- a/src/demo/share/jfc/SwingSet2/SwingSet2.java
+++ b/src/demo/share/jfc/SwingSet2/SwingSet2.java
@@ -703,8 +703,8 @@
         setStatus(getString("Status.loading") + getString(classname + ".name"));
         DemoModule demo = null;
         try {
-            Class demoClass = Class.forName(classname);
-            Constructor demoConstructor = demoClass.getConstructor(new Class[]{SwingSet2.class});
+            Class demoClass = Class.forName(classname);
+            Constructor demoConstructor = demoClass.getConstructor(new Class[]{SwingSet2.class});
             demo = (DemoModule) demoConstructor.newInstance(new Object[]{this});
             addDemo(demo);
         } catch (Exception e) {
diff --git a/src/demo/share/jfc/SwingSet2/TableDemo.java b/src/demo/share/jfc/SwingSet2/TableDemo.java
index 378f77c..130c4aa 100644
--- a/src/demo/share/jfc/SwingSet2/TableDemo.java
+++ b/src/demo/share/jfc/SwingSet2/TableDemo.java
@@ -75,8 +75,8 @@
     JSlider     interCellSpacingSlider;
     JSlider     rowHeightSlider;
 
-    JComboBox   selectionModeComboBox = null;
-    JComboBox   resizeModeComboBox = null;
+    JComboBox   selectionModeComboBox = null;
+    JComboBox   resizeModeComboBox = null;
 
     JLabel      headerLabel;
     JLabel      footerLabel;
@@ -126,7 +126,7 @@
         JPanel printPanel = new JPanel(new ColumnLayout());
 
         getDemoPanel().add(controlPanel, BorderLayout.NORTH);
-        Vector relatedComponents = new Vector();
+        Vector relatedComponents = new Vector<>();
 
 
         // check box panel
@@ -245,7 +245,7 @@
         selectMode.setBorder(new TitledBorder(getString("TableDemo.selection_mode")));
 
 
-        selectionModeComboBox = new JComboBox() {
+        selectionModeComboBox = new JComboBox<>() {
             public Dimension getMaximumSize() {
                 return getPreferredSize();
             }
@@ -256,7 +256,7 @@
         selectionModeComboBox.setSelectedIndex(tableView.getSelectionModel().getSelectionMode());
         selectionModeComboBox.addItemListener(new ItemListener() {
             public void itemStateChanged(ItemEvent e) {
-                JComboBox source = (JComboBox)e.getSource();
+                JComboBox source = (JComboBox)e.getSource();
                 tableView.setSelectionMode(source.getSelectedIndex());
             }
         });
@@ -272,7 +272,7 @@
         resizeMode.setBorder(new TitledBorder(getString("TableDemo.autoresize_mode")));
 
 
-        resizeModeComboBox = new JComboBox() {
+        resizeModeComboBox = new JComboBox<>() {
             public Dimension getMaximumSize() {
                 return getPreferredSize();
             }
@@ -285,7 +285,7 @@
         resizeModeComboBox.setSelectedIndex(tableView.getAutoResizeMode());
         resizeModeComboBox.addItemListener(new ItemListener() {
             public void itemStateChanged(ItemEvent e) {
-                JComboBox source = (JComboBox)e.getSource();
+                JComboBox source = (JComboBox)e.getSource();
                 tableView.setAutoResizeMode(source.getSelectedIndex());
             }
         });
@@ -367,7 +367,7 @@
      *
      * @param components The list of objects that are related
      */
-    void buildAccessibleGroup(Vector components) {
+    void buildAccessibleGroup(Vector components) {
 
         AccessibleContext context = null;
         int numComponents = components.size();
@@ -549,7 +549,7 @@
             public int getRowCount() { return data.length;}
             public Object getValueAt(int row, int col) {return data[row][col];}
             public String getColumnName(int column) {return names[column];}
-            public Class getColumnClass(int c) {return getValueAt(0, c).getClass();}
+            public Class getColumnClass(int c) {return getValueAt(0, c).getClass();}
             public boolean isCellEditable(int row, int col) {return col != 5;}
             public void setValueAt(Object aValue, int row, int column) { data[row][column] = aValue; }
          };
@@ -557,7 +557,7 @@
 
         // Create the table
         tableView = new JTable(dataModel);
-        TableRowSorter sorter = new TableRowSorter(dataModel);
+        TableRowSorter sorter = new TableRowSorter<>(dataModel);
         tableView.setRowSorter(sorter);
 
         // Show colors by rendering them in their own color.
@@ -575,7 +575,7 @@
         };
 
         // Create a combo box to show that you can use one in a table.
-        JComboBox comboBox = new JComboBox();
+        JComboBox comboBox = new JComboBox<>();
         comboBox.addItem(aqua);
         comboBox.addItem(beige);
         comboBox.addItem(black);
diff --git a/src/demo/share/jfc/TableExample/OldJTable.java b/src/demo/share/jfc/TableExample/OldJTable.java
index bc90794..8c77978 100644
--- a/src/demo/share/jfc/TableExample/OldJTable.java
+++ b/src/demo/share/jfc/TableExample/OldJTable.java
@@ -72,7 +72,7 @@
         return addColumn(columnIdentifier, width, null, null, null);
     }
 
-    public TableColumn addColumn(Object columnIdentifier, List columnData) {
+    public TableColumn addColumn(Object columnIdentifier, List columnData) {
         return addColumn(columnIdentifier, -1, null, null, columnData);
     }
 
@@ -86,7 +86,7 @@
 
     public TableColumn addColumn(Object columnIdentifier, int width,
                                  TableCellRenderer renderer,
-                                 TableCellEditor editor, List columnData) {
+                                 TableCellEditor editor, List columnData) {
         checkDefaultTableModel();
 
         // Set up the model side first
@@ -112,7 +112,7 @@
         ((DefaultTableModel)getModel()).addRow(rowData);
     }
 
-    public void addRow(List rowData) {
+    public void addRow(List rowData) {
         checkDefaultTableModel();
         ((DefaultTableModel)getModel()).addRow(rowData.toArray());
     }
@@ -132,7 +132,7 @@
         ((DefaultTableModel)getModel()).insertRow(rowIndex, rowData);
     }
 
-    public void insertRow(int rowIndex, List rowData) {
+    public void insertRow(int rowIndex, List rowData) {
         checkDefaultTableModel();
         ((DefaultTableModel)getModel()).insertRow(rowIndex, rowData.toArray());
     }
@@ -142,7 +142,7 @@
         ((DefaultTableModel)getModel()).setNumRows(newSize);
     }
 
-    public void setDataVector(Object[][] newData, List columnIds) {
+    public void setDataVector(Object[][] newData, List columnIds) {
         checkDefaultTableModel();
         ((DefaultTableModel)getModel()).setDataVector(
                 newData, columnIds.toArray());
diff --git a/src/demo/share/jfc/TableExample/TableExample3.java b/src/demo/share/jfc/TableExample/TableExample3.java
index ba10101..3ab77df 100644
--- a/src/demo/share/jfc/TableExample/TableExample3.java
+++ b/src/demo/share/jfc/TableExample/TableExample3.java
@@ -121,7 +121,7 @@
             }
 
             @Override
-            public Class getColumnClass(int col) {
+            public Class getColumnClass(int col) {
                 return getValueAt(0, col).getClass();
             }
 
diff --git a/src/demo/share/jfc/TableExample/TableExample4.java b/src/demo/share/jfc/TableExample/TableExample4.java
index f4132b6..053c631 100644
--- a/src/demo/share/jfc/TableExample/TableExample4.java
+++ b/src/demo/share/jfc/TableExample/TableExample4.java
@@ -123,7 +123,7 @@
             }
 
             @Override
-            public Class getColumnClass(int c) {
+            public Class getColumnClass(int c) {
                 return getValueAt(0, c).getClass();
             }
 
@@ -147,7 +147,7 @@
         tableView.setAutoResizeMode(JTable.AUTO_RESIZE_OFF);
 
         // Create a combo box to show that you can use one in a table.
-        JComboBox comboBox = new JComboBox();
+        JComboBox comboBox = new JComboBox<>();
         comboBox.addItem("Red");
         comboBox.addItem("Orange");
         comboBox.addItem("Yellow");
diff --git a/src/demo/share/jfc/TableExample/TableMap.java b/src/demo/share/jfc/TableExample/TableMap.java
index b0c24f0..cc8954a 100644
--- a/src/demo/share/jfc/TableExample/TableMap.java
+++ b/src/demo/share/jfc/TableExample/TableMap.java
@@ -94,7 +94,7 @@
     }
 
     @Override
-    public Class getColumnClass(int aColumn) {
+    public Class getColumnClass(int aColumn) {
         return model.getColumnClass(aColumn);
     }
 
diff --git a/src/demo/share/jfc/TableExample/TableSorter.java b/src/demo/share/jfc/TableExample/TableSorter.java
index 960eec1..31898db 100644
--- a/src/demo/share/jfc/TableExample/TableSorter.java
+++ b/src/demo/share/jfc/TableExample/TableSorter.java
@@ -91,7 +91,7 @@
     }
 
     public int compareRowsByColumn(int row1, int row2, int column) {
-        Class type = model.getColumnClass(column);
+        Class type = model.getColumnClass(column);
         TableModel data = model;
 
         // Check for nulls
-------------- next part --------------
diff --git a/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java b/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java
index 64af243..53a8602 100644
--- a/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java
+++ b/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java
@@ -158,7 +158,7 @@
         for (UIManager.LookAndFeelInfo lafInfo : installedLafs) {
             try {
                 Class lnfClass = Class.forName(lafInfo.getClassName());
-                LookAndFeel laf = (LookAndFeel) (lnfClass.newInstance());
+                LookAndFeel laf = (LookAndFeel) (lnfClass.getDeclaredConstructor().newInstance());
                 if (laf.isSupportedLookAndFeel()) {
                     String name = lafInfo.getName();
                     SupportedLaF supportedLaF = new SupportedLaF(name, laf);
diff --git a/src/demo/share/jfc/Font2DTest/Font2DTest.java b/src/demo/share/jfc/Font2DTest/Font2DTest.java
index de3b1ae..0fb8251 100644
--- a/src/demo/share/jfc/Font2DTest/Font2DTest.java
+++ b/src/demo/share/jfc/Font2DTest/Font2DTest.java
@@ -358,7 +358,7 @@
         userTextDialog.pack();
         userTextDialog.addWindowListener( new WindowAdapter() {
             public void windowClosing( WindowEvent e ) {
-                userTextDialog.hide();
+                userTextDialog.setVisible(false);
             }
         });
 
@@ -384,7 +384,7 @@
         printDialog.setResizable( false );
         printDialog.addWindowListener( new WindowAdapter() {
             public void windowClosing( WindowEvent e ) {
-                printDialog.hide();
+                printDialog.setVisible(false);
             }
         });
         printDialog.getContentPane().setLayout( new GridLayout( printModeCBs.length + 2, 1 ));
@@ -401,7 +401,7 @@
         fontInfoDialog.setResizable( false );
         fontInfoDialog.addWindowListener( new WindowAdapter() {
             public void windowClosing( WindowEvent e ) {
-                fontInfoDialog.hide();
+                fontInfoDialog.setVisible(false);
                 showFontInfoCBMI.setState( false );
             }
         });
@@ -672,9 +672,9 @@
 
         /// Set the visibility of User Text dialog
         if ( selectedText == fp.USER_TEXT )
-          userTextDialog.show();
+          userTextDialog.setVisible(true);
         else
-          userTextDialog.hide();
+          userTextDialog.setVisible(false);
         /// Change the visibility/status/availability of Print JDialog buttons
         printModeCBs[ fp.ONE_PAGE ].setSelected( true );
         if ( selectedText == fp.FILE_TEXT || selectedText == fp.USER_TEXT ) {
@@ -792,10 +792,10 @@
                             lcdContrast, userTextOpt );
             if ( showFontInfoOpt ) {
                 fireUpdateFontInfo();
-                fontInfoDialog.show();
+                fontInfoDialog.setVisible(true);
             }
             else
-              fontInfoDialog.hide();
+              fontInfoDialog.setVisible(false);
         }
         catch ( Exception ex ) {
             fireChangeStatus( "ERROR: Failed to Load Options File; See Stack Trace", true );
@@ -818,7 +818,7 @@
                 }
             });
             f.pack();
-            f.show();
+            f.setVisible(true);
         }
         catch ( Exception ex ) {
             fireChangeStatus( "ERROR: Failed to Load PNG File; See Stack Trace", true );
@@ -860,7 +860,7 @@
             else if ( itemName.equals( "Page Setup..." ))
               fp.doPageSetup();
             else if ( itemName.equals( "Print..." ))
-              printDialog.show();
+              printDialog.setVisible(true);
             else if ( itemName.equals( "Close" ))
               parent.dispose();
             else if ( itemName.equals( "Exit" ))
@@ -892,12 +892,12 @@
             if ( itemName.equals( "Print" )) {
                 for ( int i = 0; i < printModeCBs.length; i++ )
                   if ( printModeCBs[i].isSelected() ) {
-                      printDialog.hide();
+                      printDialog.setVisible(false);
                       fp.doPrint( i );
                   }
             }
             else if ( itemName.equals( "Cancel" ))
-              printDialog.hide();
+              printDialog.setVisible(false);
             /// Update button from Usert Text JDialog...
             else if ( itemName.equals( "Update" ))
               fp.setTextToDraw( fp.USER_TEXT, null,
@@ -995,10 +995,10 @@
             else if ( cbmi == showFontInfoCBMI ) {
                 if ( showFontInfoCBMI.getState() ) {
                     fireUpdateFontInfo();
-                    fontInfoDialog.show();
+                    fontInfoDialog.setVisible(true);
                 }
                 else
-                  fontInfoDialog.hide();
+                  fontInfoDialog.setVisible(false);
             }
         }
     }
@@ -1038,7 +1038,7 @@
 
         f.getContentPane().add( f2dt );
         f.pack();
-        f.show();
+        f.setVisible(true);
     }
 
     /// Inner class definitions...
diff --git a/src/demo/share/jfc/Font2DTest/Font2DTestApplet.java b/src/demo/share/jfc/Font2DTest/Font2DTestApplet.java
index 1292a83..40678fd 100644
--- a/src/demo/share/jfc/Font2DTest/Font2DTestApplet.java
+++ b/src/demo/share/jfc/Font2DTest/Font2DTestApplet.java
@@ -86,6 +86,6 @@
 
         f.getContentPane().add( f2dt );
         f.pack();
-        f.show();
+        f.setVisible(true);
     }
 }
diff --git a/src/demo/share/jfc/Font2DTest/FontPanel.java b/src/demo/share/jfc/Font2DTest/FontPanel.java
index d98ccd5..0e95d0e 100644
--- a/src/demo/share/jfc/Font2DTest/FontPanel.java
+++ b/src/demo/share/jfc/Font2DTest/FontPanel.java
@@ -392,7 +392,7 @@
         setTransformG2( g2transform ); // ABP
         setDrawMethod( method );
         setRenderingHints(AAValues.getValue(aa), FMValues.getValue(fm),
-                          new Integer(contrast));
+                          Integer.valueOf(contrast));
     }
 
     /// Writes the current screen to PNG file
@@ -1137,7 +1137,7 @@
                                   zoomAreaWidth / 2, (int) ( maxAscent * ZOOM ));
             g2.dispose();
             if ( !nowZooming )
-              zoomWindow.show();
+              zoomWindow.setVisible(true);
             /// This is sort of redundant... since there is a paint function
             /// inside zoomWindow definition that does the drawImage.
             /// (I should be able to call just repaint() here)
@@ -1176,7 +1176,7 @@
         public void mouseReleased( MouseEvent e ) {
             if ( textToUse == RANGE_TEXT || textToUse == ALL_GLYPHS ) {
                 if ( nowZooming )
-                  zoomWindow.hide();
+                  zoomWindow.setVisible(false);
                 nowZooming = false;
             }
             this.setCursor( Cursor.getDefaultCursor() );
diff --git a/src/demo/share/jfc/Font2DTest/RangeMenu.java b/src/demo/share/jfc/Font2DTest/RangeMenu.java
index 9200fb8..3e79653 100644
--- a/src/demo/share/jfc/Font2DTest/RangeMenu.java
+++ b/src/demo/share/jfc/Font2DTest/RangeMenu.java
@@ -186,7 +186,7 @@
                 if ( rangeName.equals("Custom...") ) {
                     useCustomRange = true;
                     customRangeDialog.setLocationRelativeTo(parent);
-                    customRangeDialog.show();
+                    customRangeDialog.setVisible(true);
                 }
                 else {
                   useCustomRange = false;
@@ -195,7 +195,7 @@
         }
         else if ( source instanceof JButton ) {
                 /// Since it is only "OK" button that sends any action here...
-                customRangeDialog.hide();
+                customRangeDialog.setVisible(false);
         }
     }
 
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/DemoPanel.java b/src/demo/share/jfc/J2Ddemo/java2d/DemoPanel.java
index 5da5cc8..40fa0cc 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/DemoPanel.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/DemoPanel.java
@@ -64,7 +64,7 @@
         try {
             if (obj instanceof String) {
                 className = (String) obj;
-                obj = Class.forName(className).newInstance();
+                obj = Class.forName(className).getDeclaredConstructor().newInstance();
             }
             if (obj instanceof Component) {
                 add((Component) obj);
diff --git a/src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/Tree.java b/src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/Tree.java
index e60ac76..48dccf2 100644
--- a/src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/Tree.java
+++ b/src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/Tree.java
@@ -51,8 +51,8 @@
 public class Tree extends AnimatingSurface {
 
     private char theC = 'A';
-    private Character theT = new Character(theC);
-    private Character theR = new Character((char) (theC + 1));
+    private Character theT = Character.valueOf(theC);
+    private Character theR = Character.valueOf((char) (theC + 1));
 
     public Tree() {
         setBackground(WHITE);
@@ -65,9 +65,9 @@
     @Override
     public void step(int w, int h) {
         setSleepAmount(4000);
-        theT = new Character(theC = ((char) (theC + 1)));
-        theR = new Character((char) (theC + 1));
-        if (theR.compareTo(new Character('z')) == 0) {
+        theT = Character.valueOf(theC = ((char) (theC + 1)));
+        theR = Character.valueOf((char) (theC + 1));
+        if (theR.compareTo(Character.valueOf('z')) == 0) {
             theC = 'A';
         }
     }
diff --git a/src/demo/share/jfc/SwingSet2/ColorChooserDemo.java b/src/demo/share/jfc/SwingSet2/ColorChooserDemo.java
index 2a4b731..d87c108 100644
--- a/src/demo/share/jfc/SwingSet2/ColorChooserDemo.java
+++ b/src/demo/share/jfc/SwingSet2/ColorChooserDemo.java
@@ -128,7 +128,7 @@
                                                             okListener,
                                                             null);
 
-                dialog.show();
+                dialog.setVisible(true);
 
                 if(e.getSource() == outerColorButton) {
                     bezAnim.setOuterColor(chosen);
diff --git a/src/demo/share/jfc/SwingSet2/DemoModule.java b/src/demo/share/jfc/SwingSet2/DemoModule.java
index 8fb6042..a080f58 100644
--- a/src/demo/share/jfc/SwingSet2/DemoModule.java
+++ b/src/demo/share/jfc/SwingSet2/DemoModule.java
@@ -190,7 +190,7 @@
         frame.getContentPane().add(getDemoPanel(), BorderLayout.CENTER);
         getDemoPanel().setPreferredSize(new Dimension(PREFERRED_WIDTH, PREFERRED_HEIGHT));
         frame.pack();
-        frame.show();
+        frame.setVisible(true);
     }
 
     public JPanel createHorizontalPanel(boolean threeD) {
diff --git a/src/demo/share/jfc/SwingSet2/DirectionPanel.java b/src/demo/share/jfc/SwingSet2/DirectionPanel.java
index 9a18f64..4906590 100644
--- a/src/demo/share/jfc/SwingSet2/DirectionPanel.java
+++ b/src/demo/share/jfc/SwingSet2/DirectionPanel.java
@@ -147,10 +147,7 @@
             getAccessibleContext().setAccessibleName(direction);
             getAccessibleContext().setAccessibleDescription(description);
             setSelected(selected);
-        }
-
-        public boolean isFocusTraversable() {
-            return false;
+            setFocusable(false);
         }
 
         public void setBorder(Border b) {
diff --git a/src/demo/share/jfc/SwingSet2/FileChooserDemo.java b/src/demo/share/jfc/SwingSet2/FileChooserDemo.java
index 297e5cb..f851000 100644
--- a/src/demo/share/jfc/SwingSet2/FileChooserDemo.java
+++ b/src/demo/share/jfc/SwingSet2/FileChooserDemo.java
@@ -273,7 +273,7 @@
                 dialog.getContentPane().add(custom, BorderLayout.CENTER);
                 dialog.pack();
                 dialog.setLocationRelativeTo(getDemoPanel());
-                dialog.show();
+                dialog.setVisible(true);
             }
         };
         return createButton(a);
diff --git a/src/demo/share/jfc/SwingSet2/InternalFrameDemo.java b/src/demo/share/jfc/SwingSet2/InternalFrameDemo.java
index b9c5959..a02ec0b 100644
--- a/src/demo/share/jfc/SwingSet2/InternalFrameDemo.java
+++ b/src/demo/share/jfc/SwingSet2/InternalFrameDemo.java
@@ -59,9 +59,9 @@
     ImageIcon icon1, icon2, icon3, icon4;
     ImageIcon smIcon1, smIcon2, smIcon3, smIcon4;
 
-    public Integer FIRST_FRAME_LAYER  = new Integer(1);
-    public Integer DEMO_FRAME_LAYER   = new Integer(2);
-    public Integer PALETTE_LAYER     = new Integer(3);
+    public Integer FIRST_FRAME_LAYER  = Integer.valueOf(1);
+    public Integer DEMO_FRAME_LAYER   = Integer.valueOf(2);
+    public Integer PALETTE_LAYER     = Integer.valueOf(3);
 
     public int FRAME0_X        = 15;
     public int FRAME0_Y        = 280;
diff --git a/src/demo/share/jfc/SwingSet2/SliderDemo.java b/src/demo/share/jfc/SwingSet2/SliderDemo.java
index 15bd7c4..989fdaf 100644
--- a/src/demo/share/jfc/SwingSet2/SliderDemo.java
+++ b/src/demo/share/jfc/SwingSet2/SliderDemo.java
@@ -166,7 +166,7 @@
 
         @SuppressWarnings("unchecked")
 		Dictionary labelTable = s.getLabelTable();
-        labelTable.put(new Integer(11), new JLabel(new Integer(11).toString(), JLabel.CENTER));
+        labelTable.put(Integer.valueOf(11), new JLabel(Integer.valueOf(11).toString(), JLabel.CENTER));
         s.setLabelTable( s.getLabelTable() );
 
         s.getAccessibleContext().setAccessibleName(getString("SliderDemo.minorticks"));
diff --git a/src/demo/share/jfc/SwingSet2/SplitPaneDemo.java b/src/demo/share/jfc/SwingSet2/SplitPaneDemo.java
index 9e92211..fba1a76 100644
--- a/src/demo/share/jfc/SwingSet2/SplitPaneDemo.java
+++ b/src/demo/share/jfc/SwingSet2/SplitPaneDemo.java
@@ -165,7 +165,7 @@
         JLabel                   label;
 
         divSize = new JTextField();
-        divSize.setText(new Integer(splitPane.getDividerSize()).toString());
+        divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString());
         divSize.setColumns(5);
         divSize.getAccessibleContext().setAccessibleName(getString("SplitPaneDemo.divider_size"));
         divSize.addActionListener(new ActionListener() {
diff --git a/src/demo/share/jfc/SwingSet2/SwingSet2.java b/src/demo/share/jfc/SwingSet2/SwingSet2.java
index 6a710b1..f553a7e 100644
--- a/src/demo/share/jfc/SwingSet2/SwingSet2.java
+++ b/src/demo/share/jfc/SwingSet2/SwingSet2.java
@@ -578,7 +578,7 @@
 
         // register key binding to activate popup menu
         InputMap map = getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW);
-        map.put(KeyStroke.getKeyStroke(KeyEvent.VK_F10, InputEvent.SHIFT_MASK),
+        map.put(KeyStroke.getKeyStroke(KeyEvent.VK_F10, InputEvent.SHIFT_DOWN_MASK),
                 "postMenuAction");
         map.put(KeyStroke.getKeyStroke(KeyEvent.VK_CONTEXT_MENU, 0), "postMenuAction");
         getActionMap().put("postMenuAction", new ActivatePopupMenuAction(this, popup));
@@ -686,7 +686,7 @@
                     screenInsets.top : centerHeight;
 
             f.setLocation(centerWidth, centerHeight);
-            f.show();
+            f.setVisible(true);
             numSSs++;
             swingSets.add(this);
         }
@@ -1213,7 +1213,7 @@
             } else {
                 aboutBox.setLocationRelativeTo(getFrame());
             }
-            aboutBox.show();
+            aboutBox.setVisible(true);
         }
     }
 
diff --git a/src/demo/share/jfc/SwingSet2/TableDemo.java b/src/demo/share/jfc/SwingSet2/TableDemo.java
index 130c4aa..48199c5 100644
--- a/src/demo/share/jfc/SwingSet2/TableDemo.java
+++ b/src/demo/share/jfc/SwingSet2/TableDemo.java
@@ -492,55 +492,55 @@
 
         // Create the dummy data (a few rows of names)
         final Object[][] data = {
-          {"Mike", "Albers",      green,       getString("TableDemo.brazil"), new Double(44.0), strawberry},
-          {"Mark", "Andrews",     blue,        getString("TableDemo.curse"), new Double(3), grapes},
-          {"Brian", "Beck",       black,       getString("TableDemo.bluesbros"), new Double(2.7182818285), raspberry},
-          {"Lara", "Bunni",       red,         getString("TableDemo.airplane"), new Double(15), strawberry},
-          {"Roger", "Brinkley",   blue,        getString("TableDemo.man"), new Double(13), peach},
-          {"Brent", "Christian",  black,       getString("TableDemo.bladerunner"), new Double(23), broccoli},
-          {"Mark", "Davidson",    darkgreen,   getString("TableDemo.brazil"), new Double(27), asparagus},
-          {"Jeff", "Dinkins",     blue,        getString("TableDemo.ladyvanishes"), new Double(8), kiwi},
-          {"Ewan", "Dinkins",     yellow,      getString("TableDemo.bugs"), new Double(2), strawberry},
-          {"Amy", "Fowler",       violet,      getString("TableDemo.reservoir"), new Double(3), raspberry},
-          {"Hania", "Gajewska",   purple,      getString("TableDemo.jules"), new Double(5), raspberry},
-          {"David", "Geary",      blue,        getString("TableDemo.pulpfiction"), new Double(3), watermelon},
-//        {"James", "Gosling",    pink,        getString("TableDemo.tennis"), new Double(21), donut},
-          {"Eric", "Hawkes",      blue,        getString("TableDemo.bladerunner"), new Double(.693), pickle},
-          {"Shannon", "Hickey",   green,       getString("TableDemo.shawshank"), new Double(2), grapes},
-          {"Earl", "Johnson",     green,       getString("TableDemo.pulpfiction"), new Double(8), carrot},
-          {"Robi", "Khan",        green,       getString("TableDemo.goodfellas"), new Double(89), apple},
-          {"Robert", "Kim",       blue,        getString("TableDemo.mohicans"), new Double(655321), strawberry},
-          {"Janet", "Koenig",     turquoise,   getString("TableDemo.lonestar"), new Double(7), peach},
-          {"Jeff", "Kesselman",   blue,        getString("TableDemo.stuntman"), new Double(17), pineapple},
-          {"Onno", "Kluyt",       orange,      getString("TableDemo.oncewest"), new Double(8), broccoli},
-          {"Peter", "Korn",       sunpurple,   getString("TableDemo.musicman"), new Double(12), sparegrass},
+          {"Mike", "Albers",      green,       getString("TableDemo.brazil"), Double.valueOf(44.0), strawberry},
+          {"Mark", "Andrews",     blue,        getString("TableDemo.curse"), Double.valueOf(3), grapes},
+          {"Brian", "Beck",       black,       getString("TableDemo.bluesbros"), Double.valueOf(2.7182818285), raspberry},
+          {"Lara", "Bunni",       red,         getString("TableDemo.airplane"), Double.valueOf(15), strawberry},
+          {"Roger", "Brinkley",   blue,        getString("TableDemo.man"), Double.valueOf(13), peach},
+          {"Brent", "Christian",  black,       getString("TableDemo.bladerunner"), Double.valueOf(23), broccoli},
+          {"Mark", "Davidson",    darkgreen,   getString("TableDemo.brazil"), Double.valueOf(27), asparagus},
+          {"Jeff", "Dinkins",     blue,        getString("TableDemo.ladyvanishes"), Double.valueOf(8), kiwi},
+          {"Ewan", "Dinkins",     yellow,      getString("TableDemo.bugs"), Double.valueOf(2), strawberry},
+          {"Amy", "Fowler",       violet,      getString("TableDemo.reservoir"), Double.valueOf(3), raspberry},
+          {"Hania", "Gajewska",   purple,      getString("TableDemo.jules"), Double.valueOf(5), raspberry},
+          {"David", "Geary",      blue,        getString("TableDemo.pulpfiction"), Double.valueOf(3), watermelon},
+//        {"James", "Gosling",    pink,        getString("TableDemo.tennis"), Double.valueOf(21), donut},
+          {"Eric", "Hawkes",      blue,        getString("TableDemo.bladerunner"), Double.valueOf(.693), pickle},
+          {"Shannon", "Hickey",   green,       getString("TableDemo.shawshank"), Double.valueOf(2), grapes},
+          {"Earl", "Johnson",     green,       getString("TableDemo.pulpfiction"), Double.valueOf(8), carrot},
+          {"Robi", "Khan",        green,       getString("TableDemo.goodfellas"), Double.valueOf(89), apple},
+          {"Robert", "Kim",       blue,        getString("TableDemo.mohicans"), Double.valueOf(655321), strawberry},
+          {"Janet", "Koenig",     turquoise,   getString("TableDemo.lonestar"), Double.valueOf(7), peach},
+          {"Jeff", "Kesselman",   blue,        getString("TableDemo.stuntman"), Double.valueOf(17), pineapple},
+          {"Onno", "Kluyt",       orange,      getString("TableDemo.oncewest"), Double.valueOf(8), broccoli},
+          {"Peter", "Korn",       sunpurple,   getString("TableDemo.musicman"), Double.valueOf(12), sparegrass},
 
-          {"Rick", "Levenson",    black,       getString("TableDemo.harold"), new Double(1327), raspberry},
-          {"Brian", "Lichtenwalter", jfcblue,  getString("TableDemo.fifthelement"), new Double(22), pear},
-          {"Malini", "Minasandram", beige,     getString("TableDemo.joyluck"), new Double(9), corn},
-          {"Michael", "Martak",   green,       getString("TableDemo.city"), new Double(3), strawberry},
-          {"David", "Mendenhall", forestgreen, getString("TableDemo.schindlerslist"), new Double(7), peach},
-          {"Phil", "Milne",       suspectpink, getString("TableDemo.withnail"), new Double(3), banana},
-          {"Lynn", "Monsanto",    cybergreen,  getString("TableDemo.dasboot"), new Double(52), peach},
-          {"Hans", "Muller",      rustred,     getString("TableDemo.eraserhead"), new Double(0), pineapple},
-          {"Joshua", "Outwater",  blue,        getString("TableDemo.labyrinth"), new Double(3), pineapple},
-          {"Tim", "Prinzing",     blue,        getString("TableDemo.firstsight"), new Double(69), pepper},
-          {"Raj", "Premkumar",    jfcblue2,    getString("TableDemo.none"), new Double(7), broccoli},
-          {"Howard", "Rosen",     green,       getString("TableDemo.defending"), new Double(7), strawberry},
+          {"Rick", "Levenson",    black,       getString("TableDemo.harold"), Double.valueOf(1327), raspberry},
+          {"Brian", "Lichtenwalter", jfcblue,  getString("TableDemo.fifthelement"), Double.valueOf(22), pear},
+          {"Malini", "Minasandram", beige,     getString("TableDemo.joyluck"), Double.valueOf(9), corn},
+          {"Michael", "Martak",   green,       getString("TableDemo.city"), Double.valueOf(3), strawberry},
+          {"David", "Mendenhall", forestgreen, getString("TableDemo.schindlerslist"), Double.valueOf(7), peach},
+          {"Phil", "Milne",       suspectpink, getString("TableDemo.withnail"), Double.valueOf(3), banana},
+          {"Lynn", "Monsanto",    cybergreen,  getString("TableDemo.dasboot"), Double.valueOf(52), peach},
+          {"Hans", "Muller",      rustred,     getString("TableDemo.eraserhead"), Double.valueOf(0), pineapple},
+          {"Joshua", "Outwater",  blue,        getString("TableDemo.labyrinth"), Double.valueOf(3), pineapple},
+          {"Tim", "Prinzing",     blue,        getString("TableDemo.firstsight"), Double.valueOf(69), pepper},
+          {"Raj", "Premkumar",    jfcblue2,    getString("TableDemo.none"), Double.valueOf(7), broccoli},
+          {"Howard", "Rosen",     green,       getString("TableDemo.defending"), Double.valueOf(7), strawberry},
           {"Ray", "Ryan",         black,       getString("TableDemo.buckaroo"),
-           new Double(3.141592653589793238462643383279502884197169399375105820974944), banana},
-          {"Georges", "Saab",     aqua,        getString("TableDemo.bicycle"), new Double(290), cantaloupe},
-          {"Tom", "Santos",       blue,        getString("TableDemo.spinaltap"), new Double(241), pepper},
-          {"Rich", "Schiavi",     blue,        getString("TableDemo.repoman"), new Double(0xFF), pepper},
-          {"Nancy", "Schorr",     green,       getString("TableDemo.fifthelement"), new Double(47), watermelon},
-          {"Keith", "Sprochi",    darkgreen,   getString("TableDemo.2001"), new Double(13), watermelon},
-          {"Matt", "Tucker",      eblue,       getString("TableDemo.starwars"), new Double(2), broccoli},
-          {"Dmitri", "Trembovetski", red,      getString("TableDemo.aliens"), new Double(222), tomato},
-          {"Scott", "Violet",     violet,      getString("TableDemo.raiders"), new Double(-97), banana},
-          {"Kathy", "Walrath",    darkgreen,   getString("TableDemo.thinman"), new Double(8), pear},
-          {"Nathan", "Walrath",   black,       getString("TableDemo.chusingura"), new Double(3), grapefruit},
-          {"Steve", "Wilson",     green,       getString("TableDemo.raiders"), new Double(7), onion},
-          {"Kathleen", "Zelony",  gray,        getString("TableDemo.dog"), new Double(13), grapes}
+           Double.valueOf(3.141592653589793238462643383279502884197169399375105820974944), banana},
+          {"Georges", "Saab",     aqua,        getString("TableDemo.bicycle"), Double.valueOf(290), cantaloupe},
+          {"Tom", "Santos",       blue,        getString("TableDemo.spinaltap"), Double.valueOf(241), pepper},
+          {"Rich", "Schiavi",     blue,        getString("TableDemo.repoman"), Double.valueOf(0xFF), pepper},
+          {"Nancy", "Schorr",     green,       getString("TableDemo.fifthelement"), Double.valueOf(47), watermelon},
+          {"Keith", "Sprochi",    darkgreen,   getString("TableDemo.2001"), Double.valueOf(13), watermelon},
+          {"Matt", "Tucker",      eblue,       getString("TableDemo.starwars"), Double.valueOf(2), broccoli},
+          {"Dmitri", "Trembovetski", red,      getString("TableDemo.aliens"), Double.valueOf(222), tomato},
+          {"Scott", "Violet",     violet,      getString("TableDemo.raiders"), Double.valueOf(-97), banana},
+          {"Kathy", "Walrath",    darkgreen,   getString("TableDemo.thinman"), Double.valueOf(8), pear},
+          {"Nathan", "Walrath",   black,       getString("TableDemo.chusingura"), Double.valueOf(3), grapefruit},
+          {"Steve", "Wilson",     green,       getString("TableDemo.raiders"), Double.valueOf(7), onion},
+          {"Kathleen", "Zelony",  gray,        getString("TableDemo.dog"), Double.valueOf(13), grapes}
         };
 
         // Create a model of the data.
diff --git a/src/demo/share/jfc/TableExample/JDBCAdapter.java b/src/demo/share/jfc/TableExample/JDBCAdapter.java
index 02d0d38..31e1113 100644
--- a/src/demo/share/jfc/TableExample/JDBCAdapter.java
+++ b/src/demo/share/jfc/TableExample/JDBCAdapter.java
@@ -125,12 +125,6 @@
         connection.close();
     }
 
-    @Override
-    protected void finalize() throws Throwable {
-        close();
-        super.finalize();
-    }
-
     //////////////////////////////////////////////////////////////////////////
     //
     //             Implementation of the TableModel Interface
diff --git a/src/demo/share/jfc/TableExample/TableExample3.java b/src/demo/share/jfc/TableExample/TableExample3.java
index 3ab77df..9f3c11f 100644
--- a/src/demo/share/jfc/TableExample/TableExample3.java
+++ b/src/demo/share/jfc/TableExample/TableExample3.java
@@ -73,27 +73,27 @@
         final String[] names = { "First Name", "Last Name", "Favorite Color",
             "Favorite Number", "Vegetarian" };
         final Object[][] data = {
-            { "Mark", "Andrews", "Red", new Integer(2), Boolean.TRUE },
-            { "Tom", "Ball", "Blue", new Integer(99), Boolean.FALSE },
-            { "Alan", "Chung", "Green", new Integer(838), Boolean.FALSE },
-            { "Jeff", "Dinkins", "Turquois", new Integer(8), Boolean.TRUE },
-            { "Amy", "Fowler", "Yellow", new Integer(3), Boolean.FALSE },
-            { "Brian", "Gerhold", "Green", new Integer(0), Boolean.FALSE },
-            { "James", "Gosling", "Pink", new Integer(21), Boolean.FALSE },
-            { "David", "Karlton", "Red", new Integer(1), Boolean.FALSE },
-            { "Dave", "Kloba", "Yellow", new Integer(14), Boolean.FALSE },
-            { "Peter", "Korn", "Purple", new Integer(12), Boolean.FALSE },
-            { "Phil", "Milne", "Purple", new Integer(3), Boolean.FALSE },
-            { "Dave", "Moore", "Green", new Integer(88), Boolean.FALSE },
-            { "Hans", "Muller", "Maroon", new Integer(5), Boolean.FALSE },
-            { "Rick", "Levenson", "Blue", new Integer(2), Boolean.FALSE },
-            { "Tim", "Prinzing", "Blue", new Integer(22), Boolean.FALSE },
-            { "Chester", "Rose", "Black", new Integer(0), Boolean.FALSE },
-            { "Ray", "Ryan", "Gray", new Integer(77), Boolean.FALSE },
-            { "Georges", "Saab", "Red", new Integer(4), Boolean.FALSE },
-            { "Willie", "Walker", "Phthalo Blue", new Integer(4), Boolean.FALSE },
-            { "Kathy", "Walrath", "Blue", new Integer(8), Boolean.FALSE },
-            { "Arnaud", "Weber", "Green", new Integer(44), Boolean.FALSE }
+            { "Mark", "Andrews", "Red", Integer.valueOf(2), Boolean.TRUE },
+            { "Tom", "Ball", "Blue", Integer.valueOf(99), Boolean.FALSE },
+            { "Alan", "Chung", "Green", Integer.valueOf(838), Boolean.FALSE },
+            { "Jeff", "Dinkins", "Turquois", Integer.valueOf(8), Boolean.TRUE },
+            { "Amy", "Fowler", "Yellow", Integer.valueOf(3), Boolean.FALSE },
+            { "Brian", "Gerhold", "Green", Integer.valueOf(0), Boolean.FALSE },
+            { "James", "Gosling", "Pink", Integer.valueOf(21), Boolean.FALSE },
+            { "David", "Karlton", "Red", Integer.valueOf(1), Boolean.FALSE },
+            { "Dave", "Kloba", "Yellow", Integer.valueOf(14), Boolean.FALSE },
+            { "Peter", "Korn", "Purple", Integer.valueOf(12), Boolean.FALSE },
+            { "Phil", "Milne", "Purple", Integer.valueOf(3), Boolean.FALSE },
+            { "Dave", "Moore", "Green", Integer.valueOf(88), Boolean.FALSE },
+            { "Hans", "Muller", "Maroon", Integer.valueOf(5), Boolean.FALSE },
+            { "Rick", "Levenson", "Blue", Integer.valueOf(2), Boolean.FALSE },
+            { "Tim", "Prinzing", "Blue", Integer.valueOf(22), Boolean.FALSE },
+            { "Chester", "Rose", "Black", Integer.valueOf(0), Boolean.FALSE },
+            { "Ray", "Ryan", "Gray", Integer.valueOf(77), Boolean.FALSE },
+            { "Georges", "Saab", "Red", Integer.valueOf(4), Boolean.FALSE },
+            { "Willie", "Walker", "Phthalo Blue", Integer.valueOf(4), Boolean.FALSE },
+            { "Kathy", "Walrath", "Blue", Integer.valueOf(8), Boolean.FALSE },
+            { "Arnaud", "Weber", "Green", Integer.valueOf(44), Boolean.FALSE }
         };
 
         // Create a model of the data.
diff --git a/src/demo/share/jfc/TableExample/TableExample4.java b/src/demo/share/jfc/TableExample/TableExample4.java
index 053c631..4d81a3d 100644
--- a/src/demo/share/jfc/TableExample/TableExample4.java
+++ b/src/demo/share/jfc/TableExample/TableExample4.java
@@ -75,27 +75,27 @@
         final String[] names = { "First Name", "Last Name", "Favorite Color",
             "Favorite Number", "Vegetarian" };
         final Object[][] data = {
-            { "Mark", "Andrews", "Red", new Integer(2), Boolean.TRUE },
-            { "Tom", "Ball", "Blue", new Integer(99), Boolean.FALSE },
-            { "Alan", "Chung", "Green", new Integer(838), Boolean.FALSE },
-            { "Jeff", "Dinkins", "Turquois", new Integer(8), Boolean.TRUE },
-            { "Amy", "Fowler", "Yellow", new Integer(3), Boolean.FALSE },
-            { "Brian", "Gerhold", "Green", new Integer(0), Boolean.FALSE },
-            { "James", "Gosling", "Pink", new Integer(21), Boolean.FALSE },
-            { "David", "Karlton", "Red", new Integer(1), Boolean.FALSE },
-            { "Dave", "Kloba", "Yellow", new Integer(14), Boolean.FALSE },
-            { "Peter", "Korn", "Purple", new Integer(12), Boolean.FALSE },
-            { "Phil", "Milne", "Purple", new Integer(3), Boolean.FALSE },
-            { "Dave", "Moore", "Green", new Integer(88), Boolean.FALSE },
-            { "Hans", "Muller", "Maroon", new Integer(5), Boolean.FALSE },
-            { "Rick", "Levenson", "Blue", new Integer(2), Boolean.FALSE },
-            { "Tim", "Prinzing", "Blue", new Integer(22), Boolean.FALSE },
-            { "Chester", "Rose", "Black", new Integer(0), Boolean.FALSE },
-            { "Ray", "Ryan", "Gray", new Integer(77), Boolean.FALSE },
-            { "Georges", "Saab", "Red", new Integer(4), Boolean.FALSE },
-            { "Willie", "Walker", "Phthalo Blue", new Integer(4), Boolean.FALSE },
-            { "Kathy", "Walrath", "Blue", new Integer(8), Boolean.FALSE },
-            { "Arnaud", "Weber", "Green", new Integer(44), Boolean.FALSE }
+            { "Mark", "Andrews", "Red", Integer.valueOf(2), Boolean.TRUE },
+            { "Tom", "Ball", "Blue", Integer.valueOf(99), Boolean.FALSE },
+            { "Alan", "Chung", "Green", Integer.valueOf(838), Boolean.FALSE },
+            { "Jeff", "Dinkins", "Turquois", Integer.valueOf(8), Boolean.TRUE },
+            { "Amy", "Fowler", "Yellow", Integer.valueOf(3), Boolean.FALSE },
+            { "Brian", "Gerhold", "Green", Integer.valueOf(0), Boolean.FALSE },
+            { "James", "Gosling", "Pink", Integer.valueOf(21), Boolean.FALSE },
+            { "David", "Karlton", "Red", Integer.valueOf(1), Boolean.FALSE },
+            { "Dave", "Kloba", "Yellow", Integer.valueOf(14), Boolean.FALSE },
+            { "Peter", "Korn", "Purple", Integer.valueOf(12), Boolean.FALSE },
+            { "Phil", "Milne", "Purple", Integer.valueOf(3), Boolean.FALSE },
+            { "Dave", "Moore", "Green", Integer.valueOf(88), Boolean.FALSE },
+            { "Hans", "Muller", "Maroon", Integer.valueOf(5), Boolean.FALSE },
+            { "Rick", "Levenson", "Blue", Integer.valueOf(2), Boolean.FALSE },
+            { "Tim", "Prinzing", "Blue", Integer.valueOf(22), Boolean.FALSE },
+            { "Chester", "Rose", "Black", Integer.valueOf(0), Boolean.FALSE },
+            { "Ray", "Ryan", "Gray", Integer.valueOf(77), Boolean.FALSE },
+            { "Georges", "Saab", "Red", Integer.valueOf(4), Boolean.FALSE },
+            { "Willie", "Walker", "Phthalo Blue", Integer.valueOf(4), Boolean.FALSE },
+            { "Kathy", "Walrath", "Blue", Integer.valueOf(8), Boolean.FALSE },
+            { "Arnaud", "Weber", "Green", Integer.valueOf(44), Boolean.FALSE }
         };
 
         // Create a model of the data.
diff --git a/src/demo/share/jfc/TableExample/TableSorter.java b/src/demo/share/jfc/TableExample/TableSorter.java
index 31898db..5ca83aa 100644
--- a/src/demo/share/jfc/TableExample/TableSorter.java
+++ b/src/demo/share/jfc/TableExample/TableSorter.java
@@ -339,7 +339,7 @@
                 int column = tableView.convertColumnIndexToModel(viewColumn);
                 if (e.getClickCount() == 1 && column != -1) {
                     System.out.println("Sorting ...");
-                    int shiftPressed = e.getModifiers() & InputEvent.SHIFT_MASK;
+                    int shiftPressed = e.getModifiersEx() & InputEvent.SHIFT_DOWN_MASK;
                     boolean ascending = (shiftPressed == 0);
                     sorter.sortByColumn(column, ascending);
                 }
-------------- next part --------------
diff --git a/src/demo/share/jfc/Font2DTest/Font2DTestApplet.java b/src/demo/share/jfc/Font2DTest/Font2DTestApplet.java
deleted file mode 100644
index 40678fd..0000000
--- a/src/demo/share/jfc/Font2DTest/Font2DTestApplet.java
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- *   - Redistributions of source code must retain the above copyright
- *     notice, this list of conditions and the following disclaimer.
- *
- *   - Redistributions in binary form must reproduce the above copyright
- *     notice, this list of conditions and the following disclaimer in the
- *     documentation and/or other materials provided with the distribution.
- *
- *   - Neither the name of Oracle nor the names of its
- *     contributors may be used to endorse or promote products derived
- *     from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
- * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-/*
- * This source code is provided to illustrate the usage of a given feature
- * or technique and has been deliberately simplified. Additional steps
- * required for a production-quality application, such as security checks,
- * input validation and proper error handling, might not be present in
- * this sample code.
- */
-
-
-/*
- */
-
-import java.awt.AWTPermission;
-import java.awt.Frame;
-import java.awt.event.WindowAdapter;
-import java.awt.event.WindowEvent;
-
-import javax.swing.*;
-
-/**
- * Font2DTestApplet.java
- *
- * @author Shinsuke Fukuda
- * @author Ankit Patel [Conversion to Swing - 01/07/30]
- */
-
-/// Applet version of Font2DTest that wraps the actual demo
-
-public final class Font2DTestApplet extends JApplet {
-    public void init() {
-        /// Check if necessary permission is given...
-        SecurityManager security = System.getSecurityManager();
-        if ( security != null ) {
-            try {
-                security.checkPermission( new AWTPermission( "showWindowWithoutWarningBanner" ));
-            }
-            catch ( SecurityException e ) {
-                System.out.println( "NOTE: showWindowWithoutWarningBanner AWTPermission not given.\n" +
-                                    "Zoom window will contain warning banner at bottom when shown\n" );
-            }
-            try {
-                security.checkPrintJobAccess();
-            }
-            catch ( SecurityException e ) {
-                System.out.println( "NOTE: queuePrintJob RuntimePermission not given.\n" +
-                                    "Printing feature will not be available\n" );
-            }
-        }
-
-        final JFrame f = new JFrame( "Font2DTest" );
-        final Font2DTest f2dt = new Font2DTest( f, true );
-        f.addWindowListener( new WindowAdapter() {
-            public void windowClosing( WindowEvent e ) { f.dispose(); }
-        });
-
-        f.getContentPane().add( f2dt );
-        f.pack();
-        f.setVisible(true);
-    }
-}
diff --git a/src/demo/share/jfc/SwingSet2/DemoModule.java b/src/demo/share/jfc/SwingSet2/DemoModule.java
index a080f58..a726cc2 100644
--- a/src/demo/share/jfc/SwingSet2/DemoModule.java
+++ b/src/demo/share/jfc/SwingSet2/DemoModule.java
@@ -51,7 +51,7 @@
  *
  * @author Jeff Dinkins
  */
-public class DemoModule extends JApplet {
+public class DemoModule extends JFrame {
 
     // The preferred size of the demo
     private int PREFERRED_WIDTH = 680;
diff --git a/src/demo/share/jfc/SwingSet2/SwingSet2.java b/src/demo/share/jfc/SwingSet2/SwingSet2.java
index f553a7e..13b3d63 100644
--- a/src/demo/share/jfc/SwingSet2/SwingSet2.java
+++ b/src/demo/share/jfc/SwingSet2/SwingSet2.java
@@ -71,12 +71,7 @@
 
     void loadDemos() {
         for(int i = 0; i < demos.length;) {
-            if(isApplet() && demos[i].equals("FileChooserDemo")) {
-               // don't load the file chooser demo if we are
-               // an applet
-            } else {
-               loadDemo(demos[i]);
-            }
+            loadDemo(demos[i]);
             i++;
         }
     }
@@ -126,9 +121,6 @@
     // Used only if swingset is an application
     private JFrame frame = null;
 
-    // Used only if swingset is an applet
-    private SwingSet2Applet applet = null;
-
     // To debug or not to debug, that is the question
     private boolean DEBUG = true;
     private int debugCounter = 0;
@@ -151,27 +143,21 @@
 
     private boolean dragEnabled = false;
 
-    public SwingSet2(SwingSet2Applet applet) {
-        this(applet, null);
+    public SwingSet2() {
+        this(null);
     }
 
     /**
      * SwingSet2 Constructor
      */
-    public SwingSet2(SwingSet2Applet applet, GraphicsConfiguration gc) {
-
-        // Note that applet may be null if this is started as an application
-        this.applet = applet;
-
+    public SwingSet2(GraphicsConfiguration gc) {
         String lafClassName = UIManager.getLookAndFeel().getClass().getName();
         lookAndFeelData = getInstalledLookAndFeelData();
         currentLookAndFeel = Arrays.stream(lookAndFeelData)
                 .filter(laf -> lafClassName.equals(laf.className))
                 .findFirst().get();
 
-        if (!isApplet()) {
-            frame = createFrame(gc);
-        }
+        frame = createFrame(gc);
 
         // set the layout
         setLayout(new BorderLayout());
@@ -198,7 +184,7 @@
         SwingUtilities.invokeLater(() -> {
             // Create SwingSet on the default monitor
             UIManager.put("swing.boldMetal", Boolean.FALSE);
-            SwingSet2 swingset = new SwingSet2(null, GraphicsEnvironment.
+            SwingSet2 swingset = new SwingSet2(GraphicsEnvironment.
                                          getLocalGraphicsEnvironment().
                                          getDefaultScreenDevice().
                                          getDefaultConfiguration());
@@ -218,11 +204,7 @@
 
         menuBar = createMenus();
 
-    if (isApplet()) {
-        applet.setJMenuBar(menuBar);
-    } else {
         frame.setJMenuBar(menuBar);
-    }
 
         // creates popup menu accessible via keyboard
         popupMenu = createPopupMenu();
@@ -309,13 +291,11 @@
                        "FileMenu.save_as_accessible_description", null);
 
 
-        if(!isApplet()) {
-            fileMenu.addSeparator();
+        fileMenu.addSeparator();
 
-            createMenuItem(fileMenu, "FileMenu.exit_label", "FileMenu.exit_mnemonic",
-                           "FileMenu.exit_accessible_description", new ExitAction(this)
-            );
-        }
+        createMenuItem(fileMenu, "FileMenu.exit_label", "FileMenu.exit_mnemonic",
+                       "FileMenu.exit_accessible_description", new ExitAction(this)
+        );
 
         // Create these menu items for the first SwingSet only.
         if (numSSs == 0) {
@@ -431,7 +411,6 @@
 
 
         // ***** create the multiscreen menu, if we have multiple screens
-    if (!isApplet()) {
         GraphicsDevice[] screens = GraphicsEnvironment.
                                     getLocalGraphicsEnvironment().
                                     getScreenDevices();
@@ -449,7 +428,6 @@
                 createMultiscreenMenuItem(multiScreenMenu, i);
             }
         }
-    }
 
         return menuBar;
     }
@@ -659,37 +637,34 @@
 
 
     /**
-     * Bring up the SwingSet2 demo by showing the frame (only
-     * applicable if coming up as an application, not an applet);
+     * Bring up the SwingSet2 demo by showing the frame
      */
     public void showSwingSet2() {
-        if(!isApplet() && getFrame() != null) {
-            // put swingset in a frame and show it
-            JFrame f = getFrame();
-            f.setTitle(getString("Frame.title"));
-            f.getContentPane().add(this, BorderLayout.CENTER);
-            f.pack();
+        // put swingset in a frame and show it
+        JFrame f = getFrame();
+        f.setTitle(getString("Frame.title"));
+        f.getContentPane().add(this, BorderLayout.CENTER);
+        f.pack();
 
-            Rectangle screenRect = f.getGraphicsConfiguration().getBounds();
-            Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(
-                    f.getGraphicsConfiguration());
+        Rectangle screenRect = f.getGraphicsConfiguration().getBounds();
+        Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(
+                f.getGraphicsConfiguration());
 
-            // Make sure we don't place the demo off the screen.
-            int centerWidth = screenRect.width < f.getSize().width ?
-                    screenRect.x :
-                    screenRect.x + screenRect.width/2 - f.getSize().width/2;
-            int centerHeight = screenRect.height < f.getSize().height ?
-                    screenRect.y :
-                    screenRect.y + screenRect.height/2 - f.getSize().height/2;
+        // Make sure we don't place the demo off the screen.
+        int centerWidth = screenRect.width < f.getSize().width ?
+                screenRect.x :
+                screenRect.x + screenRect.width/2 - f.getSize().width/2;
+        int centerHeight = screenRect.height < f.getSize().height ?
+                screenRect.y :
+                screenRect.y + screenRect.height/2 - f.getSize().height/2;
 
-            centerHeight = centerHeight < screenInsets.top ?
-                    screenInsets.top : centerHeight;
+        centerHeight = centerHeight < screenInsets.top ?
+                screenInsets.top : centerHeight;
 
-            f.setLocation(centerWidth, centerHeight);
-            f.setVisible(true);
-            numSSs++;
-            swingSets.add(this);
-        }
+        f.setLocation(centerWidth, centerHeight);
+        f.setVisible(true);
+        numSSs++;
+        swingSets.add(this);
     }
 
     // *******************************************************
@@ -713,21 +688,6 @@
     }
 
     /**
-     * Determines if this is an applet or application
-     */
-    public boolean isApplet() {
-        return (applet != null);
-    }
-
-    /**
-     * Returns the applet instance
-     */
-    public SwingSet2Applet getApplet() {
-        return applet;
-    }
-
-
-    /**
      * Returns the frame instance
      */
     public JFrame getFrame() {
@@ -763,8 +723,6 @@
         if(contentPane == null) {
             if(getFrame() != null) {
                 contentPane = getFrame().getContentPane();
-            } else if (getApplet() != null) {
-                contentPane = getApplet().getContentPane();
             }
         }
         return contentPane;
@@ -886,15 +844,11 @@
     }
 
     private void updateThisSwingSet() {
-        if (isApplet()) {
-            SwingUtilities.updateComponentTreeUI(getApplet());
+        JFrame frame = getFrame();
+        if (frame == null) {
+            SwingUtilities.updateComponentTreeUI(this);
         } else {
-            JFrame frame = getFrame();
-            if (frame == null) {
-                SwingUtilities.updateComponentTreeUI(this);
-            } else {
-                SwingUtilities.updateComponentTreeUI(frame);
-            }
+            SwingUtilities.updateComponentTreeUI(frame);
         }
 
         SwingUtilities.updateComponentTreeUI(popupMenu);
@@ -909,12 +863,8 @@
     public void updateLookAndFeel() {
         try {
             UIManager.setLookAndFeel(currentLookAndFeel.className);
-            if (isApplet()) {
-                updateThisSwingSet();
-            } else {
-                for (SwingSet2 ss : swingSets) {
-                    ss.updateThisSwingSet();
-                }
+            for (SwingSet2 ss : swingSets) {
+                ss.updateThisSwingSet();
             }
         } catch (Exception ex) {
             System.out.println("Failed loading L&F: " + currentLookAndFeel);
@@ -1142,12 +1092,8 @@
 
         public void actionPerformed(ActionEvent e) {
             boolean dragEnabled = ((JCheckBoxMenuItem)e.getSource()).isSelected();
-            if (isApplet()) {
-                setDragEnabled(dragEnabled);
-            } else {
-                for (SwingSet2 ss : swingSets) {
-                    ss.setDragEnabled(dragEnabled);
-                }
+            for (SwingSet2 ss : swingSets) {
+                ss.setDragEnabled(dragEnabled);
             }
         }
     }
@@ -1208,11 +1154,7 @@
                 button.addActionListener(new OkAction(aboutBox));
             }
             aboutBox.pack();
-            if (isApplet()) {
-                aboutBox.setLocationRelativeTo(getApplet());
-            } else {
-                aboutBox.setLocationRelativeTo(getFrame());
-            }
+            aboutBox.setLocationRelativeTo(getFrame());
             aboutBox.setVisible(true);
         }
     }
@@ -1231,13 +1173,13 @@
                                    getScreenDevices();
             if (screen == ALL_SCREENS) {
                 for (int i = 0; i < gds.length; i++) {
-                    SwingSet2 swingset = new SwingSet2(null,
+                    SwingSet2 swingset = new SwingSet2(
                                   gds[i].getDefaultConfiguration());
                     swingset.setDragEnabled(dragEnabled);
                 }
             }
             else {
-                SwingSet2 swingset = new SwingSet2(null,
+                SwingSet2 swingset = new SwingSet2(
                              gds[screen].getDefaultConfiguration());
                 swingset.setDragEnabled(dragEnabled);
             }
diff --git a/src/demo/share/jfc/SwingSet2/SwingSet2Applet.java b/src/demo/share/jfc/SwingSet2/SwingSet2Applet.java
deleted file mode 100644
index 945d1f1..0000000
--- a/src/demo/share/jfc/SwingSet2/SwingSet2Applet.java
+++ /dev/null
@@ -1,78 +0,0 @@
-/*
- *
- * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- *   - Redistributions of source code must retain the above copyright
- *     notice, this list of conditions and the following disclaimer.
- *
- *   - Redistributions in binary form must reproduce the above copyright
- *     notice, this list of conditions and the following disclaimer in the
- *     documentation and/or other materials provided with the distribution.
- *
- *   - Neither the name of Oracle nor the names of its
- *     contributors may be used to endorse or promote products derived
- *     from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
- * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-
-import javax.swing.*;
-import javax.swing.event.*;
-import javax.swing.text.*;
-import javax.swing.border.*;
-import javax.swing.colorchooser.*;
-import javax.swing.filechooser.*;
-import javax.accessibility.*;
-
-import java.awt.*;
-import java.awt.event.*;
-import java.beans.*;
-import java.util.*;
-import java.io.*;
-import java.applet.*;
-import java.net.*;
-
-/**
- *
- *
- * @author Jeff Dinkins
- */
-
-public class SwingSet2Applet extends JApplet {
-    public void init() {
-        getContentPane().setLayout(new BorderLayout());
-        getContentPane().add(new SwingSet2(this), BorderLayout.CENTER);
-    }
-
-    public URL getURL(String filename) {
-        URL codeBase = this.getCodeBase();
-        URL url = null;
-
-        try {
-            url = new URL(codeBase, filename);
-            System.out.println(url);
-        } catch (java.net.MalformedURLException e) {
-            System.out.println("Error: badly specified URL");
-            return null;
-        }
-
-        return url;
-    }
-
-
-}
-------------- next part --------------



From david.holmes at oracle.com  Tue Oct 29 02:26:43 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 29 Oct 2019 12:26:43 +1000
Subject: Fixing compiler warnings in src/demo/share/jfc
In-Reply-To: <0663E469-9C0C-4B56-AE27-A318B6583556@mountainminds.com>
References: <0663E469-9C0C-4B56-AE27-A318B6583556@mountainminds.com>
Message-ID: 

Hi Marc,

Please take this to the swing-dev at openjdk.java.net mailing list as these 
are not build issues.

Note some/many mailing lists strip attachments.

Thanks,
David

On 24/10/2019 3:59 am, Marc Hoffmann wrote:
> MOTIVATION
> 
> As a developer of the JaCoCo code coverage library I do lots of JDK builds. JDK
> builds are simple, fast and produce minimal log output. Nice! What annoys me
> though are plenty of compiler warnings at the end of the build caused by the
> example code in src/demo/share/jfc
> 
> FIX
> 
> I propose a series of 3 patches (based on each other) which fixes all compiler
> warnings for the demos:
> 
> patch1.txt - Fix compiler warnings in demos: raw types
> patch2.txt - Fix compiler warnings in demos: deprecated APIs
> patch3.txt - Fix compiler warnings in demos: deprecated Applet APIs
> 
> While patch 1 & 2 do not change functionality patch 3 actually removes the
> Applet versions of some of the demos. The java main versions of the same demos
> are still intact.
> 
> The patches are based on changeset 56699:70e6b0d8db13.
> 
> They have been tested from this clone: https://github.com/marchof/jdk/tree/fix-compiler-warnings-in-demos
> 
> RESULT
> 
> All compiler warnings on demo code during JDK build are removed
> 
> TESTING
> 
> I haven't found any automated tests so I manually launched all the demos. From
> what I can say they are still functional.
> 
> SCOPE
> 
> I applied minimal changes to remove compiler warnings only. There are many more
> cleanup opportunities in the demo code. Also there is (dead?) code in
> src/demo/share/java2d which has similar issues. Both are not on scope of these
> patches.
> 
> NEXT STEPS
> 
> I?m have no experience with OpenJDK patches. If you?re interested in getting these warnings fixed please
> let me know how I can submit these patches properly.
> 
> 
> 
> 


From magnus.ihse.bursie at oracle.com  Tue Oct 29 09:50:10 2019
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2019 10:50:10 +0100
Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent
 Mark Sweep (CMS) Garbage Collector
In-Reply-To: <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com>
References: 
 <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com>
Message-ID: 

On 2019-10-24 20:03, Leo Korinth wrote:
> Fixes after suggestions from Coleen, David, Erik, Igor and Kim:
>
> http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental)
> http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full)
Build changes now look fine.

/Magnus
>
> Thanks,
> Leo
>
> On 18/10/2019 10:20, Leo Korinth wrote:
>> Hi,
>>
>> Here is a patch that removes the CMS GC.
>>
>> I have neither tested arm nor ppc; I hope my changes to those .ad 
>> files are correct, if someone can test those architectures, that 
>> would be great.
>>
>> Please take an extra look at 
>> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before 
>> (but never called), It is now called (and hopefully correct).
>>
>> I have tried to remove most parts of CMS. I have not made it a goal 
>> to remove all traces of CMS. I guess there are much more to cleanup, 
>> and suggestions of more to remove are welcomed. I think more 
>> complicated cleanups should be dealt with in separate enhancements.
>>
>> Not fully addressed in code, but an issue that has to be dealt with, 
>> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option 
>> should be obsoleted, though I do not know if we have any precedence 
>> obsoleting -X options.
>>
>> My patch prints:
>>
>> $ java -Xconcgc -jar Notepad.jar
>> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses 
>> UseConcMarkSweepGC
>>
>> I guess that is not enough for being obsolete, compare with:
>>
>> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar
>> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option 
>> UseConcMarkSweepGC; support was removed in 14.0
>>
>> Bug:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8232365
>>
>> Webrev:
>> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00
>>
>> Testing:
>> ?? tier 1-5.
>>
>> Thanks,
>> Leo



From leo.korinth at oracle.com  Tue Oct 29 10:47:59 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Tue, 29 Oct 2019 11:47:59 +0100
Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent
 Mark Sweep (CMS) Garbage Collector
In-Reply-To: 
References: 
 <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com>
 
Message-ID: 



On 29/10/2019 10:50, Magnus Ihse Bursie wrote:
> On 2019-10-24 20:03, Leo Korinth wrote:
>> Fixes after suggestions from Coleen, David, Erik, Igor and Kim:
>>
>> http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental)
>> http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full)
> Build changes now look fine.
> 
> /Magnus

Thanks Magnus, I will add you as a reviewer.

/Leo
>>
>> Thanks,
>> Leo
>>
>> On 18/10/2019 10:20, Leo Korinth wrote:
>>> Hi,
>>>
>>> Here is a patch that removes the CMS GC.
>>>
>>> I have neither tested arm nor ppc; I hope my changes to those .ad 
>>> files are correct, if someone can test those architectures, that 
>>> would be great.
>>>
>>> Please take an extra look at 
>>> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before 
>>> (but never called), It is now called (and hopefully correct).
>>>
>>> I have tried to remove most parts of CMS. I have not made it a goal 
>>> to remove all traces of CMS. I guess there are much more to cleanup, 
>>> and suggestions of more to remove are welcomed. I think more 
>>> complicated cleanups should be dealt with in separate enhancements.
>>>
>>> Not fully addressed in code, but an issue that has to be dealt with, 
>>> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option 
>>> should be obsoleted, though I do not know if we have any precedence 
>>> obsoleting -X options.
>>>
>>> My patch prints:
>>>
>>> $ java -Xconcgc -jar Notepad.jar
>>> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses 
>>> UseConcMarkSweepGC
>>>
>>> I guess that is not enough for being obsolete, compare with:
>>>
>>> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar
>>> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option 
>>> UseConcMarkSweepGC; support was removed in 14.0
>>>
>>> Bug:
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8232365
>>>
>>> Webrev:
>>> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00
>>>
>>> Testing:
>>> ?? tier 1-5.
>>>
>>> Thanks,
>>> Leo
> 


From matthias.baesken at sap.com  Tue Oct 29 11:42:28 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 29 Oct 2019 11:42:28 +0000
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
Message-ID: 

Hello, please review the following fix .
I recently  experimented a bit with the  minimal  VM  build  on  linux x86_64    (--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .

However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le ,   I noticed that it fails  because of a few  wrong dependencies .
Thanks to Martin for the advice regarding

Register ic = as_Register(Matcher::inline_cache_reg_encode());

Replacement with


Register ic = R19_inline_cache_reg;

In http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233078
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/


Thanks, Matthias





From martin.doerr at sap.com  Tue Oct 29 11:53:22 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 29 Oct 2019 11:53:22 +0000
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
In-Reply-To: 
References: 
Message-ID: 

Hi Matthias,

thanks for fixing it. I have a few requests:

disassembler_ppc.cpp:
Please remove includes completely if no longer needed (instead of commenting out).

sharedRuntime_ppc.cpp:
I think it's better to remove the 2 align(InteriorEntryAlignment). Succeeding code is not performance critical.

stubGenerator_ppc.cpp:
Code should better be protected by #ifdef COMPILER2 than commenting out.

Otherwise, looks good to me.

Thanks,
Martin


From: Baesken, Matthias 
Sent: Dienstag, 29. Oktober 2019 12:42
To: 'hotspot-dev at openjdk.java.net' 
Cc: 'build-dev at openjdk.java.net' ; Doerr, Martin 
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hello, please review the following fix .
I recently  experimented a bit with the  minimal  VM  build  on  linux x86_64    (--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .

However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le ,   I noticed that it fails  because of a few  wrong dependencies .
Thanks to Martin for the advice regarding

Register ic = as_Register(Matcher::inline_cache_reg_encode());

Replacement with


Register ic = R19_inline_cache_reg;

In http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233078
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/


Thanks, Matthias





From magnus.ihse.bursie at oracle.com  Tue Oct 29 12:21:53 2019
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2019 13:21:53 +0100
Subject: Fixing compiler warnings in src/demo/share/jfc
In-Reply-To: <0663E469-9C0C-4B56-AE27-A318B6583556@mountainminds.com>
References: <0663E469-9C0C-4B56-AE27-A318B6583556@mountainminds.com>
Message-ID: <6e8392b6-8030-9314-7de6-31c2427c4b83@oracle.com>

Hi,

Thank you for fixing this, and for your nice workds about the OpenJDK 
build system! Those warnings have annoyed me to, and I'm glad to see 
that someone has stepped up to fix them.

Unfortunately, making a first time contribution to OpenJDK is somewhat 
cumbersome, since this is a large and very formal project. This page 
will give you most of the instructions you need: 
https://openjdk.java.net/contribute. As a minimum, you need to sign the 
OCA. Without this, we can unfortunately do nothing more with your 
patches. :-(

And as David said, these fixes will need to be approved by folks in 
swing-dev at openjdk.java.net. However, fixing warnings in the build do 
indeed intersect with build issues, so you feel free to cross-post the 
discussion here.

Let me know if you run into too much friction in the process, and want 
me to assist you to shepherd these fixes. I know getting your first 
patch in can be a bit rough.

/Magnus

On 2019-10-23 19:59, Marc Hoffmann wrote:
> MOTIVATION
>
> As a developer of the JaCoCo code coverage library I do lots of JDK builds. JDK
> builds are simple, fast and produce minimal log output. Nice! What annoys me
> though are plenty of compiler warnings at the end of the build caused by the
> example code in src/demo/share/jfc
>
> FIX
>
> I propose a series of 3 patches (based on each other) which fixes all compiler
> warnings for the demos:
>
> patch1.txt - Fix compiler warnings in demos: raw types
> patch2.txt - Fix compiler warnings in demos: deprecated APIs
> patch3.txt - Fix compiler warnings in demos: deprecated Applet APIs
>
> While patch 1 & 2 do not change functionality patch 3 actually removes the
> Applet versions of some of the demos. The java main versions of the same demos
> are still intact.
>
> The patches are based on changeset 56699:70e6b0d8db13.
>
> They have been tested from this clone: https://github.com/marchof/jdk/tree/fix-compiler-warnings-in-demos
>
> RESULT
>
> All compiler warnings on demo code during JDK build are removed
>
> TESTING
>
> I haven't found any automated tests so I manually launched all the demos. From
> what I can say they are still functional.
>
> SCOPE
>
> I applied minimal changes to remove compiler warnings only. There are many more
> cleanup opportunities in the demo code. Also there is (dead?) code in
> src/demo/share/java2d which has similar issues. Both are not on scope of these
> patches.
>
> NEXT STEPS
>
> I?m have no experience with OpenJDK patches. If you?re interested in getting these warnings fixed please
> let me know how I can submit these patches properly.
>
>
>



From matthias.baesken at sap.com  Tue Oct 29 12:25:24 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 29 Oct 2019 12:25:24 +0000
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
In-Reply-To: 
References: 
 
Message-ID: 

Hi Martin,  thanks for the input .
I  did the adjustments you suggested;  new webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.1/

Regarding  : stubGenerator_ppc.cpp: "Code should better be protected by #ifdef COMPILER2 than commenting out."
Currently  the  if (OptimizeFill) { ... }    coding  is dead on ppc  .

See  :
c2_globals.hpp
------------------------
234 /* OptimizeFill not yet supported on PowerPC. */ \
235 product(bool, OptimizeFill, true PPC64_ONLY(&& false), \

c2_init_ppc.cpp
------------------------
53 if (OptimizeFill) {
54   warning("OptimizeFill is not supported on this CPU.");
55   FLAG_SET_DEFAULT(OptimizeFill, false);


Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?

Best regards, Matthias




Hi Matthias,

thanks for fixing it. I have a few requests:

disassembler_ppc.cpp:
Please remove includes completely if no longer needed (instead of commenting out).

sharedRuntime_ppc.cpp:
I think it's better to remove the 2 align(InteriorEntryAlignment). Succeeding code is not performance critical.

stubGenerator_ppc.cpp:
Code should better be protected by #ifdef COMPILER2 than commenting out.

Otherwise, looks good to me.

Thanks,
Martin


From: Baesken, Matthias >
Sent: Dienstag, 29. Oktober 2019 12:42
To: 'hotspot-dev at openjdk.java.net' >
Cc: 'build-dev at openjdk.java.net' >; Doerr, Martin >
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hello, please review the following fix .
I recently  experimented a bit with the  minimal  VM  build  on  linux x86_64    (--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .

However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le ,   I noticed that it fails  because of a few  wrong dependencies .
Thanks to Martin for the advice regarding

Register ic = as_Register(Matcher::inline_cache_reg_encode());

Replacement with


Register ic = R19_inline_cache_reg;

In http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233078
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/


Thanks, Matthias





From magnus.ihse.bursie at oracle.com  Tue Oct 29 12:32:19 2019
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2019 13:32:19 +0100
Subject: RFR: JDK-8232834: RunTest sometimes fails to produce valid
 exitcode.txt
In-Reply-To: 
References: 
 
 
Message-ID: 

On 2019-10-23 14:41, Erik Joelsson wrote:
>
> Yes, I've been torn about this. On Windows I made measurable build 
> speed improvements some years ago by minimizing the extra shell 
> invocations for compile commands, so I didn't like the idea of 
> introducing an unconditional extra shell. Another option could be to 
> scan the input for '[<>]' in ExecuteWithLog and only add it if found. 
> It will certainly make the ExecuteWithLog body convoluted but may be a 
> better solution.
>
Yes, that might be best. If we write a support function 
AddSubshellIfNeeded or so, and wrap the command line in it, it might be 
okay-ish. :)

I filed https://bugs.openjdk.java.net/browse/JDK-8233115 to keep track 
of this.

/Magnus


From magnus.ihse.bursie at oracle.com  Tue Oct 29 12:44:18 2019
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2019 13:44:18 +0100
Subject: RFR: JDK-8232748: Build static versions of certain JDK libraries
In-Reply-To: 
References: 
Message-ID: <9e74697f-2ced-54fc-928a-ebea6c51d466@oracle.com>

On 2019-10-28 21:46, Erik Joelsson wrote:
> Certain downstream consumers of the JDK need to link to parts of it 
> statically. To support this usecase, this patch adds a set of optional 
> make targets that produce static native libraries for a selection of 
> modules. These static libraries do not end up in the main JDK 
> distribution but are instead packaged in a separate bundle that can be 
> optionally overlayed on top of a JDK bundle. The new targets are only 
> built when requested and are not added as dependencies on any existing 
> target.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8232748/webrev.01
Looks good to me.

Hopefully we can make a follow-up fix to remove the current "static 
libs" implementation that was needed by the Mobile project. This 
implementation was a bit hackish from the start, and it has bit-rotted 
severly, and might not even work right now. I'm eager to remove it, but 
I don't want to break the Mobile build, so hopefully we can find some 
way to adjust this new system to be usable by them, too.

/Magnus


>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232748
>
> /Erik
>
>



From martin.doerr at sap.com  Tue Oct 29 12:48:27 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 29 Oct 2019 12:48:27 +0000
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi Matthias,

> Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?
This question is not related to this issue.
Commenting out parts of it is not a good style.

Thank you for your update. The new webrev looks good to me.

Best regards,
Martin


From: Baesken, Matthias 
Sent: Dienstag, 29. Oktober 2019 13:25
To: Doerr, Martin ; 'hotspot-dev at openjdk.java.net' 
Cc: 'build-dev at openjdk.java.net' 
Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hi Martin,  thanks for the input .
I  did the adjustments you suggested;  new webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.1/

Regarding  : stubGenerator_ppc.cpp: "Code should better be protected by #ifdef COMPILER2 than commenting out."
Currently  the  if (OptimizeFill) { ... }    coding  is dead on ppc  .

See  :
c2_globals.hpp
------------------------
234 /* OptimizeFill not yet supported on PowerPC. */ \
235 product(bool, OptimizeFill, true PPC64_ONLY(&& false), \

c2_init_ppc.cpp
------------------------
53 if (OptimizeFill) {
54   warning("OptimizeFill is not supported on this CPU.");
55   FLAG_SET_DEFAULT(OptimizeFill, false);


Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?

Best regards, Matthias




Hi Matthias,

thanks for fixing it. I have a few requests:

disassembler_ppc.cpp:
Please remove includes completely if no longer needed (instead of commenting out).

sharedRuntime_ppc.cpp:
I think it's better to remove the 2 align(InteriorEntryAlignment). Succeeding code is not performance critical.

stubGenerator_ppc.cpp:
Code should better be protected by #ifdef COMPILER2 than commenting out.

Otherwise, looks good to me.

Thanks,
Martin


From: Baesken, Matthias >
Sent: Dienstag, 29. Oktober 2019 12:42
To: 'hotspot-dev at openjdk.java.net' >
Cc: 'build-dev at openjdk.java.net' >; Doerr, Martin >
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hello, please review the following fix .
I recently  experimented a bit with the  minimal  VM  build  on  linux x86_64    (--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .

However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le ,   I noticed that it fails  because of a few  wrong dependencies .
Thanks to Martin for the advice regarding

Register ic = as_Register(Matcher::inline_cache_reg_encode());

Replacement with


Register ic = R19_inline_cache_reg;

In http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233078
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/


Thanks, Matthias





From bob.vandette at oracle.com  Tue Oct 29 13:11:45 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 29 Oct 2019 09:11:45 -0400
Subject: RFR: JDK-8232748: Build static versions of certain JDK libraries
In-Reply-To: <9e74697f-2ced-54fc-928a-ebea6c51d466@oracle.com>
References: 
 <9e74697f-2ced-54fc-928a-ebea6c51d466@oracle.com>
Message-ID: <189F8FDE-36CC-45E8-97F0-504501EC8FBD@oracle.com>


> On Oct 29, 2019, at 8:44 AM, Magnus Ihse Bursie  wrote:
> 
> On 2019-10-28 21:46, Erik Joelsson wrote:
>> Certain downstream consumers of the JDK need to link to parts of it statically. To support this usecase, this patch adds a set of optional make targets that produce static native libraries for a selection of modules. These static libraries do not end up in the main JDK distribution but are instead packaged in a separate bundle that can be optionally overlayed on top of a JDK bundle. The new targets are only built when requested and are not added as dependencies on any existing target.
>> 
>> Webrev: http://cr.openjdk.java.net/~erikj/8232748/webrev.01
> Looks good to me.

+1

> 
> Hopefully we can make a follow-up fix to remove the current "static libs" implementation that was needed by the Mobile project. This implementation was a bit hackish from the start, and it has bit-rotted severly, and might not even work right now.

The current static build mostly works for a Mac build.  There?s only a one or two line change missing.
This was done to validate https://openjdk.java.net/jeps/178  but we haven?t added a build/test to
keep it from bit rotting.


> I'm eager to remove it, but I don't want to break the Mobile build, so hopefully we can find some way to adjust this new system to be usable by them, too.

I?ve forwarded the RFR to Johan Vos to get his opinion on the new static lib mechanism.  I?m sure he has an opinion on the 
old static build deprecation.  I think he?d be more interested in getting iOS and Android build changes that using the old 
static build support once this change gets integrated.

Bob.


> 
> /Magnus
> 
> 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232748
>> 
>> /Erik
>> 
>> 
> 



From matthias.baesken at sap.com  Tue Oct 29 13:32:07 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 29 Oct 2019 13:32:07 +0000
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Thanks .
May I have a second review please ?

Best regards, Matthias

From: Doerr, Martin 
Sent: Dienstag, 29. Oktober 2019 13:48
To: Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' 
Cc: 'build-dev at openjdk.java.net' 
Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hi Matthias,

> Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?
This question is not related to this issue.
Commenting out parts of it is not a good style.

Thank you for your update. The new webrev looks good to me.

Best regards,
Martin


From: Baesken, Matthias >
Sent: Dienstag, 29. Oktober 2019 13:25
To: Doerr, Martin >; 'hotspot-dev at openjdk.java.net' >
Cc: 'build-dev at openjdk.java.net' >
Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hi Martin,  thanks for the input .
I  did the adjustments you suggested;  new webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.1/

Regarding  : stubGenerator_ppc.cpp: "Code should better be protected by #ifdef COMPILER2 than commenting out."
Currently  the  if (OptimizeFill) { ... }    coding  is dead on ppc  .

See  :
c2_globals.hpp
------------------------
234 /* OptimizeFill not yet supported on PowerPC. */ \
235 product(bool, OptimizeFill, true PPC64_ONLY(&& false), \

c2_init_ppc.cpp
------------------------
53 if (OptimizeFill) {
54   warning("OptimizeFill is not supported on this CPU.");
55   FLAG_SET_DEFAULT(OptimizeFill, false);


Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?

Best regards, Matthias




Hi Matthias,

thanks for fixing it. I have a few requests:

disassembler_ppc.cpp:
Please remove includes completely if no longer needed (instead of commenting out).

sharedRuntime_ppc.cpp:
I think it's better to remove the 2 align(InteriorEntryAlignment). Succeeding code is not performance critical.

stubGenerator_ppc.cpp:
Code should better be protected by #ifdef COMPILER2 than commenting out.

Otherwise, looks good to me.

Thanks,
Martin


From: Baesken, Matthias >
Sent: Dienstag, 29. Oktober 2019 12:42
To: 'hotspot-dev at openjdk.java.net' >
Cc: 'build-dev at openjdk.java.net' >; Doerr, Martin >
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hello, please review the following fix .
I recently  experimented a bit with the  minimal  VM  build  on  linux x86_64    (--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .

However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le ,   I noticed that it fails  because of a few  wrong dependencies .
Thanks to Martin for the advice regarding

Register ic = as_Register(Matcher::inline_cache_reg_encode());

Replacement with


Register ic = R19_inline_cache_reg;

In http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233078
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/


Thanks, Matthias





From johan at lodgon.com  Tue Oct 29 13:31:08 2019
From: johan at lodgon.com (Johan Vos)
Date: Tue, 29 Oct 2019 14:31:08 +0100
Subject: RFR: JDK-8232748: Build static versions of certain JDK libraries
In-Reply-To: <189F8FDE-36CC-45E8-97F0-504501EC8FBD@oracle.com>
References: 
 <9e74697f-2ced-54fc-928a-ebea6c51d466@oracle.com>
 <189F8FDE-36CC-45E8-97F0-504501EC8FBD@oracle.com>
Message-ID: 

Op di 29 okt. 2019 om 14:11 schreef Bob Vandette :

>
> On Oct 29, 2019, at 8:44 AM, Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
> On 2019-10-28 21:46, Erik Joelsson wrote:
>
> Certain downstream consumers of the JDK need to link to parts of it
> statically. To support this usecase, this patch adds a set of optional make
> targets that produce static native libraries for a selection of modules.
> These static libraries do not end up in the main JDK distribution but are
> instead packaged in a separate bundle that can be optionally overlayed on
> top of a JDK bundle. The new targets are only built when requested and are
> not added as dependencies on any existing target.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8232748/webrev.01
>
> Looks good to me.
>
>
> +1
>
>
> Hopefully we can make a follow-up fix to remove the current "static libs"
> implementation that was needed by the Mobile project. This implementation
> was a bit hackish from the start, and it has bit-rotted severly, and might
> not even work right now.
>
>
> The current static build mostly works for a Mac build.  There?s only a one
> or two line change missing.
> This was done to validate https://openjdk.java.net/jeps/178 but we
> haven?t added a build/test to
> keep it from bit rotting.
>
>
> I'm eager to remove it, but I don't want to break the Mobile build, so
> hopefully we can find some way to adjust this new system to be usable by
> them, too.
>
>
> I?ve forwarded the RFR to Johan Vos to get his opinion on the new static
> lib mechanism.  I?m sure he has an opinion on the
> old static build deprecation.  I think he?d be more interested in getting
> iOS and Android build changes that using the old
> static build support once this change gets integrated.
>

True. Actually, my main goal is to stay as close as possible to the OpenJDK
master. Redoing the static changes for Mobile won't be a major issue, so I
prefer having the best approach in OpenJDK (as in the current webrev) and
we can then work on fixing what is broken on mobile. If the mobile changes
can get upstreamed to openjdk, that would be ideal. Otherwise, we can
upstream them to https://github.com/openjdk/mobile (which is auto-synced
from openjdk/jdk).

- Johan


From sgehwolf at redhat.com  Tue Oct 29 18:19:20 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 29 Oct 2019 19:19:20 +0100
Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies
Message-ID: <83a5cb7fc463fc89516d7de8e8706577afc9461f.camel@redhat.com>

Hi,

Please review this OpenJDK 11u backport of JDK-8214311. It's an Oracle
JDK 11.0.6 feature parity patch. The jdk/jdk patch didn't apply cleanly
due to context differences in make/hotspot/gensrc/GensrcDtrace.gmk.
That is due to JDK-8211029 not being present in OpenJDK 11u code-base.
I have fixed the patch manually, which was quite trivial.

Bug: https://bugs.openjdk.java.net/browse/JDK-8214311
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214311/jdk11/01/webrev/
Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/7b757120a053

Testing: Building on Linux x86_64 with dtrace enabled. Still works.
Unfortunately I don't have a Solaris machine available.

Thoughts?

Thanks,
Severin



From alexey.ivanov at oracle.com  Tue Oct 29 19:29:57 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 29 Oct 2019 19:29:57 +0000
Subject: RFR 8232880: Update test documentation with additional settings
 for client UI tooltip tests
In-Reply-To: <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
 <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>
Message-ID: <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com>

Hi Dmitry,

Shall we drop hyphen in the header: ?Client UI Tests??

I think there should be no definite article in this sentence: ?use -the- 
key sequences?.

??Turn off Windowss key hotkeys??, there's an extra ?s? in Windows.

?Note: restart is required to make the settings take effect.?
Just to confirm: is signing out and signing in not enough?

I'd use backticks for gpedit markup: ?Type `gpedit` in the Search??


Does it make sense to move the example into macOS section? Then the 
steps to disable the shortcut can be reduced to the required option 
only. The steps themselves should not be listed as code, i.e. no backticks.

(For my understanding, "Turn keyboard access on or off" turns off only 
one specific shortcut, i.e. Ctrl+F1?)


Regards,
Alexey

On 28/10/2019 17:23, Dmitry Markov wrote:
> Hi Alexey, Erik, Sergey,
> Thank you for your feedback. I have updated the fix based on your 
> suggestions: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.01/
> Can you take a look, please?
>
> Thanks,
> Dmitry
>
>> On 26 Oct 2019, at 00:55, Sergey Bylokhov > > wrote:
>>
>> Hi, Dmitry.
>>
>> I suggest to make this block more generic, and describe the ?"### 
>> Client UI - Tests".
>> It would be useful to mention that the tests in this category use 
>> different key combinations,
>> which might be registered as a system shortcuts, and it could cause a 
>> test failure. It is suggested
>> to disable these shortcuts:
>> - macOS config location.....
>> - Linux config location.....
>> - On window some other application may have global shortcuts....
>>
>> As an example of such issue you can provide CTRL+F1 which is used....
>>
>>
>> On 10/25/19 3:27 am, Dmitry Markov wrote:
>>> Hello,
>>> Could you review the fix for jdk14, please?
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232880 
>>> 
>>> webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ 
>>> 
>>> Some Client UI tests use the following key sequence to show/hide 
>>> tooltip message: ?CTRL? + ?F1". However this key combination is 
>>> reserved by operating system on OS X platform. As a results the 
>>> tests fail.
>>> Test documentation should be updated with some notes regarding this.
>>> Thanks,
>>> Dmitry
>>
>>
>> -- 
>> Best regards, Sergey.
>



From christoph.langer at sap.com  Wed Oct 30 05:48:10 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 30 Oct 2019 05:48:10 +0000
Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies
In-Reply-To: <83a5cb7fc463fc89516d7de8e8706577afc9461f.camel@redhat.com>
References: <83a5cb7fc463fc89516d7de8e8706577afc9461f.camel@redhat.com>
Message-ID: 

Hi Severin,

backport looks good. Thanks for doing it.

Cheers
Christoph

> -----Original Message-----
> From: build-dev  On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 29. Oktober 2019 19:19
> To: jdk-updates-dev 
> Cc: build-dev 
> Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies
> 
> Hi,
> 
> Please review this OpenJDK 11u backport of JDK-8214311. It's an Oracle
> JDK 11.0.6 feature parity patch. The jdk/jdk patch didn't apply cleanly
> due to context differences in make/hotspot/gensrc/GensrcDtrace.gmk.
> That is due to JDK-8211029 not being present in OpenJDK 11u code-base.
> I have fixed the patch manually, which was quite trivial.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214311
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8214311/jdk11/01/webrev/
> Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/7b757120a053
> 
> Testing: Building on Linux x86_64 with dtrace enabled. Still works.
> Unfortunately I don't have a Solaris machine available.
> 
> Thoughts?
> 
> Thanks,
> Severin


From hoffmann at mountainminds.com  Wed Oct 30 06:19:08 2019
From: hoffmann at mountainminds.com (Marc Hoffmann)
Date: Wed, 30 Oct 2019 07:19:08 +0100
Subject: Fixing compiler warnings in src/demo/share/jfc
In-Reply-To: <6e8392b6-8030-9314-7de6-31c2427c4b83@oracle.com>
References: <0663E469-9C0C-4B56-AE27-A318B6583556@mountainminds.com>
 <6e8392b6-8030-9314-7de6-31c2427c4b83@oracle.com>
Message-ID: <2AFE88C9-3A0C-4BB6-A78B-475BFC76186C@mountainminds.com>

Hi Magnus,

I submitted a signed OCA and will suggest the patch to swing-dev.

I'll come back in case I struggle with the process.

Thanks for your support for my little contribution!
-marc

> On 29. Oct 2019, at 13:21, Magnus Ihse Bursie  wrote:
> 
> Hi,
> 
> Thank you for fixing this, and for your nice workds about the OpenJDK build system! Those warnings have annoyed me to, and I'm glad to see that someone has stepped up to fix them.
> 
> Unfortunately, making a first time contribution to OpenJDK is somewhat cumbersome, since this is a large and very formal project. This page will give you most of the instructions you need: https://openjdk.java.net/contribute . As a minimum, you need to sign the OCA. Without this, we can unfortunately do nothing more with your patches. :-(
> 
> And as David said, these fixes will need to be approved by folks in swing-dev at openjdk.java.net . However, fixing warnings in the build do indeed intersect with build issues, so you feel free to cross-post the discussion here. 
> 
> Let me know if you run into too much friction in the process, and want me to assist you to shepherd these fixes. I know getting your first patch in can be a bit rough.
> 
> /Magnus
> 
> On 2019-10-23 19:59, Marc Hoffmann wrote:
>> MOTIVATION
>> 
>> As a developer of the JaCoCo code coverage library I do lots of JDK builds. JDK
>> builds are simple, fast and produce minimal log output. Nice! What annoys me
>> though are plenty of compiler warnings at the end of the build caused by the
>> example code in src/demo/share/jfc
>> 
>> FIX
>> 
>> I propose a series of 3 patches (based on each other) which fixes all compiler
>> warnings for the demos:
>> 
>> patch1.txt - Fix compiler warnings in demos: raw types
>> patch2.txt - Fix compiler warnings in demos: deprecated APIs
>> patch3.txt - Fix compiler warnings in demos: deprecated Applet APIs
>> 
>> While patch 1 & 2 do not change functionality patch 3 actually removes the
>> Applet versions of some of the demos. The java main versions of the same demos
>> are still intact.
>> 
>> The patches are based on changeset 56699:70e6b0d8db13.
>> 
>> They have been tested from this clone: https://github.com/marchof/jdk/tree/fix-compiler-warnings-in-demos 
>> 
>> RESULT
>> 
>> All compiler warnings on demo code during JDK build are removed
>> 
>> TESTING
>> 
>> I haven't found any automated tests so I manually launched all the demos. From
>> what I can say they are still functional.
>> 
>> SCOPE
>> 
>> I applied minimal changes to remove compiler warnings only. There are many more
>> cleanup opportunities in the demo code. Also there is (dead?) code in
>> src/demo/share/java2d which has similar issues. Both are not on scope of these
>> patches.
>> 
>> NEXT STEPS
>> 
>> I?m have no experience with OpenJDK patches. If you?re interested in getting these warnings fixed please
>> let me know how I can submit these patches properly.
>> 
>> 
>> 
>> 
> 



From sgehwolf at redhat.com  Wed Oct 30 09:08:50 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 30 Oct 2019 10:08:50 +0100
Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies
In-Reply-To: 
References: <83a5cb7fc463fc89516d7de8e8706577afc9461f.camel@redhat.com>
 
Message-ID: <3a8e3d76ca105da99493a47adf8c188e685eee09.camel@redhat.com>

Hi Christoph,

On Wed, 2019-10-30 at 05:48 +0000, Langer, Christoph wrote:
> Hi Severin,
> 
> backport looks good. Thanks for doing it.

Thanks for the review!

Cheers,
Severin

> Cheers
> Christoph
> 
> > -----Original Message-----
> > From: build-dev  On Behalf Of
> > Severin Gehwolf
> > Sent: Dienstag, 29. Oktober 2019 19:19
> > To: jdk-updates-dev 
> > Cc: build-dev 
> > Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies
> > 
> > Hi,
> > 
> > Please review this OpenJDK 11u backport of JDK-8214311. It's an
> > Oracle
> > JDK 11.0.6 feature parity patch. The jdk/jdk patch didn't apply
> > cleanly
> > due to context differences in make/hotspot/gensrc/GensrcDtrace.gmk.
> > That is due to JDK-8211029 not being present in OpenJDK 11u code-
> > base.
> > I have fixed the patch manually, which was quite trivial.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8214311
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > 8214311/jdk11/01/webrev/
> > Original changeset: 
> > http://hg.openjdk.java.net/jdk/jdk/rev/7b757120a053
> > 
> > Testing: Building on Linux x86_64 with dtrace enabled. Still works.
> > Unfortunately I don't have a Solaris machine available.
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin



From matthias.baesken at sap.com  Wed Oct 30 14:37:46 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 30 Oct 2019 14:37:46 +0000
Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when
 compiling with xlc16/legacy-xlc 
Message-ID: 

Hello, please review the following small  AIX related fix.
It is a JDK11 only change ,  and  fixes issues  when building JDK11  with xlc16/legacy xlc .
Currently the product build of jdk11   already works with xlc16 ; however  without this change ,  the (fast)debug build  still fails
  because  we call into  operator new   ( operator_new.cpp)     from   Iostream_init::Iostream_init()()   and this  leads to  a failing build .

( The described  issue   was not seen  when  using  the old  xlc12  for the build . )


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233203

http://cr.openjdk.java.net/~mbaesken/webrevs/8233203.0/

Thanks, Matthias


From martin.doerr at sap.com  Wed Oct 30 14:43:25 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 30 Oct 2019 14:43:25 +0000
Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when
 compiling with xlc16/legacy-xlc 
In-Reply-To: 
References: 
Message-ID: 

Hi Matthias,

thanks for fixing xlc16 support for jdk11u. I appreciate it.
Fix looks good to me.

Best regards,
Martin


From: Baesken, Matthias 
Sent: Mittwoch, 30. Oktober 2019 15:38
To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' 
Cc: Langer, Christoph ; Doerr, Martin 
Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when compiling with xlc16/legacy-xlc

Hello, please review the following small  AIX related fix.
It is a JDK11 only change ,  and  fixes issues  when building JDK11  with xlc16/legacy xlc .
Currently the product build of jdk11   already works with xlc16 ; however  without this change ,  the (fast)debug build  still fails
  because  we call into  operator new   ( operator_new.cpp)     from   Iostream_init::Iostream_init()()   and this  leads to  a failing build .

( The described  issue   was not seen  when  using  the old  xlc12  for the build . )


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233203

http://cr.openjdk.java.net/~mbaesken/webrevs/8233203.0/

Thanks, Matthias


From christoph.langer at sap.com  Wed Oct 30 14:48:38 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 30 Oct 2019 14:48:38 +0000
Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when
 compiling with xlc16/legacy-xlc 
In-Reply-To: 
References: 
Message-ID: 

Hi Matthias,

the change looks ok-ish to me. However, I?d encourage to have another look whether there are newer versions of C++ runtimes for the systems where we see this issue which would maybe fix that? But I won?t object to that patch, though. ?

Cheers
Christoph

From: Baesken, Matthias 
Sent: Mittwoch, 30. Oktober 2019 15:38
To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' 
Cc: Langer, Christoph ; Doerr, Martin 
Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when compiling with xlc16/legacy-xlc

Hello, please review the following small  AIX related fix.
It is a JDK11 only change ,  and  fixes issues  when building JDK11  with xlc16/legacy xlc .
Currently the product build of jdk11   already works with xlc16 ; however  without this change ,  the (fast)debug build  still fails
  because  we call into  operator new   ( operator_new.cpp)     from   Iostream_init::Iostream_init()()   and this  leads to  a failing build .

( The described  issue   was not seen  when  using  the old  xlc12  for the build . )


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233203

http://cr.openjdk.java.net/~mbaesken/webrevs/8233203.0/

Thanks, Matthias

From dmitry.markov at oracle.com  Thu Oct 31 10:56:07 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 31 Oct 2019 10:56:07 +0000
Subject: RFR 8232880: Update test documentation with additional settings
 for client UI tooltip tests
In-Reply-To: <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com>
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
 <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>
 <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com>
Message-ID: 

Hi Alexey,

I have updated the fix based on your recommendation. The new version is located at: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.02/ 
Also please find my answers inline.

Thanks,
Dmitry

> On 29 Oct 2019, at 19:29, Alexey Ivanov  wrote:
> 
> Hi Dmitry,
> 
> Shall we drop hyphen in the header: ?Client UI Tests??
> 
> I think there should be no definite article in this sentence: ?use -the- key sequences?.
> 
> ??Turn off Windowss key hotkeys??, there's an extra ?s? in Windows.
> 
> ?Note: restart is required to make the settings take effect.?
> Just to confirm: is signing out and signing in not enough?
According to Microsoft site: restart is required but I guess signing out/in should work too. Unfortunately I do not have Windows on hand to check it out. 

> 
> I'd use backticks for gpedit markup: ?Type `gpedit` in the Search??
> 
> 
> Does it make sense to move the example into macOS section? Then the steps to disable the shortcut can be reduced to the required option only. The steps themselves should not be listed as code, i.e. no backticks.
> 
> (For my understanding, "Turn keyboard access on or off" turns off only one specific shortcut, i.e. Ctrl+F1?)
Yes, that?s right. I have added clarification to the doc.

> 
> 
> Regards,
> Alexey
> 
> On 28/10/2019 17:23, Dmitry Markov wrote:
>> Hi Alexey, Erik, Sergey,
>> Thank you for your feedback. I have updated the fix based on your suggestions: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.01/ 
>> Can you take a look, please?
>> 
>> Thanks,
>> Dmitry
>> 
>>> On 26 Oct 2019, at 00:55, Sergey Bylokhov > wrote:
>>> 
>>> Hi, Dmitry.
>>> 
>>> I suggest to make this block more generic, and describe the  "### Client UI - Tests".
>>> It would be useful to mention that the tests in this category use different key combinations,
>>> which might be registered as a system shortcuts, and it could cause a test failure. It is suggested
>>> to disable these shortcuts:
>>> - macOS config location.....
>>> - Linux config location.....
>>> - On window some other application may have global shortcuts....
>>> 
>>> As an example of such issue you can provide CTRL+F1 which is used....
>>> 
>>> 
>>> On 10/25/19 3:27 am, Dmitry Markov wrote:
>>>> Hello,
>>>> Could you review the fix for jdk14, please?
>>>> 	bug: https://bugs.openjdk.java.net/browse/JDK-8232880  >
>>>> 	webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/  >
>>>> Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail.
>>>> Test documentation should be updated with some notes regarding this.
>>>> Thanks,
>>>> Dmitry
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>> 
> 



From alexey.ivanov at oracle.com  Thu Oct 31 16:27:23 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 31 Oct 2019 16:27:23 +0000
Subject: RFR 8232880: Update test documentation with additional settings
 for client UI tooltip tests
In-Reply-To: 
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
 <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>
 <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com>
 
Message-ID: <3776f84b-b845-3233-47da-021aba45ff84@oracle.com>

Hi Dmitry,

437 ?by the operating system. ?

I'd modify the following text a bit:
To run the test correctly, the default global key shortcut should be 
disabled. Follow the steps above, and then deselect "Turn keyboard 
access on or off" property which is responsible for `CTRL + F1` combination.

Does it sound clearer?
I'd not use backticks on the "Turn keyboard access on or off" because 
it's not something user is typing, nor is it a piece of code. Is the 
word ?property? correct? Does ?shortcut? or ?option? fit better?

I'd recommend adding quotes around the option to look for:
448 in the right-side pane look for "Turn off Windows key hotkeys" and 
double click on it;

Consider adding an empty line before this line
450 Note: restart is required to make the settings take effect.
to make it a separate paragraph in HTML.


Regards,
Alexey

On 31/10/2019 10:56, Dmitry Markov wrote:
> Hi Alexey,
>
> I have updated the fix based on your recommendation. The new version 
> is located at: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.02/
> Also please find my answers inline.
>
> Thanks,
> Dmitry
>
>> On 29 Oct 2019, at 19:29, Alexey Ivanov > > wrote:
>>
>> Hi Dmitry,
>>
>> Shall we drop hyphen in the header: ?Client UI Tests??
>>
>> I think there should be no definite article in this sentence: ?use 
>> -the- key sequences?.
>>
>> ??Turn off Windowss key hotkeys??, there's an extra ?s? in Windows.
>>
>> ?Note: restart is required to make the settings take effect.?
>> Just to confirm: is signing out and signing in not enough?
> According to Microsoft site: restart is required but I guess signing 
> out/in should work too. Unfortunately I do not have Windows on hand to 
> check it out.
>
>>
>> I'd use backticks for gpedit markup: ?Type `gpedit` in the Search??
>>
>>
>> Does it make sense to move the example into macOS section? Then the 
>> steps to disable the shortcut can be reduced to the required option 
>> only. The steps themselves should not be listed as code, i.e. no 
>> backticks.
>>
>> (For my understanding, "Turn keyboard access on or off" turns off 
>> only one specific shortcut, i.e. Ctrl+F1?)
> Yes, that?s right. I have added clarification to the doc.
>
>>
>>
>> Regards,
>> Alexey