From gnu.andrew at redhat.com Fri Oct 1 01:55:59 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 1 Oct 2021 02:55:59 +0100 Subject: Backport JDK-8066588 into 8u In-Reply-To: References: Message-ID: On 13:50 Wed 08 Sep , Anton Ostrouhhov wrote: > Hello! > > I see a letter (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-July/014126.html) in which Andrew (gnu.andrew at redhat.com) wrote that JDK-8066588 will be backported into 8u for 8u312. It is already a 'rampdown' stage so as far as I understand this fix is not going to be included into 8u312. > > Can I take this task and do the fix for u322? > > -- > Regards, > Anton Ostrouhhov > Software Engineer > Azul (https://www.azul.com) > You're welcome to do so. Sorry for not getting around to it myself. -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Oct 1 02:25:15 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 1 Oct 2021 03:25:15 +0100 Subject: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: On 06:57 Tue 14 Sep , erik.joelsson at oracle.com wrote: > Hello, > Hi. Sorry for the delayed reply, but we needed some time to think this over in detail. > Back in February there was a discussion about moving the OpenJDK 8u > development to Git/Skara together with the jdk11u move [1]. The > conclusion then, as I understood it, was to wait until sometime after > jdk11u was moved to give people a chance to get familiar with the new > development process and iron out the details on how it should be > applied. The jdk11u move took place over the summer, so I thought now > would be a good time to revisit the discussion for jdk8u. > I'd still consider the 11u move in progress, as it's not yet completed a release from the new repository. That's the stage that particularly concerns me and I'll be keeping an eye on. > The move for 8u is a bit trickier than 11u as a necessary pre step is to > first consolidate the Mercurial repositories into one, like we did for > JDK 10. I have already produced a prototype conversion during the > previous discussion [2], but it's quite outdated at this time. > Unfortunately, the consolidation process is not easily automated and > only incremental to a point (basically on a per promotion tag level, but > even that comes with some caveats in the update world where multiple > releases are are being developed in parallel). Because of this it's not > feasible to setup a live mirror like we did for jdk11u. Instead, we will > need to plan for up to a week (worst case) of downtime where I produce > the final consolidated HG repository, and then let Skara convert and > publish this to Github. Ideally it should only take 1-2 days, but these > consolidations have been finicky in the past, so better plan for the worst. > > Another option would be to transition in 2 steps, first to a > consolidated HG repo, then to Git. This certainly has other drawbacks, > having to adjust to and support another development process for a short > period of time. It would, however, make the final transition to Git much > smoother and similar to the jdk11u transition. > > I would like to hear from the maintainers of jdk8u what your preferred > strategy would be and what timelines that would make sense to you. > > /Erik > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-February/013402.html > [2] https://github.com/openjdk/jdk8u > The possibility of a two-phase approach to this has allayed a lot of my fears about the possibility of such a transition. Following the well-trodden path used by the main JDK repositories, and the greater time period to adapt to the transition, would ease things a lot. Having discussed this at length with Severin, I propose the following timetable: 1. End of November 2021 (Rampdown of 8u322 / Start of 8u332 Development) * Convert 8u & 8u-dev to Mercurial mono repositories. Given they should be identical at this point, it should be possible to do one conversion of 8u, provide copies at both 8u and 8u-dev, and then let each copy diverge. * Create live read-only mirrors of 8u & 8u-dev in git 2. End of February 2022 (Rampdown of 8u332 / Start of 8u342 Development) * 8u-dev development switches to Git & Skara, with the previous read-only git mirror being used directly. * 8u remains on Mercurial for the release of 8u332. 8u can be synced to 8u-dev from the 8u git mirror. 3. April 2022 (Release of 8u332) * 8u git is used directly for promotions of 8u342. I think this provides the best balance of risk, while also allowing 8u to be consumed from git within the next few months. The most demand I'm seeing for 8u to be in git is from downstream users, who expect it to be on github with the rest, while the most change is required from developers, who have to adapt to the markedly different process used by Skara. The above allows an additional cycle for developers to adapt to this change, see the live git mirrors in operation and perhaps experiment with development in later JDK trees. Meanwhile, downstream users should be able to start working with 8u in git from December. Please let us know if the above seems feasible. My understanding is that the majority of work will be at the end of November, and the second and third changes should just be a matter of making it possible to commit to the git repositories. A couple of additional questions: 1. Would the consolidation to a monorepo take place on top of the existing root repository or be an entirely new Mercurial repository? I've been trying to recall from the jdk10 transition, but can't remember. Either way, the change for developers should just be a one-time switch to the repository and the process of submitting patches remains exactly the same as it is now, except everything is from the one repository. 2. Is the consolidated repository expected to be identical to a fully-checked out copy of the forest (i.e. the root repository with each subrepo as a top-level subdirectory). I know some files moved with jdk10, but I think we'd want everything to stay the same with 8u. 3. As mentioned in another reply, could Skara's backport command be adapted to "shuffle" the paths to fit the 8u layout? This may be quite tricky as currently it requires both the 10u->9u conversion and the 9u->8u conversion, but without this, the backport command is effectively unusable and they all would have to be performed manually. 4. Could Skara be adapted to enforce the jdk8u-fix-yes / jdk8u-critical-yes JIRA labels so the change can't be pushed until it has been approved? Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Oct 1 02:35:28 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 1 Oct 2021 03:35:28 +0100 Subject: Result: New OpenJDK 8 Updates Committer: Jonathan Dowland Message-ID: Voting for Jonathan Dowland [0] is now closed. Yes: 10 Veto: 0 Abstain: 0 Turnout: 4% (10/229) According to the Bylaws definition of Lazy Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-September/014272.html [1] https://openjdk.java.net/bylaws#lazy-consensus -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Oct 1 02:40:20 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 1 Oct 2021 03:40:20 +0100 Subject: [FREEZE] 8u312 NOW FROZEN Message-ID: The release forest: https://hg.openjdk.java.net/jdk8u/jdk8u (and friends) is now frozen in preparation for release on or after 2021-10-19. The final pre-release tag is jdk8u312-b06. As there were effectively no source code changes in jdk8u312-b06 (the same patch was reverted and committed under the correct bug ID), jdk8u312-b05 source tarballs and builds remain valid as the final pre-release. The final release tag will be no lower than jdk8u312-b07. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From erik.joelsson at oracle.com Fri Oct 1 13:22:45 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 1 Oct 2021 06:22:45 -0700 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: Hello Andrew, Thank you for your detailed reply! On 2021-09-30 19:25, Andrew Hughes wrote: > Hi. Sorry for the delayed reply, but we needed some time to think > this over in detail. No worries. > I'd still consider the 11u move in progress, as it's not yet > completed a release from the new repository. That's the stage > that particularly concerns me and I'll be keeping an eye on. Understood. > The possibility of a two-phase approach to this has allayed a lot of my > fears about the possibility of such a transition. Following the well-trodden > path used by the main JDK repositories, and the greater time period to > adapt to the transition, would ease things a lot. > > Having discussed this at length with Severin, I propose the following timetable: > > 1. End of November 2021 (Rampdown of 8u322 / Start of 8u332 Development) > > * Convert 8u & 8u-dev to Mercurial mono repositories. > Given they should be identical at this point, it should be possible to > do one conversion of 8u, provide copies at both 8u and 8u-dev, and > then let each copy diverge. > > * Create live read-only mirrors of 8u & 8u-dev in git > > 2. End of February 2022 (Rampdown of 8u332 / Start of 8u342 Development) > > * 8u-dev development switches to Git & Skara, with the previous read-only > git mirror being used directly. > * 8u remains on Mercurial for the release of 8u332. 8u can be synced > to 8u-dev from the 8u git mirror. > > 3. April 2022 (Release of 8u332) > > * 8u git is used directly for promotions of 8u342. > > I think this provides the best balance of risk, while also allowing 8u > to be consumed from git within the next few months. I think this plan looks reasonable, but I will need to check internally before I can give a final go ahead. Could you narrow down the potential cut over windows to date ranges? > The most demand I'm seeing for 8u to be in git is from downstream > users, who expect it to be on github with the rest, while the most > change is required from developers, who have to adapt to the markedly > different process used by Skara. The above allows an additional cycle > for developers to adapt to this change, see the live git mirrors in > operation and perhaps experiment with development in later JDK trees. > Meanwhile, downstream users should be able to start working with > 8u in git from December. > > Please let us know if the above seems feasible. My understanding > is that the majority of work will be at the end of November, > and the second and third changes should just be a matter of making > it possible to commit to the git repositories. Yes, the consolidation is the trickiest part with the most amount of unknowns that could potentially delay things. I do believe I have it under control however. You can look at the current prototype here: https://hg.openjdk.java.net/jdk8u/consol-proto/ > A couple of additional questions: > > 1. Would the consolidation to a monorepo take place on top of > the existing root repository or be an entirely new Mercurial > repository? I've been trying to recall from the jdk10 transition, > but can't remember. Either way, the change for developers should > just be a one-time switch to the repository and the process > of submitting patches remains exactly the same as it is now, > except everything is from the one repository. No, it's a new repository. In the case of the OpenJDK 8u consolidation, it will be based on the existing JDK 10 consolidated repository and share history up until jdk8-b120, where the history started to diverge in the original repositories. The change for developers should be minimal as you say. The guarantee we give is that each promotion tag is equivalent between the monorepo and the forest. > 2. Is the consolidated repository expected to be identical > to a fully-checked out copy of the forest (i.e. the root > repository with each subrepo as a top-level subdirectory). > I know some files moved with jdk10, but I think we'd want > everything to stay the same with 8u. Yes, the file layout is identical. We have no plans to rearrange things for 8u. You may want to do some cleanup afterwards, like removing the hgforest.sh/get_source.sh scripts that are no longer useful and remove the no longer used .hgtags files from old nested repo directories. > 3. As mentioned in another reply, could Skara's backport > command be adapted to "shuffle" the paths to fit the > 8u layout? This may be quite tricky as currently it > requires both the 10u->9u conversion and the 9u->8u > conversion, but without this, the backport command > is effectively unusable and they all would have to > be performed manually. I can see this being a very useful feature, but also a non trivial effort to implement. I can't say at this time if I would personally be able to allocate time for this. > 4. Could Skara be adapted to enforce the jdk8u-fix-yes / > jdk8u-critical-yes JIRA labels so the change can't be pushed until it > has been approved? This sounds like a rather simple feature in comparison. Please file an enhancement request for SKARA. /Erik From christoph.langer at sap.com Fri Oct 1 15:21:05 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Oct 2021 15:21:05 +0000 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: Hi, > > 4. Could Skara be adapted to enforce the jdk8u-fix-yes / > > jdk8u-critical-yes JIRA labels so the change can't be pushed until it > > has been approved? > > This sounds like a rather simple feature in comparison. Please file an > enhancement request for SKARA. I filed https://bugs.openjdk.java.net/browse/SKARA-1199 because this would be a very nice feature for the other update projects (e.g. jdk11u) as well. Thanks & Best regards Christoph From akashche at redhat.com Mon Oct 4 20:25:43 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 4 Oct 2021 21:25:43 +0100 Subject: [8u] RFR: 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: <69a581fe-4067-56bb-1d22-80ea2b7ac277@redhat.com> References: <55ba423a-fec5-c67f-6f91-441dda37b9e5@redhat.com> <69a581fe-4067-56bb-1d22-80ea2b7ac277@redhat.com> Message-ID: Hi, On 6/30/20, Alex Kashchenko wrote: > On 06/29/2020 01:47 PM, Andrew Hughes wrote: >> On 26/06/2020 23:30, Alex Kashchenko wrote: >>> Hi, >>> >>> Please review the backport of JDK-8146215 to 8u: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146215 >>> >>> 9 commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/44bb7c7997ca >>> >>> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8146215/webrev.00/ >>> >>> 8u code change is almost identical to 9, only copyright year is changed >>> in AbstractFileTypeDetector.java. Test part doesn't apply cleanly, >>> because probeContentType/Basic.java in 9 contains changes that are not >>> in 8u (JDK-8129632 and others), it is adjusted for 8u. Testing: included >>> test, jck:api/java_net;api/java_nio. >>> >>> >> >> Hi Alex, >> >> The class library code changes look fine. >> >> For the testing, I think JDK-8150204 should at least be backported >> first. It's a test-only change, and you're effectively doing that in >> this patch, but uncredited. I can understand the reluctance to backport >> the Mac OS X fix, JDK-8129632, so I'm happy for the 8150204 backport to >> just take the testing changes from 8129632 as part of it, or work around >> them as you have here. >> >> Once 8150204 is in place, this backport should be close to the 11u >> version. > > Thanks for your comments! I've posted 8150204 for review: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012063.html Returning to this issue that was overlooked: 8150204 has been added to 8u, please review updated backport of 8146215: https://cr.openjdk.java.net/~akasko/jdk8u/8146215/webrev.01/ Differences from original commit: paths reshuffling, copyright year in AbstractFileTypeDetector.java, list of issues numbers changed and checkOSXContentTypes() function removed in Basic.java test. Testing: java/nio/file/Files/probeContentType/ and java/net/URLConnection/ jtreg tests. -- -Alex From akashche at redhat.com Mon Oct 4 20:47:37 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 4 Oct 2021 21:47:37 +0100 Subject: [8u] RFR: 8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException In-Reply-To: References: Message-ID: On 9/30/20, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8139414 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139414 > > jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/26cb3ae62fd3 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8139414/webrev.00/ > > This backport is a dependency of the JDK-8172695 (RFC thread [1]). It > includes necessary parts of JDK-8072722 (RFR thread [2], rejected) and > applies almost cleanly on top of it. The only change to original > patch, besides paths, is the removal of two lines that reference > "modCount" variable [3][4]. Testing: jtreg:java/util/Scanner , > jck:api/java_util/Scanner . > > > [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011789.html > [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011854.html > [3] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/26cb3ae62fd3#l1.86 > [4] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/26cb3ae62fd3#l1.98 Pinging politely, it would be great to have this issue reviewed. -- -Alex From akashche at redhat.com Mon Oct 4 22:15:50 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 4 Oct 2021 23:15:50 +0100 Subject: [8u] RFR: 8231254: (fs) Add test for macOS Catalina changes to protect system software Message-ID: Hi, Please review the parity backport of JDK-8231254: Bug: https://bugs.openjdk.java.net/browse/JDK-8231254 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/1e57d3774190 8 webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8231254/webrev.00/ 8u changes: removed "jdk" prefix from file path, Path.of() replaced with Paths.get(). This backport only adds a new test, I've checked that it can be run on Mac and intend to follow up with JDK-8232178 backport. -- -Alex From vkempik at azul.com Tue Oct 5 08:14:37 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 5 Oct 2021 08:14:37 +0000 Subject: [8u] RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 In-Reply-To: References: Message-ID: <792F6188-A5DE-4FAD-A990-6AD881C06EFE@azul.com> Hello Can I get this reviewed please ? The fix is rather simple and there are no critical differences between 8 and 11 patches. The Oracle have already included this into their October jdk8 update. Regards, Vladimir > 14 ????. 2021 ?., ? 13:28, Vladimir Kempik ???????(?): > > Please review this backport of 8261397 to jdk8u > > The fix didn?t apply cleanly due to MACOS_ONLY macro missing in jdk8 and some context code difference. > > The fix is low-risk, affect only macos_x86 when running in rosetta2 translation mode on m1 mac. > Checked the build with fix on m1 mac with testcase from the bug, testcase now works. > > The webrev - http://cr.openjdk.java.net/~vkempik/8261397/webrev.8u.01/ > > The Bug - https://bugs.openjdk.java.net/browse/JDK-8261397 > > Original changeset - https://github.com/openjdk/jdk/commit/0257caad > > Regards, Vladimir From akashche at redhat.com Tue Oct 5 09:24:05 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 5 Oct 2021 10:24:05 +0100 Subject: [8u] RFR: 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings Message-ID: Hi, Please review the parity backport of JDK-8214578: Bug: https://bugs.openjdk.java.net/browse/JDK-8214578 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8214578/webrev.00/ Patch doesn't apply cleanly because of the JDK-8148555 change that is not in 8u, useString variable is changed to aString to workaround this. Testing: checked manually with an on-screen JIS keyboard that yen symbol is shown without the change and a backslash - with the change. -- -Alex From yan at azul.com Tue Oct 5 10:16:55 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 5 Oct 2021 13:16:55 +0300 Subject: [8u] RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 In-Reply-To: <792F6188-A5DE-4FAD-A990-6AD881C06EFE@azul.com> References: <792F6188-A5DE-4FAD-A990-6AD881C06EFE@azul.com> Message-ID: <58d3408b-a38f-bd00-9b9e-9ddbe0a61763@azul.com> Hi Vladimir, the fix looks good to me. Thanks, --yan On 05.10.2021 11:14, Vladimir Kempik wrote: > Hello > Can I get this reviewed please ? > The fix is rather simple and there are no critical differences between 8 and 11 patches. > The Oracle have already included this into their October jdk8 update. > Regards, Vladimir > >> 14 ????. 2021 ?., ? 13:28, Vladimir Kempik ???????(?): >> >> Please review this backport of 8261397 to jdk8u >> >> The fix didn?t apply cleanly due to MACOS_ONLY macro missing in jdk8 and some context code difference. >> >> The fix is low-risk, affect only macos_x86 when running in rosetta2 translation mode on m1 mac. >> Checked the build with fix on m1 mac with testcase from the bug, testcase now works. >> >> The webrev - http://cr.openjdk.java.net/~vkempik/8261397/webrev.8u.01/ >> >> The Bug - https://bugs.openjdk.java.net/browse/JDK-8261397 >> >> Original changeset - https://github.com/openjdk/jdk/commit/0257caad >> >> Regards, Vladimir > From akashche at redhat.com Tue Oct 5 10:59:03 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 5 Oct 2021 11:59:03 +0100 Subject: [8u] RFR: 8185500: [TESTBUG] Add keywords headful/printer in java/awt and javax tests. In-Reply-To: References: <37e50eaf-79ee-48d6-dc8a-2d03dc70073d@redhat.com> Message-ID: Hi, On 9/1/20, Alex Kashchenko wrote: > Hi, > > On 7/6/20, Alex Kashchenko wrote: >> Hi, >> >> Please review the backport of JDK-8185500 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185500 >> >> 10 change: https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/b762aafa34e3 >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8185500/webrev.00 >> >> This change adds "headful" and "printer" keywords to a number of client >> test, 129 tests are changed in jdk10, 63 of them are present in 8u. >> >> Patch is altered for 8u leaving only the tests that are present, some >> tests also have required changes to jtreg tags section and copyright >> year. There are no changes to test code itself. >> >> Testing: checked that modified tests can be selected correctly with >> "headful" and "printer" keywords: >> >> Before: >> >> $ jtreg [...] -l @list.txt >> >> Tests found: 63 >> >> After: >> >> $ jtreg [...] -l -k:headful @list.txt >> >> Tests found: 53 >> >> $ jtreg [...] -l -k:printer @list.txt >> >> Tests found: 10 >> >> $ jtreg [...] -l -k:"(headful|printer)" @list.txt >> >> Tests found: 63 >> >> Note, some tests include "os.family" requirement, so the numbers above >> may differ. > > Adding Jira traces for the tests, that were excluded from this backport: > > test/java/awt/Choice/ChoiceHiDpi/ChoiceTest.java > 8144594: HiDPI: awt.Choice looks improperly (Win 8) > > test/java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java > test/java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java > 8160266: [macosx] NestedModalDialogTest.java and > NestedModelessDialogTest.java tests does not run with current JDK > codebase after taking the files from MACOSX_PORT > > test/java/awt/FileDialog/FileDialogIconTest/FileDialogIconTest.java > 8157163: AWT FileDialog does not inherit icon image from parent Frame > > test/java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java > 8154043: Fields not reachable anymore by tab-key, because of new > tabbing behaviour of radio button groups. > > test/java/awt/Focus/RequestFocusByCause/RequestFocusByCauseTest.java > 8154434: Open the request focus methods of the java.awt.Component > which accept FocusEvent.Cause > > test/java/awt/Frame/8158918/SetExtendedState.java > 8158918: setExtendedState(1) for maximized Frame results in state==7 > > test/java/awt/Frame/DecoratedFrameInsets/DecoratedFrameInsetsTest.java > 8165619: Frame is not repainted if created in state=MAXIMIZED_BOTH on Unity > > test/java/awt/Frame/SetMaximizedBounds/MaximizedMovedWindow.java > 8065739: [macosx] Frame warps to lower left of screen when displayed > > test/java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java > 8039279: Move awt tests to openjdk repository > > test/java/awt/FullScreen/CurrentDisplayModeTest/CurrentDisplayModeTest.java > 8167486: Device.getDisplayMode() doesn't report refresh rate on Linux > in case of dual screen > > test/java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java > 8022810: Cannot list all the available display modes on Ubuntu linux > in case of two screen devices > > test/java/awt/Robot/HiDPIMouseClick/HiDPIRobotMouseClick.java > test/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java > 8073320: Windows HiDPI Graphics support > > test/java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java > 8015900: [TEST_BUG] ScrollbarMouseWheelTest failed on ubuntu 12 with > unity and unity 2D > > test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java > 8145174: HiDPI splash screen support on Linux > > test/java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java > 8151588: Press the button first two times, the 'First' and 'Next' didn't > show > > test/java/awt/TextArea/OverScrollTest/OverScrollTest.java > 8149636: TextField flicker & over scroll when selection scrolls beyond > the bounds of TextField > > test/java/awt/TextField/OverScrollTest/OverScrollTest.java > 8149636: TextField flicker & over scroll when selection scrolls beyond > the bounds of TextField > > test/java/awt/Window/GetScreenLocation/GetScreenLocationTest.java > 8036915: setLocationRelativeTo stopped working in Ubuntu 13.10 (Unity) > > test/java/awt/Window/SetWindowLocationByPlatformTest/SetWindowLocationByPlatformTest.java > 8025130: [macosx] Frame setLocationByPlatform has no effect under Mac OS X > > test/java/awt/hidpi/properties/HiDPIPropertiesWindowsTest.java > 8073320: Windows HiDPI Graphics support > > test/java/awt/image/multiresolution/Corrupted2XImageTest.java > 8142406: [TEST] MultiResolution image: need test to cover the case > when @2x image is corrupted > > test/java/awt/keyboard/AllKeyCode/AllKeyCode.java > 8149456: [macosx] robot.keyPress do not generate key events > (keyPressed and keyReleased) for function keys F13 to F19 > > test/java/awt/keyboard/AltPlusNumberKeyCombinationsTest/AltPlusNumberKeyCombinationsTest.java > 8044172: [TEST_BUG] Move regtests for 4523758 and > AltPlusNumberKeyCombinationsTest to jdk > > test/java/awt/print/PrinterJob/CheckPrivilege.java > test/java/awt/print/PrinterJob/PaintText.java > test/java/awt/print/PrinterJob/PrintTextPane.java > 8038723: Openup some PrinterJob tests > > test/javax/swing/JButton/8151303/PressedIconTest.java > 8151303: [macosx] [hidpi] JButton's low-res. icon is visible when clicking > on it > > test/javax/swing/JComboBox/6567433/UpdateUIRecursionTest.java > 6567433: JComponent.updateUI() may create StackOverflowError > > test/javax/swing/JComboBox/8041909/ActionListenerExceptionTest.java > 8041909: Uncaught exceptions in JComboBox listeners cause listener not > to receive events > > test/javax/swing/JComboBox/WindowsComboBoxSize/WindowsComboBoxSizeTest.java > 8179027: JComboBox too small under Windows LAF > > test/javax/swing/JFileChooser/8010718/bug8010718.java > 8010718: javax/swing/JFileChooser/8013442/Test8013442.java fails > > test/javax/swing/JFileChooser/8152677/SelectAllFilesFilterTest.java > 8152677: [macosx] All files filter can't be selected in JFileChooser > > test/javax/swing/JInternalFrame/6288609/TestJInternalFrameDispose.java > 6288609: JInternalFrame.setDefaultCloseOperation() interferes with > "close" behavior > > test/javax/swing/JInternalFrame/8075314/bug8075314.java > 8075314: All the InternalFrames will be maximized after maximizing > only one of the InternalFrame with WindowsLookAndFeel > > test/javax/swing/JInternalFrame/8145060/TestJInternalFrameMinimize.java > 8145060: Minimizing a JInternal frame not shifting focus to frame below it > > test/javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java > 8160248: Dragged internal frame leaves artifacts for floating point ui > scale > > test/javax/swing/JInternalFrame/DockIconRepaint/DockIconRepaint.java > 8144166: [macosx] Test > java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java > fails > > test/javax/swing/JList/6567433/UpdateUIRecursionTest.java > 6567433: JComponent.updateUI() may create StackOverflowError > > test/javax/swing/JList/8161483/Bug8161483.java > 8161483: Implement AccessibleAction interface in > JList.AccessibleJList.AccessibleJListChild > > test/javax/swing/JMenu/6538132/bug6538132.java > 8063107: Change open swing regression tests to avoid > sun.awt.SunToolkit.realSync, part 2 > > test/javax/swing/JMenu/8067346/bug8067346.java > 8067346: Swing submenu has a changed starting offset > > test/javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java > 8139169: [macosx] Action registered for keyboard shortcut is called twice > > test/javax/swing/JMenuItem/8158566/CloseOnMouseClickPropertyTest.java > 8158566: Provide a Swing property to not close toggle menu items on mouse > click > > test/javax/swing/JMenuItem/ClickMenuTestManual/ClickMenuTestManual.java > 8158230: [macosx] ActionEvent is not fired for menu item with option > apple.laf.useScreenMenuBar > > test/javax/swing/JOptionPane/8081019/bug8081019.java > 8081019: Check peer to null in CPlatformWindow.checkZoom() > > test/javax/swing/JPopupMenu/6217905/bug6217905.java > 8063107: Change open swing regression tests to avoid > sun.awt.SunToolkit.realSync, part 2 > > test/javax/swing/JTable/6567433/UpdateUIRecursionTest.java > test/javax/swing/JTableHeader/6567433/UpdateUIRecursionTest.java > 6567433: JComponent.updateUI() may create StackOverflowError > > test/javax/swing/JTextArea/ScrollbarFlicker/ScrollFlickerTest.java > 8160246: Regression: 4410243 reproducible with GTK LaF > > test/javax/swing/JTree/6567433/UpdateUIRecursionTest.java > 6567433: JComponent.updateUI() may create StackOverflowError > > test/javax/swing/ProgressMonitor/ProgressMonitorEscapeKeyPress.java > 8065861: Pressing Esc does not set 'canceled' property of ProgressMonitor > > test/javax/swing/UI/UnninstallUIMemoryLeaks/UnninstallUIMemoryLeaks.java > 8134947: [macosx] Various memory leaks in Aqua look and feel > > test/javax/swing/plaf/basic/6866751/bug6866751.java > 6866751: J2SE_Swing_Reg: the caret disappears when moving to the end > of the line. > > test/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java > 8135176: Moving test from javax/swing/plaf/basic/BasicHTML/4960629 to > test/javax/swing/plaf/basic/BasicHTML/4960629 > > test/javax/swing/plaf/windows/6921687/bug6921687.java > 6921687: Mnemonic disappears after repeated attempts to open menu > items using mnemonics > > test/javax/swing/text/GlyphPainter2/6427244/bug6427244.java > 8144015: [PIT] failures of text layout font tests > > test/javax/swing/text/Utilities/8142966/SwingFontMetricsTest.java > 8142966: Wrong cursor position in text components on HiDPI display > > test/sun/awt/image/OffScreenImageSource/ImageConsumerUnregisterTest.java > 8160421: Regression: JDK-8139192 causes NPE in > java.awt.Toolkit.createCustomCursor() > > test/sun/java2d/xrender/HugeGradientTest.java > 8162591: All existing gradient paint implementations have issues with > coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux > systems I would like to return to this change because it blocks a number of other parity changes. I've updated the patch accommodating to more recent 8u changes that were pushed with JDK-8063104, 8063106, 8063107 and 8081764: https://cr.openjdk.java.net/~akasko/jdk8u/8185500/webrev.02/ The following tests were updated: test/java/awt/Focus/FocusEmbeddedFrameTest/FocusEmbeddedFrameTest.java test/java/awt/event/KeyEvent/DeadKey/DeadKeyMacOSXInputText.java test/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java test/javax/swing/JPopupMenu/7154841/bug7154841.java test/javax/swing/JTabbedPane/7170310/bug7170310.java test/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java Note, review email for the previous version of this patch: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/013061.html -- -Alex From akashche at redhat.com Tue Oct 5 11:26:50 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 5 Oct 2021 12:26:50 +0100 Subject: [8u] RFR: 8140329: [TEST_BUG] test FullScreenAfterSplash.java failed because image was not generated Message-ID: Hi, Please review a parity backport of JDK-8140329: Bug: https://bugs.openjdk.java.net/browse/JDK-8140329 Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/502905f8b0aa 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8140329/webrev.00/ FullScreenAfterSplash.java has required minor adjustments to copyright year and imports because of JDK-8076468 and 8074092 changes that are not in 8u. Testing: checked that the test fails without the patch and passes with the patch. -- -Alex From zgu at redhat.com Tue Oct 5 15:11:19 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 5 Oct 2021 11:11:19 -0400 Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride Message-ID: <9d8fe2ad-e42e-2ce5-4e5f-ee24eb87a6c5@redhat.com> This backport is for parity with Oracle 8u321. Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 The original patch does not apply cleanly. There is not newThread(String name, Runnable target) method in 8u, so discard this part of change. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ Thanks, -Zhengyu From akashche at redhat.com Wed Oct 6 10:00:41 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 6 Oct 2021 11:00:41 +0100 Subject: [8u] RFR: 8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS Message-ID: Hi, Please review a parity backport of JDK-8066652: Bug: https://bugs.openjdk.java.net/browse/JDK-8066652 Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/17a073876794 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8066652/webrev.00/ Only 8u-specific change is that copyright year hunk is skipped. Testing: checked that added test fails on Mac without the patch and passes with the patch. Ran jtreg:java/util/TimeZone on Mac and Linux. -- -Alex From bylokhov at amazon.com Wed Oct 6 19:46:12 2021 From: bylokhov at amazon.com (Sergey Bylokhov) Date: Wed, 6 Oct 2021 12:46:12 -0700 Subject: [UNVERIFIED SENDER] [8u] RFR: 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: References: Message-ID: <786c84fb-d042-514d-a797-57f90663c94b@amazon.com> Hi, Alex. You need to backport the fixes for a regressions caused by the 8214578: https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20regression_8214578 Since regressions are crashes I think it will be better to backport them at the same time. On 10/5/21 2:24 AM, Alex Kashchenko wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi, > > Please review the parity backport of JDK-8214578: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214578 > > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8214578/webrev.00/ > > Patch doesn't apply cleanly because of the JDK-8148555 change that is > not in 8u, useString variable is changed to aString to workaround > this. > > Testing: checked manually with an on-screen JIS keyboard that yen > symbol is shown without the change and a backslash - with the change. > > -- > -Alex > -- Best regards, Sergey. From akashche at redhat.com Wed Oct 6 21:06:54 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 6 Oct 2021 22:06:54 +0100 Subject: [8u] RFR: 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: <786c84fb-d042-514d-a797-57f90663c94b@amazon.com> References: <786c84fb-d042-514d-a797-57f90663c94b@amazon.com> Message-ID: Hi Sergey, On 10/6/21, Sergey Bylokhov wrote: > Hi, Alex. > > You need to backport the fixes for a regressions caused by the 8214578: > https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20regression_8214578 > > Since regressions are crashes I think it will be better to backport them at > the same time. Thanks for the pointers! I've checked that 8234786 and 8248532 can be applied cleanly on top of this change and marked both of them for 8u approval. I intend to push all 3 changes at once when this patch is reviewed and all of them are approved. -- -Alex From akashche at redhat.com Fri Oct 8 10:11:05 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 8 Oct 2021 11:11:05 +0100 Subject: [8u] RFR: 8044365: (dc) MulticastSendReceiveTests.java failing with ENOMEM when joining group (OS X 10.9) Message-ID: Hi, Please review the parity backport of JDK-8044365: Bug: https://bugs.openjdk.java.net/browse/JDK-8044365 Original commit: https://hg.openjdk.java.net/jdk-updates/jdk14u/rev/591e3b2374db 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8044365/webrev.00/ 8u specific changes are only to path and copyright header. Testing: ran jtreg:java/nio/channels/DatagramChannel on Mac. -- -Alex From qingfeng.yy at alibaba-inc.com Fri Oct 8 11:03:37 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Fri, 08 Oct 2021 19:03:37 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlI6IDgyMjU2OTA6IE11bHRpcGxlIEF0dGFjaExpc3RlbmVyIHRocmVhZHMgY2Fu?= =?UTF-8?B?IGJlIGNyZWF0ZWQ=?= Message-ID: <3da82111-5b80-49fe-91be-e3a9c9171921.qingfeng.yy@alibaba-inc.com> Hi, Can I have a review for this backport of JDK-8225690? Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02 Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953 Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/ VM can't be attached If someone cleans up the /tmp directory. This patch addresses the problem. It can not apply cleanly, some minor conflicts are as follows: 1. Atomic::store(new_state, &_state) jdk8u does not have templated Atomic function family, use explicitly type conversion `Atomic::store((jlong)new_state, (volatile jlong*)&_state)`. 2. IsRegisteredEnum jdk8u does not have metaprogramming type traits, `template<> struct IsRegisteredEnum : public TrueType {};` simply omit it. 3. os::naked_yield os::naked_yield is missing due to https://bugs.openjdk.java.net/browse/JDK-8047714, use os::yield instead. 4. log_debug(attach)("...") jdk8u does not have unified logging system. Use the following code: `debug_only(warning("..."))` 5. Test They can not work because of the usages of LingeredApp. Remove @test tag to disable them while keeping their source code. Test cases have been passed manually. The original issue has related bugs: https://bugs.openjdk.java.net/browse/JDK-8227815 https://bugs.openjdk.java.net/browse/JDK-8235211 https://bugs.openjdk.java.net/browse/JDK-8227738 I'd like to create follow-up backports(JDK-8227815 and JDK-8227738) once this merged. JDK-8235211 is not necessary since RemovingUnixDomainSocketTest.java will be ignored as I said before. Thanks! From akashche at redhat.com Fri Oct 8 11:38:48 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 8 Oct 2021 12:38:48 +0100 Subject: [8u] RFR: 8162572: Update License Header for all JAXP sources Message-ID: Hi, Please review a backport of JDK-8162572: Bug (not public): https://bugs.openjdk.java.net/browse/JDK-8162572 Original commit: https://hg.openjdk.java.net/jdk10/jdk10/jaxp/rev/2fdbfbde3bc0 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8162572/webrev.00/ This change can make it easier to backport subsequent JAXP parity issues to 8u. There are no code changes, only copyright headers are changed. Majority of the files apply cleanly, the following files were resolved manually: src/com/sun/org/apache/xalan/internal/lib/Extensions.java src/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java src/com/sun/org/apache/xml/internal/dtm/DTMConfigurationException.java src/com/sun/org/apache/xml/internal/dtm/DTMException.java src/com/sun/org/apache/xml/internal/dtm/DTMManager.java src/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOM3SerializerImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorHandlerImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMLocatorImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMOutputImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMStringListImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/NamespaceSupport.java src/com/sun/org/apache/xml/internal/serializer/utils/AttList.java src/com/sun/org/apache/xml/internal/serializer/utils/DOM2Helper.java src/com/sun/org/apache/xml/internal/utils/DOMOrder.java src/com/sun/org/apache/xpath/internal/XPath.java src/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java src/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java -- -Alex From bylokhov at amazon.com Mon Oct 11 01:45:19 2021 From: bylokhov at amazon.com (Sergey Bylokhov) Date: Sun, 10 Oct 2021 18:45:19 -0700 Subject: [8u] RFR: 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: References: <786c84fb-d042-514d-a797-57f90663c94b@amazon.com> Message-ID: <7477efbf-23fb-3d16-4d91-9f9618019011@amazon.com> > Thanks for the pointers! I've checked that 8234786 and 8248532 can be > applied cleanly on top of this change and marked both of them for 8u > approval. I intend to push all 3 changes at once when this patch is > reviewed and all of them are approved. Did you have a chance to reproduce these issues? Can you confirm that crashes are resolved by these changes? Am not sure that the list of fixes above is complete. -- Best regards, Sergey. From akashche at redhat.com Mon Oct 11 10:49:53 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 11 Oct 2021 11:49:53 +0100 Subject: [8u] RFR: 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: <7477efbf-23fb-3d16-4d91-9f9618019011@amazon.com> References: <786c84fb-d042-514d-a797-57f90663c94b@amazon.com> <7477efbf-23fb-3d16-4d91-9f9618019011@amazon.com> Message-ID: On 10/11/21, Sergey Bylokhov wrote: >> Thanks for the pointers! I've checked that 8234786 and 8248532 can be >> applied cleanly on top of this change and marked both of them for 8u >> approval. I intend to push all 3 changes at once when this patch is >> reviewed and all of them are approved. > > Did you have a chance to reproduce these issues? I am unable to reproduce the crash on macOS 10.14 with 8u-dev (with 8214578 applied) with muCommander 0.9.3 changing from US to Romaji multiple times. > Can you confirm that > crashes are resolved by these > changes? Unfortunately, no. >Am not sure that the list of fixes above is complete. Besides 8248532 I can see 8257242 (that is also backported to 15, 13 and 11). I've checked that it can be applied to 8u, just it also depends on a header change from 8234786. I assume 8257242 should go into 8u too if 8214578 is approved. PS: if someone with a deep knowledge in this area thinks that 8214578 is too dangerous for 8u, it may be better to explicitly mark it with "8u-rejected" or something similar. -- -Alex From erik.joelsson at oracle.com Tue Oct 12 22:13:47 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 12 Oct 2021 15:13:47 -0700 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: On 2021-10-01 06:22, erik.joelsson at oracle.com wrote: >> Having discussed this at length with Severin, I propose the following >> timetable: >> >> 1. End of November 2021 (Rampdown of 8u322 / Start of 8u332 Development) >> >> * Convert 8u & 8u-dev to Mercurial mono repositories. >> Given they should be identical at this point, it should be possible to >> do one conversion of 8u, provide copies at both 8u and 8u-dev, and >> then let each copy diverge. >> >> * Create live read-only mirrors of 8u & 8u-dev in git >> >> 2. End of February 2022 (Rampdown of 8u332 / Start of 8u342 Development) >> >> * 8u-dev development switches to Git & Skara, with the previous >> read-only >> git mirror being used directly. >> * 8u remains on Mercurial for the release of 8u332.? 8u can be synced >> to 8u-dev from the 8u git mirror. >> >> 3. April 2022 (Release of 8u332) >> >> * 8u git is used directly for promotions of 8u342. >> >> I think this provides the best balance of risk, while also allowing 8u >> to be consumed from git within the next few months. > I think this plan looks reasonable, but I will need to check > internally before I can give a final go ahead. Could you narrow down > the potential cut over windows to date ranges? > We think this timetable is good. I have filed [1] for the first step. We need to decide on: 1. Cutoff date 2. New URL/name for https://hg.openjdk.java.net/jdk8u/jdk8u 3. New URL/name for https://hg.openjdk.java.net/jdk8u/jdk8u-dev /Erik [1] https://bugs.openjdk.java.net/browse/SKARA-1214 From gnu.andrew at redhat.com Tue Oct 12 23:13:01 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Oct 2021 00:13:01 +0100 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: On 06:22 Fri 01 Oct , erik.joelsson at oracle.com wrote: > Hello Andrew, > > Thank you for your detailed reply! > > On 2021-09-30 19:25, Andrew Hughes wrote: > > Hi. Sorry for the delayed reply, but we needed some time to think > > this over in detail. > No worries. You're welcome and again, sorry for taking a while to reply; the October security update is consuming most of my time at the minute. snip... > > > > 1. End of November 2021 (Rampdown of 8u322 / Start of 8u332 Development) > > > > * Convert 8u & 8u-dev to Mercurial mono repositories. > > Given they should be identical at this point, it should be possible to > > do one conversion of 8u, provide copies at both 8u and 8u-dev, and > > then let each copy diverge. > > > > * Create live read-only mirrors of 8u & 8u-dev in git > > > > 2. End of February 2022 (Rampdown of 8u332 / Start of 8u342 Development) > > > > * 8u-dev development switches to Git & Skara, with the previous read-only > > git mirror being used directly. > > * 8u remains on Mercurial for the release of 8u332. 8u can be synced > > to 8u-dev from the 8u git mirror. > > > > 3. April 2022 (Release of 8u332) > > > > * 8u git is used directly for promotions of 8u342. > > > > I think this provides the best balance of risk, while also allowing 8u > > to be consumed from git within the next few months. > I think this plan looks reasonable, but I will need to check internally > before I can give a final go ahead. Could you narrow down the potential > cut over windows to date ranges? Certainly. 1. The monorepo transition and creation of live read-only git mirrors would be after the rampdown of 8u322, which is scheduled for Friday, November the 26th, 2021. So I would expect the transition to begin on the week beginning Monday, November the 29th, 2021. One of the reasons we chose this particular period for what is expected to be the most involved work is that the December period is usually quiet, as many people ramp down themselves for the holiday period. So a delay should be less problematic than at other times. 2. The 8u-dev git repo should go live the week beginning Monday, February 28th, 2022, following rampdown on Friday the 25th. Technically, this should hopefully just mean making the repository writable. The main issue is in adjusting our processes to using git and Skara. 3. The 8u git repo should go live after the 8u332 release is pushed, on Tuesday, April the 19th 2022. As 8u is only used at this point for the build promotions I'm making, a delay here doesn't directly affect developers; it would just mean a later build promotion. I've updated the 8u wiki with the 8u322 & 8u332 schedules as well: https://wiki.openjdk.java.net/display/jdk8u/Main > > The most demand I'm seeing for 8u to be in git is from downstream > > users, who expect it to be on github with the rest, while the most > > change is required from developers, who have to adapt to the markedly > > different process used by Skara. The above allows an additional cycle > > for developers to adapt to this change, see the live git mirrors in > > operation and perhaps experiment with development in later JDK trees. > > Meanwhile, downstream users should be able to start working with > > 8u in git from December. > > > > Please let us know if the above seems feasible. My understanding > > is that the majority of work will be at the end of November, > > and the second and third changes should just be a matter of making > > it possible to commit to the git repositories. > > Yes, the consolidation is the trickiest part with the most amount of > unknowns that could potentially delay things. I do believe I have it > under control however. You can look at the current prototype here: > > https://hg.openjdk.java.net/jdk8u/consol-proto/ > Thanks. Are the commits from duke usual? The one for 8u312-b05 particularly catches my attention, as I'd expect several tags from myself, as with b04, instead. > > A couple of additional questions: > > > > 1. Would the consolidation to a monorepo take place on top of > > the existing root repository or be an entirely new Mercurial > > repository? I've been trying to recall from the jdk10 transition, > > but can't remember. Either way, the change for developers should > > just be a one-time switch to the repository and the process > > of submitting patches remains exactly the same as it is now, > > except everything is from the one repository. > No, it's a new repository. In the case of the OpenJDK 8u consolidation, > it will be based on the existing JDK 10 consolidated repository and > share history up until jdk8-b120, where the history started to diverge > in the original repositories. The change for developers should be > minimal as you say. The guarantee we give is that each promotion tag is > equivalent between the monorepo and the forest. That makes sense. In the worst case, I assume the original forest will still be available for reference. One of the reasons I suggest the rampdown for the consolidation is we should be able to just do the process once for 8u, and then 8u-dev can just be a duplicate that diverges afterwards. I presume once the hg monorepos are there, we can have read-only git mirrors which will eventually become the live repos? > > 2. Is the consolidated repository expected to be identical > > to a fully-checked out copy of the forest (i.e. the root > > repository with each subrepo as a top-level subdirectory). > > I know some files moved with jdk10, but I think we'd want > > everything to stay the same with 8u. > Yes, the file layout is identical. We have no plans to rearrange things > for 8u. You may want to do some cleanup afterwards, like removing the > hgforest.sh/get_source.sh scripts that are no longer useful and remove > the no longer used .hgtags files from old nested repo directories. That's good to hear. Yes, having just been looking through the 11.0.13 changes, I see quite a few alterations to adapt to using git in build instructions, testing, etc. I expect we'll want to do similar over the 8u322 & 8u332 lifecycles. > > 3. As mentioned in another reply, could Skara's backport > > command be adapted to "shuffle" the paths to fit the > > 8u layout? This may be quite tricky as currently it > > requires both the 10u->9u conversion and the 9u->8u > > conversion, but without this, the backport command > > is effectively unusable and they all would have to > > be performed manually. > I can see this being a very useful feature, but also a non trivial > effort to implement. I can't say at this time if I would personally be > able to allocate time for this. Ok, I was thinking it might be quite difficult, especially as it needs to adapt over time to changes being made in the different repos. Developers should be used to doing it themselves by now anyway ;-) > > 4. Could Skara be adapted to enforce the jdk8u-fix-yes / > > jdk8u-critical-yes JIRA labels so the change can't be pushed until it > > has been approved? > > This sounds like a rather simple feature in comparison. Please file an > enhancement request for SKARA. > Oh, excellent, will do. > /Erik > Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Oct 12 23:25:45 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Oct 2021 00:25:45 +0100 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: On 15:13 Tue 12 Oct , erik.joelsson at oracle.com wrote: > > On 2021-10-01 06:22, erik.joelsson at oracle.com wrote: > >> Having discussed this at length with Severin, I propose the following > >> timetable: > >> > >> 1. End of November 2021 (Rampdown of 8u322 / Start of 8u332 Development) > >> > >> * Convert 8u & 8u-dev to Mercurial mono repositories. > >> Given they should be identical at this point, it should be possible to > >> do one conversion of 8u, provide copies at both 8u and 8u-dev, and > >> then let each copy diverge. > >> > >> * Create live read-only mirrors of 8u & 8u-dev in git > >> > >> 2. End of February 2022 (Rampdown of 8u332 / Start of 8u342 Development) > >> > >> * 8u-dev development switches to Git & Skara, with the previous > >> read-only > >> git mirror being used directly. > >> * 8u remains on Mercurial for the release of 8u332.? 8u can be synced > >> to 8u-dev from the 8u git mirror. > >> > >> 3. April 2022 (Release of 8u332) > >> > >> * 8u git is used directly for promotions of 8u342. > >> > >> I think this provides the best balance of risk, while also allowing 8u > >> to be consumed from git within the next few months. > > I think this plan looks reasonable, but I will need to check > > internally before I can give a final go ahead. Could you narrow down > > the potential cut over windows to date ranges? > > > We think this timetable is good. I have filed [1] for the first step. We > need to decide on: > Great news! > 1. Cutoff date > As I just mentioned in replying to your last mail, for the monorepo conversion, I would say the week beginning Monday, November 29th 2021. Rampdown is due to happen the Friday before: https://wiki.openjdk.java.net/display/jdk8u/Main > 2. New URL/name for https://hg.openjdk.java.net/jdk8u/jdk8u > > 3. New URL/name for https://hg.openjdk.java.net/jdk8u/jdk8u-dev > Assuming the git versions can be different again and retain the jdk8u & jdk8u-dev names for consistency with later versions (i.e. github.com/openjdk/jdk8u & github.com/openjdk/jdk8u-dev), I would suggest just using a "mono" prefix i.e. jdk8u/monojdk8u & jdk8u/monojdk8u-dev as these are only going to be in active use for <6 months. But I'm open to better suggestions :-) > /Erik > > [1] https://bugs.openjdk.java.net/browse/SKARA-1214 > Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akashche at redhat.com Wed Oct 13 07:42:37 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 13 Oct 2021 08:42:37 +0100 Subject: [8u] RFR: 8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs Message-ID: Hi, Please review the backport of JDK-8220150 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8220150 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/a57d3822c2fa 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8220150/webrev.00/ Patch does not apply cleanly: change to FontUtilities.java (contains multiple updates that are not in 8u) is adjusted, change to ProblemList.txt is excluded (was added in JDK-8238721), paths reshuffled. Testing: checked that RenderToCustomBufferTest fails without the patch and passes with the patch. -- -Alex From akashche at redhat.com Wed Oct 13 09:21:57 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 13 Oct 2021 10:21:57 +0100 Subject: [8u] RFR: 8258373: Update the text handling in the JPasswordField Message-ID: Hi, Please review a backport of JDK-8258373 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8258373 Mainline commit: https://github.com/openjdk/jdk/commit/7afb01dce966e4c00880711ef232af12af755b3a 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8258373/webrev.00/ Patch does not apply cleanly, changes besides paths reshuffling: In JPasswordField::setText @BeanProperty is changed to @beaninfo; description is preserved, but bound=false flag is excluded because the same method in parent class does not have this flag (added in JDK-4763438). It is not clear whether it may be better to add this flag to the parent class or alternatively exclude all @beaninfo changes. In tests String::repeat usage is replaced with Collections::nCopies. TextBeanProperty test is excluded, it won't pass in 8u without additional @beaninfo changes. Testing: checked that added tests pass. -- -Alex From zgu at redhat.com Wed Oct 13 12:01:46 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 13 Oct 2021 08:01:46 -0400 Subject: [8u] RFR: 8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs In-Reply-To: References: Message-ID: <097fd5a8-747a-8388-321e-7fe40b48459f@redhat.com> Looks good to me. -Zhengyu On 10/13/21 03:42, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8220150 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220150 > > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/a57d3822c2fa > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8220150/webrev.00/ > > Patch does not apply cleanly: change to FontUtilities.java (contains > multiple updates that are not in 8u) is adjusted, change to > ProblemList.txt is excluded (was added in JDK-8238721), paths > reshuffled. > > Testing: checked that RenderToCustomBufferTest fails without the patch > and passes with the patch. > From erik.joelsson at oracle.com Wed Oct 13 12:52:56 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 13 Oct 2021 05:52:56 -0700 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: On 2021-10-12 16:13, Andrew Hughes wrote: > On 06:22 Fri 01 Oct , erik.joelsson at oracle.com wrote: >> I think this plan looks reasonable, but I will need to check internally >> before I can give a final go ahead. Could you narrow down the potential >> cut over windows to date ranges? > Certainly. > > 1. The monorepo transition and creation of live read-only git mirrors > would be after the rampdown of 8u322, which is scheduled for Friday, > November the 26th, 2021. So I would expect the transition to begin on > the week beginning Monday, November the 29th, 2021. One of the > reasons we chose this particular period for what is expected to be the > most involved work is that the December period is usually quiet, as > many people ramp down themselves for the holiday period. So a delay > should be less problematic than at other times. > > 2. The 8u-dev git repo should go live the week beginning Monday, > February 28th, 2022, following rampdown on Friday the 25th. > Technically, this should hopefully just mean making the repository > writable. The main issue is in adjusting our processes to using > git and Skara. > > 3. The 8u git repo should go live after the 8u332 release is pushed, > on Tuesday, April the 19th 2022. As 8u is only used at this point > for the build promotions I'm making, a delay here doesn't > directly affect developers; it would just mean a later build promotion. > > I've updated the 8u wiki with the 8u322 & 8u332 schedules as well: > > https://wiki.openjdk.java.net/display/jdk8u/Main Thanks, updating my calendar. >> Yes, the consolidation is the trickiest part with the most amount of >> unknowns that could potentially delay things. I do believe I have it >> under control however. You can look at the current prototype here: >> >> https://hg.openjdk.java.net/jdk8u/consol-proto/ >> > Thanks. Are the commits from duke usual? The one for 8u312-b05 > particularly catches my attention, as I'd expect several tags > from myself, as with b04, instead. Yes, this is (unfortunately) normal. The original tag commits are transplanted over to the mono repo, but they are no longer actual tag commits as they refer to .hgtags files that are no longer actual .hgtags files. The actual new tags are created at consolidation time and I use the user "duke" to create them (just as "duke" is also performing all the merges that need to be done). For every tag except the very last one, the original tag commits are included in the mono repo, as they are part of the changes for the next tag. For the very last tag however, the current logic does not include them. At least for the prototype, doing so would invalidate (or at least complicate) the ability to incrementally continue the consolidation with new changes. In theory, I could convert them at the very end as a special case, but I don't think it's really worth it. The same thing happened in the JDK 10 consolidation. > That makes sense. In the worst case, I assume the original forest will > still be available for reference. > > One of the reasons I suggest the rampdown for the consolidation is we > should be able to just do the process once for 8u, and then 8u-dev can > just be a duplicate that diverges afterwards. > > I presume once the hg monorepos are there, we can have read-only git > mirrors which will eventually become the live repos? Yes, all correct. The old forests will be around as read-only references for a very long time. There are a lot of deep links in JBS for example pointing into repositories. Doing the consolidation at a point where 8u and 8u-dev are equivalent definitely helps. Git mirrors will be up very soon after the consolidation. >> Yes, the file layout is identical. We have no plans to rearrange things >> for 8u. You may want to do some cleanup afterwards, like removing the >> hgforest.sh/get_source.sh scripts that are no longer useful and remove >> the no longer used .hgtags files from old nested repo directories. > That's good to hear. Yes, having just been looking through the 11.0.13 > changes, I see quite a few alterations to adapt to using git in > build instructions, testing, etc. I expect we'll want to do similar > over the 8u322 & 8u332 lifecycles. There is also a bit of build logic in there to record the state of the HG forest into the release file that needed to be adapted to git. >>> 4. Could Skara be adapted to enforce the jdk8u-fix-yes / >>> jdk8u-critical-yes JIRA labels so the change can't be pushed until it >>> has been approved? >> This sounds like a rather simple feature in comparison. Please file an >> enhancement request for SKARA. >> > Oh, excellent, will do. > I believe Christoph beat you to it. See SKARA-1199. /Erik From akashche at redhat.com Wed Oct 13 15:24:32 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 13 Oct 2021 16:24:32 +0100 Subject: [8u] RFR: 8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs In-Reply-To: <097fd5a8-747a-8388-321e-7fe40b48459f@redhat.com> References: <097fd5a8-747a-8388-321e-7fe40b48459f@redhat.com> Message-ID: On 10/13/21, Zhengyu Gu wrote: > Looks good to me. Thanks for the review! I've marked the bug for approval. > > -Zhengyu > > On 10/13/21 03:42, Alex Kashchenko wrote: >> Hi, >> >> Please review the backport of JDK-8220150 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220150 >> >> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/a57d3822c2fa >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8220150/webrev.00/ >> >> Patch does not apply cleanly: change to FontUtilities.java (contains >> multiple updates that are not in 8u) is adjusted, change to >> ProblemList.txt is excluded (was added in JDK-8238721), paths >> reshuffled. >> >> Testing: checked that RenderToCustomBufferTest fails without the patch >> and passes with the patch. >> > > -- -Alex From bylokhov at amazon.com Wed Oct 13 22:46:26 2021 From: bylokhov at amazon.com (Sergey Bylokhov) Date: Wed, 13 Oct 2021 15:46:26 -0700 Subject: [8u] RFR: 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: References: <786c84fb-d042-514d-a797-57f90663c94b@amazon.com> <7477efbf-23fb-3d16-4d91-9f9618019011@amazon.com> Message-ID: <4cec5a8e-5eb2-3dbd-763d-a4009a608f55@amazon.com> On 10/11/21 3:49 AM, Alex Kashchenko wrote: >> Am not sure that the list of fixes above is complete. > > Besides 8248532 I can see 8257242 (that is also backported to 15, 13 > and 11). I've checked that it can be applied to 8u, just it also > depends on a header change from 8234786. I assume 8257242 should go > into 8u too if 8214578 is approved. > > > PS: if someone with a deep knowledge in this area thinks that 8214578 > is too dangerous for 8u, it may be better to explicitly mark it with > "8u-rejected" or something similar. I'll take a look probably next week. -- Best regards, Sergey. From akashche at redhat.com Thu Oct 14 13:11:33 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 14 Oct 2021 14:11:33 +0100 Subject: [8u] RFR: 8196572: [TESTBUG] Test sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java sun/java2d/cmm/ColorConvertOp/MTColConvTest.java fails Message-ID: Hi, Please review a backport of JDK-8196572: Bug: https://bugs.openjdk.java.net/browse/JDK-8196572 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/3a384c83c756 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8196572/webrev.00/ Besides the path adjustment, change to ProblemList is excluded - it was added by JDK-8202301 that is not in 8u. Testing: checked on Linux, Windows and Mac that ColConvCCMTest test fails without the patch and passes with the patch. -- -Alex From zgu at redhat.com Thu Oct 14 13:17:06 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 14 Oct 2021 09:17:06 -0400 Subject: [8u] RFR: 8196572: [TESTBUG] Test sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java sun/java2d/cmm/ColorConvertOp/MTColConvTest.java fails In-Reply-To: References: Message-ID: LGTM. -Zhengyu On 10/14/21 09:11, Alex Kashchenko wrote: > Hi, > > Please review a backport of JDK-8196572: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196572 > > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/3a384c83c756 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8196572/webrev.00/ > > Besides the path adjustment, change to ProblemList is excluded - it > was added by JDK-8202301 that is not in 8u. > > Testing: checked on Linux, Windows and Mac that ColConvCCMTest test > fails without the patch and passes with the patch. > From akashche at redhat.com Thu Oct 14 13:42:27 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 14 Oct 2021 14:42:27 +0100 Subject: [8u] RFR: 8148915: Intermittent failures of bug6400879.java Message-ID: Hi, Please review a backport of JDK-8148915: Bug: https://bugs.openjdk.java.net/browse/JDK-8148915 Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7b4de9e4c16b 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8148915/webrev.00/ Patch is test-only, change to the test itself applies cleanly. Change to ProblemList.txt was added in JDK-8153725 (that cannot be applied cleanly to 8u) and is excluded. Testing: checked that updated test passes on Linux, Windows and Mac. Was unable to reproduce the problem on Linux without the patch. -- -Alex From akashche at redhat.com Thu Oct 14 13:47:04 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 14 Oct 2021 14:47:04 +0100 Subject: [8u] RFR: 8196572: [TESTBUG] Test sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java sun/java2d/cmm/ColorConvertOp/MTColConvTest.java fails In-Reply-To: References: Message-ID: On 10/14/21, Zhengyu Gu wrote: > LGTM. Thanks for the review! I've marked the bug for approval. > > -Zhengyu > > On 10/14/21 09:11, Alex Kashchenko wrote: >> Hi, >> >> Please review a backport of JDK-8196572: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196572 >> >> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/3a384c83c756 >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8196572/webrev.00/ >> >> Besides the path adjustment, change to ProblemList is excluded - it >> was added by JDK-8202301 that is not in 8u. >> >> Testing: checked on Linux, Windows and Mac that ColConvCCMTest test >> fails without the patch and passes with the patch. >> > > -- -Alex From zgu at redhat.com Thu Oct 14 13:58:22 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 14 Oct 2021 09:58:22 -0400 Subject: [8u] RFR: 8148915: Intermittent failures of bug6400879.java In-Reply-To: References: Message-ID: LGTM. -Zhengyu On 10/14/21 09:42, Alex Kashchenko wrote: > Hi, > > Please review a backport of JDK-8148915: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148915 > > Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7b4de9e4c16b > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8148915/webrev.00/ > > Patch is test-only, change to the test itself applies cleanly. Change > to ProblemList.txt was added in JDK-8153725 (that cannot be applied > cleanly to 8u) and is excluded. > > Testing: checked that updated test passes on Linux, Windows and Mac. > Was unable to reproduce the problem on Linux without the patch. > From akashche at redhat.com Thu Oct 14 14:45:25 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 14 Oct 2021 15:45:25 +0100 Subject: [8u] RFR: 8148915: Intermittent failures of bug6400879.java In-Reply-To: References: Message-ID: On 10/14/21, Zhengyu Gu wrote: > LGTM. Thanks for the review! I've marked the bug for approval. > > -Zhengyu > > On 10/14/21 09:42, Alex Kashchenko wrote: >> Hi, >> >> Please review a backport of JDK-8148915: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148915 >> >> Original commit: >> https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7b4de9e4c16b >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8148915/webrev.00/ >> >> Patch is test-only, change to the test itself applies cleanly. Change >> to ProblemList.txt was added in JDK-8153725 (that cannot be applied >> cleanly to 8u) and is excluded. >> >> Testing: checked that updated test passes on Linux, Windows and Mac. >> Was unable to reproduce the problem on Linux without the patch. >> > > -- -Alex From hohensee at amazon.com Fri Oct 15 18:55:49 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 18:55:49 +0000 Subject: [8u] RFR: 8162572: Update License Header for all JAXP sources Message-ID: DTMConfigurationException.java, all the dom3 files, xml/internal/utils/DOMOrder.java, xml/internal/serializer/utils/DOM2Helper.java, and xml/internal/serializer/utils/AttList.java aren't in the webrev or in jdk8u, but I guess that means they've been resolved manually. Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Friday, October 8, 2021 at 4:41 AM To: jdk8u-dev Subject: [8u] RFR: 8162572: Update License Header for all JAXP sources Hi, Please review a backport of JDK-8162572: Bug (not public): https://bugs.openjdk.java.net/browse/JDK-8162572 Original commit: https://hg.openjdk.java.net/jdk10/jdk10/jaxp/rev/2fdbfbde3bc0 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8162572/webrev.00/ This change can make it easier to backport subsequent JAXP parity issues to 8u. There are no code changes, only copyright headers are changed. Majority of the files apply cleanly, the following files were resolved manually: src/com/sun/org/apache/xalan/internal/lib/Extensions.java src/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java src/com/sun/org/apache/xml/internal/dtm/DTMConfigurationException.java src/com/sun/org/apache/xml/internal/dtm/DTMException.java src/com/sun/org/apache/xml/internal/dtm/DTMManager.java src/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOM3SerializerImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorHandlerImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMLocatorImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMOutputImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/DOMStringListImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java src/com/sun/org/apache/xml/internal/serializer/dom3/NamespaceSupport.java src/com/sun/org/apache/xml/internal/serializer/utils/AttList.java src/com/sun/org/apache/xml/internal/serializer/utils/DOM2Helper.java src/com/sun/org/apache/xml/internal/utils/DOMOrder.java src/com/sun/org/apache/xpath/internal/XPath.java src/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java src/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java -- -Alex From akashche at redhat.com Fri Oct 15 19:53:42 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 15 Oct 2021 20:53:42 +0100 Subject: [8u] RFR: 8162572: Update License Header for all JAXP sources In-Reply-To: References: Message-ID: On 10/15/21, Hohensee, Paul wrote: > DTMConfigurationException.java, all the dom3 files, > xml/internal/utils/DOMOrder.java, > xml/internal/serializer/utils/DOM2Helper.java, and > xml/internal/serializer/utils/AttList.java aren't in the webrev or in jdk8u, > but I guess that means they've been resolved manually. Yes, changes to all files listed above were removed from the patch manually. > > Lgtm. Thanks for the review! Bug is not public, so I will send the RFA to the list instead. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Alex > Kashchenko > Date: Friday, October 8, 2021 at 4:41 AM > To: jdk8u-dev > Subject: [8u] RFR: 8162572: Update License Header for all JAXP sources > > Hi, > > Please review a backport of JDK-8162572: > > Bug (not public): https://bugs.openjdk.java.net/browse/JDK-8162572 > > Original commit: > https://hg.openjdk.java.net/jdk10/jdk10/jaxp/rev/2fdbfbde3bc0 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8162572/webrev.00/ > > This change can make it easier to backport subsequent JAXP parity > issues to 8u. There are no code changes, only copyright headers are > changed. Majority of the files apply cleanly, the following files were > resolved manually: > > src/com/sun/org/apache/xalan/internal/lib/Extensions.java > src/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java > src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java > src/com/sun/org/apache/xml/internal/dtm/DTMConfigurationException.java > src/com/sun/org/apache/xml/internal/dtm/DTMException.java > src/com/sun/org/apache/xml/internal/dtm/DTMManager.java > src/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java > src/com/sun/org/apache/xml/internal/serializer/dom3/DOM3SerializerImpl.java > src/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java > src/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorHandlerImpl.java > src/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorImpl.java > src/com/sun/org/apache/xml/internal/serializer/dom3/DOMLocatorImpl.java > src/com/sun/org/apache/xml/internal/serializer/dom3/DOMOutputImpl.java > src/com/sun/org/apache/xml/internal/serializer/dom3/DOMStringListImpl.java > src/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java > src/com/sun/org/apache/xml/internal/serializer/dom3/NamespaceSupport.java > src/com/sun/org/apache/xml/internal/serializer/utils/AttList.java > src/com/sun/org/apache/xml/internal/serializer/utils/DOM2Helper.java > src/com/sun/org/apache/xml/internal/utils/DOMOrder.java > src/com/sun/org/apache/xpath/internal/XPath.java > src/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java > src/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java > > -- > -Alex > > > -- -Alex From akashche at redhat.com Fri Oct 15 19:54:40 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 15 Oct 2021 20:54:40 +0100 Subject: [8u] RFA: 8162572: Update License Header for all JAXP sources Message-ID: Hi, JDK-8162572 is not public, so requesting the approval here: Fix request (8u) Backport is requested because it can make it easier to backport subsequent JAXP parity issues to 8u (don't have a comprehensive list, intend to proceed with JDK-8163121 first). Review approval: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014353.html -- -Alex From hohensee at amazon.com Fri Oct 15 20:39:47 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 20:39:47 +0000 Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created Message-ID: <967A142B-ED73-4F79-9506-8E7DAAC4AF0C@amazon.com> In attachListener.hpp, the AttachListenerState enum's underlying type will be int, so casting to jlong for the atomic operations will clobber whatever is beyond _state, and won't work at all on big-endian machines. C++11 adds enum base type specification, but we can't use C++11 features in 8u. I would define const int AL_* values and declare _state to be an int. I'm leery of disabling the test. Please see if you can backport 8165500, which introduced LingeredApp. You have code from 8237499 in the patch which has already been backported. Please remove it. Also, please post review requests for 8227815 and 8227738 backports, with the intent to push all three at once. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Yi Yang Reply-To: Yi Yang Date: Friday, October 8, 2021 at 4:21 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created Hi, Can I have a review for this backport of JDK-8225690? Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02 Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953 Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/ VM can't be attached If someone cleans up the /tmp directory. This patch addresses the problem. It can not apply cleanly, some minor conflicts are as follows: 1. Atomic::store(new_state, &_state) jdk8u does not have templated Atomic function family, use explicitly type conversion `Atomic::store((jlong)new_state, (volatile jlong*)&_state)`. 2. IsRegisteredEnum jdk8u does not have metaprogramming type traits, `template<> struct IsRegisteredEnum : public TrueType {};` simply omit it. 3. os::naked_yield os::naked_yield is missing due to https://bugs.openjdk.java.net/browse/JDK-8047714, use os::yield instead. 4. log_debug(attach)("...") jdk8u does not have unified logging system. Use the following code: `debug_only(warning("..."))` 5. Test They can not work because of the usages of LingeredApp. Remove @test tag to disable them while keeping their source code. Test cases have been passed manually. The original issue has related bugs: https://bugs.openjdk.java.net/browse/JDK-8227815 https://bugs.openjdk.java.net/browse/JDK-8235211 https://bugs.openjdk.java.net/browse/JDK-8227738 I'd like to create follow-up backports(JDK-8227815 and JDK-8227738) once this merged. JDK-8235211 is not necessary since RemovingUnixDomainSocketTest.java will be ignored as I said before. Thanks! From hohensee at amazon.com Fri Oct 15 20:42:44 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 20:42:44 +0000 Subject: [8u] RFR: 8044365: (dc) MulticastSendReceiveTests.java failing with ENOMEM when joining group (OS X 10.9) Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Friday, October 8, 2021 at 3:12 AM To: jdk8u-dev Subject: [8u] RFR: 8044365: (dc) MulticastSendReceiveTests.java failing with ENOMEM when joining group (OS X 10.9) Hi, Please review the parity backport of JDK-8044365: Bug: https://bugs.openjdk.java.net/browse/JDK-8044365 Original commit: https://hg.openjdk.java.net/jdk-updates/jdk14u/rev/591e3b2374db 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8044365/webrev.00/ 8u specific changes are only to path and copyright header. Testing: ran jtreg:java/nio/channels/DatagramChannel on Mac. -- -Alex From hohensee at amazon.com Fri Oct 15 21:01:38 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 21:01:38 +0000 Subject: [8u] RFR: 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings Message-ID: <479DA1C8-08FE-437E-A23C-1772DA5DE9A3@amazon.com> I'm don't have deep area knowledge, but all 4 backports, including 8214578, look good to me. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Sergey Bylokhov Date: Wednesday, October 13, 2021 at 3:47 PM To: Alex Kashchenko Cc: jdk8u-dev Subject: Re: [8u] RFR: 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings On 10/11/21 3:49 AM, Alex Kashchenko wrote: >> Am not sure that the list of fixes above is complete. > > Besides 8248532 I can see 8257242 (that is also backported to 15, 13 > and 11). I've checked that it can be applied to 8u, just it also > depends on a header change from 8234786. I assume 8257242 should go > into 8u too if 8214578 is approved. > > > PS: if someone with a deep knowledge in this area thinks that 8214578 > is too dangerous for 8u, it may be better to explicitly mark it with > "8u-rejected" or something similar. I'll take a look probably next week. -- Best regards, Sergey. From hohensee at amazon.com Fri Oct 15 21:05:27 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 21:05:27 +0000 Subject: [8u] RFR: 8196572: [TESTBUG] Test sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java sun/java2d/cmm/ColorConvertOp/MTColConvTest.java fails Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Thursday, October 14, 2021 at 6:20 AM To: jdk8u-dev Subject: [8u] RFR: 8196572: [TESTBUG] Test sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java sun/java2d/cmm/ColorConvertOp/MTColConvTest.java fails Hi, Please review a backport of JDK-8196572: Bug: https://bugs.openjdk.java.net/browse/JDK-8196572 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/3a384c83c756 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8196572/webrev.00/ Besides the path adjustment, change to ProblemList is excluded - it was added by JDK-8202301 that is not in 8u. Testing: checked on Linux, Windows and Mac that ColConvCCMTest test fails without the patch and passes with the patch. -- -Alex From hohensee at amazon.com Fri Oct 15 21:23:57 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 21:23:57 +0000 Subject: [8u] RFR: 8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS Message-ID: <606F36F7-B162-46C9-915B-D029077FD1D5@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Wednesday, October 6, 2021 at 3:01 AM To: jdk8u-dev Subject: [8u] RFR: 8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS Hi, Please review a parity backport of JDK-8066652: Bug: https://bugs.openjdk.java.net/browse/JDK-8066652 Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/17a073876794 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8066652/webrev.00/ Only 8u-specific change is that copyright year hunk is skipped. Testing: checked that added test fails on Mac without the patch and passes with the patch. Ran jtreg:java/util/TimeZone on Mac and Linux. -- -Alex From hohensee at amazon.com Fri Oct 15 21:30:17 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 21:30:17 +0000 Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride Message-ID: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Zhengyu Gu Date: Tuesday, October 5, 2021 at 8:12 AM To: jdk8u-dev Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride This backport is for parity with Oracle 8u321. Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 The original patch does not apply cleanly. There is not newThread(String name, Runnable target) method in 8u, so discard this part of change. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ Thanks, -Zhengyu From hohensee at amazon.com Fri Oct 15 21:35:02 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 21:35:02 +0000 Subject: [8u] RFR: 8140329: [TEST_BUG] test FullScreenAfterSplash.java failed because image was not generated Message-ID: <6BB7BAA1-CD0A-471B-83A9-E6C1E59804E4@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Tuesday, October 5, 2021 at 4:28 AM To: jdk8u-dev Subject: [8u] RFR: 8140329: [TEST_BUG] test FullScreenAfterSplash.java failed because image was not generated Hi, Please review a parity backport of JDK-8140329: Bug: https://bugs.openjdk.java.net/browse/JDK-8140329 Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/502905f8b0aa 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8140329/webrev.00/ FullScreenAfterSplash.java has required minor adjustments to copyright year and imports because of JDK-8076468 and 8074092 changes that are not in 8u. Testing: checked that the test fails without the patch and passes with the patch. -- -Alex From hohensee at amazon.com Fri Oct 15 21:39:51 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 21:39:51 +0000 Subject: [8u] RFR: 8148915: Intermittent failures of bug6400879.java Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Thursday, October 14, 2021 at 6:43 AM To: jdk8u-dev Subject: [8u] RFR: 8148915: Intermittent failures of bug6400879.java Hi, Please review a backport of JDK-8148915: Bug: https://bugs.openjdk.java.net/browse/JDK-8148915 Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7b4de9e4c16b 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8148915/webrev.00/ Patch is test-only, change to the test itself applies cleanly. Change to ProblemList.txt was added in JDK-8153725 (that cannot be applied cleanly to 8u) and is excluded. Testing: checked that updated test passes on Linux, Windows and Mac. Was unable to reproduce the problem on Linux without the patch. -- -Alex From hohensee at amazon.com Fri Oct 15 21:51:26 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 21:51:26 +0000 Subject: [8u] RFR: 8231254: (fs) Add test for macOS Catalina changes to protect system software Message-ID: <7AE5094B-56AC-4421-BF77-2D67F76FD12A@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Monday, October 4, 2021 at 3:17 PM To: jdk8u-dev Subject: [8u] RFR: 8231254: (fs) Add test for macOS Catalina changes to protect system software Hi, Please review the parity backport of JDK-8231254: Bug: https://bugs.openjdk.java.net/browse/JDK-8231254 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/1e57d3774190 8 webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8231254/webrev.00/ 8u changes: removed "jdk" prefix from file path, Path.of() replaced with Paths.get(). This backport only adds a new test, I've checked that it can be run on Mac and intend to follow up with JDK-8232178 backport. -- -Alex From hohensee at amazon.com Fri Oct 15 21:56:48 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Oct 2021 21:56:48 +0000 Subject: [8u] RFR: 8274595: DisableRMIOverHTTPTest failed: connection refused Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alexey Bakhtin Date: Thursday, September 30, 2021 at 7:17 AM To: jdk8u-dev Subject: [8u] RFR: 8274595: DisableRMIOverHTTPTest failed: connection refused Hi, Please review the trivial change to sun/rmi/transport/tcp/DisableRMIOverHttp/DisableRMIOverHTTPTest.java: Bug: https://bugs.openjdk.java.net/browse/JDK-8274595 Webrev: http://cr.openjdk.java.net/~abakhtin/8274595/webrev.v0/ The test fails because of URLConnection behaviour changes caused by JDK-8161016 [1] Initially, the test was created on the base of BlockAcceptTest.java. Unlike BlockAcceptTest, DisableRMIOverHTTPTest does not use http proxy functionality but sets proxy via "http.proxyHost" system property. HttpURLConnection in the JDK8u302 fallbacks to the direct connection in case of connection via proxy fails. As result, this test were passed using direct connection JDK-8161016 changes the behavior of the HttpURLConnection: no fallback to the direct connection. As result, DisableRMIOverHTTPTest fails because of can no connection via dummy proxy. Regards Alexey [1] - https://bugs.openjdk.java.net/browse/JDK-8161016 From akashche at redhat.com Sat Oct 16 19:35:00 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Sat, 16 Oct 2021 20:35:00 +0100 Subject: [8u] RFR: 8140329: [TEST_BUG] test FullScreenAfterSplash.java failed because image was not generated In-Reply-To: <6BB7BAA1-CD0A-471B-83A9-E6C1E59804E4@amazon.com> References: <6BB7BAA1-CD0A-471B-83A9-E6C1E59804E4@amazon.com> Message-ID: On 10/15/21, Hohensee, Paul wrote: > Lgtm. Thanks for this and other reviews! I've marked the issue for approval. Besides it the following issues were also marked: 8044365, 8066652, 8148915, 8196572. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Alex > Kashchenko > Date: Tuesday, October 5, 2021 at 4:28 AM > To: jdk8u-dev > Subject: [8u] RFR: 8140329: [TEST_BUG] test FullScreenAfterSplash.java > failed because image was not generated > > Hi, > > Please review a parity backport of JDK-8140329: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140329 > > Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/502905f8b0aa > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8140329/webrev.00/ > > FullScreenAfterSplash.java has required minor adjustments to copyright > year and imports because of JDK-8076468 and 8074092 changes that are > not in 8u. > > Testing: checked that the test fails without the patch and passes with > the patch. > > -- > -Alex > > > -- -Alex From zgu at redhat.com Sat Oct 16 23:39:12 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Sat, 16 Oct 2021 19:39:12 -0400 Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride In-Reply-To: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> References: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> Message-ID: Thanks, Paul -Zhengyu On 10/15/21 17:30, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Tuesday, October 5, 2021 at 8:12 AM > To: jdk8u-dev > Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride > > This backport is for parity with Oracle 8u321. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 > Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 > > The original patch does not apply cleanly. There is not newThread(String > name, Runnable target) method in 8u, so discard this part of change. > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ > > > Thanks, > > -Zhengyu > > From akashche at redhat.com Mon Oct 18 14:51:58 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 18 Oct 2021 15:51:58 +0100 Subject: [8u] RFR: 8232178: MacVolumesTest failed after upgrade to MacOS Catalina Message-ID: Hi, Please review this small test-only backport: Bug: https://bugs.openjdk.java.net/browse/JDK-8232178 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/19744a63c295 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8232178/webrev.00/ Patch needs to be applied on top of JDK-8231254, that was recently reviewed and intended to be pushed along with this one. 8u adjustments are to paths and changing Path.of to Paths.get. Testing: checked that updated test passes on macOS 10.15 . -- -Alex From akashche at redhat.com Mon Oct 18 14:55:00 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 18 Oct 2021 15:55:00 +0100 Subject: [8u] RFR: 8231254: (fs) Add test for macOS Catalina changes to protect system software In-Reply-To: <7AE5094B-56AC-4421-BF77-2D67F76FD12A@amazon.com> References: <7AE5094B-56AC-4421-BF77-2D67F76FD12A@amazon.com> Message-ID: On 10/15/21, Hohensee, Paul wrote: > Lgtm. Thanks for the review! I've marked the bug for approval and posted the follow-up 8232178 for review. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Alex > Kashchenko > Date: Monday, October 4, 2021 at 3:17 PM > To: jdk8u-dev > Subject: [8u] RFR: 8231254: (fs) Add test for macOS Catalina changes to > protect system software > > Hi, > > Please review the parity backport of JDK-8231254: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231254 > > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/1e57d3774190 > > 8 webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8231254/webrev.00/ > > 8u changes: removed "jdk" prefix from file path, Path.of() replaced > with Paths.get(). > > This backport only adds a new test, I've checked that it can be run on > Mac and intend to follow up with JDK-8232178 backport. > > -- > -Alex > > > -- -Alex From hohensee at amazon.com Mon Oct 18 23:35:59 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 18 Oct 2021 23:35:59 +0000 Subject: [8u] RFR: 8232178: MacVolumesTest failed after upgrade to MacOS Catalina Message-ID: <73075696-44B8-445E-9BAA-C80990A1B25F@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Monday, October 18, 2021 at 7:52 AM To: jdk8u-dev Subject: [8u] RFR: 8232178: MacVolumesTest failed after upgrade to MacOS Catalina Hi, Please review this small test-only backport: Bug: https://bugs.openjdk.java.net/browse/JDK-8232178 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/19744a63c295 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8232178/webrev.00/ Patch needs to be applied on top of JDK-8231254, that was recently reviewed and intended to be pushed along with this one. 8u adjustments are to paths and changing Path.of to Paths.get. Testing: checked that updated test passes on macOS 10.15 . -- -Alex From akashche at redhat.com Tue Oct 19 08:45:45 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 19 Oct 2021 09:45:45 +0100 Subject: [8u] RFR: 8232178: MacVolumesTest failed after upgrade to MacOS Catalina In-Reply-To: <73075696-44B8-445E-9BAA-C80990A1B25F@amazon.com> References: <73075696-44B8-445E-9BAA-C80990A1B25F@amazon.com> Message-ID: On 10/19/21, Hohensee, Paul wrote: > Lgtm. Thanks for the review! I've marked the bug for approval. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Alex > Kashchenko > Date: Monday, October 18, 2021 at 7:52 AM > To: jdk8u-dev > Subject: [8u] RFR: 8232178: MacVolumesTest failed after upgrade to MacOS > Catalina > > Hi, > > Please review this small test-only backport: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232178 > > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/19744a63c295 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8232178/webrev.00/ > > Patch needs to be applied on top of JDK-8231254, that was recently > reviewed and intended to be pushed along with this one. 8u adjustments > are to paths and changing Path.of to Paths.get. > > Testing: checked that updated test passes on macOS 10.15 . > > -- > -Alex > > > -- -Alex From akashche at redhat.com Tue Oct 19 13:08:42 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 19 Oct 2021 14:08:42 +0100 Subject: [8u] RFR: 8048021: Remove @version tag in jaxp repo Message-ID: Hi, Please review the backport of JDK-8048021 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8048021 Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/01c25780f33f 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8048021/webrev.00/ This change can make it easier to backport subsequent JAXP parity issues to 8u. There are no code changes, all changes are to comments. The following files were resolved manually: src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java src/com/sun/org/apache/xerces/internal/util/EncodingMap.java src/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java src/javax/xml/parsers/DocumentBuilderFactory.java src/javax/xml/parsers/FactoryConfigurationError.java src/javax/xml/parsers/SAXParserFactory.java -- -Alex From gnu.andrew at redhat.com Wed Oct 20 04:24:40 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Oct 2021 05:24:40 +0100 Subject: OpenJDK 8u312 Released Message-ID: <20211020042440.GA558487@rincewind> We are pleased to announce the release of OpenJDK 8u312. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u312-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u312-ga.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 62173a8233397088101b97c4175831120550124b24ae03d79721498e0d5a355b openjdk8u312-ga.tar.xz 82b1b4683eff4cab6779671457017feee24a36b57371b943ba282bcb50d3a681 openjdk8u312-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u312-ga.sha256 New in release OpenJDK 8u312 (2021-10-19): =========================================== Live versions of these release notes can be found at: * https://bitly.com/openjdk8u312 * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u312.txt * Security fixes - JDK-8130183, CVE-2021-35588: InnerClasses: VM permits wrong Throw ClassFormatError if InnerClasses attribute's inner_class_info_index is 0 - JDK-8161016: Strange behavior of URLConnection with proxy - JDK-8163326, CVE-2021-35550: Update the default enabled cipher suites preference - JDK-8254967, CVE-2021-35565: com.sun.net.HttpsServer spins on TLS session close - JDK-8263314: Enhance XML Dsig modes - JDK-8265167, CVE-2021-35556: Richer Text Editors - JDK-8265574: Improve handling of sheets - JDK-8265580, CVE-2021-35559: Enhanced style for RTF kit - JDK-8265776: Improve Stream handling for SSL - JDK-8266097, CVE-2021-35561: Better hashing support - JDK-8266103: Better specified spec values - JDK-8266109: More Resilient Classloading - JDK-8266115: More Manifest Jar Loading - JDK-8266137, CVE-2021-35564: Improve Keystore integrity - JDK-8266689, CVE-2021-35567: More Constrained Delegation - JDK-8267086: ArrayIndexOutOfBoundsException in java.security.KeyFactory.generatePublic - JDK-8267712: Better LDAP reference processing - JDK-8267729, CVE-2021-35578: Improve TLS client handshaking - JDK-8267735, CVE-2021-35586: Better BMP support - JDK-8268193: Improve requests of certificates - JDK-8268199: Correct certificate requests - JDK-8268506: More Manifest Digests - JDK-8269618, CVE-2021-35603: Better session identification - JDK-8269624: Enhance method selection support - JDK-8270398: Enhance canonicalization - JDK-8270404: Better canonicalization * Other changes - JDK-6847157: java.lang.NullPointerException: HDC for component at sun.java2d.loops.Blit.Blit - JDK-7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection - JDK-7188942: Remove support of pbuffers in OGL Java2d pipeline - JDK-8004148: NPE in sun.awt.SunToolkit.getWindowDeactivationTime - JDK-8022323: [JavaSecurityScanner] review package com.sun.management.* Native methods should be private - JDK-8027154: [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails - JDK-8035001: TEST_BUG: the retry logic in RMID.start() should check that the subprocess hasn't terminated - JDK-8035424: (reflect) Performance problem in sun.reflect.generics.parser.SignatureParser - JDK-8042557: compiler/uncommontrap/TestSpecTrapClassUnloading.java fails with: GC triggered before VM initialization completed - JDK-8054118: java/net/ipv6tests/UdpTest.java failed intermittently - JDK-8065215: Print warning summary at end of configure - JDK-8072767: DefaultCellEditor for comboBox creates ActionEvent with wrong source object - JDK-8079891: Store configure log in $BUILD/configure.log - JDK-8080082: configure fails if you create an empty directory and then run configure from it - JDK-8086003: Test fails on OSX with java.lang.RuntimeException 'Narrow klass base: 0x0000000000000000, Narrow klass shift: 3' missing - JDK-8131062: aarch64: add support for GHASH acceleration - JDK-8134869: AARCH64: GHASH intrinsic is not optimal - JDK-8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address - JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get - JDK-8157404: Unable to read certain PKCS12 keystores from SequenceInputStream - JDK-8166673: The new implementation of Robot.waitForIdle() may hang - JDK-8170467: (reflect) Optimize SignatureParser's use of StringBuilders - JDK-8194246: JVM crashes when calling getStackTrace if stack contains a method that is a member of a very large class - JDK-8196181: sun/java2d/GdiRendering/InsetClipping.java fails - JDK-8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore - JDK-8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error - JDK-8214418: half-closed SSLEngine status may cause application dead loop - JDK-8214513: A PKCS12 keystore from Java 8 using custom PBE parameters cannot be read in Java 11 - JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr - JDK-8222751: closed/test/jdk/sun/security/util/DerIndefLenConverter/IndefBerPkcs12.java fail - JDK-8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 - JDK-8231222: fix pkcs11 P11_DEBUG guarded native traces - JDK-8237495: Java MIDI fails with a dereferenced memory error when asked to send a raw 0xF7 - JDK-8238567: SoftMainMixer.processAudioBuffers(): Wrong handling of stoppedMixers - JDK-8240518: Incorrect JNU_ReleaseStringPlatformChars in Windows Print - JDK-8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) - JDK-8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files - JDK-8247469: getSystemCpuLoad() returns -1 on linux when some offline cpus are present and cpusets.effective_cpus is not available - JDK-8248901: Signed immediate support in .../share/assembler.hpp is broken. - JDK-8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test - JDK-8262000: jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithParallelScavenge.java failed with "OutOfMemoryError: Java heap space" - JDK-8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() - JDK-8263311: Watch registry changes for remote printers update instead of polling - JDK-8263382: java/util/logging/ParentLoggersTest.java failed with "checkLoggers: getLoggerNames() returned unexpected loggers" - JDK-8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M - JDK-8265238: [8u] [macos] build failure in OpenJDK8u after JDK-8211301 in older xcode - JDK-8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container - JDK-8265978: make test should look for more locations when searching for exit code - JDK-8266206: Build failure after JDK-8264752 with older GCCs - JDK-8268103: JNI functions incorrectly return a double after JDK-8265836 - JDK-8268965: TCP Connection Reset when connecting simple socket to SSL server - JDK-8269594: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark - JDK-8269763: The JEditorPane is blank after JDK-8265167 - JDK-8269810: [8u] Update generated_configure.sh after JDK-8250876 backport - JDK-8269851: OperatingSystemMXBean getProcessCpuLoad reports incorrect process cpu usage in containers - JDK-8269859: BacktraceBuilder._cprefs needs to be accessed as unsigned short - JDK-8269882: stack-use-after-scope in NewObjectA - JDK-8269953: config.log is not in build directory after 8u backport of JDK-8079891 - JDK-8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup - JDK-8271466: StackGap test fails on aarch64 due to "-m64" - JDK-8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon - JDK-8272214: [8u] Build failure after backport of JDK-8248901 - JDK-8272714: [8u] Build failure after backport of JDK-8248901 with MSVC 2013 Notes on individual issues: =========================== core-libs/java.net: JDK-8164200: Modified HttpURLConnection behavior when no suitable proxy is found ================================================================================ The behavior of HttpURLConnection when using a ProxySelector has been modified with this JDK release. HttpURLConnection used to fall back to a DIRECT connection attempt if the configured proxy(s) failed to make a connection. This release introduces a change whereby no DIRECT connection will be attempted in such a scenario. Instead, the HttpURLConnection.connect() method will fail and throw an IOException which occurred from the last proxy tested. security-libs/javax.net.ssl: JDK-8219551: Updated the Default Enabled Cipher Suites Preference ================================================================= The preference of the default enabled cipher suites has been changed. The compatibility impact should be minimal. If needed, applications can customize the enabled cipher suites and the preference. For more details, refer to the SunJSSE provider documentation and the JSSE Reference Guide documentation. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From qingfeng.yy at alibaba-inc.com Thu Oct 21 08:08:16 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Thu, 21 Oct 2021 16:08:16 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSOiA4MjI1NjkwOiBNdWx0aXBsZSBBdHRhY2hMaXN0ZW5lciB0aHJlYWRz?= =?UTF-8?B?IGNhbiBiZSBjcmVhdGVk?= In-Reply-To: <967A142B-ED73-4F79-9506-8E7DAAC4AF0C@amazon.com> References: <967A142B-ED73-4F79-9506-8E7DAAC4AF0C@amazon.com> Message-ID: Hi Paul, Currently, Atomic::load only accepts jlong as a parameter, so I use some macros to define AL_XX values and change type of _state to `volatile jlong`, what do you think? Introduction LingeredApp has a relatively large effort and may also be relatively risky. There are already similar examples of removing @test tag when using LingeredApp(ClhsdbJstackXcompStress, LingeredAppWithRecComputation), so this may be a feasible solution. These tests are all passed(w/ some modifications to allow it working on JDK8u). Nevertheless, I could investigate if it's possible to backport LingeredApp to after these patches. I have prepared all related changeset. Please help review it, thank you. -yyang 1. 8225690: Multiple AttachListener threads can be created Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02 Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953 Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/webrev.00/ Review Effort: M 2. 8227815: Minimal VM: set_state is not a member of AttachListener Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227815 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/2660d47140da Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275694 Backport Changeset: https://cr.openjdk.java.net/~yyang/8275694/webrev/ Review Effort: XS 3. 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134" Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227738 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/4888ccfc234e Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275695 Backport Changeset: https://cr.openjdk.java.net/~yyang/8275695/webrev/Review Effort: XS ------------------------------------------------------------------ From:Hohensee, Paul Send Time:2021 Oct. 16 (Sat.) 04:39 To:"YANG, Yi" ; jdk8u-dev at openjdk.java.net Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created In attachListener.hpp, the AttachListenerState enum's underlying type will be int, so casting to jlong for the atomic operations will clobber whatever is beyond _state, and won't work at all on big-endian machines. C++11 adds enum base type specification, but we can't use C++11 features in 8u. I would define const int AL_* values and declare _state to be an int. I'm leery of disabling the test. Please see if you can backport 8165500, which introduced LingeredApp. You have code from 8237499 in the patch which has already been backported. Please remove it. Also, please post review requests for 8227815 and 8227738 backports, with the intent to push all three at once. Thanks, Paul -----Original Message----- From: jdk8u-dev on behalf of Yi Yang Reply-To: Yi Yang Date: Friday, October 8, 2021 at 4:21 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created Hi, Can I have a review for this backport of JDK-8225690? Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02 Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953 Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/ VM can't be attached If someone cleans up the /tmp directory. This patch addresses the problem. It can not apply cleanly, some minor conflicts are as follows: 1. Atomic::store(new_state, &_state) jdk8u does not have templated Atomic function family, use explicitly type conversion `Atomic::store((jlong)new_state, (volatile jlong*)&_state)`. 2. IsRegisteredEnum jdk8u does not have metaprogramming type traits, `template<> struct IsRegisteredEnum : public TrueType {};` simply omit it. 3. os::naked_yield os::naked_yield is missing due to https://bugs.openjdk.java.net/browse/JDK-8047714, use os::yield instead. 4. log_debug(attach)("...") jdk8u does not have unified logging system. Use the following code: `debug_only(warning("..."))` 5. Test They can not work because of the usages of LingeredApp. Remove @test tag to disable them while keeping their source code. Test cases have been passed manually. The original issue has related bugs: https://bugs.openjdk.java.net/browse/JDK-8227815 https://bugs.openjdk.java.net/browse/JDK-8235211 https://bugs.openjdk.java.net/browse/JDK-8227738 I'd like to create follow-up backports(JDK-8227815 and JDK-8227738) once this merged. JDK-8235211 is not necessary since RemovingUnixDomainSocketTest.java will be ignored as I said before. Thanks! From qingfeng.yy at alibaba-inc.com Thu Oct 21 08:11:29 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Thu, 21 Oct 2021 16:11:29 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlI6IDgyMjc4MTU6IE1pbmltYWwgVk06IHNldF9zdGF0ZSBpcyBub3QgYSBtZW1i?= =?UTF-8?B?ZXIgb2YgQXR0YWNoTGlzdGVuZXI=?= Message-ID: <4ea395a9-2940-4848-acf2-51ffe598e2c4.qingfeng.yy@alibaba-inc.com> Hi, This is a follow-up backport for 8225690: Multiple AttachListener threads can be created. Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227815 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/2660d47140da Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275694 Backport Changeset: https://cr.openjdk.java.net/~yyang/8275694/webrev/ Review Effort: XS Please help review it. Thanks,-yyang From qingfeng.yy at alibaba-inc.com Thu Oct 21 08:13:17 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Thu, 21 Oct 2021 16:13:17 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlI6IDgyMjc3Mzg6IGp2bXRpL0RhdGFEdW1wUmVxdWVzdC9kYXRhZHVtcHJlcTAw?= =?UTF-8?B?MSBmYWlsZWQgZHVlIHRvICJleGl0IGNvZGUgaXMgMTM0Ig==?= Message-ID: <0d517833-0a81-461d-8624-8261454dc7d9.qingfeng.yy@alibaba-inc.com> Hi, This is a follow-up backport for 8225690: Multiple AttachListener threads can be created. Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227738 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/4888ccfc234e Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275695 Backport Changeset: https://cr.openjdk.java.net/~yyang/8275695/webrev/ Review Effort: XS Please help review it.Thanks, -yyang From jvanek at redhat.com Thu Oct 21 16:59:37 2021 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 21 Oct 2021 18:59:37 +0200 Subject: [8u] RFR bad source/target in Makefile of J2DBench In-Reply-To: <0dae8811-f1c1-0371-5283-4c2374f2fbbe@redhat.com> References: <0dae8811-f1c1-0371-5283-4c2374f2fbbe@redhat.com> Message-ID: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/ Note, that jdk11 have in both Makefile and build.xml 1.6 ; jdk18 have in both 1.7 - always simply hardcoded. J. On 10/21/21 18:56, Jiri Vanek wrote: > http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/ > > Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect, > and have -source/target correctly on 1.5 > > However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play. > > > Am looking forward for kind soul to create a bug a commit on my behalf. > > Happy hacking, > ?? J. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From jvanek at redhat.com Thu Oct 21 16:56:40 2021 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 21 Oct 2021 18:56:40 +0200 Subject: [8u] RFR bad source/target in Makefile of J2DBench Message-ID: <0dae8811-f1c1-0371-5283-4c2374f2fbbe@redhat.com> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/ Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect, and have -source/target correctly on 1.5 However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play. Am looking forward for kind soul to create a bug a commit on my behalf. Happy hacking, J. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From xxinliu at amazon.com Fri Oct 22 23:42:11 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 22 Oct 2021 16:42:11 -0700 Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade Message-ID: <7b33ba25-1f76-5feb-ec44-af28788d34ed@amazon.com> Hi, Please review the backport of JDK-8077590 to jdk8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/ Original Review Thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/018258.html This patch will append the MSVC flag '/arch:IA32' to cl.exe on Windows x86. "/arch:IA32 Specifies no enhanced instructions and also specifies x87 for floating-point calculations." https://docs.microsoft.com/en-us/cpp/build/reference/arch-x86?view=msvc-160 I can't access JDK-8077590, but I think it is close to the C2 bug we encounter on Windows x86. After we upgrade our toolchain from VS2010 to VS2013 on Windows, it starts using XMM registers in codegen. Currently, generate_d2i_wrapper(), which is only used for x86_32, doesn't save XMM registers. C2 UseFPUForSpilling may spill General-purpose Registers(GPRs) to XMM registers. Therefore, native functions such as SharedRuntime::d2l may accidentally clobber XMM registers used by RA spilling. More details are in JDK-8275565. Refraining cl.exe from using XMM registers can solve problem. Besides the register clobbering issue, I guess there is another floating point precision issue described in JDK-8077590. I think it's a good idea to keep using x87 on windows x86. Is it possible the original author of this patch unlocks JDK-8077590 so I can follow the 8u backport label process? Risk: This patch only affects the build on Windows x86. The recommended toolchain for jdk8u is Visual Studio 2010. This patch ensures that vs2013 has consistent behavior with vs2010 in terms of FP codegen. Thus, I think the risk is low. We have verified this patch using our pipeline. thanks, --lx From java at devonfrosch.eu Sun Oct 24 16:18:04 2021 From: java at devonfrosch.eu (Elmar Frerichs) Date: Sun, 24 Oct 2021 18:18:04 +0200 Subject: ClassCastException in LayoutFocusTraversalPolicy Message-ID: <0555413d-baf9-2311-b44d-8928c93c7249@devonfrosch.eu> Hello, I am new to the whole process of java development and bug reporting, and I hope this is the right place for my request - if not please tell me :-) A project I am currently working on uses custom implementations of ButtonModel as a model for javax.swing.JToggleButton. Until JRE 8u301-b09, this worked fine, but with the latest version (JRE 8u311-b11, especially the build by java.com for Windows x64) the app in some occasions crashes with a ClassCastException. I dug through the source code and the OpenJDK bug tracker to find out more about it, and found the following bug report: https://bugs.openjdk.java.net/browse/JDK-8182577 As it turns out, the stack trace matches the one of my project, and the Snippet for reproducing the bug now also fails in JRE 8u311-b11. If I understood the connections correctly, the bug of JDK-8182577 was introduced to JRE 9 by the fix from JDK-8154043 (https://bugs.openjdk.java.net/browse/JDK-8154043). This bug has a backport ticket for JDK 8u311, but without a hg changeset attached (https://bugs.openjdk.java.net/browse/JDK-8268519). I am a bit confused that the source code in hg for LayoutFocusTraversalPolicy.java (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/00cd9dc3c2b5/src/share/classes/javax/swing/LayoutFocusTraversalPolicy.java) does not mention the ToggleButtonModel at all - it seems that at least in hg the backport was never applied? Or is hg out of date here? Or did I miss a switch somewhere? Anyways, I would appreciate any feedback on whether others can reproduce the bug with the snippet of JDK-8182577 in JRE 8u311-b11 as well or if I might have done something else wrong. Thanks, Elmar From gnu.andrew at redhat.com Mon Oct 25 13:37:04 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Oct 2021 14:37:04 +0100 Subject: [8u] RFR bad source/target in Makefile of J2DBench In-Reply-To: <0dae8811-f1c1-0371-5283-4c2374f2fbbe@redhat.com> References: <0dae8811-f1c1-0371-5283-4c2374f2fbbe@redhat.com> Message-ID: On 18:56 Thu 21 Oct , Jiri Vanek wrote: > http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/ > > Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect, > and have -source/target correctly on 1.5 > > However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play. > > > Am looking forward for kind soul to create a bug a commit on my behalf. > > Happy hacking, > J. > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > This looks like a subset of: https://bugs.openjdk.java.net/browse/JDK-8042199 I think it would be preferable to backport this to keep this code aligned across JDKs. It fixes some other differences between the Makefile & build.xml, as well as actually making it buildable with 1.4, as the README claims. The -g:none addition seemed strange to me, but it seems debug=false has been in build.xml since the start of the OpenJDK project [0]. If we want to remove that, we should probably do so in HEAD and backport for consistency across releases. [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hohensee at amazon.com Mon Oct 25 17:38:40 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 25 Oct 2021 17:38:40 +0000 Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade Message-ID: <0BFB2CAB-779A-410B-9703-2C5509227AD0@amazon.com> Looks good. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of "Liu, Xin" Date: Friday, October 22, 2021 at 4:43 PM To: "jdk8u-dev at openjdk.java.net" Cc: Nils Eliasson Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade Hi, Please review the backport of JDK-8077590 to jdk8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/ Original Review Thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/018258.html This patch will append the MSVC flag '/arch:IA32' to cl.exe on Windows x86. "/arch:IA32 Specifies no enhanced instructions and also specifies x87 for floating-point calculations." https://docs.microsoft.com/en-us/cpp/build/reference/arch-x86?view=msvc-160 I can't access JDK-8077590, but I think it is close to the C2 bug we encounter on Windows x86. After we upgrade our toolchain from VS2010 to VS2013 on Windows, it starts using XMM registers in codegen. Currently, generate_d2i_wrapper(), which is only used for x86_32, doesn't save XMM registers. C2 UseFPUForSpilling may spill General-purpose Registers(GPRs) to XMM registers. Therefore, native functions such as SharedRuntime::d2l may accidentally clobber XMM registers used by RA spilling. More details are in JDK-8275565. Refraining cl.exe from using XMM registers can solve problem. Besides the register clobbering issue, I guess there is another floating point precision issue described in JDK-8077590. I think it's a good idea to keep using x87 on windows x86. Is it possible the original author of this patch unlocks JDK-8077590 so I can follow the 8u backport label process? Risk: This patch only affects the build on Windows x86. The recommended toolchain for jdk8u is Visual Studio 2010. This patch ensures that vs2013 has consistent behavior with vs2010 in terms of FP codegen. Thus, I think the risk is low. We have verified this patch using our pipeline. thanks, --lx From jvanek at redhat.com Mon Oct 25 18:14:46 2021 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 25 Oct 2021 20:14:46 +0200 Subject: [8u] RFR bad source/target in Makefile of J2DBench In-Reply-To: References: <0dae8811-f1c1-0371-5283-4c2374f2fbbe@redhat.com> Message-ID: <8d950e2d-22ee-3115-5618-c467edc3ba4a@redhat.com> Thanx! webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/ Compared to original, I had dropepd the build.xml change, as it was not relevant. The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed. Should it be reopened, or new bug will be created? Thanx! J. On 10/25/21 15:37, Andrew Hughes wrote: > On 18:56 Thu 21 Oct , Jiri Vanek wrote: >> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/ >> >> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect, >> and have -source/target correctly on 1.5 >> >> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play. >> >> >> Am looking forward for kind soul to create a bug a commit on my behalf. >> >> Happy hacking, >> J. >> -- >> Jiri Vanek Mgr. >> Principal QA Software Engineer >> Red Hat Inc. >> +420 775 39 01 09 >> > > This looks like a subset of: > > https://bugs.openjdk.java.net/browse/JDK-8042199 > > I think it would be preferable to backport this to keep this code aligned > across JDKs. It fixes some other differences between the Makefile & > build.xml, as well as actually making it buildable with 1.4, as the > README claims. > > The -g:none addition seemed strange to me, but it seems debug=false > has been in build.xml since the start of the OpenJDK project [0]. > If we want to remove that, we should probably do so in HEAD and > backport for consistency across releases. > > [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html > -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From hohensee at amazon.com Tue Oct 26 16:21:43 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 26 Oct 2021 16:21:43 +0000 Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade In-Reply-To: <0BFB2CAB-779A-410B-9703-2C5509227AD0@amazon.com> References: <0BFB2CAB-779A-410B-9703-2C5509227AD0@amazon.com> Message-ID: Also, approval by a Maintainer (Severin or Andrew) on the list is needed because the JBS issue is private. Thanks Paul ?-----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Monday, October 25, 2021 at 10:40 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Cc: Nils Eliasson Subject: Re: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade Looks good. Thanks, Paul -----Original Message----- From: jdk8u-dev on behalf of "Liu, Xin" Date: Friday, October 22, 2021 at 4:43 PM To: "jdk8u-dev at openjdk.java.net" Cc: Nils Eliasson Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade Hi, Please review the backport of JDK-8077590 to jdk8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/ Original Review Thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/018258.html This patch will append the MSVC flag '/arch:IA32' to cl.exe on Windows x86. "/arch:IA32 Specifies no enhanced instructions and also specifies x87 for floating-point calculations." https://docs.microsoft.com/en-us/cpp/build/reference/arch-x86?view=msvc-160 I can't access JDK-8077590, but I think it is close to the C2 bug we encounter on Windows x86. After we upgrade our toolchain from VS2010 to VS2013 on Windows, it starts using XMM registers in codegen. Currently, generate_d2i_wrapper(), which is only used for x86_32, doesn't save XMM registers. C2 UseFPUForSpilling may spill General-purpose Registers(GPRs) to XMM registers. Therefore, native functions such as SharedRuntime::d2l may accidentally clobber XMM registers used by RA spilling. More details are in JDK-8275565. Refraining cl.exe from using XMM registers can solve problem. Besides the register clobbering issue, I guess there is another floating point precision issue described in JDK-8077590. I think it's a good idea to keep using x87 on windows x86. Is it possible the original author of this patch unlocks JDK-8077590 so I can follow the 8u backport label process? Risk: This patch only affects the build on Windows x86. The recommended toolchain for jdk8u is Visual Studio 2010. This patch ensures that vs2013 has consistent behavior with vs2010 in terms of FP codegen. Thus, I think the risk is low. We have verified this patch using our pipeline. thanks, --lx From sgehwolf at redhat.com Wed Oct 27 10:10:36 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 27 Oct 2021 12:10:36 +0200 Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade In-Reply-To: References: <0BFB2CAB-779A-410B-9703-2C5509227AD0@amazon.com> Message-ID: On Tue, 2021-10-26 at 16:21 +0000, Hohensee, Paul wrote: > Also, approval by a Maintainer (Severin or Andrew) on the list is > needed because the JBS issue is private. > > Thanks > Paul > [...] > -----Original Message----- > From: jdk8u-dev on behalf of "Liu, > Xin" > Date: Friday, October 22, 2021 at 4:43 PM > To: "jdk8u-dev at openjdk.java.net" > Cc: Nils Eliasson > Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2- > runThese8_Xcomp_vm failing after win compiler upgrade > > Hi, > > Please review the backport of JDK-8077590 to jdk8u: > Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 > Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/ This looks fine. Approved for jdk8u-dev. Thanks, Severin From hohensee at amazon.com Wed Oct 27 17:07:22 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 27 Oct 2021 17:07:22 +0000 Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade Message-ID: <901CF05E-B668-4903-B750-69A6CA3D8BD5@amazon.com> Thanks, Severin. Pushed. Paul ?-----Original Message----- From: Severin Gehwolf Date: Wednesday, October 27, 2021 at 3:11 AM To: "Hohensee, Paul" , "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade On Tue, 2021-10-26 at 16:21 +0000, Hohensee, Paul wrote: > Also, approval by a Maintainer (Severin or Andrew) on the list is > needed because the JBS issue is private. > > Thanks > Paul > [...] > -----Original Message----- > From: jdk8u-dev on behalf of "Liu, > Xin" > Date: Friday, October 22, 2021 at 4:43 PM > To: "jdk8u-dev at openjdk.java.net" > Cc: Nils Eliasson > Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2- > runThese8_Xcomp_vm failing after win compiler upgrade > > Hi, > > Please review the backport of JDK-8077590 to jdk8u: > Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 > Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/ This looks fine. Approved for jdk8u-dev. Thanks, Severin From hohensee at amazon.com Wed Oct 27 20:12:32 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 27 Oct 2021 20:12:32 +0000 Subject: [8u] RFR: 8048021: Remove @version tag in jaxp repo Message-ID: <2177EC97-3957-4A91-96E7-E03711A424C5@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Tuesday, October 19, 2021 at 6:09 AM To: jdk8u-dev Subject: [8u] RFR: 8048021: Remove @version tag in jaxp repo Hi, Please review the backport of JDK-8048021 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8048021 Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/01c25780f33f 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8048021/webrev.00/ This change can make it easier to backport subsequent JAXP parity issues to 8u. There are no code changes, all changes are to comments. The following files were resolved manually: src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java src/ com/sun/org/apache/xerces/internal/util /EncodingMap.java src/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java src/javax/xml/parsers/DocumentBuilderFactory.java src/javax/xml/parsers/FactoryConfigurationError.java src/javax/xml/parsers/SAXParserFactory.java -- -Alex From xxinliu at amazon.com Wed Oct 27 20:13:00 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 27 Oct 2021 13:13:00 -0700 Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade In-Reply-To: <901CF05E-B668-4903-B750-69A6CA3D8BD5@amazon.com> References: <901CF05E-B668-4903-B750-69A6CA3D8BD5@amazon.com> Message-ID: <1a64d815-42d6-29a9-a7eb-1a25085c30f7@amazon.com> hi, Paul & Severin, Thank you for reviewing this patch. I just found VS2010 and older don't support /arch:IA32. Here is the archived documentation of VS2010. https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/7t5yh4fd(v=vs.100)?redirectedfrom=MSDN My concern is that patch may break users who are still using vs2010 or older. VS2010 has been end of life. https://docs.microsoft.com/en-us/lifecycle/products/visual-studio-2010 This contradicts jdk8u's build instructions. Should we update README-builds.html as well? That would be a separate issue for sure. or I am paranoid. we're all using vs2013 as the minimal toolchain Windows. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/2c60e3009d12/README-builds.html#vs2010 thanks, --lx On 10/27/21 10:07 AM, Hohensee, Paul wrote: > Thanks, Severin. Pushed. > > Paul > > ?-----Original Message----- > From: Severin Gehwolf > Date: Wednesday, October 27, 2021 at 3:11 AM > To: "Hohensee, Paul" , "Liu, Xin" , "jdk8u-dev at openjdk.java.net" > Subject: RE: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade > > On Tue, 2021-10-26 at 16:21 +0000, Hohensee, Paul wrote: >> Also, approval by a Maintainer (Severin or Andrew) on the list is >> needed because the JBS issue is private. >> >> Thanks >> Paul >> > > [...] > >> -----Original Message----- >> From: jdk8u-dev on behalf of "Liu, >> Xin" >> Date: Friday, October 22, 2021 at 4:43 PM >> To: "jdk8u-dev at openjdk.java.net" >> Cc: Nils Eliasson >> Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2- >> runThese8_Xcomp_vm failing after win compiler upgrade >> >> Hi, >> >> Please review the backport of JDK-8077590 to jdk8u: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 >> Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/ > > This looks fine. Approved for jdk8u-dev. > > Thanks, > Severin > > From akashche at redhat.com Wed Oct 27 22:00:25 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 27 Oct 2021 23:00:25 +0100 Subject: [8u] RFR: 8048021: Remove @version tag in jaxp repo In-Reply-To: <2177EC97-3957-4A91-96E7-E03711A424C5@amazon.com> References: <2177EC97-3957-4A91-96E7-E03711A424C5@amazon.com> Message-ID: On 10/27/21, Hohensee, Paul wrote: > Lgtm. Thanks for the review! I've marked the bug for approval. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Alex > Kashchenko > Date: Tuesday, October 19, 2021 at 6:09 AM > To: jdk8u-dev > Subject: [8u] RFR: 8048021: Remove @version tag in jaxp repo > > Hi, > > Please review the backport of JDK-8048021 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048021 > > Original commit: > https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/01c25780f33f > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8048021/webrev.00/ > > This change can make it easier to backport subsequent JAXP parity > issues to 8u. There are no code changes, all changes are to comments. > The following files were resolved manually: > > src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java > src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java > src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java > src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java > src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java > src/ com/sun/org/apache/xerces/internal/util /EncodingMap.java > src/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java > src/javax/xml/parsers/DocumentBuilderFactory.java > src/javax/xml/parsers/FactoryConfigurationError.java > src/javax/xml/parsers/SAXParserFactory.java > > -- > -Alex > > > -- -Alex From sgehwolf at redhat.com Thu Oct 28 08:36:34 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Oct 2021 10:36:34 +0200 Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade In-Reply-To: <1a64d815-42d6-29a9-a7eb-1a25085c30f7@amazon.com> References: <901CF05E-B668-4903-B750-69A6CA3D8BD5@amazon.com> <1a64d815-42d6-29a9-a7eb-1a25085c30f7@amazon.com> Message-ID: <9355d3e72afaede6eafc235ee3d58cfe1bcded84.camel@redhat.com> Hi, On Wed, 2021-10-27 at 13:13 -0700, Liu, Xin wrote: > hi, Paul & Severin, > > Thank you for reviewing this patch. > > I just found VS2010 and older don't support /arch:IA32. Here is the > archived documentation of VS2010. > https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/7t5yh4fd(v=vs.100)?redirectedfrom=MSDN > > My concern is that patch may break users who are still using vs2010 or > older. VS2010 has been end of life. > https://docs.microsoft.com/en-us/lifecycle/products/visual-studio-2010 > Sigh. My understanding was that it was tested on VS2010 too :-/ In that case we need to conditionalize the patch based on VS version. There are still people using VS 2010. This isn't the patch to break it. Please file an 8u-only bug to rectify this. After that we can have a discussion on whether or not to move to a newer toolchain for 8u. Thanks, Severin > This contradicts jdk8u's build instructions. Should we update > README-builds.html as well? That would be a separate issue for sure. or > I am paranoid. we're all using vs2013 as the minimal toolchain Windows. > > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/2c60e3009d12/README-builds.html#vs2010 > > thanks, > --lx > > > > On 10/27/21 10:07 AM, Hohensee, Paul wrote: > > Thanks, Severin. Pushed. > > > > Paul > > > > ?-----Original Message----- > > From: Severin Gehwolf > > Date: Wednesday, October 27, 2021 at 3:11 AM > > To: "Hohensee, Paul" , "Liu, Xin" , "jdk8u-dev at openjdk.java.net" > > Subject: RE: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade > > > > On Tue, 2021-10-26 at 16:21 +0000, Hohensee, Paul wrote: > > > Also, approval by a Maintainer (Severin or Andrew) on the list is > > > needed because the JBS issue is private. > > > > > > Thanks > > > Paul > > > > > > > [...] > > > > > -----Original Message----- > > > From: jdk8u-dev on behalf of "Liu, > > > Xin" > > > Date: Friday, October 22, 2021 at 4:43 PM > > > To: "jdk8u-dev at openjdk.java.net" > > > Cc: Nils Eliasson > > > Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2- > > > runThese8_Xcomp_vm failing after win compiler upgrade > > > > > > Hi, > > > > > > Please review the backport of JDK-8077590 to jdk8u: > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 > > > Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/ > > > > This looks fine. Approved for jdk8u-dev. > > > > Thanks, > > Severin > > From xxinliu at amazon.com Thu Oct 28 22:15:49 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 28 Oct 2021 15:15:49 -0700 Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade In-Reply-To: <9355d3e72afaede6eafc235ee3d58cfe1bcded84.camel@redhat.com> References: <901CF05E-B668-4903-B750-69A6CA3D8BD5@amazon.com> <1a64d815-42d6-29a9-a7eb-1a25085c30f7@amazon.com> <9355d3e72afaede6eafc235ee3d58cfe1bcded84.camel@redhat.com> Message-ID: <809be0ac-8b9e-086e-dceb-d4566d0749b3@amazon.com> hi, Severin, Sorry, we should have tested out in the first place. I manage to set up VS2010 back today. It is still capable of building jdk8u-dev with warnings. cl : Command line warning D9002 : ignoring unknown option '/arch:IA32' It's better than I thought. At least it won't break anybody. Besides noisy warnings, JVM works fine. I think we can live with it given the fact that VS2010 isn't an active toolchain. This patch is almost a clean backport. It's easy to track it than adding a condition on top of it. thanks, --lx On 10/28/21 1:36 AM, Severin Gehwolf wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi, > > On Wed, 2021-10-27 at 13:13 -0700, Liu, Xin wrote: >> hi, Paul & Severin, >> >> Thank you for reviewing this patch. >> >> I just found VS2010 and older don't support /arch:IA32. Here is the >> archived documentation of VS2010. >> https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/7t5yh4fd(v=vs.100)?redirectedfrom=MSDN >> >> My concern is that patch may break users who are still using vs2010 or >> older. VS2010 has been end of life. >> https://docs.microsoft.com/en-us/lifecycle/products/visual-studio-2010 >> > > Sigh. My understanding was that it was tested on VS2010 too :-/ > > In that case we need to conditionalize the patch based on VS version. > There are still people using VS 2010. This isn't the patch to break it. > Please file an 8u-only bug to rectify this. > > After that we can have a discussion on whether or not to move to a > newer toolchain for 8u. > > Thanks, > Severin > >> This contradicts jdk8u's build instructions. Should we update >> README-builds.html as well? That would be a separate issue for sure. or >> I am paranoid. we're all using vs2013 as the minimal toolchain Windows. >> >> https://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/2c60e3009d12/README-builds.html#vs2010 >> >> thanks, >> --lx >> >> >> >> On 10/27/21 10:07 AM, Hohensee, Paul wrote: >>> Thanks, Severin. Pushed. >>> >>> Paul >>> >>> ?-----Original Message----- >>> From: Severin Gehwolf >>> Date: Wednesday, October 27, 2021 at 3:11 AM >>> To: "Hohensee, Paul" , "Liu, Xin" , "jdk8u-dev at openjdk.java.net" >>> Subject: RE: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade >>> >>> On Tue, 2021-10-26 at 16:21 +0000, Hohensee, Paul wrote: >>>> Also, approval by a Maintainer (Severin or Andrew) on the list is >>>> needed because the JBS issue is private. >>>> >>>> Thanks >>>> Paul >>>> >>> >>> [...] >>> >>>> -----Original Message----- >>>> From: jdk8u-dev on behalf of "Liu, >>>> Xin" >>>> Date: Friday, October 22, 2021 at 4:43 PM >>>> To: "jdk8u-dev at openjdk.java.net" >>>> Cc: Nils Eliasson >>>> Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2- >>>> runThese8_Xcomp_vm failing after win compiler upgrade >>>> >>>> Hi, >>>> >>>> Please review the backport of JDK-8077590 to jdk8u: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077590 >>>> Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/ >>> >>> This looks fine. Approved for jdk8u-dev. >>> >>> Thanks, >>> Severin >>> > > From panxuefeng at loongson.cn Sat Oct 9 03:37:50 2021 From: panxuefeng at loongson.cn (panxuefeng) Date: Sat, 09 Oct 2021 03:37:50 -0000 Subject: RFR [8u] JDK-8044051 : Test jdk/lambda/vm/InterfaceAccessFlagsTest.java gets IOException during compilation Message-ID: <80fbf095-3290-4eea-e4e9-c5ef64b1c748@loongson.cn> Hi , Please review the backport of JDK-8044051: Original bug: https://bugs.openjdk.java.net/browse/JDK-8044051 Original commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/157b0a8bf65c Webrev: http://cr.openjdk.java.net/~aoqi/8044051/webrev.8u.01/ Patch applies clean. 8u specific changes are only to path and copyright header. Testing: ran jtreg: jdk/lambda/vm/InterfaceAccessFlagsTest.java. Thanks, Pan xuefeng From panxuefeng at loongson.cn Mon Oct 11 01:11:55 2021 From: panxuefeng at loongson.cn (panxuefeng) Date: Mon, 11 Oct 2021 01:11:55 -0000 Subject: RFR [8u] JDK-8044051: Test jdk/lambda/vm/InterfaceAccessFlagsTest.java gets IOException during compilation Message-ID: <2d07dcf3-8af6-6b86-8dad-480dc35fc0b1@loongson.cn> Hi, Please review the backport of JDK-8044051: Original bug: https://bugs.openjdk.java.net/browse/JDK-8044051 Original commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/157b0a8bf65c Webrev: http://cr.openjdk.java.net/~aoqi/8044051/webrev.8u.01/ Patch applies clean. 8u specific changes are only to path and copyright header. Testing: ran jtreg: jdk/lambda/vm/InterfaceAccessFlagsTest.java. Thanks, Pan xuefeng