From karen.kinnear at oracle.com Mon Jun 3 03:21:25 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Sun, 2 Jun 2019 23:21:25 -0400 Subject: CFV: New JDK Reviewer: Mikael Vidstedt In-Reply-To: <68C0365A-99F9-43AE-806B-ACADDE097591@oracle.com> References: <68C0365A-99F9-43AE-806B-ACADDE097591@oracle.com> Message-ID: <76C7C01E-BD31-484D-AC8D-95A768F1F9E5@oracle.com> Vote: yes thanks, Karen > On May 23, 2019, at 8:44 PM, jesper.wilhelmsson at oracle.com wrote: > > I hereby nominate Mikael Vidstedt (mikael) to JDK Reviewer. > > Mikael has contributed 127 changesets [1] to various parts of OpenJDK, mainly in the HotSpot and build areas, starting back in 2012. Mikael is also the project lead for the Portola project. How he has escaped becoming a Reviewer until now is a mystery. > > Votes are due by June 6, 2019. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > For Lazy Consensus voting instructions, see [3]. > > Thanks, > /Jesper > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mikael)+or+desc(%22mikael.vidstedt at oracle.com%22))+and+not+merge() > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#project-reviewer > From aph at redhat.com Mon Jun 3 09:14:30 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 3 Jun 2019 10:14:30 +0100 Subject: Result: New JDK Reviewer: Severin Gehwolf Message-ID: <38171b58-9c62-b9de-2c7a-a7417f6f22d2@redhat.com> Voting for Severin Gehwolf [1] is now closed. Yes: 24 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Mon Jun 3 09:18:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 3 Jun 2019 11:18:14 +0200 Subject: Result: New JDK Reviewer: Boris Ulasevich Message-ID: <4f4fbad4-a8aa-9e47-a87c-eaa4f78b894f@redhat.com> Voting for Boris Ulasevich [1] is now closed. Yes: 23 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002914.html -- Thanks, -Aleksey From shade at redhat.com Mon Jun 3 09:19:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 3 Jun 2019 11:19:22 +0200 Subject: Result: New JDK Committer: Boris Ulasevich In-Reply-To: <4f4fbad4-a8aa-9e47-a87c-eaa4f78b894f@redhat.com> References: <4f4fbad4-a8aa-9e47-a87c-eaa4f78b894f@redhat.com> Message-ID: <07ae18bf-bdc9-2b12-18e3-905a0e947945@redhat.com> It seems I have tremendously bad luck here. Of course, the real subject is: "New JDK ***Committer***: Boris Ulasevich" Updated accordingly. On 6/3/19 11:18 AM, Aleksey Shipilev wrote: > Voting for Boris Ulasevich [1] is now closed. > > Yes: 23 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the > nomination. > > [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002914.html > -- Thanks, -Aleksey From jianglizhou at google.com Mon Jun 3 16:10:27 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 3 Jun 2019 09:10:27 -0700 Subject: Result: New JDK Committer: Arthur Eubanks Message-ID: Voting for Arthur Eubanks (aeubanks) [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002951.html Best regards, Jiangli From mark.reinhold at oracle.com Thu Jun 6 15:00:52 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 06 Jun 2019 08:00:52 -0700 Subject: JEP proposed to target JDK 13: 355: Text Blocks (Preview) In-Reply-To: <20190529212257.F30092B0869@eggemoggin.niobe.net> References: <20190529212257.F30092B0869@eggemoggin.niobe.net> Message-ID: <20190606080052.775320501@eggemoggin.niobe.net> 2019/5/29 14:22:57 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 13: > > 355: Text Blocks (Preview) > https://openjdk.java.net/jeps/355 > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:00 UTC on Wednesday, 5 June, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 13. Hearing no objections, I?ve targeted this JEP to JDK 13. - Mark From mark.reinhold at oracle.com Thu Jun 6 15:49:26 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 6 Jun 2019 08:49:26 -0700 (PDT) Subject: JDK 13 enters Rampdown Phase One next week Message-ID: <20190606154926.E4D052B1FD7@eggemoggin.niobe.net> JDK 13 enters Rampdown Phase One next week, on Thursday, 13 June. Changes intended for JDK 13 should be in the main-line repository (https://hg.openjdk.java.net/jdk/jdk) by 16:00 UTC on that day [1]. At that time we?ll fork jdk/jdk to the JDK 13 stabilization repository, jdk/jdk13, and promote next week?s build (jdk-13+25) and all remaining JDK 13 builds from there. We'll semi-automatically merge changes pushed to jdk/jdk13 into the main-line jdk/jdk repository, as we have in previous feature-release transitions. This means that: - If you make a change in JDK 13 then you needn't do any extra work to get it into the main line, though if a merge conflict arises then you might be asked to help resolve it. - If you need to make a change in both JDK 13 and the main line then just push it to JDK 13, and wait for the automatic merge to complete. Changes pushed to jdk/jdk after 16:00 UTC next Thursday will be bound for JDK 14 only, unless they're back-ported. The jdk/submit repo will continue to be for main-line (jdk/jdk) work. We?ll set up a jdk/submit13 repo for jdk/jdk13 work. The Rampdown Phase One process is defined in JEP 3 [2]. - Mark [1] https://time.is/1600_13_Jun_2019_in_UTC?JDK_13_Rampdown_Phase_One [2] https://openjdk.java.net/jeps/3 From mark.reinhold at oracle.com Fri Jun 7 20:38:35 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 07 Jun 2019 13:38:35 -0700 Subject: JEP proposed to target JDK 13: 354: Switch Expressions (Preview) In-Reply-To: <20190530210911.73F0E2B0915@eggemoggin.niobe.net> References: <20190530210911.73F0E2B0915@eggemoggin.niobe.net> Message-ID: <20190607133835.40468103@eggemoggin.niobe.net> 2019/5/30 14:09:11 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 13: > > 354: Switch Expressions (Preview) > https://openjdk.java.net/jeps/354 > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:00 UTC on Thursday, 6 June, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 13. Hearing no objections, I?ve targeted this JEP to JDK 13. - Mark From jesper.wilhelmsson at oracle.com Fri Jun 7 22:27:40 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Sat, 8 Jun 2019 00:27:40 +0200 Subject: OpenJDK section for the JDK project Message-ID: <8B921B46-9B07-482B-AF9F-1AED83023419@oracle.com> Hi, I think the JDK project would benefit from having a wiki section in the OpenJDK wiki, similar to many other projects. There are currently some "how-to" guides [1] and similar pages in the HotSpot wiki that (after an update) would be better placed in a JDK section, as these are not hotspot specific. There is also the new JBS label dictionary [2] that is also meant to be a JDK page rather than a HotSpot page. I'm sure that if the section was created many more pages would find their way there :-) Are there any objections to creating a JDK wiki? Thanks, /Jesper [1] https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To [2] https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary From jesper.wilhelmsson at oracle.com Fri Jun 7 22:50:56 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Sat, 8 Jun 2019 00:50:56 +0200 Subject: CFV: New JDK Reviewer: Mikael Vidstedt In-Reply-To: References: <68C0365A-99F9-43AE-806B-ACADDE097591@oracle.com> Message-ID: <6DAC99A6-967F-445A-A690-26DFD860D29E@oracle.com> Hi Igor, I did check with Mikael before sending the vote out and he was OK with it. /Jesper > On 24 May 2019, at 03:40, Igor Ignatyev wrote: > > As far as I remember, Mikael has his own reasons not to become a Reviewer and r privately ejected several offers to nominate him. I don't think it's enough to veto his nomination, however to respect his choice, I abstain from this voting. > > Vote: abstain > > -- Igor > >> On May 23, 2019, at 5:44 PM, jesper.wilhelmsson at oracle.com wrote: >> >> I hereby nominate Mikael Vidstedt (mikael) to JDK Reviewer. >> >> Mikael has contributed 127 changesets [1] to various parts of OpenJDK, mainly in the HotSpot and build areas, starting back in 2012. Mikael is also the project lead for the Portola project. How he has escaped becoming a Reviewer until now is a mystery. >> >> Votes are due by June 6, 2019. >> >> Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> /Jesper >> >> [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mikael)+or+desc(%22mikael.vidstedt at oracle.com%22))+and+not+merge() >> [2] http://openjdk.java.net/census >> [3] http://openjdk.java.net/projects/#project-reviewer >> > From jesper.wilhelmsson at oracle.com Fri Jun 7 22:58:16 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Sat, 8 Jun 2019 00:58:16 +0200 Subject: Result: New JDK Reviewer: Mikael Vidstedt Message-ID: Voting for Mikael Vidstedt [1] is now closed. Yes: 55 Veto: 0 Abstain: 1 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thanks, /Jesper [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002977.html From orionllmain at gmail.com Tue Jun 11 05:49:55 2019 From: orionllmain at gmail.com (Zheka Kozlov) Date: Tue, 11 Jun 2019 12:49:55 +0700 Subject: Apple Notarization In-Reply-To: References: Message-ID: FYI: https://bugs.openjdk.java.net/browse/JDK-8223671 ??, 5 ???. 2019 ?. ? 18:19, Zheka Kozlov : > Hello Jessica. We also deliver our software with a bundled Java. In the > last couple of months, I was trying to overcome Apple notarization. I > finally managed to do it, however, after signing of Java executables and > dynamic libraries it doesn't work anymore. > > Here I'll describe the steps I did: > > 1. Downloaded JRE 10.0.2 for macOS from Oracle (I could use JDK 11 as > well, JR). > > 2. Ungzipped it with `tar -zxf`. > > 3. Signed all executables and dynamic libraries with `codesign --force > --verify --deep --verbose --sign --timestamp -o runtime > --entitlements test.entitlements` > `-o runtime` enabled hardened runtime (which is required for successful > notarization) > test.entitlements is a file with entitlements. Its contents are: > > > http://www.apple.com/DTDs/PropertyList-1.0.dtd"> > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.allow-unsigned-executable-memory > > com.apple.security.cs.disable-executable-page-protection > > com.apple.security.cs.disable-library-validation > > > > > 4. Zipped the JRE and submitted it for notarization: `xcrun altool > --notarize-app --primary-bundle-id "" --username > --file > > The archive successfully passed the notarization. However, JRE is not > executable anymore. When I run `java -version`, it reports an error: > Error occurred during initialization of VM > Could not reserve enough space in CodeHeap 'non-nmethods' (2496K) > > And I'm stuck here. I have no ideas on how to resolve this. I was trying > to read the JVM source code but with no luck (it requires deep knowledge of > the JVM internals). > > Can anyone help with this? I would really appreciate if someone helped me > to understand this error message. > > Thanks. > > > ??, 19 ???. 2018 ?. ? 03:51, Jessica Leigh : > >> I'm investigating the process of getting an application "notarized" for >> Mac >> OS. This is a process that Apple has introduced with Mac OS 10.14 Mojave, >> and they've indicated that it will be required for developer-signed >> applications in the near future. The process differs from code signing >> (applications are uploaded to Apple, where they're scanned and either >> notarized or rejected). More information is available from Apple: >> >> https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution >> >> Our software is bundled with Java 11, and my attempts to find information >> on notarizing Java applications led me to some Stack Overflow questions >> that suggest there may be problems with JAR files, e.g., >> >> https://stackoverflow.com/questions/53439639/notarize-java-app-for-distribution-on-mac-app-store >> , where dynamic libraries inside JARs aren't signed, which causes >> notarization to fail. >> >> Has any thought been put into preparing/signing Java for the purpose of >> notarization? It seems like Java might not be ready for this yet. >> >> >> >> *Dr. Jessica Leigh*Software Developer >> GENEIOUS >> > From jai.forums2013 at gmail.com Tue Jun 11 12:48:26 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 11 Jun 2019 18:18:26 +0530 Subject: How do you run the TestNG tests that are in the JDK code? Message-ID: I have been writing a patch to fix a specific reported issue in JDK. I'm familiar with running tests with jtreg, but I see that there are some TestNG based tests which I can't seem to run from the command line. I read the testing documentation[1] and that too doesn't explain how to run such tests. I have tried using "make test TEST=..." and even direct "jtreg -jdk:....." and neither has worked. Examples of such TestNG tests reside in test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/. I'm on the latest 4.2b14 version of jtreg. Any inputs on how to get these running? I don't yet have my IDE (IntelliJ) configured for running tests from there, so that isn't an option right now (will be great if there's a doc which explains how to set this up for the JDK project). [1] https://hg.openjdk.java.net/jdk/jdk/raw-file/d9a157f6fd71/doc/testing.html -Jaikiran From pavel.rappo at oracle.com Tue Jun 11 13:01:52 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 11 Jun 2019 14:01:52 +0100 Subject: How do you run the TestNG tests that are in the JDK code? In-Reply-To: References: Message-ID: <01400F40-6C3B-452D-9A8A-4D31955B0296@oracle.com> > On 11 Jun 2019, at 13:48, Jaikiran Pai wrote: > > test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/. Those are the tests that are not run directly by JTREG, but rather using a JTREG wrapper. Consider test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/DefaultProxy.java The wrapper for this test would be test/jdk/java/net/httpclient/whitebox/DefaultProxyDriver.java That wrapper is the actual test you should pass to JTREG. Hope that helps. -Pavel From jai.forums2013 at gmail.com Tue Jun 11 13:11:17 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 11 Jun 2019 18:41:17 +0530 Subject: How do you run the TestNG tests that are in the JDK code? In-Reply-To: <01400F40-6C3B-452D-9A8A-4D31955B0296@oracle.com> References: <01400F40-6C3B-452D-9A8A-4D31955B0296@oracle.com> Message-ID: <7a5877e2-b599-a156-fe5d-19fffa299c64@gmail.com> Excellent! Thank you very much for the help. I found the "driver" for the testng tests I was interested in, using the example you showed. -Jaikiran On 11/06/19 6:31 PM, Pavel Rappo wrote: >> On 11 Jun 2019, at 13:48, Jaikiran Pai wrote: >> >> test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/. > Those are the tests that are not run directly by JTREG, but rather using a JTREG > wrapper. Consider > > test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/DefaultProxy.java > > The wrapper for this test would be > > test/jdk/java/net/httpclient/whitebox/DefaultProxyDriver.java > > That wrapper is the actual test you should pass to JTREG. > Hope that helps. > > -Pavel > From mark.reinhold at oracle.com Thu Jun 13 20:33:58 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 Jun 2019 13:33:58 -0700 (PDT) Subject: JDK 13 is now in Rampdown Phase One Message-ID: <20190613203358.C8CBD2B3620@eggemoggin.niobe.net> Per the JDK 13 schedule [1], we are now in Rampdown Phase One. The overall feature set is frozen. No further JEPs will be targeted to this release. We?ve forked the main-line source repository, jdk/jdk, to the jdk/jdk13 stabilization repository. Any changes pushed to jdk/jdk are now bound for JDK 14, as noted previously [2]. The stabilization repository is open for select bug fixes and, with approval, late enhancements per JEP 3, the JDK Release Process [3]. If you?re responsible for any of the bugs on the RDP 1 candidate-bug list [3] then please see JEP 3 for guidance on how to handle them. - Mark [1] http://openjdk.java.net/projects/jdk/13/#Schedule [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003051.html [3] http://openjdk.java.net/jeps/3 [4] http://j.mp/jdk-rdp-1 From doko at ubuntu.com Fri Jun 14 12:57:43 2019 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 14 Jun 2019 14:57:43 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 Message-ID: My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I tried jdk-13+22, which didn't build anymore, with no change to the most recent jdk-13+25, and also seen in jdk-14+1. All builds fail with Compiling 12 properties into resource bundles for jdk.jdeps # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 2155274940 bytes for AllocateHeap # An error report file with more information is saved as: It looks like the normal build instead of the bootcycle build succeeds. Does anybody else is doing regular ix86 builds and could help narrowing down when this started to fail? Thanks, Matthias From david.holmes at oracle.com Fri Jun 14 13:10:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Jun 2019 23:10:07 +1000 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: Hi Matthias, On 14/06/2019 10:57 pm, Matthias Klose wrote: > My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I > tried jdk-13+22, which didn't build anymore, with no change to the most recent > jdk-13+25, and also seen in jdk-14+1. > > All builds fail with > > Compiling 12 properties into resource bundles for jdk.jdeps > # > # There is insufficient memory for the Java Runtime Environment to continue. > # Native memory allocation (malloc) failed to allocate 2155274940 bytes for > AllocateHeap > # An error report file with more information is saved as: Do you have the full stack for that? It might shed some light. Thanks, David > It looks like the normal build instead of the bootcycle build succeeds. Does > anybody else is doing regular ix86 builds and could help narrowing down when > this started to fail? > > Thanks, Matthias > From shade at redhat.com Fri Jun 14 13:26:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jun 2019 15:26:32 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: On 6/14/19 2:57 PM, Matthias Klose wrote: > My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I > tried jdk-13+22, which didn't build anymore, with no change to the most recent > jdk-13+25, and also seen in jdk-14+1. > > All builds fail with > > Compiling 12 properties into resource bundles for jdk.jdeps > # > # There is insufficient memory for the Java Runtime Environment to continue. > # Native memory allocation (malloc) failed to allocate 2155274940 bytes for > AllocateHeap This looks like the environmental trouble? It seems to try to allocate 2G heap, and cannot find (contiguous) memory for it? I would suspect recent changes to make it more likely, for example: https://bugs.openjdk.java.net/browse/JDK-8224871 > # An error report file with more information is saved as: > > It looks like the normal build instead of the bootcycle build succeeds. Does > anybody else is doing regular ix86 builds and could help narrowing down when > this started to fail? I build and test x86_32 regularly, but not bootcycle it. Current jdk/jdk does not build on x86_32, due to JDK-8225695. Current jdk/jdk13 build and runs on x86_32 fine, tier1 seems good too. -Aleksey From doko at ubuntu.com Fri Jun 14 14:02:03 2019 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 14 Jun 2019 16:02:03 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> On 14.06.19 15:10, David Holmes wrote: > Hi Matthias, > > On 14/06/2019 10:57 pm, Matthias Klose wrote: >> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I >> tried jdk-13+22, which didn't build anymore, with no change to the most recent >> jdk-13+25, and also seen in jdk-14+1. >> >> All builds fail with >> >> Compiling 12 properties into resource bundles for jdk.jdeps >> # >> # There is insufficient memory for the Java Runtime Environment to continue. >> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >> AllocateHeap >> # An error report file with more information is saved as: > > Do you have the full stack for that? It might shed some light. now attached. From doko at ubuntu.com Fri Jun 14 14:10:52 2019 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 14 Jun 2019 16:10:52 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> References: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> Message-ID: <1ba8c918-841d-b2ec-43bb-e2521d4b9049@ubuntu.com> On 14.06.19 16:02, Matthias Klose wrote: > On 14.06.19 15:10, David Holmes wrote: >> Hi Matthias, >> >> On 14/06/2019 10:57 pm, Matthias Klose wrote: >>> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I >>> tried jdk-13+22, which didn't build anymore, with no change to the most recent >>> jdk-13+25, and also seen in jdk-14+1. >>> >>> All builds fail with >>> >>> Compiling 12 properties into resource bundles for jdk.jdeps >>> # >>> # There is insufficient memory for the Java Runtime Environment to continue. >>> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >>> AllocateHeap >>> # An error report file with more information is saved as: >> >> Do you have the full stack for that? It might shed some light. > > now attached. > From coderodd3 at gmail.com Fri Jun 14 15:34:34 2019 From: coderodd3 at gmail.com (Rodion Efremov) Date: Fri, 14 Jun 2019 18:34:34 +0300 Subject: Slightly faster java.util.Arrays.byteSort(byte[]) Message-ID: Good evening! I managed to improve the JDK 8 java.util.Arrays.sort(byte[]) performance-wise [1]. The (warmed up) demonstration program produces more or less optimistic results on arrays of 1e8 bytes: seed = 1560526264738 java.util.Arrays.sort(byte[]) in 87.643701 milliseconds. java.util.Arrays.parallelSort(byte[]) in 301.329701 milliseconds. net.coderodde.Arrays.sort(byte[]) in 62.0763 milliseconds. Algorithms agree: true I would like to hear any comments on how to make it eligible for inclusion in JDK. Best regards, Rodion E. References: [1] https://gist.github.com/coderodde/493407bc1c57352b53c2aa18b5c9a7a8 From bradford.wetmore at oracle.com Fri Jun 14 23:06:03 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 14 Jun 2019 16:06:03 -0700 Subject: Updated: Using the Netbeans IDE to work on JDK library development In-Reply-To: References: Message-ID: <65702f9e-9e54-9e20-ad8d-2cccb653a149@oracle.com> [This updates an earlier version of this document from a couple years ago.] Apache's Netbeans 11 has progressed to the point where developing/debugging JDK 13/14 library builds (exploded and image) is now quite usable with a couple of add-ons. Debugging my latest project was actually quite enjoyable. Please understand: I'm not a Netbeans power user, I'm just sharing what has worked for me in hopes this might save you some time. There are always better ways of doing things. 1. Build a JDK to debug. 1a. If you're in Oracle and want to use jib and closed source, clone/configure the current source from the closed/open repositories: % hg clone jdk % cd jdk % bash ./get_source.sh (clones corresponding open repo) % bash jib.sh configure -- \ --with-default-make-target=jdk ...other options... 1b. If you're external to Oracle, clone/configure the source from the open repository: % hg clone http://hg.openjdk.java.net/jdk/jdk jdk % cd jdk % bash configure \ --with-default-make-target=jdk ...other options... 2. Build the JDK: % cd build/linux-x64 % make 3. Download Apache NetBeans (incubating 11.0 version). https://netbeans.apache.org/ % unzip incubating-netbeans-11.0-bin.zip If you are using Windows, you'll need to make the .exe/.dll bits executable: % cd netbeans* % find . -type f -name '*.exe' -exec chmod +x {} \; % find . -type f -name '*.dll' -exec chmod +x {} \; Be sure to have a recent JDK build for netbeans_jdkhome. If NB can't find a JDK in your path, you can hardcode it in etc/netbeans.conf: netbeans_jdkhome="/java/bootdirs/jdk-12.0.1" It was also recommended to me to have lots of initial memory: netbeans_default_options="-J-Xms2048m ..." 3. Start NetBeans: % bin/netbeans # Solaris/Linux/MacOS/etc. % bin/netbeans64.exe # Windows 4. Install Jan Lahoda's (Oracle JDK/Netbeans) "JDK Project for NetBeans" plugin, and "JTReg Support" if you are using JTReg. . In Tools->Plugins menu go to Settings . Update proxy if needed. . Click Add button . In the URL paste: http://lahoda.info/hudson/job/nb-jdk-project/lastSuccessfulBuild/artifact/build/updates/updates.xml . In Configuration of Update Centers, enable the 8.2 plugins Center. . In the Available Plugins tab, install: . JDK Project for NetBeans . JTReg Support . nb-javac . You can also click ?Check for Newest? in "Updates" tab in case your NetBeans install is out of date. Restart NetBeans. 5. Add your JDK 13/14 exploded build as a Java Platform: . Tools->Java Platforms->Add Platform /export/home/me/build/linux-x64/jdk . Pick a platform name. Do not add sources, they will be found by the JDK Project (above and below). (gensrc/shared/platform/closed) . Finish 6. Navigate to and open the Java module directories you'll be using. e.g. /export/home/me jdk/src/java.base jdk/src/jdk.crypto.ec The module sources for debugging the platform will be found in these open modules. The very first time you open a module, it may take a couple minutes to scan through everything (source/binary/etc). Restarts are faster after things are cached. 7. Next, depending on whether you'll debug a standalone app or a JTREG test from the test directories: 7a. Standalone: create a test project app as normal, then select the JDK platform. . Right click on project, select Properties. . Choose libraries, select the platform you just created. 7b. JTREG: In the module you opened (above), navigate to the jdk test directory. e.g. ${jdkRoot}/jdk/test Then select the exact test you want to run, then "Debug->Debug Test File". It takes a little while to load, and there is some System.out/System.err weirdness: System.err is delivered much later than System.out, or even lost if the app exits quickly. NOTE WELL: The JTReg plugin understands the JTReg directives, however (currently) debugging a JTReg test will trigger a remake of the entire(!) JDK platform. Turn this behavior off by right clicking on the java.base module, then "properties", then set "Never" to the question of "Build before running tests." It will take a while to scan through the test directories (source/binary/etc). Restarts are faster as things are cached. 8. Set a break point in your app(s) and start debugging. You should be able to "Step In (F7)" to the JDK library code. I have been successfully able to debug multi-process client/server code by setting breakpoints in both the client and server code, then "Debug Project" each project. 9. If you make any changes (think/edit/compile) to your JDK code, I suggest stopping the debugger(s), then use a separate window to do the make. For a simple rebuild of the Java classes in javax/net/ssl + sun/security/ssl, I do: # cwd: build/*-normal-server-fastdebug % make LOG=debug \ JDK_FILTER=javax/net/ssl,sun/security/ssl \ java.base-java-only # or java.base-only Netbeans will notice any changes and reload as needed. Then restart the debugger. 10. If you use an external editor to edit your code, any breakpoints might get confused. e.g. if you have a breakpoint on line 51, and externally you add a line, Netbeans won't realize that the breakpoint should be on line 52. If you edit within Netbeans, this doesn't happen. I would like to make a wiki page with this info at some point, so if you have any comments, let me know. Good luck, Brad From pavel.rappo at oracle.com Sun Jun 16 13:37:45 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sun, 16 Jun 2019 14:37:45 +0100 Subject: Slightly faster java.util.Arrays.byteSort(byte[]) In-Reply-To: References: Message-ID: Hi Rodion, A more appropriate place for your email would be the core-libs-dev mailing list, so CC'ing that list. > On 14 Jun 2019, at 16:34, Rodion Efremov wrote: > > Good evening! > > I managed to improve the JDK 8 java.util.Arrays.sort(byte[]) > performance-wise [1]. The (warmed up) demonstration program produces more > or less optimistic results on arrays of 1e8 bytes: > > seed = 1560526264738 > java.util.Arrays.sort(byte[]) in 87.643701 milliseconds. > java.util.Arrays.parallelSort(byte[]) in 301.329701 milliseconds. > net.coderodde.Arrays.sort(byte[]) in 62.0763 milliseconds. > Algorithms agree: true > > I would like to hear any comments on how to make it eligible for inclusion > in JDK. > > Best regards, > Rodion E. > > References: > [1] https://gist.github.com/coderodde/493407bc1c57352b53c2aa18b5c9a7a8 From orionllmain at gmail.com Mon Jun 17 06:11:29 2019 From: orionllmain at gmail.com (Zheka Kozlov) Date: Mon, 17 Jun 2019 13:11:29 +0700 Subject: Slightly faster java.util.Arrays.byteSort(byte[]) In-Reply-To: References: Message-ID: Hi Rodion. Your implementation is indeed a bit faster on large arrays. However, it's much slower on small arrays (~10 elements). My JMH benchmark says it is about 7 times slower. ??, 15 ???. 2019 ?. ? 03:36, Rodion Efremov : > Good evening! > > I managed to improve the JDK 8 java.util.Arrays.sort(byte[]) > performance-wise [1]. The (warmed up) demonstration program produces more > or less optimistic results on arrays of 1e8 bytes: > > seed = 1560526264738 > java.util.Arrays.sort(byte[]) in 87.643701 milliseconds. > java.util.Arrays.parallelSort(byte[]) in 301.329701 milliseconds. > net.coderodde.Arrays.sort(byte[]) in 62.0763 milliseconds. > Algorithms agree: true > > I would like to hear any comments on how to make it eligible for inclusion > in JDK. > > Best regards, > Rodion E. > > References: > [1] https://gist.github.com/coderodde/493407bc1c57352b53c2aa18b5c9a7a8 > From jianglizhou at google.com Mon Jun 17 22:47:34 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 17 Jun 2019 15:47:34 -0700 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> References: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> Message-ID: Hi Matthias, Do you have a bug with the trace attached? I couldn't find any attachment in the email. Best regards, Jiangli On Fri, Jun 14, 2019 at 7:02 AM Matthias Klose wrote: > On 14.06.19 15:10, David Holmes wrote: > > Hi Matthias, > > > > On 14/06/2019 10:57 pm, Matthias Klose wrote: > >> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. > After that I > >> tried jdk-13+22, which didn't build anymore, with no change to the most > recent > >> jdk-13+25, and also seen in jdk-14+1. > >> > >> All builds fail with > >> > >> Compiling 12 properties into resource bundles for jdk.jdeps > >> # > >> # There is insufficient memory for the Java Runtime Environment to > continue. > >> # Native memory allocation (malloc) failed to allocate 2155274940 bytes > for > >> AllocateHeap > >> # An error report file with more information is saved as: > > > > Do you have the full stack for that? It might shed some light. > > now attached. > > From aph at redhat.com Wed Jun 19 12:12:14 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Jun 2019 13:12:14 +0100 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: On 6/14/19 2:26 PM, Aleksey Shipilev wrote: > Current jdk/jdk does not build on x86_32, due to JDK-8225695. Bootcycle works for me, but I'm building on a 64-bit system. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jun 19 12:12:26 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Jun 2019 13:12:26 +0100 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: <352fea90-2cf2-adca-53c8-e2fa80da32b6@redhat.com> On 6/14/19 1:57 PM, Matthias Klose wrote: > Compiling 12 properties into resource bundles for jdk.jdeps > # > # There is insufficient memory for the Java Runtime Environment to continue. > # Native memory allocation (malloc) failed to allocate 2155274940 bytes for > AllocateHeap > # An error report file with more information is saved as: > > It looks like the normal build instead of the bootcycle build succeeds. Does > anybody else is doing regular ix86 builds and could help narrowing down when > this started to fail? Is this a 32-bit x86 kernel virtual machione or are you building a 32-bit JDK in a 64-bit environment? What does cat /proc/meminfo say? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ioi.lam at oracle.com Wed Jun 19 17:06:17 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 19 Jun 2019 10:06:17 -0700 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <352fea90-2cf2-adca-53c8-e2fa80da32b6@redhat.com> References: <352fea90-2cf2-adca-53c8-e2fa80da32b6@redhat.com> Message-ID: On 6/19/19 5:12 AM, Andrew Haley wrote: > On 6/14/19 1:57 PM, Matthias Klose wrote: >> Compiling 12 properties into resource bundles for jdk.jdeps >> # >> # There is insufficient memory for the Java Runtime Environment to continue. >> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >> AllocateHeap >> # An error report file with more information is saved as: >> >> It looks like the normal build instead of the bootcycle build succeeds. Does >> anybody else is doing regular ix86 builds and could help narrowing down when >> this started to fail? > Is this a 32-bit x86 kernel virtual machione or are you building a > 32-bit JDK in a 64-bit environment? What does cat /proc/meminfo say? > Andrew, the bug that causes the broken build is https://bugs.openjdk.java.net/browse/JDK-8226404 The failure doesn't always happen, but it's more likely to happen when your BOOT_JDK is significantly different than the JDK sources in both age and 32/64 bit-ness. Thanks - Ioi From doko at ubuntu.com Wed Jun 19 20:44:05 2019 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 19 Jun 2019 22:44:05 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: <352fea90-2cf2-adca-53c8-e2fa80da32b6@redhat.com> Message-ID: On 19.06.19 19:06, Ioi Lam wrote: > On 6/19/19 5:12 AM, Andrew Haley wrote: >> On 6/14/19 1:57 PM, Matthias Klose wrote: >>> Compiling 12 properties into resource bundles for jdk.jdeps >>> # >>> # There is insufficient memory for the Java Runtime Environment to continue. >>> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >>> AllocateHeap >>> # An error report file with more information is saved as: >>> >>> It looks like the normal build instead of the bootcycle build succeeds.? Does >>> anybody else is doing regular ix86 builds and could help narrowing down when >>> this started to fail? >> Is this a 32-bit x86 kernel virtual machione or are you building a >> 32-bit JDK in a 64-bit environment? What does cat /proc/meminfo say? this is a pure 32bit chroot, run with a 64bit kernel, using the linux32 personality to enter the chroot. The build should not see any hint about the 64bit kernel. The bootstrap JDK is OpenJDK 12 (32bit). Most buildd infrastructure for any Linux distribution doesn't mix 32/64 bit, including Fedora, Debian, Ubuntu. > Andrew, the bug that causes the broken build is > https://bugs.openjdk.java.net/browse/JDK-8226404 > > The failure doesn't always happen, but it's more likely to happen when your > BOOT_JDK is significantly different than the JDK sources in both age and 32/64 > bit-ness. yes, using the work-around, the build succeeds. Thanks, Matthias From li.jiang at oracle.com Sat Jun 22 02:48:52 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Sat, 22 Jun 2019 10:48:52 +0800 Subject: JDK 13 message drop 10 kicked off Message-ID: <06fc8156-2791-f933-a812-aa32e28759c6@oracle.com> Hi, As scheduled, we kicked off the l10n message drop 10 for JDK 13 on June 21. The resource extraction was based on the jdk/jdk13 repo. The resource translation and integration would be done before July 12. Note: The new added resource files might be missing in this message drop if you didn't notify me the changes. If you add any resource files in JDK 13, pls let me know. We have scheduled the second msg drop on 2019-07-26, pls make sure your latest change can catch this drop. Thanks, Leo From jai.forums2013 at gmail.com Sat Jun 29 09:16:47 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 29 Jun 2019 14:46:47 +0530 Subject: [PATCH] Properly (.hg)ignore the JTwork and JTreport directories Message-ID: Can I please get a review and a sponsor for this patch[1] which fixes the .hgignore file to take into account the JTreport and JTwork directories that can reside at the root of the repository. In its current form (without this patch), if I have these directories at the root of my repo, then these aren't being ignored. I see output like below for commands like "hg st": $> hg st ? JTreport/html/config.html ? JTreport/html/env.html ? JTreport/html/error.html ? JTreport/html/error_gr.html ? JTreport/html/excluded.html ? JTreport/html/failed.html ... ? JTwork/classes/0/java/net/httpclient/ALPNFailureTest.d/ALPNFailureTest$ReadOnlyServer.class ? JTwork/classes/0/java/net/httpclient/ALPNFailureTest.d/ALPNFailureTest.class ? JTwork/classes/0/java/net/httpclient/ALPNProxyFailureTest.d/ALPNFailureTest$ReadOnlyServer.class ? JTwork/classes/0/java/net/httpclient/ALPNProxyFailureTest.d/ALPNFailureTest.class ... With the proposed patch, these directories are correctly ignored. With this patch, I also tested that similar directories which are within sub-directories of the repo are ignored too, by running arbitrary jtreg tests to generate such directories at different locations. The change in that patch uses the "glob" syntax noted in [2] to properly exclude these directories. I haven't explicitly tested it for the ".git" directory being ignored in that list, but I expect the change is needed for that directory too and hence decided to include it in the patch. I'm a bit new to the contribution process and don't know if changes like these need a JBS issue to be created. If it's needed, I can create one and regenerate a webrev to reference it. So please do let me know. FWIW, I am on: hg --version Mercurial Distributed SCM (version 4.3.1) (see https://mercurial-scm.org for more information) [1] http://cr.openjdk.java.net/~jpai/webrev/hgignore-patch/webrev/ [2] https://www.selenic.com/mercurial/hgignore.5.html -Jaikiran From david.holmes at oracle.com Sun Jun 30 05:33:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 30 Jun 2019 15:33:23 +1000 Subject: [PATCH] Properly (.hg)ignore the JTwork and JTreport directories In-Reply-To: References: Message-ID: <85fb7b26-d699-98e2-0a42-8271d1d1f565@oracle.com> Hi Jaikiran, On 29/06/2019 5:16 am, Jaikiran Pai wrote: > Can I please get a review and a sponsor for this patch[1] which fixes > the .hgignore file to take into account the JTreport and JTwork > directories that can reside at the root of the repository. I don't see any problem with current settings. I wonder if it is hg version specific? > hg status -i | grep "I JT" I JTwork/error.html But this patch doesn't seem to cause me any problems either. David ----- > In its current form (without this patch), if I have these directories at > the root of my repo, then these aren't being ignored. I see output like > below for commands like "hg st": > > $> hg st > > ? JTreport/html/config.html > ? JTreport/html/env.html > ? JTreport/html/error.html > ? JTreport/html/error_gr.html > ? JTreport/html/excluded.html > ? JTreport/html/failed.html > ... > > ? > JTwork/classes/0/java/net/httpclient/ALPNFailureTest.d/ALPNFailureTest$ReadOnlyServer.class > ? > JTwork/classes/0/java/net/httpclient/ALPNFailureTest.d/ALPNFailureTest.class > ? > JTwork/classes/0/java/net/httpclient/ALPNProxyFailureTest.d/ALPNFailureTest$ReadOnlyServer.class > ? > JTwork/classes/0/java/net/httpclient/ALPNProxyFailureTest.d/ALPNFailureTest.class > > ... > > With the proposed patch, these directories are correctly ignored. With > this patch, I also tested that similar directories which are within > sub-directories of the repo are ignored too, by running arbitrary jtreg > tests to generate such directories at different locations. > > The change in that patch uses the "glob" syntax noted in [2] to properly > exclude these directories. I haven't explicitly tested it for the ".git" > directory being ignored in that list, but I expect the change is needed > for that directory too and hence decided to include it in the patch. > > I'm a bit new to the contribution process and don't know if changes like > these need a JBS issue to be created. If it's needed, I can create one > and regenerate a webrev to reference it. So please do let me know. > > FWIW, I am on: > > hg --version > Mercurial Distributed SCM (version 4.3.1) > (see https://mercurial-scm.org for more information) > > [1] http://cr.openjdk.java.net/~jpai/webrev/hgignore-patch/webrev/ > > [2] https://www.selenic.com/mercurial/hgignore.5.html > > -Jaikiran > > From jai.forums2013 at gmail.com Sun Jun 30 12:22:59 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 30 Jun 2019 17:52:59 +0530 Subject: [PATCH] Properly (.hg)ignore the JTwork and JTreport directories In-Reply-To: <85fb7b26-d699-98e2-0a42-8271d1d1f565@oracle.com> References: <85fb7b26-d699-98e2-0a42-8271d1d1f565@oracle.com> Message-ID: <10541bec-6399-0dbc-af06-2bd59d15b276@gmail.com> Hello David, On 30/06/19 11:03 AM, David Holmes wrote: > Hi Jaikiran, > > On 29/06/2019 5:16 am, Jaikiran Pai wrote: >> Can I please get a review and a sponsor for this patch[1] which fixes >> the .hgignore file to take into account the JTreport and JTwork >> directories that can reside at the root of the repository. > > I don't see any problem with current settings. I wonder if it is hg > version specific? > That's possible. I am on macOS (10.14.1) with mercurial version at 4.3.1: hg --version Mercurial Distributed SCM (version 4.3.1) (see https://mercurial-scm.org for more information) I will upgrade to latest release of mercurial and see if it changes anything. -Jaikiran > ?> hg status -i | grep "I JT" > I JTwork/error.html > > But this patch doesn't seem to cause me any problems either. > > David > ----- > >> In its current form (without this patch), if I have these directories at >> the root of my repo, then these aren't being ignored. I see output like >> below for commands like "hg st": >> >> $> hg st >> >> ? JTreport/html/config.html >> ? JTreport/html/env.html >> ? JTreport/html/error.html >> ? JTreport/html/error_gr.html >> ? JTreport/html/excluded.html >> ? JTreport/html/failed.html >> ... >> >> ? >> JTwork/classes/0/java/net/httpclient/ALPNFailureTest.d/ALPNFailureTest$ReadOnlyServer.class >> >> ? >> JTwork/classes/0/java/net/httpclient/ALPNFailureTest.d/ALPNFailureTest.class >> >> ? >> JTwork/classes/0/java/net/httpclient/ALPNProxyFailureTest.d/ALPNFailureTest$ReadOnlyServer.class >> >> ? >> JTwork/classes/0/java/net/httpclient/ALPNProxyFailureTest.d/ALPNFailureTest.class >> >> >> ... >> >> With the proposed patch, these directories are correctly ignored. With >> this patch, I also tested that similar directories which are within >> sub-directories of the repo are ignored too, by running arbitrary jtreg >> tests to generate such directories at different locations. >> >> The change in that patch uses the "glob" syntax noted in [2] to properly >> exclude these directories. I haven't explicitly tested it for the ".git" >> directory being ignored in that list, but I expect the change is needed >> for that directory too and hence decided to include it in the patch. >> >> I'm a bit new to the contribution process and don't know if changes like >> these need a JBS issue to be created. If it's needed, I can create one >> and regenerate a webrev to reference it. So please do let me know. >> >> FWIW, I am on: >> >> hg --version >> Mercurial Distributed SCM (version 4.3.1) >> (see https://mercurial-scm.org for more information) >> >> [1] http://cr.openjdk.java.net/~jpai/webrev/hgignore-patch/webrev/ >> >> [2] https://www.selenic.com/mercurial/hgignore.5.html >> >> -Jaikiran >> >> From david.holmes at oracle.com Sun Jun 30 22:30:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Jul 2019 08:30:14 +1000 Subject: [PATCH] Properly (.hg)ignore the JTwork and JTreport directories In-Reply-To: <10541bec-6399-0dbc-af06-2bd59d15b276@gmail.com> References: <85fb7b26-d699-98e2-0a42-8271d1d1f565@oracle.com> <10541bec-6399-0dbc-af06-2bd59d15b276@gmail.com> Message-ID: <600f6e7f-b5c7-5c9b-1f8e-33033e3c64c6@oracle.com> On 30/06/2019 10:22 pm, Jaikiran Pai wrote: > Hello David, > > On 30/06/19 11:03 AM, David Holmes wrote: >> Hi Jaikiran, >> >> On 29/06/2019 5:16 am, Jaikiran Pai wrote: >>> Can I please get a review and a sponsor for this patch[1] which fixes >>> the .hgignore file to take into account the JTreport and JTwork >>> directories that can reside at the root of the repository. >> >> I don't see any problem with current settings. I wonder if it is hg >> version specific? >> > That's possible. I am on macOS (10.14.1) with mercurial version at 4.3.1: > > hg --version > Mercurial Distributed SCM (version 4.3.1) > (see https://mercurial-scm.org for more information) > > I will upgrade to latest release of mercurial and see if it changes > anything. I'm actually downrev at 3.4.2, on Linux. David > > -Jaikiran > > >> ?> hg status -i | grep "I JT" >> I JTwork/error.html >> >> But this patch doesn't seem to cause me any problems either. >> >> David >> ----- >> >>> In its current form (without this patch), if I have these directories at >>> the root of my repo, then these aren't being ignored. I see output like >>> below for commands like "hg st": >>> >>> $> hg st >>> >>> ? JTreport/html/config.html >>> ? JTreport/html/env.html >>> ? JTreport/html/error.html >>> ? JTreport/html/error_gr.html >>> ? JTreport/html/excluded.html >>> ? JTreport/html/failed.html >>> ... >>> >>> ? >>> JTwork/classes/0/java/net/httpclient/ALPNFailureTest.d/ALPNFailureTest$ReadOnlyServer.class >>> >>> ? >>> JTwork/classes/0/java/net/httpclient/ALPNFailureTest.d/ALPNFailureTest.class >>> >>> ? >>> JTwork/classes/0/java/net/httpclient/ALPNProxyFailureTest.d/ALPNFailureTest$ReadOnlyServer.class >>> >>> ? >>> JTwork/classes/0/java/net/httpclient/ALPNProxyFailureTest.d/ALPNFailureTest.class >>> >>> >>> ... >>> >>> With the proposed patch, these directories are correctly ignored. With >>> this patch, I also tested that similar directories which are within >>> sub-directories of the repo are ignored too, by running arbitrary jtreg >>> tests to generate such directories at different locations. >>> >>> The change in that patch uses the "glob" syntax noted in [2] to properly >>> exclude these directories. I haven't explicitly tested it for the ".git" >>> directory being ignored in that list, but I expect the change is needed >>> for that directory too and hence decided to include it in the patch. >>> >>> I'm a bit new to the contribution process and don't know if changes like >>> these need a JBS issue to be created. If it's needed, I can create one >>> and regenerate a webrev to reference it. So please do let me know. >>> >>> FWIW, I am on: >>> >>> hg --version >>> Mercurial Distributed SCM (version 4.3.1) >>> (see https://mercurial-scm.org for more information) >>> >>> [1] http://cr.openjdk.java.net/~jpai/webrev/hgignore-patch/webrev/ >>> >>> [2] https://www.selenic.com/mercurial/hgignore.5.html >>> >>> -Jaikiran >>> >>>