From Alan.Bateman at oracle.com Fri Aug 1 00:17:22 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Aug 2014 01:17:22 +0100 Subject: CFV: New jdk9 Reviewer: Rickard =?ISO-8859-1?Q?B=E4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <53DADC92.2050007@oracle.com> Vote: yes From vladimir.kozlov at oracle.com Fri Aug 1 00:33:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jul 2014 17:33:29 -0700 Subject: CFV: New jdk9 Reviewer: Rickard =?ISO-8859-1?Q?B=E4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <53DAE059.7060006@oracle.com> Vote: yes On 7/31/14 2:06 PM, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > From david.holmes at oracle.com Fri Aug 1 07:15:44 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Aug 2014 17:15:44 +1000 Subject: CFV: New jdk9 Reviewer: Rickard =?ISO-8859-1?Q?B=E4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <53DB3EA0.6060005@oracle.com> Vote: yes David On 1/08/2014 7:06 AM, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. Before > that he worked in Hotspot Serviceability group and participated in > porting JFR to Hotspot. For past year Rickard has been worked on C2 > optimizations which improve jsr292 performance. So far he has authored > 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 > and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From john.r.rose at oracle.com Fri Aug 1 15:34:16 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 1 Aug 2014 08:34:16 -0700 Subject: =?utf-8?Q?Re:_CFV:_New_jdk9_Reviewer:_Rickard_B=C3=A4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <606B7B33-ACFA-4A95-920D-1E7198FE00D2@oracle.com> Vote: yes From karen.kinnear at oracle.com Fri Aug 1 16:00:58 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 1 Aug 2014 12:00:58 -0400 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_jdk9_Reviewer=3A_Rickard_B=E4ckm?= =?iso-8859-1?Q?an?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: vote: yes Karen On Jul 31, 2014, at 5:06 PM, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. Before that he worked in Hotspot Serviceability group and participated in porting JFR to Hotspot. For past year Rickard has been worked on C2 optimizations which improve jsr292 performance. So far he has authored 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From joe.darcy at oracle.com Fri Aug 1 16:33:16 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Aug 2014 09:33:16 -0700 Subject: Update on lint warnings in the jdk repo In-Reply-To: <53D018CE.3030304@oracle.com> References: <53D018CE.3030304@oracle.com> Message-ID: <53DBC14C.8090301@oracle.com> Hello, I'm happy to report that after an extensive cleanup effort, raw types and unchecked warnings have been eliminated from the jdk repo and those warnings are successfully enabled in the build: 8039102: Add raw and unchecked lint warnings to build of jdk repository http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d766f563d30d Next up, deprecation :-) -Joe On 07/23/2014 01:19 PM, Joe Darcy wrote: > Hello, > > A quick update on lint warnings in the jdk repo, the unchecked and > rawtypes warnings are nearly eliminated! > > Once some warning fixes already in the client repo [1] are integrated > into the dev repo and the sole open subtask of > > JDK-8039096: Fix raw and unchecked lint warnings in jdk libraries > > is fixed in dev, all the unchecked and rawtypes warnings will be > resolved. At that point, those warnings will be enabled in the build > (after any straggling newly-introduced raw and unchecked warnings are > cleaned up). The warnings should be able to be enabled within the next > few weeks. > > Of all the javac lint warning categories, once rawtypes and unchecked > are cleared, that will just leave ~500 deprecation warnings in the > open repo. Assuming deprecation warning on import statements can be > elided [2], I'd like to approach eliminating deprecation warnings > differently than the previously eliminated categories of lint > warnings. Resolving issues in previous lint warning categories relied > primarily on general Java language expertise without much > component-area expertise being necessary; resolving deprecations > warnings has the reversed expertise balance. Therefore, I propose to > address the deprecation warnings by suppressing them in a small number > of changesets and at the same time filing follow-up bugs at, say, a > package-level granularity for the component teams to do a more > thorough investigation of replacingg the deprecated functionality. > That approach should be quick to execute, will not worsen the code > quality in the jdk repo, and will prevent any unintended new > deprecation warnings from being added. > > Comments? > > Thanks, > > -Joe > > [1] JDK-8049797: Fix raw and unchecked lint warnings in > javax.swing.SortingFocusTraversalPolicy > JDK-8042872: Fix raw and unchecked warnings in sun.applet > > [2] JDK-8042566: Elide deprecation warnings on import statements From christian.thalinger at oracle.com Fri Aug 1 18:02:50 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 1 Aug 2014 11:02:50 -0700 Subject: Result: New jdk9 Reviewer: Volker Simonis In-Reply-To: <53DACF60.1070906@oracle.com> References: <53DACF60.1070906@oracle.com> Message-ID: <5A024618-95C7-4945-A933-DBD9358FD6E4@oracle.com> Sweet! With great power? ;-) On Jul 31, 2014, at 4:21 PM, Coleen Phillimore wrote: > Voting for Volker Simonis [1] is now closed. > > Yes: 26 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is > sufficient to approve the nomination. > > Coleen Phillimore > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-July/000990.html From christian.thalinger at oracle.com Fri Aug 1 18:03:48 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 1 Aug 2014 11:03:48 -0700 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_jdk9_Reviewer=3A_Rickard_B=E4ckm?= =?iso-8859-1?Q?an?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: Vote: yes On Jul 31, 2014, at 2:06 PM, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. Before that he worked in Hotspot Serviceability group and participated in porting JFR to Hotspot. For past year Rickard has been worked on C2 optimizations which improve jsr292 performance. So far he has authored 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From John.Coomes at oracle.com Sat Aug 2 01:42:11 2014 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 1 Aug 2014 18:42:11 -0700 Subject: CFV: New jdk9 Reviewer: Rickard =?iso-8859-1?Q?B=E4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <21468.16883.513040.503800@mykonos.us.oracle.com> Vote: yes -John From maurizio.cimadamore at oracle.com Sat Aug 2 14:04:46 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 02 Aug 2014 07:04:46 -0700 Subject: CFV: New jdk9 Reviewer: Rickard =?windows-1252?Q?B=E4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <53DCEFFE.7050405@oracle.com> Vote: yes Maurizio On 31/07/14 14:06, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. > Before that he worked in Hotspot Serviceability group and participated > in porting JFR to Hotspot. For past year Rickard has been worked on C2 > optimizations which improve jsr292 performance. So far he has authored > 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 > and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From bengt.rutisson at oracle.com Mon Aug 4 06:40:05 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 04 Aug 2014 08:40:05 +0200 Subject: CFV: New jdk9 Reviewer: Rickard =?ISO-8859-1?Q?B=E4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <53DF2AC5.9030705@oracle.com> Vote: yes Bengt On 2014-07-31 23:06, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. > Before that he worked in Hotspot Serviceability group and participated > in porting JFR to Hotspot. For past year Rickard has been worked on C2 > optimizations which improve jsr292 performance. So far he has authored > 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 > and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From stefan.karlsson at oracle.com Mon Aug 4 11:10:35 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 04 Aug 2014 13:10:35 +0200 Subject: CFV: New jdk9 Reviewer: Rickard =?windows-1252?Q?B=E4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <53DF6A2B.9010501@oracle.com> Vote: yes StefanK On 2014-07-31 23:06, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. > Before that he worked in Hotspot Serviceability group and participated > in porting JFR to Hotspot. For past year Rickard has been worked on C2 > optimizations which improve jsr292 performance. So far he has authored > 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 > and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From stefan.karlsson at oracle.com Mon Aug 4 13:42:05 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 04 Aug 2014 15:42:05 +0200 Subject: Result: New jdk9 Reviewer: Mikael Gerdin Message-ID: <53DF8DAD.3080504@oracle.com> |Voting for Mikael Gerdin [1] is now closed.| || |Yes: 13| |Veto: 0| |Abstain: 0| || |According to the Bylaws definition of Three-Vote Consensus, this is| |sufficient to approve the nomination.| || |Stefan Karlsson| || |[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-July/000955.html||**| From anthony.petrov at oracle.com Mon Aug 4 14:04:23 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 04 Aug 2014 18:04:23 +0400 Subject: CFV: New jdk9 Reviewer: Alexander Zuev In-Reply-To: <53C9B99A.3040606@oracle.com> References: <53C96717.3010200@oracle.com> <53C9B99A.3040606@oracle.com> Message-ID: <53DF92E7.7030503@oracle.com> Vote: YES -- best regards, Anthony On 7/19/2014 4:19 AM, Kumar Srinivasan wrote: > I hereby nominate Alexander Zuev (kizune) as a jdk9 Reviewer. > > Alexander (Alex) is a member of the LangTools team at Oracle, a > member of the AWT group and a committer to the macosx-port, > jdk7, jdk7u, jdk8, jdk8u, jdk9 projects as well as a security release > integrator. > > Alexander started his Java career in 1998 for Sun Microsystems, > working on the erstwhile HotJava browser and contributing to the > Mozilla browser. In 2003, he switched to the client team and has > contributed to the client libraries (Swing and AWT) as well as to the > Mac OS X porting project, he has implemented complex input methods > for JavaFX on Mac OS X. Recently he has been enhancing and fixing > the jdk and language tools, such as the java launcher, jar/pack200 tool, > performance and defense in depth fixes to the pack200 and unpack200 > tools. > > Alexander's contributions and review participation to the openjdk are > listed in [3] and [4]. > > Votes are due by: Aug 1, 2014, Midnight PDT. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [2]. > > Kumar Srinivasan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk9/dev/jdk/search/?rev=kizune&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/langtools/search/?rev=kizune&revcount=100 > > > > From konstantin.shefov at oracle.com Mon Aug 4 14:18:59 2014 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 04 Aug 2014 18:18:59 +0400 Subject: Fwd: RFR (XS) JDK-8051861 [TESTBUG] test "java/math/BigInteger/BigIntegerTest.java" does not hold Random value to have a possibility to reproduce it In-Reply-To: <53DF9298.3050307@oracle.com> References: <53DF8E5E.6020306@oracle.com> <53DF9298.3050307@oracle.com> Message-ID: <53DF9653.6050302@oracle.com> Hi, Fix looks fine to me. -Konstantin On 04.08.2014 18:03, vasily stolbov wrote: > > > > -------- Original Message -------- > Subject: RFR (XS) JDK-8051861 [TESTBUG] test > "java/math/BigInteger/BigIntegerTest.java" does not hold Random value > to have a possibility to reproduce it > Date: Mon, 04 Aug 2014 17:45:02 +0400 > From: vasily stolbov > Organization: Oracle Corporation > To: core-libs-dev at openjdk.java.net > > > > Hi, > > Please review and help me with integration: > > Problem: > java.math.BigInteger.BigIntegerTest uses java.math.Random(), so we have > no possibility to reproduce it. > > Solution: > Test gets start random seed from environment variable. > If this variable not exists, test write current random seed to log. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8051861 > Fix: (in attachment) > > Best regards, Vasily > > > > > > > > > From kumar.x.srinivasan at oracle.com Mon Aug 4 15:21:00 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 04 Aug 2014 08:21:00 -0700 Subject: Result: New JDK9 Reviewer: Alexander Zuev Message-ID: <53DFA4DC.1060008@oracle.com> The vote for Alexander Zuev [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. Kumar Srinivasan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-July/001019.htm and http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-August/001123.html From volker.simonis at gmail.com Mon Aug 4 15:37:30 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Aug 2014 17:37:30 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_jdk9_Reviewer=3A_Rickard_B=C3=A4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: Vote: yes On Thu, Jul 31, 2014 at 11:06 PM, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. Before that > he worked in Hotspot Serviceability group and participated in porting JFR to > Hotspot. For past year Rickard has been worked on C2 optimizations which > improve jsr292 performance. So far he has authored 41 changesets (see list > bellow). He is a Committer in jdk6, jdk7, jdk8 and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From marcus.lagergren at oracle.com Mon Aug 4 15:54:29 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 4 Aug 2014 17:54:29 +0200 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_jdk9_Reviewer=3A_Rickard_B=E4ckm?= =?iso-8859-1?Q?an?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <4DE49B30-142D-4D64-94E2-6A91C49FA50E@oracle.com> Vote: Yes! (with extreme pleasure) /M On 31 Jul 2014, at 23:06, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. Before that he worked in Hotspot Serviceability group and participated in porting JFR to Hotspot. For past year Rickard has been worked on C2 optimizations which improve jsr292 performance. So far he has authored 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From alexander.potochkin at oracle.com Tue Aug 5 12:09:24 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Tue, 05 Aug 2014 16:09:24 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov Message-ID: <53E0C974.9030604@oracle.com> I hereby nominate Dmitry Markov to JDK 9 Committer. Dmitry is a member of the Java SE sustaining team. He has spent most of that time working on the GUI and deployment issues. Dmitry already has a JDK7u and JDK8 committer status and contributed 13 changes to JDK9 so far: http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed Votes are due by 19th August 2014 23:59 GMT Only current JDK 9 Committers [1] 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 [2]. Thanks alexp [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From anthony.petrov at oracle.com Tue Aug 5 12:09:04 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 05 Aug 2014 16:09:04 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0C960.1050802@oracle.com> Vote: YES -- best regards, Anthony On 8/5/2014 4:09 PM, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From andrew.brygin at oracle.com Tue Aug 5 12:15:22 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Tue, 05 Aug 2014 16:15:22 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0CADA.7040804@oracle.com> Vote: YES Thanks, Andrew On 8/5/2014 4:09 PM, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From aleksej.efimov at oracle.com Tue Aug 5 12:43:49 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 05 Aug 2014 16:43:49 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0D185.6070201@oracle.com> Vote: YES Best Regards, Aleksej On 05.08.2014 16:09, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From artem.ananiev at oracle.com Tue Aug 5 13:31:32 2014 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 05 Aug 2014 17:31:32 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0DCB4.3000400@oracle.com> Vote: yes Artem On 8/5/2014 4:09 PM, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From ivan.gerasimov at oracle.com Tue Aug 5 13:52:11 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 05 Aug 2014 17:52:11 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0E18B.8040508@oracle.com> Vote: yes On 05.08.2014 16:09, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > From anton.litvinov at oracle.com Tue Aug 5 14:09:55 2014 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Tue, 05 Aug 2014 18:09:55 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0E5B3.6040908@oracle.com> Vote: yes Thank you, Anton On 8/5/2014 4:09 PM, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From alexander.zvegintsev at oracle.com Tue Aug 5 14:11:52 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 05 Aug 2014 18:11:52 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0E628.6020105@oracle.com> Vote: YES Thanks, Alexander. On 08/05/2014 04:09 PM, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From alexander.potochkin at oracle.com Tue Aug 5 14:14:46 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Tue, 05 Aug 2014 18:14:46 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev Message-ID: <53E0E6D6.6070903@oracle.com> I hereby nominate Anton Nashatyrev to jdk9 Committer. Anton is a member of the Java SE sustaining team. He has spent most of that time working on the GUI and deployment issues. He has contributed 14 changes to jdk7u so far: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 Votes are due by August 19, 2014. Only current JDK7u Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thanks, alexp [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote From alexander.zvegintsev at oracle.com Tue Aug 5 14:13:53 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 05 Aug 2014 18:13:53 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E0E6A1.8050605@oracle.com> Vote: YES Thanks, Alexander. On 08/05/2014 06:14 PM, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From kirill.kirichenko at oracle.com Tue Aug 5 14:15:52 2014 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Tue, 05 Aug 2014 18:15:52 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E0E718.1070809@oracle.com> Vote: yes On 05.08.2014 18:14, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From anthony.petrov at oracle.com Tue Aug 5 14:17:08 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 05 Aug 2014 18:17:08 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E0E764.4080509@oracle.com> Vote: YES -- best regards, Anthony On 8/5/2014 6:14 PM, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From anton.litvinov at oracle.com Tue Aug 5 14:22:10 2014 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Tue, 05 Aug 2014 18:22:10 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E0E892.7020500@oracle.com> Vote: yes Thank you, Anton On 8/5/2014 6:14 PM, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From andrew.brygin at oracle.com Tue Aug 5 14:22:34 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Tue, 05 Aug 2014 18:22:34 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E0E8AA.7000905@oracle.com> Vote: YES Thanks, Andrew On 8/5/2014 6:14 PM, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From dalibor.topic at oracle.com Tue Aug 5 14:53:10 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 05 Aug 2014 16:53:10 +0200 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E0EFD6.7050203@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Aug 5 14:54:29 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 05 Aug 2014 16:54:29 +0200 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0F025.70004@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From artem.ananiev at oracle.com Tue Aug 5 15:06:37 2014 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 05 Aug 2014 19:06:37 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E0F2FD.4080709@oracle.com> Vote: yes Artem On 8/5/2014 6:14 PM, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From sean.mullan at oracle.com Tue Aug 5 15:28:44 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 05 Aug 2014 11:28:44 -0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E0F82C.6080600@oracle.com> Vote: yes --Sean On 08/05/2014 10:14 AM, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From sean.mullan at oracle.com Tue Aug 5 15:30:48 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 05 Aug 2014 11:30:48 -0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E0F8A8.1060704@oracle.com> Vote: yes --Sean On 08/05/2014 08:09 AM, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From mandy.chung at oracle.com Tue Aug 5 15:42:01 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Aug 2014 08:42:01 -0700 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: <53E0FB49.40108@oracle.com> Vote: yes Mandy From david.dehaven at oracle.com Tue Aug 5 15:58:12 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 5 Aug 2014 08:58:12 -0700 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <3BA36BB1-FC22-4EB8-9AC9-69F0DBBF7241@oracle.com> Vote: yes -DrD- > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From joe.darcy at oracle.com Tue Aug 5 16:25:52 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 05 Aug 2014 09:25:52 -0700 Subject: Swing generification changes in JDK 9 b24 In-Reply-To: <53D9073A.90108@oracle.com> References: <53D4152E.20001@oracle.com> <53D9073A.90108@oracle.com> Message-ID: <53E10590.2010801@oracle.com> Hello, A quick follow-up, I've filed JDK-8054360: Refine generification of javax.swing https://bugs.openjdk.java.net/browse/JDK-8054360#comment-13532821 to tweak the generification of TreeNode and possibly a few other types. Thanks for the feedback, -Joe On 7/30/2014 7:54 AM, Joe Darcy wrote: > Hi Andrej and Martijn, > > Thanks for responding. > > On 7/28/2014 5:04 AM, Andrej Golovnin wrote: >> Hi Joe, >> >> I'm not sure if it is what you are looking for. > > For context, the general evolution policy of the JDK: > > http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy > > > includes "avoid introducing source incompatibilities." As this is a > large generification change to swing, some level of source > incompatibility may be acceptable in a platform release like JDK 9, > but if there are very widespread issues, some of the changes may be > reconsidered. > > The request to try out the changes was to get enough information to > see if any (partial) reconsideration was warranted. > > >> But I tried to compile my project with the new build. And I got a >> compile error in one of my classes. I have a class which implements >> the TreeNode interface and looks like this: >> >> class MyTreeNode implements TreeNode { >> .... >> @Override >> public Enumeration children() { >> return ....; >> } >> ... >> } >> >> The error message is: "return type Enumeration is not >> compatible with Enumeration". >> >> If I change (see attached patch) the definition of the >> children()-method in the TreeNode-interface to: >> >> public interface TreeNode { >> ... >> Enumeration children(); >> ... >> } >> >> then my code compiles. > > That design issue was raised during code review: > > http://mail.openjdk.java.net/pipermail/swing-dev/2014-June/003643.html > > "It was not immediately clear how javax.swing.tree.TreeNode.children(), > which returns a raw Enumeration, should be generified. I changed it to > > Enumeration children(); > > and that seems to work fine. Something like > > Enumeration > > with a covariant override would save a few casts in a private > implementation, but generally doesn't seem to be a good trade-off since > many normal clients could be inconvenienced dealing with the wildcard." > > If generified subclasses of TreeNode are common, the generification of > children may need reconsideration. > >> >> BTW, a good test for your changes would be to try to compile NetBeans >> and/or IntelliJ IDEA using the new JDK 9 build. They both are really >> big Swing applications which make use maybe of all Swing APIs. >> >> > > My preference would be for the NetBeans and IntelliJ teams to do that > task :-) > > Thanks, > > -Joe From alexander.potochkin at oracle.com Tue Aug 5 16:32:43 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Tue, 05 Aug 2014 20:32:43 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <0DAEE211-088F-4CC6-971A-42CE65BEE8E7@oracle.com> References: <53E0C974.9030604@oracle.com> <0DAEE211-088F-4CC6-971A-42CE65BEE8E7@oracle.com> Message-ID: <53E1072B.2070502@oracle.com> resending to the alias On 8/5/2014 7:57 PM, David DeHaven wrote: > Vote: yes > > -DrD- > >> I hereby nominate Dmitry Markov to JDK 9 Committer. >> >> Dmitry is a member of the Java SE sustaining team. >> He has spent most of that time working on the GUI and deployment issues. >> >> Dmitry already has a JDK7u and JDK8 committer status >> and contributed 13 changes to JDK9 so far: >> >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed >> >> Votes are due by 19th August 2014 23:59 GMT >> >> Only current JDK 9 Committers [1] 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 [2]. >> >> Thanks >> alexp >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote From alexander.potochkin at oracle.com Tue Aug 5 16:33:31 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Tue, 05 Aug 2014 20:33:31 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0FA2C.5040503@oracle.com> References: <53E0E6D6.6070903@oracle.com> <53E0FA2C.5040503@oracle.com> Message-ID: <53E1075B.9070001@oracle.com> resending to the alias On 8/5/2014 7:37 PM, Yuri Nesterenko wrote: > Vote: yes > > -yan > > On 08/05/2014 06:14 PM, Alexander Potochkin wrote: >> I hereby nominate Anton Nashatyrev to jdk9 Committer. >> >> Anton is a member of the Java SE sustaining team. >> He has spent most of that time working on the GUI and deployment issues. >> >> He has contributed 14 changes to jdk7u so far: >> >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 >> >> Votes are due by August 19, 2014. >> >> Only current JDK7u Committers [1] are eligible to vote on this >> nomination. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Thanks, >> alexp >> >> [1] http://openjdk.java.net/census#jdk9 >> [2] http://openjdk.java.net/projects#committer-vote >> > From mark.reinhold at oracle.com Tue Aug 5 17:00:18 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 05 Aug 2014 10:00:18 -0700 Subject: FYI: First two Jigsaw JEPs posted Message-ID: <20140805100018.24558@eggemoggin.niobe.net> http://openjdk.java.net/jeps/200 -- The Modular JDK http://openjdk.java.net/jeps/201 -- Modular Source Code These JEPs will soon be proposed for JDK 9. Please direct questions and comments to the jigsaw-dev list. - Mark From ivan.gerasimov at oracle.com Tue Aug 5 17:12:41 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 05 Aug 2014 21:12:41 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E11089.2090406@oracle.com> Vote: yes On 05.08.2014 18:14, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > > > From aleksej.efimov at oracle.com Tue Aug 5 17:24:40 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 05 Aug 2014 21:24:40 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E11358.3030105@oracle.com> Vote: YES On 05.08.2014 18:14, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From bengt.rutisson at oracle.com Tue Aug 5 18:20:08 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 05 Aug 2014 20:20:08 +0200 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: <53E12058.7050004@oracle.com> Vote: yes Bengt On 7/28/14 11:27 PM, Christian Tornqvist wrote: > I hereby nominate Mikael Vidstedt (OpenJDK user name: mikael) to JDK 9 > Committer. > > > > Mikael is the Tech Lead of the Hotspot JVM. He contributed 46 changesets to > jdk9 project and he is qualified to be committer: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/search/?rev=mikael > > &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/search/?rev=mikael > 00> &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/search/?rev=mikael > > &revcount=100 > > > > Votes are due by 11th August 2014 > > > > Only current JDK 9 Committers [1] 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 [2]. > > > > Thanks, > > Christian Tornqvist > > > > [1] http://openjdk.java.net/census#jdk9 > > [2] http://openjdk.java.net/projects#committer-vote > > > From John.Coomes at oracle.com Wed Aug 6 00:23:19 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 5 Aug 2014 17:23:19 -0700 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: <21473.30071.460901.992631@mykonos.us.oracle.com> Vote: yes -John From igor.veresov at oracle.com Wed Aug 6 06:09:09 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Aug 2014 23:09:09 -0700 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: Vote: yes igor On Jul 28, 2014, at 2:27 PM, Christian Tornqvist wrote: > I hereby nominate Mikael Vidstedt (OpenJDK user name: mikael) to JDK 9 > Committer. > > > > Mikael is the Tech Lead of the Hotspot JVM. He contributed 46 changesets to > jdk9 project and he is qualified to be committer: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/search/?rev=mikael > > &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/search/?rev=mikael > 00> &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/search/?rev=mikael > > &revcount=100 > > > > Votes are due by 11th August 2014 > > > > Only current JDK 9 Committers [1] 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 [2]. > > > > Thanks, > > Christian Tornqvist > > > > [1] http://openjdk.java.net/census#jdk9 > > [2] http://openjdk.java.net/projects#committer-vote > > > From yuri.nesterenko at oracle.com Wed Aug 6 08:44:20 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 06 Aug 2014 12:44:20 +0400 Subject: CFV: New JDK9 Committer: Andrei Eremeev Message-ID: <53E1EAE4.4050805@oracle.com> I hereby nominate Andrei Eremeev (aeremeev) to JDK9 Committer. Andrei is a member of Java SQE team. He worked in various GUI (client) and lately langtools projects and contributed some 17 changes to JDK9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5334c651c7ba http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e4bdf647215f http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26d8a3d778f2 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b7e8552b328 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb18a27ea6de http://hg.openjdk.java.net/jdk9/dev/jdk/rev/964aedefc63c http://hg.openjdk.java.net/jdk9/dev/jdk/rev/da94137883d5 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bea6c6fff7fa http://hg.openjdk.java.net/jdk9/dev/jdk/rev/00551446be0e http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cc87c0d62651 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9fe87c9a16da http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13a49fc1810 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b7d9f25bd883 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a5d6ebf7da3 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c08675c5da7c http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f434ca8aface (and also, in fact, http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1c63fdd5dee3 ) Votes are due by August 20, 2014 Only current JDK9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thank you, -yan [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote From alexander.zvegintsev at oracle.com Wed Aug 6 08:59:49 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 06 Aug 2014 12:59:49 +0400 Subject: CFV: New JDK9 Committer: Andrei Eremeev In-Reply-To: <53E1EAE4.4050805@oracle.com> References: <53E1EAE4.4050805@oracle.com> Message-ID: <53E1EE85.6060208@oracle.com> Vote: yes Thanks, Alexander. On 08/06/2014 12:44 PM, Yuri Nesterenko wrote: > I hereby nominate Andrei Eremeev (aeremeev) to JDK9 Committer. > > Andrei is a member of Java SQE team. > He worked in various GUI (client) and lately langtools projects > and contributed some 17 changes to JDK9: > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5334c651c7ba > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e4bdf647215f > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26d8a3d778f2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b7e8552b328 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb18a27ea6de > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/964aedefc63c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/da94137883d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bea6c6fff7fa > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/00551446be0e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cc87c0d62651 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9fe87c9a16da > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13a49fc1810 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b7d9f25bd883 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a5d6ebf7da3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c08675c5da7c > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f434ca8aface > (and also, in fact, > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1c63fdd5dee3 ) > > Votes are due by August 20, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > -yan > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From dalibor.topic at oracle.com Wed Aug 6 09:58:05 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 06 Aug 2014 11:58:05 +0200 Subject: CFV: New JDK9 Committer: Andrei Eremeev In-Reply-To: <53E1EAE4.4050805@oracle.com> References: <53E1EAE4.4050805@oracle.com> Message-ID: <53E1FC2D.2050201@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From sean.coffey at oracle.com Wed Aug 6 10:21:45 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 06 Aug 2014 11:21:45 +0100 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: <53E201B9.1070009@oracle.com> Vote: yes regards, Sean. On 28/07/14 22:27, Christian Tornqvist wrote: > I hereby nominate Mikael Vidstedt (OpenJDK user name: mikael) to JDK 9 > Committer. > > > > Mikael is the Tech Lead of the Hotspot JVM. He contributed 46 changesets to > jdk9 project and he is qualified to be committer: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/search/?rev=mikael > > &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/search/?rev=mikael > 00> &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/search/?rev=mikael > > &revcount=100 > > > > Votes are due by 11th August 2014 > > > > Only current JDK 9 Committers [1] 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 [2]. > > > > Thanks, > > Christian Tornqvist > > > > [1] http://openjdk.java.net/census#jdk9 > > [2] http://openjdk.java.net/projects#committer-vote > > > From sean.coffey at oracle.com Wed Aug 6 10:24:06 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 06 Aug 2014 11:24:06 +0100 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E20246.4030900@oracle.com> Vote: Yes regards, Sean. On 05/08/14 13:09, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From sean.coffey at oracle.com Wed Aug 6 10:24:38 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 06 Aug 2014 11:24:38 +0100 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E20266.2080400@oracle.com> Vote: Yes regards, Sean. On 05/08/14 15:14, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From stefan.karlsson at oracle.com Wed Aug 6 10:57:59 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 06 Aug 2014 12:57:59 +0200 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: <53E20A37.9020302@oracle.com> Vote: yes StefanK On 2014-07-28 23:27, Christian Tornqvist wrote: > I hereby nominate Mikael Vidstedt (OpenJDK user name: mikael) to JDK 9 > Committer. > > > > Mikael is the Tech Lead of the Hotspot JVM. He contributed 46 changesets to > jdk9 project and he is qualified to be committer: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/search/?rev=mikael > > &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/search/?rev=mikael > 00> &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/search/?rev=mikael > > &revcount=100 > > > > Votes are due by 11th August 2014 > > > > Only current JDK 9 Committers [1] 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 [2]. > > > > Thanks, > > Christian Tornqvist > > > > [1] http://openjdk.java.net/census#jdk9 > > [2] http://openjdk.java.net/projects#committer-vote > > > From roger.riggs at oracle.com Wed Aug 6 16:21:56 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 06 Aug 2014 12:21:56 -0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E25624.5000201@oracle.com> Vote: Yes On 8/5/2014 8:09 AM, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. From vicente.romero at oracle.com Wed Aug 6 20:06:57 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 06 Aug 2014 16:06:57 -0400 Subject: CFV: New jdk9 Reviewer: Rickard =?windows-1252?Q?B=E4ckman?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <53E28AE1.5010001@oracle.com> vote: yes Vicente On 07/31/2014 05:06 PM, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. > Before that he worked in Hotspot Serviceability group and participated > in porting JFR to Hotspot. For past year Rickard has been worked on C2 > optimizations which improve jsr292 performance. So far he has authored > 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 > and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From sonali.goel at oracle.com Wed Aug 6 20:47:48 2014 From: sonali.goel at oracle.com (Sonali Goel) Date: Wed, 06 Aug 2014 13:47:48 -0700 Subject: CFV: New JDK9 Committer: Andrei Eremeev In-Reply-To: <53E1EAE4.4050805@oracle.com> References: <53E1EAE4.4050805@oracle.com> Message-ID: <53E29474.5060008@oracle.com> Vote: Yes Thanks, Sonali On 8/6/2014 1:44 AM, Yuri Nesterenko wrote: > I hereby nominate Andrei Eremeev (aeremeev) to JDK9 Committer. > > Andrei is a member of Java SQE team. > He worked in various GUI (client) and lately langtools projects > and contributed some 17 changes to JDK9: > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5334c651c7ba > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e4bdf647215f > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26d8a3d778f2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b7e8552b328 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb18a27ea6de > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/964aedefc63c > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/da94137883d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bea6c6fff7fa > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/00551446be0e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cc87c0d62651 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9fe87c9a16da > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13a49fc1810 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b7d9f25bd883 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a5d6ebf7da3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c08675c5da7c > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f434ca8aface > (and also, in fact, > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1c63fdd5dee3 ) > > Votes are due by August 20, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > -yan > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From alexandr.scherbatiy at oracle.com Thu Aug 7 11:48:53 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 07 Aug 2014 15:48:53 +0400 Subject: CFV: New JDK 9 Committer: Dmitry Markov In-Reply-To: <53E0C974.9030604@oracle.com> References: <53E0C974.9030604@oracle.com> Message-ID: <53E367A5.5060700@oracle.com> Vote: Yes Thanks, Alexandr. On 8/5/2014 4:09 PM, Alexander Potochkin wrote: > I hereby nominate Dmitry Markov to JDK 9 Committer. > > Dmitry is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > Dmitry already has a JDK7u and JDK8 committer status > and contributed 13 changes to JDK9 so far: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/85df65495177 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c8a0abc1fd2d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b274eccd94a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/cb7f711e1752 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/72f167edf630 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/22ef5187a3e6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3213c388740a > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ecd72faf8d11 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0a574bcd66a7 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/44b5e71b143f > http://hg.openjdk.java.net/jdk9/client/jdk/rev/25f07ac917f2 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/97e2bc137f9e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6e8290ca6ed > > Votes are due by 19th August 2014 23:59 GMT > > Only current JDK 9 Committers [1] 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 [2]. > > Thanks > alexp > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From alexandr.scherbatiy at oracle.com Thu Aug 7 11:49:51 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 07 Aug 2014 15:49:51 +0400 Subject: CFV: New JDK9 Committer: Anton Nashatyrev In-Reply-To: <53E0E6D6.6070903@oracle.com> References: <53E0E6D6.6070903@oracle.com> Message-ID: <53E367DF.5060704@oracle.com> Vote: Yes Thanks, Alexandr. On 8/5/2014 6:14 PM, Alexander Potochkin wrote: > I hereby nominate Anton Nashatyrev to jdk9 Committer. > > Anton is a member of the Java SE sustaining team. > He has spent most of that time working on the GUI and deployment issues. > > He has contributed 14 changes to jdk7u so far: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90daa7f1e0e3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f8c51d72400f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/46170b8aaccc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e343eef24517 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3112aa051345 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3fae2ca5fc3e > http://hg.openjdk.java.net/jdk9/client/jdk/rev/128190321f5d > http://hg.openjdk.java.net/jdk9/client/jdk/rev/7caf08701170 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/15d846fe8ee3 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6fe5443c3dde > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a0c28e64c049 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4ba3d9ea041 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27d1bdf2f7d9 > > Votes are due by August 19, 2014. > > Only current JDK7u Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > alexp > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From christopherbrown06 at gmail.com Fri Aug 8 06:43:27 2014 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Fri, 8 Aug 2014 08:43:27 +0200 Subject: Any native WatchService implementation planned on Mac OS X for JDK9? Message-ID: Hello, First of all, I've just subscribed to the list and I hope this is the correct place (if not, please advise, I tried to pick the most suitable one from http://mail.openjdk.java.net/mailman/listinfo based on list title...). Following on from this message: https://www.mail-archive.com/macosx-port-dev at openjdk.java.net/msg00103.html (on a list which is apparently no longer active as the Mac OS X "port" project is complete and Mac OS X development is now "just one supported platform among many") ...I am trying to find out if any native WatchService implementation planned on Mac OS X for JDK9, and if I can help test? I have an application that runs on Linux, Windows, and Mac OS X with many unit tests that are dependent on file watching events. It runs fine on Linux and Windows, but on Mac OS X using the WatchService hardly a viable option (I have applied the com.sun.nio.file.SensitivityWatchEventModifier option suggested by Alan Bateman, which could be used in production on Mac OS X despite being resource-hungry); in unit tests, they slow down to a crawl due to the polling interval. The application used historically TeamDev's JXFileWatcher, but it's not sufficiently stable under load (in their 1.3 release, a heavy load causes it to just stop creating events at an arbitrary moment, usually quite quickly, and their 1.4 release seems to send events at the wrong time and miss some events). Thanks in advance for any information on this, or advice as to where I can enquire. As this solution would be very useful to our application, I am more than willing to help test. Thanks, Christopher Brown From Alan.Bateman at oracle.com Fri Aug 8 09:55:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Aug 2014 10:55:38 +0100 Subject: Any native WatchService implementation planned on Mac OS X for JDK9? In-Reply-To: References: Message-ID: <53E49E9A.5020801@oracle.com> On 08/08/2014 07:43, Christopher Brown wrote: > Hello, > > First of all, I've just subscribed to the list and I hope this is the > correct place (if not, please advise, I tried to pick the most suitable one > from http://mail.openjdk.java.net/mailman/listinfo based on list title...). > > Following on from this message: > https://www.mail-archive.com/macosx-port-dev at openjdk.java.net/msg00103.html > > (on a list which is apparently no longer active as the Mac OS X "port" > project is complete and Mac OS X development is now "just one supported > platform among many") > > ...I am trying to find out if any native WatchService implementation > planned on Mac OS X for JDK9, and if I can help test? > There are a couple of remaining areas where the OS X port isn't on par with the other platforms, this is one of them. The right list is nio-dev. The issue tracking it is JDK-7133447. -Alan From lana.steuck at oracle.com Fri Aug 8 16:59:26 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 8 Aug 2014 09:59:26 -0700 (PDT) Subject: jdk9-b26: dev Message-ID: <201408081659.s78GxQQg020329@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/d3ec8d048e6c http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/ed60a4e9dd35 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/5b20a93f8db0 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dde9f5cfde5f http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/9b43f3993b96 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/a5aea8318ae4 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/48b95a073d75 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/6c777df597bb --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8049893 client-libs Replace uses of 'new Integer()' with appropriate alternative across client classes JDK-8044301 client-libs BasicTreeUI: "revisit when Java2D is ready" JDK-8048328 client-libs CUPS Printing does not report supported printer resolutions. JDK-8030051 client-libs Check class loaders usage in Swing classes JDK-8048583 client-libs CustomMediaSizeName class matching to standard media is too loose JDK-8043968 client-libs Fix doclint warnings from javax.swing.plaf.basic package, 1 of 7 JDK-8049704 client-libs Fix doclint warnings from javax.swing.plaf.basic package, 2 of 7 JDK-8049808 client-libs Fix doclint warnings from javax.swing.plaf.basic package, 3 of 7 JDK-8049870 client-libs Fix doclint warnings from javax.swing.plaf.basic package, 4 of 7 JDK-8050009 client-libs Fix doclint warnings from javax.swing.plaf.basic package, 7 of 7 JDK-8047027 client-libs Fix raw and unchecked lint warnings in generated beaninfo files JDK-8047025 client-libs Fix raw and unchecked lint warnings in generated nimbus files JDK-8049797 client-libs Fix raw and unchecked lint warnings in javax.swing.SortingFocusTraversalPolicy JDK-8044862 client-libs Fix raw and unchecked lint warnings in macosx specific code JDK-8048289 client-libs Gtk: call to UIManager.getSystemLookAndFeelClassName() leads to crash JDK-8046888 client-libs JNI exception pending in jdk/src/share/native/sun/awt/image/awt_parseImage.c JDK-8046884 client-libs JNI exception pending in jdk/src/solaris/native/sun/java2d/x11: X11PMPLitLoops.c, X11SurfaceData.c JDK-8048720 client-libs KSS: sun.swing.SwingUtilities2#makeIcon JDK-8049694 client-libs Migrate functional AWT_DesktopProperties/Automated tests to OpenJDK JDK-4991647 client-libs PNGMetadata.getAsTree() sets bitDepth to invalid value JDK-8047336 client-libs Read flavormap.properties as resource JDK-8049830 client-libs Remove reflection from ScreenMenuBar JDK-8050465 client-libs Remove sun.audio package JDK-8027895 client-libs Remove unused com.sun.java.accessibility.extensions package from jdk repo JDK-8049583 client-libs Test closed/java/awt/List/ListMultipleSelectTest/ListMultipleSelectTest fails on Window XP JDK-8047066 client-libs Test test/sun/awt/image/bug8038000.java fails with ClassCastException JDK-8037511 client-libs Tidy warnings cleanup for java.awt - 2d part JDK-8040808 client-libs Uninitialised memory in OGLBufImgsOps.c, D3DBufImgOps.cpp JDK-8049198 client-libs [macosx] Incorrect thread access when showing splash screen JDK-8049996 client-libs [macosx] test java/awt/image/ImageIconHang.java fails with NPE JDK-8046597 client-libs fix doclint issues in swing classes, part 4 of 4 JDK-8043126 client-libs move awt automated functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK repository JDK-8047367 client-libs move awt automated tests from AWT_Modality to OpenJDK repository - part 2 JDK-8049617 client-libs move awt automated tests from AWT_Modality to OpenJDK repository - part 3 JDK-8051440 client-libs move tests about maximizing undecorated to OpenJDK JDK-8053931 core-libs (fc) FileDispatcherImpl.lock0 does not handle ERROR_IO_PENDING [win] JDK-8054411 core-libs Add "nashorn.args.prepend" system property JDK-8053913 core-libs Auto format caused warning in CompositeTypeBasedGuardingDynamicLinker JDK-8053938 core-libs Collections.checkedList(empty list).replaceAll((UnaryOperator)null) doesn't throw NPE after JDK-8047795 JDK-8030942 core-libs Explicitly state floating-point summation requirements on non-finite inputs JDK-8042872 core-libs Fix raw and unchecked warnings in sun.applet JDK-8054050 core-libs Fix stay raw and unchecked lint warnings in core libs JDK-8054158 core-libs Fix typos in JNDI-related packages JDK-8051991 core-libs Flatten VersionHelper hierarchies JDK-8031435 core-libs Ftp download does not work properly for ftp user without password JDK-8044671 core-libs NPE from JapaneseEra when a new era is defined in calendar.properties JDK-8054223 core-libs Nashorn: AssertionError when use __DIR__ and ScriptEngine.eval() JDK-8051382 core-libs Optimize java.lang.reflect.Modifier.toString() JDK-8048869 core-libs Reduce time spent in jdk.nashorn.internal.ir.Node.accept/java.lang.Class.cast(Object) JDK-8051422 core-libs Remove JNDI dependency on java.applet.Applet JDK-8044786 core-libs Some tests fail with non-optimistic compilation JDK-8048209 core-libs SynchronizedNavigableSet tailSet uses wrong mutex JDK-8049318 core-libs Test hideLocationProperties.js fail on Window due to backslash in path. JDK-8051439 core-libs Wrong type calculated for ADD operator with undefined operand JDK-8051839 core-libs [Findbugs] jdk.internal.dynalink.linker.GuardedInvocation may expose internal representation JDK-8049618 core-libs [Test Bug ] Test closed/java/net/SocketPermission/BindTest.java fails on Sctp Channel JDK-8030166 core-libs java/lang/ProcessBuilder/Basic.java fails intermittently: waitFor took too long JDK-8053908 core-libs jdeps is not PATH on Mac, results in ant clean test failure on Mac JDK-8049194 core-svc com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 JDK-8048906 deploy Broken exception site list GUI- Unable to add a site to the list JDK-8043671 deploy Convert @exception -> @throws to make doclint happy JDK-8048337 deploy Examine if macosx/bundle/JavaAppLauncher and JavaAppLauncher.java can be removed JDK-8051368 deploy Incremental build fails JDK-8049519 deploy JNLP TCK failure: Fix for JDK-8048297 fails on MacOSX JDK-8031989 deploy Provide API to get all the JNLP artifacts JDK-8048709 deploy Remove references to sun.audio package JDK-8037471 deploy The warning message displays the app name and publisher as "UNKNOWN" if cache is disabled JDK-8048882 hotspot Some regression tests are not robust with VM output JDK-8051303 hotspot 'optimized' build broken by JDK-8039425 JDK-8051378 hotspot AIX: Change "8030763: Validate global memory allocation" breaks the HotSpot build JDK-8048085 hotspot Aborting marking just before remark results in useless additional clearing of the next mark bitmap JDK-8050972 hotspot Concurrency problem in PcDesc cache JDK-8048088 hotspot Conservative maximum heap alignment should take vm_allocation_granularity into account JDK-8051866 hotspot Error message for JFR.start lacks reason for failure JDK-8050978 hotspot Fix bad field access check in C1 and C2 JDK-8053902 hotspot Fix for 8030115 breaks build on Windows and Solaris JDK-8048112 hotspot G1 Full GC needs to support the case when the very first region is not available JDK-8032449 hotspot Get rid of JMX in test/compiler JDK-8049325 hotspot Introduce and clean up umbrella headers for the files in the cpu subdirectories. JDK-8004128 hotspot NPG: remove stackwalking in Threads::gc_prologue and gc_epilogue code JDK-8049441 hotspot PPC64: Don't use StubCodeMarks for zero-length stubs JDK-8051550 hotspot Printing of 'cmpN_reg_branch_short' instruction shows wrong 'op2' register JDK-8050144 hotspot Remove '-client' from compiler/8004051/Test8004051.java's options JDK-8050228 hotspot Rename 'rem_size' in compactibleFreeListSpace.cpp because of name clashes on AIX JDK-8050802 hotspot Update jprt runthese test suite to jck-8 JDK-8049051 hotspot Use of during_initial_mark_pause() in G1CollectorPolicy::record_collection_pause_end() prevents use of seperate object copy time prediction during marking JDK-6848902 hotspot [TESTBUG] The compiler/6589834/Test_ia32.java timed out JDK-8030115 hotspot [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending JDK-7033917 hotspot closed/compiler/6507107/HeapwalkingTest.java sometimes works too long JDK-8031978 hotspot compiler/ciReplay/TestVM_no_comp_level.sh fails with "TEST [CHECK :: REPLAY DATA GENERATION] FAILED:" JDK-8049348 hotspot compiler/intrinsics/bmi/verifycode tests on lzcnt and tzcnt use incorrect assumption about REXB prefix usage JDK-8049881 hotspot jstack not working on core files JDK-8050165 hotspot linux-sparcv9: NMT detail causes assert((intptr_t*)younger_sp[FP->sp_offset_in_saved_window()] == (intptr_t*)((intptr_t)sp - STACK_BIAS)) failed: younger_sp must be valid JDK-8050167 hotspot linux-sparcv9: hs_err file does not show any stack information JDK-8049684 hotspot pstack crashes on java core dump JDK-8039102 infrastructure Add raw and unchecked lint warnings to build of jdk repository JDK-8054095 infrastructure No space allowed in platforms string in ProblemList.txt JDK-8054009 infrastructure Support SKIP_BOOT_CYCLE=false when invoked from JPRT JDK-8048611 infrastructure Windows VS 2013 install 64-bit build fails with: LINK : fatal error LNK1181: cannot open input file 'Ole32.lib' JDK-8047890 infrastructure clang errors thrown when building in install: implicit instantiation of undefined template JDK-8050865 install 8u20 to jdk8 downgrade: javapath files are not removed JDK-8049481 install AU removes static installations JDK-8049056 install Deployment .jar files are missing in JAVA_HOME\lib, when installer calls RegisterDeployEx() from deploy.dll JDK-8047370 install Fix incorrect phrase "Development Rule Set" JDK-8050918 install JUT cannot determine languages with countries JDK-8049706 install JUT should take into account, that 8u25 will be the default on java.com JDK-8050994 install JUT uses incorrect layout for punctuation symbols in Japanese JDK-8048281 install JavaScrub unit tests are failing JDK-8029185 install The jre/jdk installers do not install on 32bit win XP because of unsupported WinAPI Calls JDK-8038842 install Update ds build scripts to set correct baseimage and boot_jdk for 8u20 builds JDK-8042653 install jre offline should get upx compressed JDK-8047724 other-libs @since tag cleanup in jaxws JDK-8044867 other-libs Fix raw and unchecked lint warnings in sun.tools.* JDK-8051953 security-libs Add Unreachable.java test to ProblemList on Windows JDK-8044659 security-libs Java SecureRandom on SPARC T4 much slower than on x86/Linux JDK-8052999 security-libs ProblemList update for Unreachable.java JDK-8052406 security-libs SSLv2Hello protocol may be filter out unexpectedly JDK-8042982 security-libs Unexpected RuntimeExceptions being thrown by SSLEngine JDK-8052808 security-libs [TESTBUG] some of the closed/javax/security/auth/ tests should be changed to work under profiles JDK-8036612 security-libs [parfait] JNI exception pending in jdk/src/windows/native/sun/security/mscapi/security.cpp JDK-7147060 security-libs com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode JDK-8051972 security-libs sun/security/pkcs11/ec/ReadCertificates.java fails intermittently JDK-8043643 tools Add an crules analyzer avoiding string concatenation in messages of Assert checks. JDK-8048890 tools Add option to keep track of symbol completion dependencies JDK-8051958 tools Cannot assign a value to final variable in lambda JDK-8042469 tools Launcher changes for native memory tracking scalability enhancement JDK-8050979 tools Provide javadoc for "framework" classes in langtools tests JDK-8047072 tools javap OOM on fuzzed classfile JDK-8049109 xml Add @since 1.9 to new packages added in jaxp JDK-8035467 xml Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate Xerces' native serializer. JDK-8053965 xml Xerces update breaks profile build JDK-8032908 xml getTextContent doesn't return string in JAXP From mark.reinhold at oracle.com Mon Aug 11 16:17:51 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Aug 2014 09:17:51 -0700 Subject: First batch of JEPs proposed to target JDK 9 Message-ID: <20140811091751.593136@eggemoggin.niobe.net> The JDK 9 repositories have been open for bug fixes and small enhancements for some time now. Features for the release will be proposed and tracked via the JEP Process [1] as amended by the JEP 2.0 proposal [2], which will shortly be folded into the main JEP process document. Here are the JEPs currently proposed to target JDK 9: 102: Process API Updates http://openjdk.java.net/jeps/102 143: Improve Contended Locking http://openjdk.java.net/jeps/143 197: Segmented Code Cache http://openjdk.java.net/jeps/197 198: Light-Weight JSON API http://openjdk.java.net/jeps/198 199: Smart Java Compilation, Phase Two http://openjdk.java.net/jeps/199 201: Modular Source Code http://openjdk.java.net/jeps/201 These JEPs will be targeted to JDK 9 unless reasoned objections are raised by 19:00 UTC next Monday, 18 August. (This information is also available on the JDK 9 Project Page [3]). - Mark [1] http://openjdk.java.net/jeps/1 [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [3] http://openjdk.java.net/projects/jdk9 From mark.reinhold at oracle.com Mon Aug 11 18:30:41 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Aug 2014 11:30:41 -0700 Subject: First batch of JEPs proposed to target JDK 9 In-Reply-To: <20140811091751.593136@eggemoggin.niobe.net> References: <20140811091751.593136@eggemoggin.niobe.net> Message-ID: <20140811113041.669623@eggemoggin.niobe.net> 2014/8/11 9:17 -0700, mark.reinhold at oracle.com: > ... > > Here are the JEPs currently proposed to target JDK 9: > > 102: Process API Updates http://openjdk.java.net/jeps/102 > 143: Improve Contended Locking http://openjdk.java.net/jeps/143 > 197: Segmented Code Cache http://openjdk.java.net/jeps/197 > 198: Light-Weight JSON API http://openjdk.java.net/jeps/198 > 199: Smart Java Compilation, Phase Two http://openjdk.java.net/jeps/199 > 201: Modular Source Code http://openjdk.java.net/jeps/201 > > These JEPs will be targeted to JDK 9 unless reasoned objections are > raised by 19:00 UTC next Monday, 18 August. As background, this list reflects the JEPs currently placed into the "Proposed to Target" state by their respective owners after discussion and review on (usually) other mailing lists. (You can find the mailing list for a JEP in the JEP itself.) These JEPs are offered to all JDK 9 Committers for their consideration. Feedback is more than welcome, as are reasoned objections. If no such objections are raised in one week's time, or if they're raised and then satisfactorily answered, then I'll target these JEPs to JDK 9. - Mark From staffan.larsen at oracle.com Tue Aug 12 06:28:35 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 08:28:35 +0200 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: <40E61918-2489-4D9C-8CEB-53E53819B7C4@oracle.com> Vote: yes. On 28 jul 2014, at 23:27, Christian Tornqvist wrote: > I hereby nominate Mikael Vidstedt (OpenJDK user name: mikael) to JDK 9 > Committer. > > > > Mikael is the Tech Lead of the Hotspot JVM. He contributed 46 changesets to > jdk9 project and he is qualified to be committer: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/search/?rev=mikael > > &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/search/?rev=mikael > 00> &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/search/?rev=mikael > > &revcount=100 > > > > Votes are due by 11th August 2014 > > > > Only current JDK 9 Committers [1] 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 [2]. > > > > Thanks, > > Christian Tornqvist > > > > [1] http://openjdk.java.net/census#jdk9 > > [2] http://openjdk.java.net/projects#committer-vote > > > From joel.franck at oracle.com Tue Aug 12 06:34:45 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 12 Aug 2014 08:34:45 +0200 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: <2387232B-BAFD-4937-BE55-CBD9582B9AA6@oracle.com> Vote: yes cheers /Joel On 28 jul 2014, at 23:27, Christian Tornqvist wrote: > this From staffan.larsen at oracle.com Tue Aug 12 11:50:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 13:50:33 +0200 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_jdk9_Reviewer=3A_Rickard_B=E4ckm?= =?iso-8859-1?Q?an?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <4522D3E2-0D13-4FA7-8BED-C14BFFD41BCF@oracle.com> Vote: yes On 31 jul 2014, at 23:06, Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. Before that he worked in Hotspot Serviceability group and participated in porting JFR to Hotspot. For past year Rickard has been worked on C2 optimizations which improve jsr292 performance. So far he has authored 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From mikael.gerdin at oracle.com Tue Aug 12 12:05:31 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Aug 2014 14:05:31 +0200 Subject: CFV: New jdk9 Reviewer: Rickard =?UTF-8?B?QsOkY2ttYW4=?= In-Reply-To: <53DAAFD8.5060709@oracle.com> References: <53DAAFD8.5060709@oracle.com> Message-ID: <5709312.1y2CuGjyIB@mgerdin03> Vote: yes /Mikael On Thursday 31 July 2014 14.06.32 Vladimir Kozlov wrote: > I hereby nominate Rickard B?ckman (rbackman) to jdk9 Reviewer. > > Rickard is a member of Hotspot Compiler team for 1 year already. Before > that he worked in Hotspot Serviceability group and participated in > porting JFR to Hotspot. For past year Rickard has been worked on C2 > optimizations which improve jsr292 performance. So far he has authored > 41 changesets (see list bellow). He is a Committer in jdk6, jdk7, jdk8 > and jdk9 projects. > > Votes are due by August 14 2014. > > Only current JDK9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > 8020701:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5e3b6f79d280 > 8016131:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e619a2766bcc > 8013117:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12494ffb721b > 8011882:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d0459a316814 > 8012210:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f438a35cc903 > 8008357:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 > 8008340:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec2eddfed950 > 8008088:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2394a89e89f4 > 8006563:http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 > 8005849:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f2110083203d > 7127792:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c284cf4781f0 > 7093328:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/045cb62046a7 > 7171422:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df84b4a3ebcb > 7161732:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/960a442eae91 > 7160570:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0105f367a14c > 7160924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/df4cd4aac5c1 > 7130476:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/34e2e90e7182 > 7091417:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/11c26bfcf8c7 > 7112308:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c17bc65648de > 7106766:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/95009f678859 > 8046289:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/08250e173426 > 8030976:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6ad207fd3e26 > 8031994:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/82a396fba1e6 > 8041934:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a485aafdbb1 > 8027754:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cd5d10655495 > 8028624:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/55dd6e77b399 > 8028997:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9949533a8623 > 8028207:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b957c650babb > 8028198:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f675976a61e7 > 8027622:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e428d5e768e3 > 8027444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/60a32bb8ff99 > 8027353:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a57a165b8296 > 8026844:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59e8ad757e19 > 8026959:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/435c7b4577cd > 8025657:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a2acfb16e97 > 8024924:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c9ccd7b85f20 > 8022283:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/59982ff9e0ec > 8022675:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acedd49a1bce > 8016444:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/acfa2cc19146 > 4965252:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f49e0508a38a > 8008255:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0b7f78069732 From stefan.johansson at oracle.com Tue Aug 12 13:43:57 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 12 Aug 2014 15:43:57 +0200 Subject: CFV: New jdk9 Committer: Mikael Vidstedt In-Reply-To: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> References: <07c401cfaaaa$c49eafd0$4ddc0f70$@oracle.com> Message-ID: <53EA1A1D.1020400@oracle.com> Vote: yes Stefan On 2014-07-28 23:27, Christian Tornqvist wrote: > I hereby nominate Mikael Vidstedt (OpenJDK user name: mikael) to JDK 9 > Committer. > > > > Mikael is the Tech Lead of the Hotspot JVM. He contributed 46 changesets to > jdk9 project and he is qualified to be committer: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/search/?rev=mikael > > &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/search/?rev=mikael > 00> &revcount=100 > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/search/?rev=mikael > > &revcount=100 > > > > Votes are due by 11th August 2014 > > > > Only current JDK 9 Committers [1] 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 [2]. > > > > Thanks, > > Christian Tornqvist > > > > [1] http://openjdk.java.net/census#jdk9 > > [2] http://openjdk.java.net/projects#committer-vote > > > From chris.hegarty at oracle.com Tue Aug 12 14:10:15 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Aug 2014 15:10:15 +0100 Subject: RFR [9] Modular Source Code Message-ID: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. Webrevs: http://cr.openjdk.java.net/~chegar/8054834/00/ Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8051619 [2] https://bugs.openjdk.java.net/browse/JDK-8051618 [3] http://hg.openjdk.java.net/jigsaw/stage From alejandro.murillo at oracle.com Tue Aug 12 21:21:25 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 12 Aug 2014 15:21:25 -0600 Subject: jdk9-dev: HotSpot Message-ID: <53EA8555.4090502@oracle.com> jdk9-hs-2014-08-08 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/73274a451ccb http://hg.openjdk.java.net/jdk9/dev/corba/rev/87987d1c767f http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a154419021ba http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/f88b3047d322 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/c5caa888da25 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cf0f449f1836 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c998c4293abc http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/11a4f68806bc Component : VM Status : 0 major failures, 0 minor failures Date : 08/11/2014 at 19:00 MSK Tested By : VM SQE &Leonid.Mesnik at oracle.com Bundles : 2014-08-08-184238.amurillo.jdk9-hs-2014-08-08-jdk9-dev-control Testing: 723 new failures, 3482 known failures, 418959 passed. Issues and Notes: So huge number of "new" failures is caused by: Aurora reports don't contain information about OS They are not product. No detailed analysis. No stoppers have been detected so far. Go for integration. -- Alejandro From yuri.nesterenko at oracle.com Wed Aug 13 11:57:06 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 13 Aug 2014 15:57:06 +0400 Subject: CFV: New JDK9 Committer: Dmitriy Ermashov Message-ID: <53EB5292.2050307@oracle.com> I hereby nominate Dmitriy Ermashov (dermashov) to JDK9 Committer. Dmitriy is a member of Java SQE team. He has contributed to several testing-related GUI OpenJDK projects. A list of his changesets has, so far, 11 items: http://hg.openjdk.java.net/jdk9/client/jdk/rev/fa382ba1a8a7 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/db1d1894985c http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6a4534a458d http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8af305206840 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b2304c83a42d http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca9cc86574c1 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f51d560f6190 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c35d0a40b6e1 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c904d2c4425d http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/320dd90143c2 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0d65f6942ae9 Votes are due by August 27, 2014 Only current JDK9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thank you, -yan [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote From erik.joelsson at oracle.com Wed Aug 13 12:11:18 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Aug 2014 14:11:18 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EB55E6.4010104@oracle.com> I should probably write something about the rather extensive changes to the build logic in this patch. As the source gets organized around modules, it made sense to also organize the build more around modules. In this patch, the makefiles have in large parts been split into module specific files and the top level targets are oriented around modules. This means the top level targets are much more fine granular than currently in JDK 9. Another difference is that the top level targets are now able to run concurrently, to give more opportunity for utilizing multiple cpus. In JDK 9, the build moves sequentially through each repository, in a given order, now make is free to run more things in parallel. This makes the build faster, at least on beefy hardware. The drawback is that the build log gets a bit more confusing. When something fails, it won't interrupt other building threads at once, so the actual failure may be further up the log (even further than before). I have found that searching for "Error 2" is a good way to find the real failure. Another consequence is that the build time summary at the end only displays total time as there is no good definition for how much time was spent in each repository anymore. A summary on the new targets: make [default] Does pretty much the same as before. It compiles everything but does not build all jars or create images. make all Builds everything, including jars, images and docs. Also runs a verification tool on the java classes which will point out any broken module boundaries. make images Same as before make hotspot Builds the hotspot repository, like before. make docs Builds all the documentation, including javadoc. make docs-javadoc Builds just the javadoc. This target has very few prerequisites so provides a fast way to just build javadoc. make gensrc Runs all source code generation steps. make java Compiles all java classes. Other similar targets are libs, launchers, gendata and copy make java.desktop Compiles everything in the java.desktop module (and its dependencies), both java and native code. Works for any module name. make java.desktop-java Compiles the java classes in java.desktop (and its dependencies). Works for any module name (and -gensrc, -libs, -launchers, -gendata, -copy) In addition to this, the suffix -only can be added to any target to disable the prerequisites for it. Using this is not recommended but it may save time when doing certain incremental builds and you are in a terrible hurry. For incremental builds, sjavac can be used and works reasonably well (configure --enable-sjavac). Work is in progress on making it work even better. The old workaround JDK_FILTER=package/to/compile is still working. The clean target is still oriented around repositories, mostly because the build output is still in large parts repository oriented. This is something we hope to improve later. /Erik On 2014-08-12 16:10, Chris Hegarty wrote: > This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. > > For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ > > Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8051619 > [2] https://bugs.openjdk.java.net/browse/JDK-8051618 > [3] http://hg.openjdk.java.net/jigsaw/stage From Alan.Bateman at oracle.com Wed Aug 13 12:35:47 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Aug 2014 13:35:47 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EB5BA3.2050504@oracle.com> Just to add to Chris and Erik's mails, I would encourage everyone that pushes to jdk9/dev or the other jdk9 project integration forests to clone and build jigsaw/stage and get familiar with the proposed layout, new build targets, and the very different output emitted during the build. The changes are arguably as significant as the transition in JDK 8 from the "old build" to the "new build" so the more people taking the forest for a test drive the better. If you maintain your our own own IDE project then you'll likely have to adjust file paths so any issues encountered would be useful to hear about too. -Alan. From erik.joelsson at oracle.com Wed Aug 13 13:16:53 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Aug 2014 15:16:53 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EB5771.2010908@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5407.50306@oracle.com> <53EB5771.2010908@oracle.com> Message-ID: <53EB6545.2090008@oracle.com> On 2014-08-13 14:17, Chris Hegarty wrote: > Thanks for the explanation Erik. > > I have taken a pass over the changes, and they look ok to me ( I am > happy to be listed as a reviewer ). I also did several build and test > runs on Solaris, Linux, Max OSX, and Windows. All look good. > > I am seeing, in some cases, about a 20% reduction in image build times > on an 8 core i7, running Linux x86. > Nice to hear! > One question; Are there any new requirements on build systems as a > result of these changes? > Yes and no. The build should still be compatible with gnu make 3.81. However, certain builds of that make version (particularly the one we have used for jdk8 internally) are known to crash in Cygwin and it is instead recommended to use a newer 4.0 version of make in Cygwin. Also to get good concurrent build performance on Windows, gnu make 4.0 is required for Cygwin. I have done test builds with msys and it seems to be working too. One more thing that I forgot to mention. If you are using gnu make 4.0, there is a new feature called output-sync that can be enabled that will make it somewhat easier to read the build output. This can be enabled either with the configure parameter --with-output-sync=recurse, or at the make command line "make OUTPUT_SYNC=recurse". (it will be enabled by default in JPRT). More information on this can be found here: http://www.gnu.org/software/make/manual/make.html#Parallel-Output /Erik From chris.hegarty at oracle.com Wed Aug 13 12:17:53 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Aug 2014 13:17:53 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EB5407.50306@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5407.50306@oracle.com> Message-ID: <53EB5771.2010908@oracle.com> Thanks for the explanation Erik. I have taken a pass over the changes, and they look ok to me ( I am happy to be listed as a reviewer ). I also did several build and test runs on Solaris, Linux, Max OSX, and Windows. All look good. I am seeing, in some cases, about a 20% reduction in image build times on an 8 core i7, running Linux x86. One question; Are there any new requirements on build systems as a result of these changes? -Chris. On 13/08/14 13:03, Erik Joelsson wrote: > I should probably write something about the rather extensive changes to > the build logic in this patch. > > As the source gets organized around modules, it made sense to also > organize the build more around modules. In this patch, the makefiles > have in large parts been split into module specific files and the top > level targets are oriented around modules. This means the top level > targets are much more fine granular than currently in JDK 9. > > Another difference is that the top level targets are now able to run > concurrently, to give more opportunity for utilizing multiple cpus. In > JDK 9, the build moves sequentially through each repository, in a given > order, now make is free to run more things in parallel. This makes the > build faster, at least on beefy hardware. The drawback is that the build > log gets a bit more confusing. When something fails, it won't interrupt > other building threads at once, so the actual failure may be further up > the log (even further than before). I have found that searching for > "Error 2" is a good way to find the real failure. Another consequence is > that the build time summary at the end only displays total time as there > is no good definition for how much time was spent in each repository > anymore. > > A summary on the new targets: > > make [default] > Does pretty much the same as before. It compiles everything but does not > build all jars or create images. > > make all > Builds everything, including jars, images and docs. Also runs a > verification tool on the java classes which will point out any broken > module boundaries. > > make images > Same as before > > make hotspot > Builds the hotspot repository, like before. > > make docs > Builds all the documentation, including javadoc. > > make docs-javadoc > Builds just the javadoc. This target has very few prerequisites so > provides a fast way to just build javadoc. > > make gensrc > Runs all source code generation steps. > > make java > Compiles all java classes. > Other similar targets are libs, launchers, gendata and copy > > make java.desktop > Compiles everything in the java.desktop module (and its dependencies), > both java and native code. Works for any module name. > > make java.desktop-java > Compiles the java classes in java.desktop (and its dependencies). Works > for any module name (and -gensrc, -libs, -launchers, -gendata, -copy) > > In addition to this, the suffix -only can be added to any target to > disable the prerequisites for it. Using this is not recommended but it > may save time when doing certain incremental builds and you are in a > terrible hurry. > > For incremental builds, sjavac can be used and works reasonably well > (configure --enable-sjavac). Work is in progress on making it work even > better. The old workaround JDK_FILTER=package/to/compile is still working. > > The clean target is still oriented around repositories, mostly because > the build output is still in large parts repository oriented. This is > something we hope to improve later. > > /Erik > > > On 2014-08-12 16:10, Chris Hegarty wrote: >> This is a review request for the Initial changes for JEP 201: Modular >> Source Code [1]. >> >> There are a number of individuals responsible for these changes. Some, >> possibly not all, are explicitly listed in the To section of this >> mail, and they will help address any comments arising from this review >> request. >> >> For the purposes of review, the actual source file moves have been >> omitted from the webrev below, with the exception of any source file >> that has a change to it?s actual content. The new location of the >> source files can be determined from JEP 201 [1] and JEP 200 "The >> Modular JDK" [2], or by browsing the staging forest [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8054834/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has >> been tentatively reserved for their integration. All comments are >> welcome, although given the nature of the changes then we might have >> to create separate issues in JIRA to address some of them later in >> jdk9/dev.. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >> [3] http://hg.openjdk.java.net/jigsaw/stage > From mark.reinhold at oracle.com Wed Aug 13 14:47:57 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 Aug 2014 07:47:57 -0700 Subject: CFV: New JDK9 Committer: Dmitriy Ermashov In-Reply-To: <53EB5292.2050307@oracle.com> References: <53EB5292.2050307@oracle.com> Message-ID: <20140813074757.286996@eggemoggin.niobe.net> 2014/8/13 4:57 -0700, yuri.nesterenko at oracle.com: > I hereby nominate Dmitriy Ermashov (dermashov) to JDK9 Committer. > > Dmitriy is a member of Java SQE team. > He has contributed to several testing-related GUI OpenJDK > projects. A list of his changesets has, so far, 11 items: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/fa382ba1a8a7 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/db1d1894985c > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6a4534a458d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8af305206840 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b2304c83a42d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca9cc86574c1 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f51d560f6190 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c35d0a40b6e1 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c904d2c4425d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/320dd90143c2 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0d65f6942ae9 Nearly all of these changesets appear simply to be transfers of existing tests from Oracle-internal suites to the JDK 9 forest. Do you really think these count as "significant" contributions? - Mark From mike.duigou at oracle.com Wed Aug 13 21:29:47 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Aug 2014 14:29:47 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> There's a lot to review here. This is not a complete review but hopefully contributes to our review "coverage". I am focusing on the top project in this set of comments. - --with-output-sync seems like it should be on by default if available. Downside? This could also be split out from the jigsaw changes if there is any interest in reducing the patch size. - what is TESTMAKE_OUTPUTDIR for? (ugh, more outputdir dirs...) - spec.gmk.in: Can we have a separate assignment for JAVA_TOOL_FLAGS_SMALL? It is nice to be able to see every AC_SUBST somewhere solo. - jdk-options.m4: should with_cacerts_file being empty not merit an error? what does the empty default do? - javadoc.gmk: retire JDK_IMPSRC, JDK_GENSRC, JDK_SHARE_CLASSES and JDK_SHARE_SRC - javadoc.gmk: JAVADOC_CMD should perhaps use (currently non-existant) JAVA_TOOL_FLAGS_BIG or at least JAVA_FLAGS_BIG? - MakeHelpers: CleanComponent should call strip on the $1 argument to $(RM) so that it is deleting what it promises to be deleting. Or it could check to make sure $(words $1) is 1 - modules.xml "Changes to this file will require review by Committers to Project Jigsaw." Will this be true after integration into jdk9/dev repo? - modules.list seems to be redundant with modules.xml but there don't seem to be any measures to ensure that they remain in sync. Even a comment in modules.xml would help. This kind of problem has been a source of errors in the past. - What is TestMake.gmk and associated for? jdk project: - I am slightly unsettled by the number of makefiles and putting them all in to the same directory. Will they eventually be moved into their modules? More to come but first I want to build it! On Aug 12 2014, at 07:10 , Chris Hegarty wrote: > This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. > > For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ > > Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8051619 > [2] https://bugs.openjdk.java.net/browse/JDK-8051618 > [3] http://hg.openjdk.java.net/jigsaw/stage From Alan.Bateman at oracle.com Wed Aug 13 22:54:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Aug 2014 23:54:46 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> Message-ID: <53EBECB6.7050301@oracle.com> On 13/08/2014 22:29, Mike Duigou wrote: > : > > - modules.xml "Changes to this file will require review by Committers to Project Jigsaw." Will this be true after integration into jdk9/dev repo? > There's a section in JEP 200 about modules.xml, it is temporary until there is a module system in place. The jdeps tool is updated with a new option to read it and check for changes (the dependency check is more detailed that might be initially obvious). For now, committers to Project Jigsaw are the custodians of the module graph and I think the requirement for a Reviewer will last at least as long as this side file needs to exist. In time I assume that processes for dealing with changes to the module graph will be on par with other API changes. -Alan From erik.joelsson at oracle.com Thu Aug 14 07:07:17 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Aug 2014 09:07:17 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> Message-ID: <53EC6025.7080003@oracle.com> Hello Mike, Thanks for the comments. See inline. On 2014-08-13 23:29, Mike Duigou wrote: > There's a lot to review here. This is not a complete review but hopefully contributes to our review "coverage". I am focusing on the top project in this set of comments. > > - --with-output-sync seems like it should be on by default if available. Downside? This could also be split out from the jigsaw changes if there is any interest in reducing the patch size. There are downsides yes. The way this works is that make will buffer output from all commands and print them when done. Depending on level that's when the command line is done, the recipe is done, or the complete submake. I played around with having it default for a while. For a normal build this isn't too confusing once you get used to it, but it really made running tests annoying as the output from jtreg would all be buffered until it was done. Also, a hotspot developer that was to build hotspot from the root repo would see nothing until the whole build was complete. I simply believe we need some more experience with this before we can decide on a better default behavior. Possibly we need to do the hotspot makefile rewrite first so that the hotspot build can be split into smaller logical chunks from the top level. I wanted the output-sync feature to be in this from the start to make JPRT logs easier to look at, as the feature will be default turned on there. Especially debug logs become very hard to read without it. > > - what is TESTMAKE_OUTPUTDIR for? (ugh, more outputdir dirs...) While doing this work, I had the need for adding features to SetupArchive (mainly to support multiple source dirs for jars). It quickly turned quite nasty and to make development easier, I added specific test cases for this macro in a separate makefile structure. This is the output directory for those tests. > - spec.gmk.in: Can we have a separate assignment for JAVA_TOOL_FLAGS_SMALL? It is nice to be able to see every AC_SUBST somewhere solo. Certainly, that makes sense. Must have just missed it. > - jdk-options.m4: should with_cacerts_file being empty not merit an error? what does the empty default do? The default is to use the bundled one. I didn't like having that default being defined in configure. I think it better belongs in the makefile handling the file. > - javadoc.gmk: retire JDK_IMPSRC, JDK_GENSRC, JDK_SHARE_CLASSES and JDK_SHARE_SRC We should certainly clean up javadoc.gmk properly, but I thought that was out of scope for this patch. You do have a point in that those variables are now unused so no longer need to be declared. > - javadoc.gmk: JAVADOC_CMD should perhaps use (currently non-existant) JAVA_TOOL_FLAGS_BIG or at least JAVA_FLAGS_BIG? I agree, but that should be a separate change. > - MakeHelpers: CleanComponent should call strip on the $1 argument to $(RM) so that it is deleting what it promises to be deleting. Or it could check to make sure $(words $1) is 1 Strip clears leading and trailing whitespace. The reason I added a strip to the echo is that in some cases the macro was called with a space after comma and in some not. The output looked weird when the echo line sometimes had 2 spaces before the component name instead of one. It should not matter to the rm command line however. > - modules.xml "Changes to this file will require review by Committers to Project Jigsaw." Will this be true after integration into jdk9/dev repo? > > - modules.list seems to be redundant with modules.xml but there don't seem to be any measures to ensure that they remain in sync. Even a comment in modules.xml would help. This kind of problem has been a source of errors in the past. They are redundant yes. modules.list is used by make to extract dependency information and modules.xml is used by the verification tool. In jigsaw development both files were dynamically created during the build process and here we simply committed static versions of them. Ideally we should only need one, but it's a temporary solution anyway. We would need to create a tool to extract dependency information from the xml to make. > - What is TestMake.gmk and associated for? These are my new tests for the common makefile logic. It's far from a complete coverage, but it has already helped me greatly. > jdk project: > > - I am slightly unsettled by the number of makefiles and putting them all in to the same directory. Will they eventually be moved into their modules? This is something I'm thinking about and would like to discuss. I think that ideally the makefiles for specific modules should be moved to module specific directories. For now I kept the existing task based directory structure. > More to come but first I want to build it! Go for it! /Erik > On Aug 12 2014, at 07:10 , Chris Hegarty wrote: > >> This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. >> >> For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8054834/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >> [3] http://hg.openjdk.java.net/jigsaw/stage From yuri.nesterenko at oracle.com Thu Aug 14 07:30:10 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 14 Aug 2014 11:30:10 +0400 Subject: CFV: New JDK9 Committer: Dmitriy Ermashov In-Reply-To: <20140813074757.286996@eggemoggin.niobe.net> References: <53EB5292.2050307@oracle.com> <20140813074757.286996@eggemoggin.niobe.net> Message-ID: <53EC6582.1090800@oracle.com> On 08/13/2014 06:47 PM, mark.reinhold at oracle.com wrote: > 2014/8/13 4:57 -0700, yuri.nesterenko at oracle.com: >> I hereby nominate Dmitriy Ermashov (dermashov) to JDK9 Committer. >> >> Dmitriy is a member of Java SQE team. >> He has contributed to several testing-related GUI OpenJDK >> projects. A list of his changesets has, so far, 11 items: >> >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/fa382ba1a8a7 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/db1d1894985c >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6a4534a458d >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8af305206840 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b2304c83a42d >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca9cc86574c1 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f51d560f6190 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c35d0a40b6e1 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c904d2c4425d >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/320dd90143c2 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0d65f6942ae9 > > Nearly all of these changesets appear simply to be transfers of > existing tests from Oracle-internal suites to the JDK 9 forest. > > Do you really think these count as "significant" contributions? > > - Mark > Mark, first of all, it's not exactly transfer but rather refactoring. Some of the patches are huge but still much much smaller than prototypes, and more stable and useful for jdk9. So the work is commendable in any case. Another question is, how much JDK9 need stable tests, who is going to maintain them and how, technically. Answer may be, and is to me, just about the same as to your question; yes, it is significant, useful and ongoing contribution -- humble but indispensable. Thank you, -yan PS: unfortunately I cannot attach here a link to the previous state of these tests to prove my first thesis but I can provide it to you personally if you wish. They are still in use with jdk8. From erik.joelsson at oracle.com Thu Aug 14 08:12:38 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Aug 2014 10:12:38 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EC6025.7080003@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> <53EC6025.7080003@oracle.com> Message-ID: <53EC6F76.4080407@oracle.com> On 2014-08-14 09:07, Erik Joelsson wrote: > - javadoc.gmk: JAVADOC_CMD should perhaps use (currently non-existant) > JAVA_TOOL_FLAGS_BIG or at least JAVA_FLAGS_BIG? > I agree, but that should be a separate change. Actually, the variable JAVA already contains the big java flags. The correct fix here is to remove the redundant explicit mx flag from Javadoc.gmk and just trust that JAVA is correctly sized. /Erik From alexander.zuev at oracle.com Thu Aug 14 14:50:52 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 14 Aug 2014 17:50:52 +0300 Subject: CFV: New JDK9 Committer: Dmitriy Ermashov In-Reply-To: <53EB5292.2050307@oracle.com> References: <53EB5292.2050307@oracle.com> Message-ID: <834C2A6F-B192-4E9A-8ECC-C006A201AC1A@oracle.com> Vote: yes Even after Mark's note I still vote for Dmitry for his contributions clearly are not simple copy commands. /Alex > On 13 Aug 2014, at 14:57, Yuri Nesterenko wrote: > > I hereby nominate Dmitriy Ermashov (dermashov) to JDK9 Committer. > > Dmitriy is a member of Java SQE team. > He has contributed to several testing-related GUI OpenJDK > projects. A list of his changesets has, so far, 11 items: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/fa382ba1a8a7 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/db1d1894985c > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6a4534a458d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8af305206840 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b2304c83a42d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca9cc86574c1 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f51d560f6190 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c35d0a40b6e1 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c904d2c4425d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/320dd90143c2 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0d65f6942ae9 > > Votes are due by August 27, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > -yan > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Thu Aug 14 16:57:21 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 14 Aug 2014 09:57:21 -0700 Subject: CFV: New JDK9 Committer: Dmitriy Ermashov In-Reply-To: <53EB5292.2050307@oracle.com> References: <53EB5292.2050307@oracle.com> Message-ID: <53ECEA71.6040106@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 8/13/14, 4:57 AM, Yuri Nesterenko wrote: > I hereby nominate Dmitriy Ermashov (dermashov) to JDK9 Committer. > > Dmitriy is a member of Java SQE team. > He has contributed to several testing-related GUI OpenJDK > projects. A list of his changesets has, so far, 11 items: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/fa382ba1a8a7 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/db1d1894985c > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6a4534a458d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8af305206840 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b2304c83a42d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca9cc86574c1 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f51d560f6190 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c35d0a40b6e1 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c904d2c4425d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/320dd90143c2 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0d65f6942ae9 > > Votes are due by August 27, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > -yan > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From jesper.wilhelmsson at oracle.com Thu Aug 14 17:03:39 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 14 Aug 2014 19:03:39 +0200 Subject: CFV: New JDK9 Committer: Dmitriy Ermashov In-Reply-To: <53EB5292.2050307@oracle.com> References: <53EB5292.2050307@oracle.com> Message-ID: <53ECEBEB.20200@oracle.com> Vote: yes Cleaning up the old tests is a significant contribution. /Jesper Yuri Nesterenko skrev 13/8/14 13:57: > I hereby nominate Dmitriy Ermashov (dermashov) to JDK9 Committer. > > Dmitriy is a member of Java SQE team. > He has contributed to several testing-related GUI OpenJDK > projects. A list of his changesets has, so far, 11 items: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/fa382ba1a8a7 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/db1d1894985c > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6a4534a458d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8af305206840 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b2304c83a42d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca9cc86574c1 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f51d560f6190 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c35d0a40b6e1 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c904d2c4425d > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/320dd90143c2 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0d65f6942ae9 > > Votes are due by August 27, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > -yan > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Thu Aug 14 23:04:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Aug 2014 16:04:37 -0700 Subject: Result: New jdk9 Reviewer: Rickard =?ISO-8859-1?Q?B=E4ckman?= Message-ID: <53ED4085.8090102@oracle.com> Voting for Rickard B?ckman [1] is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-July/001101.html From christian.tornqvist at oracle.com Thu Aug 14 23:09:39 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 14 Aug 2014 19:09:39 -0400 Subject: Result: New jdk9 Committer: Mikael Vidstedt Message-ID: <055101cfb814$d3787fa0$7a697ee0$@oracle.com> Voting for Mikael Vidstedt [1] is now closed. Yes: 53 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Regards, Christian Tornqvist [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-July/001047.html From xuelei.fan at oracle.com Thu Aug 14 23:39:05 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 15 Aug 2014 07:39:05 +0800 Subject: CFV: New JDK9 Committer: Dmitriy Ermashov In-Reply-To: <53EB5292.2050307@oracle.com> References: <53EB5292.2050307@oracle.com> Message-ID: <53ED4899.8090802@oracle.com> vote: yes From magnus.ihse.bursie at oracle.com Fri Aug 15 08:52:36 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Aug 2014 10:52:36 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EDCA54.2090107@oracle.com> On 2014-08-12 16:10, Chris Hegarty wrote: > This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. > > For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ These are indeed the single most significant changes to the build system since the "new" build system was introduced. Here follows a partial review of the changes in the jdk repo. Even though it's long, I'm not done. ;-) *** General issues *** * The new directory jdk/make/bundle should instead reside in jdk/make/data/bundles. * In GensrcSwing.gmk is a "$(if $(SHUFFLED)..." part that seems to be remnants of older, temporary work. * The new file GensrcProviders.gmk are included by the Gensrc files for jdk.attach and jdk.jdi, which only uses half of it each. Each half is just a few lines long. I believe a better solution is to remove the GensrcProviders.gmk file, move the process-provider macro to GensrcCommon.gmk and move the two actual rules to the respective module gensrc file. * In the gensrc directory, there are now almost twice as many files. For many of them, the following pattern holds: GensrcOldStyle.gmk -- defines the actual logic for some gensrc target Gensrc-.gmk -- does nothing but includes GensrcOldStyle.gmk In these cases, I think the contents of GensrcOldStyle should be inlined directly in the Gensrc-.gmk instead. This holds for all modules except the two mammuth modules java.base and java.desktop. (Depending on the treatment of GensrcProviders as described above.) * In CreateJars.gmk, the following new comment is found embedded: # This currently won't work with modular build layout, but there currently are no # types needing to be re added. In my opinion, leaving code which looks like it's working but with a note saying "out of order", is bad practice. I'd recommend that the code is removed or commented out, if it is not needed. * In CreateJars.gmk, in BUILD_TOOLS_JAR: The following looks like a duplication; I believe the "classes" version should be removed. $(JDK_OUTPUTDIR)/modules/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector \ $(JDK_OUTPUTDIR)/classes/META-INF/services/com.sun.jdi.connect.Connector \ * In CreateSecurityJars.gmk, there is a variable SECURITY_CLASSES_SUBDIR that is always set to 'modules'. I believe this is remains of an older temporary design, and that "modules" should be hard-coded into the paths. * The old Setup.gmk had a very generic-sounding name, even though it only did setup java compilers. So, the rename to SetupJava.gmk was good; however, I'd suggest we follow it through all the way and rename it further to SetupJavaCompilers.gmk, since that is an even more accurate description of it's job. * The file CopyIntoClasses.gmk is not used anymore and should be removed. * In CoreLibraries.gmk, there used to be a line "BUILD_LIBRARIES += $(BUILD_LIBFDLIBM)" which is now removed. After discussion with Erik, I learned that this was since the libfdlibm was not delivered in itself, but was used solely as a helper lib for libjava, which has BUILD_LIBFDLIBM as a requirement. While this change is thus correct, I believe a comment describing this fact would be in place on libfdlibm, since it makes it behave differently than all other libraries. *** Issues with source files moving and its repercussions *** * When the source code has moved, especially the native libraries, most of the specific INCLUDE and EXCLUDE statements are, or should be, unnecessary. Nevertheless, there are still several occasions of such statements. In some cases, it seems like dead code that can (and should) be removed. But in some cases, I believe it is an indication that the source code has still not yet been moved to a suitable location. I believe the end goal with this shuffling regarding native library source code is that there should be a one-to-one correspondance between compiled native library and source code directory. This is now indeed the case for 99% of the libraries, but there are still some exceptions. This is a slightly vague point at the moment. I indent to check the INCLUDE and EXCLUDE statements more fully and will post a second review with results of what I find. Nevertheless, I think it is important to make sure we do get things correct this time. *** Issues regarding modules.xml *** The new modules.xml and associated Java tools and make files seems rather confusing to me. I understand some of the mysteries here are due the the fact that the file has moved around during development. Nevertheless, such historical relics should be removed when the code is ready to be pushed to mainline. More concretely: * ModulesXml.gmk referes to make/data/checkdeps/modules.xml. This file does not exist. I believe this should be the $(TOPDIR)/modules.xml. * GenererateModules.Xml says: "This tool is used to generate com/sun/tools/jdeps/resources/modules.xml". This is an incorrect claim. In fact, the output file of the tool is specified by the user. The way it is used by the build tool currently, the output file is placed in $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml, but that is decided by the make file and not the Java utility. * In fact, what happens is this: ** $(TOPDIR)/modules.xml is copied to $(JDK_OUTPUTDIR)/btclasses/build/tools/module/modules.xml ** Then the GenerateModulesXml tool is executed. ** The tool will open and read this file using GenerateModulesXml.class.getResourceAsStream("modules.xml"). ** The tool will generate output to a new file, specified to be $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml. ** Afterwards, the separate tool $(JDK_OUTPUTDIR)/bin/jdeps is executed, which will pick up the $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml, presumably using getResourceAsStream. (I have not verified this.) I have several objections to this. * First, we are actually dealing with two different files, but both are named modules.xml. I believe one of them is an annotated version of the other, but I have not chec,ed. Nevertheless, this is just an unneccessary source of confusion. One of them should change name, e.g. annotated-modules.xml or jdeps-modules.xml or whatever. * Second, it is not documented anywhere that GenerateModulexXml requires an modules.xml as input. * Third, and this links into the bullet above, this dependency is not explicit but hidden away with unnessary shuffling and hard-to-understand shuffling of files as result. A better solution, I believe, is two modify GenerateModulesXml to require a path to the input modules.xml as an argument, in addition to the output file. That way, the dependency will be obvious, and we can just point to $(TOPDIR)/modules.xml instead of copying it around. * And fourth, all old comments etc refering to old placements of the files should be corrected. * Finally, I'm also not entirely happy with the placement of modules.xml in the root directory. Erik has told me that the intention is that this file will ultimately be created dynamically at build time, and when that happens, it will just be a build by-product which can be placed elsewhere. If this is indeed the case, I can live with some temporary extra cluttering of the top-level directory. *** More major undertakings *** * The file GensrcProperties.gmk is not split according to modules. I understand why this is harder to do and why it was not done for this milestone; nevertheless I believe it should be done in a followup patch. * GensrcCLDR.gmk is not ideal. It generates source for multiple modules, and the output is separated afterwards. Fixing this will probably means some modification to the java helper tools. * This code that previously was in jdk/make/CopyIntoClasses has now unfortunately moved this very specific logic up into the top repo. In fact, the top/make/CompileJavaModules.gmk now contain module-specific data such as "java.base_COPY := .icu .dat .spp content-types.properties". This should really be split into module-specific files and pushed down once again to the jdk/make directory, maybe into the copy directory. * I think the jdk/make/data directory could (and should) be separated on module level, e.g. jdk/make/data/java.base/... etc. Or, maybe, that the contents should even be moved out into like src/java.base/share/data, since the contents of that directory in a way is "source code" (only just not Java or native source code), and not really part of the build system. *** Issues that was not introduced now, but should be fixed at some point *** * In CopyCommon, the variables LIBDIR and INCLUDEDIR has very generic-sounding name even though they are very specific. These names are not new, but since the definition is now in a different file than the uses of it, the badly chosen names makes it even harder to understand the code. * The platform-specific correspondance, OPENJDK_TARGET_OS_INCLUDE = $(INCLUDEDIR)/$(OPENJDK_TARGET_OS) is also bad from several perspectives: It is a variant of INCLUDEDIR but it does not end in DIR, it should not start with OPENJDK since it's not a global variable, and finally it uses incorrect assignment (= instead of :=). * In Awt2dLibraries.gmk, for libsplashscreen, the logic for the three included external graphics libraries (gif, jpeg and png) is highly asymmetric, which make it hard to understand. It seems likely that at least the libjpeg handling is broken. * The BUILD_LIBT2K is used only by the Oracle closed build, and the definition should move to the closed sources. /Magnus From magnus.ihse.bursie at oracle.com Fri Aug 15 10:13:27 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Aug 2014 12:13:27 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDCA54.2090107@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> Message-ID: <53EDDD47.2010204@oracle.com> On 2014-08-15 10:52, Magnus Ihse Bursie wrote: > > *** Issues with source files moving and its repercussions *** > > * When the source code has moved, especially the native libraries, > most of the specific INCLUDE and EXCLUDE statements are, or should be, > unnecessary. Nevertheless, there are still several occasions of such > statements. In some cases, it seems like dead code that can (and > should) be removed. But in some cases, I believe it is an indication > that the source code has still not yet been moved to a suitable > location. I believe the end goal with this shuffling regarding native > library source code is that there should be a one-to-one > correspondance between compiled native library and source code > directory. This is now indeed the case for 99% of the libraries, but > there are still some exceptions. > > This is a slightly vague point at the moment. I indent to check the > INCLUDE and EXCLUDE statements more fully and will post a second > review with results of what I find. Nevertheless, I think it is > important to make sure we do get things correct this time. Here are the more concrete specification of this, for all files except Awt2dLibraries.gmk, which I'll return to. In NioLibraries: * The line "EXCLUDES := sctp" is unnecessary. In NetworkingLibraries.gmk: * There are multiple instances of this pattern: ifneq ($(OPENJDK_TARGET_OS), solaris) LIBNET_EXCLUDE_FILES += solaris_close.c endif The correct solution is to move the corresponding files away from the "unix" directory and into more specific libraries (linux, solaris and macosx) and include these directories automatically depending on platform. This will allow us to remove the exclude expression. * For AIX, this is already done (woho!); however, unfortunately, the file aix_close.c ended up not in java.base/aix/native/libnet/ but in java.base/aix/native/libnet/java/net, with remnants of the old directory structure still intact. * Also, the corresponding source line in NetworkingLibraries.gmk for AIX is incorrect, and refers to the old structure: LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/ is incorrect. But if solving the two problems above, this will be corrected all by itself, rendering this statement unnecessary. In Lib-jdk.security.auth.gmk: * The file src/jdk.security.auth/unix/native/libjaas/Solaris.c should move to a solaris directory instead, rendering the EXCLUDE for libjaas unnecessary. In Lib-jdk.attach.gmk: The files * src/jdk.attach/unix/native/libattach/LinuxVirtualMachine.c * src/jdk.attach/unix/native/libattach/SolarisVirtualMachine.c * src/jdk.attach/unix/native/libattach/BsdVirtualMachine.c should move from unix to linux, solaris and macosx respectively, rendering the EXCLUDES unnecessary. The statement LIBATTACH_EXCLUDE_FILES += AixVirtualMachine.c is already unnecessary, since that files virtuously is already placed in an aix directory! :-) In Lib-java.management.gmk: The files * src/java.management/unix/native/libmanagement/LinuxOperatingSystem.c * src/java.management/unix/native/libmanagement/SolarisOperatingSystem.c * src/java.management/unix/native/libmanagement/MacosxOperatingSystem.c should move from unix to linux, solaris and macosx respectively, rendering the EXCLUDES unnecessary. In CoreLibraries.gmk, for libjava: * The file src/java.base/unix/native/libjava/java_props_macosx.c should move to a macosx directory. * The line "EXCLUDES := fdlibm/src zip prefs" is not needed anymore. * The stanza: ifeq ($(OPENJDK_TARGET_OS), macosx) LIBJAVA_EXCLUDE_FILES += $(JDK_TOPDIR)/src/java.base/unix/native/libjava/HostLocaleProviderAdapter_md.c endif is unnecessary since no such file exists. In CoreLibraries.gmk, for libjli: Here are include statements galore! :) After parsing what we're supposed to do and checking with how the source code now actually looks, this can boil down to: * As normal, set the source dirs to share and PLATFORM_OS and OS_API. * On macosx, exclude java_md_solinux.c, ergo.c and ergo_i586.c. * On unixes that are not macosx: If OPENJDK_TARGET_CPU_ARCH != x86 then also exclude ergo_i586.c and set LIBJLI_CFLAGS += -DUSE_GENERIC_ERGO But to make things worse, we also use a selected subset of the source from zlib :-(, viz.: inflate.c inftrees.c inffast.c zadler32.c zcrc32.c zutil.c This should be turned into a exclude-based statement instead (unless USE_EXTERNAL_LIBZ is true, of course), like this: BUILD_LIBJLI_SRC_DIRS += $(JDK_TOPDIR)/src/java.base/share/native/libzip/zlib-1.2.8 (as before) and exclude: compress.c deflate.c gzclose.c gzlib.c gzread.c gzwrite.c infback.c trees.c uncompr.c /Magnus From erik.joelsson at oracle.com Fri Aug 15 10:13:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Aug 2014 12:13:45 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDCA54.2090107@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> Message-ID: <53EDDD59.1000502@oracle.com> Hello, Magnus Thanks for the thorough review. I tend to agree with Alan, that we should rather push this in unless we find critical issues but make sure to continue cleaning this up in jdk9/dev. I have created bugs for (almost) everything you have listed below. See inline for links and comments. On 2014-08-15 10:52, Magnus Ihse Bursie wrote: > Here follows a partial review of the changes in the jdk repo. Even > though it's long, I'm not done. ;-) > > *** General issues *** > > * The new directory jdk/make/bundle should instead reside in > jdk/make/data/bundles. > > * In GensrcSwing.gmk is a "$(if $(SHUFFLED)..." part that seems to be > remnants of older, temporary work. > Created " General cleanup of minor issues from source restructure" https://bugs.openjdk.java.net/browse/JDK-8055188 > * The new file GensrcProviders.gmk are included by the Gensrc files > for jdk.attach and jdk.jdi, which only uses half of it each. Each half > is just a few lines long. I believe a better solution is to remove the > GensrcProviders.gmk file, move the process-provider macro to > GensrcCommon.gmk and move the two actual rules to the respective > module gensrc file. > > * In the gensrc directory, there are now almost twice as many files. > For many of them, the following pattern holds: > GensrcOldStyle.gmk -- defines the actual logic for some gensrc target > Gensrc-.gmk -- does nothing but includes GensrcOldStyle.gmk > > In these cases, I think the contents of GensrcOldStyle should be > inlined directly in the Gensrc-.gmk instead. This holds for > all modules except the two mammuth modules java.base and java.desktop. > (Depending on the treatment of GensrcProviders as described above.) > Created "Cleanup gensrc after source code restructure" https://bugs.openjdk.java.net/browse/JDK-8055189 > * In CreateJars.gmk, the following new comment is found embedded: > # This currently won't work with modular build layout, but > there currently are no > # types needing to be re added. > In my opinion, leaving code which looks like it's working but with a > note saying "out of order", is bad practice. I'd recommend that the > code is removed or commented out, if it is not needed. > While I agree on this in principle, I would rather not spend time on the profiles generation code since it's planned to go away soon anyway. > * In CreateJars.gmk, in BUILD_TOOLS_JAR: The following looks like a > duplication; I believe the "classes" version should be removed. > $(JDK_OUTPUTDIR)/modules/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector > \ > $(JDK_OUTPUTDIR)/classes/META-INF/services/com.sun.jdi.connect.Connector > \ > > * In CreateSecurityJars.gmk, there is a variable > SECURITY_CLASSES_SUBDIR that is always set to 'modules'. I believe > this is remains of an older temporary design, and that "modules" > should be hard-coded into the paths. > > * The old Setup.gmk had a very generic-sounding name, even though it > only did setup java compilers. So, the rename to SetupJava.gmk was > good; however, I'd suggest we follow it through all the way and rename > it further to SetupJavaCompilers.gmk, since that is an even more > accurate description of it's job. > > * The file CopyIntoClasses.gmk is not used anymore and should be removed. > > * In CoreLibraries.gmk, there used to be a line "BUILD_LIBRARIES += > $(BUILD_LIBFDLIBM)" which is now removed. After discussion with Erik, > I learned that this was since the libfdlibm was not delivered in > itself, but was used solely as a helper lib for libjava, which has > BUILD_LIBFDLIBM as a requirement. While this change is thus correct, I > believe a comment describing this fact would be in place on libfdlibm, > since it makes it behave differently than all other libraries. > Added to general cleanup > *** Issues with source files moving and its repercussions *** > > * When the source code has moved, especially the native libraries, > most of the specific INCLUDE and EXCLUDE statements are, or should be, > unnecessary. Nevertheless, there are still several occasions of such > statements. In some cases, it seems like dead code that can (and > should) be removed. But in some cases, I believe it is an indication > that the source code has still not yet been moved to a suitable > location. I believe the end goal with this shuffling regarding native > library source code is that there should be a one-to-one > correspondance between compiled native library and source code > directory. This is now indeed the case for 99% of the libraries, but > there are still some exceptions. > > This is a slightly vague point at the moment. I indent to check the > INCLUDE and EXCLUDE statements more fully and will post a second > review with results of what I find. Nevertheless, I think it is > important to make sure we do get things correct this time. > Created "Cleanup include and exclude of native libraries after source code restructure" https://bugs.openjdk.java.net/browse/JDK-8055190 > *** Issues regarding modules.xml *** > > The new modules.xml and associated Java tools and make files seems > rather confusing to me. I understand some of the mysteries here are > due the the fact that the file has moved around during development. > Nevertheless, such historical relics should be removed when the code > is ready to be pushed to mainline. More concretely: > > * ModulesXml.gmk referes to make/data/checkdeps/modules.xml. This file > does not exist. I believe this should be the $(TOPDIR)/modules.xml. > > * GenererateModules.Xml says: "This tool is used to generate > com/sun/tools/jdeps/resources/modules.xml". This is an incorrect > claim. In fact, the output file of the tool is specified by the user. > The way it is used by the build tool currently, the output file is > placed in > $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml, > but that is decided by the make file and not the Java utility. > > * In fact, what happens is this: > ** $(TOPDIR)/modules.xml is copied to > $(JDK_OUTPUTDIR)/btclasses/build/tools/module/modules.xml > ** Then the GenerateModulesXml tool is executed. > ** The tool will open and read this file using > GenerateModulesXml.class.getResourceAsStream("modules.xml"). > ** The tool will generate output to a new file, specified to be > $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml. > ** Afterwards, the separate tool $(JDK_OUTPUTDIR)/bin/jdeps is > executed, which will pick up the > $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml, > presumably using getResourceAsStream. (I have not verified this.) > > I have several objections to this. > > * First, we are actually dealing with two different files, but both > are named modules.xml. I believe one of them is an annotated version > of the other, but I have not chec,ed. Nevertheless, this is just an > unneccessary source of confusion. One of them should change name, e.g. > annotated-modules.xml or jdeps-modules.xml or whatever. > > * Second, it is not documented anywhere that GenerateModulexXml > requires an modules.xml as input. > > * Third, and this links into the bullet above, this dependency is not > explicit but hidden away with unnessary shuffling and > hard-to-understand shuffling of files as result. A better solution, I > believe, is two modify GenerateModulesXml to require a path to the > input modules.xml as an argument, in addition to the output file. That > way, the dependency will be obvious, and we can just point to > $(TOPDIR)/modules.xml instead of copying it around. > > * And fourth, all old comments etc refering to old placements of the > files should be corrected. > > * Finally, I'm also not entirely happy with the placement of > modules.xml in the root directory. Erik has told me that the intention > is that this file will ultimately be created dynamically at build > time, and when that happens, it will just be a build by-product which > can be placed elsewhere. If this is indeed the case, I can live with > some temporary extra cluttering of the top-level directory. > While I agree it's messy at the moment, this is an area that is temporary and will change drastically. Added as optional to general cleanup. > *** More major undertakings *** > > * The file GensrcProperties.gmk is not split according to modules. I > understand why this is harder to do and why it was not done for this > milestone; nevertheless I believe it should be done in a followup patch. > Created "Split GensrcProperties.gmk into separate modules" https://bugs.openjdk.java.net/browse/JDK-8055191 > * GensrcCLDR.gmk is not ideal. It generates source for multiple > modules, and the output is separated afterwards. Fixing this will > probably means some modification to the java helper tools. > While I think it would be good to split this in principle, I'm not sure it's worth pursuing. The english locale is in the base module and the others are in a different module. I would leave this as it is for now. > * This code that previously was in jdk/make/CopyIntoClasses has now > unfortunately moved this very specific logic up into the top repo. In > fact, the top/make/CompileJavaModules.gmk now contain module-specific > data such as "java.base_COPY := .icu .dat .spp > content-types.properties". This should really be split into > module-specific files and pushed down once again to the jdk/make > directory, maybe into the copy directory. > Created "Move java and copy specific information in CompileJavaModules.gmk to module specific makefiles" https://bugs.openjdk.java.net/browse/JDK-8055192 > * I think the jdk/make/data directory could (and should) be separated > on module level, e.g. jdk/make/data/java.base/... etc. Or, maybe, that > the contents should even be moved out into like > src/java.base/share/data, since the contents of that directory in a > way is "source code" (only just not Java or native source code), and > not really part of the build system. > Created "Move jdk/make/data to module specific src dirs after source restructure" https://bugs.openjdk.java.net/browse/JDK-8055193 > *** Issues that was not introduced now, but should be fixed at some > point *** > > * In CopyCommon, the variables LIBDIR and INCLUDEDIR has very > generic-sounding name even though they are very specific. These names > are not new, but since the definition is now in a different file than > the uses of it, the badly chosen names makes it even harder to > understand the code. > > * The platform-specific correspondance, OPENJDK_TARGET_OS_INCLUDE = > $(INCLUDEDIR)/$(OPENJDK_TARGET_OS) is also bad from several > perspectives: It is a variant of INCLUDEDIR but it does not end in > DIR, it should not start with OPENJDK since it's not a global > variable, and finally it uses incorrect assignment (= instead of :=). > Added to general cleanup. > * In Awt2dLibraries.gmk, for libsplashscreen, the logic for the three > included external graphics libraries (gif, jpeg and png) is highly > asymmetric, which make it hard to understand. It seems likely that at > least the libjpeg handling is broken. > Created "Cleanup source and makefile logic for libsplashscreen and libjavajpeg after source restructure" https://bugs.openjdk.java.net/browse/JDK-8055194 > * The BUILD_LIBT2K is used only by the Oracle closed build, and the > definition should move to the closed sources. > Added to general cleanup /Erik From erik.joelsson at oracle.com Fri Aug 15 10:32:09 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Aug 2014 12:32:09 +0200 Subject: CFV: New JDK9 Committer: Dmitriy Ermashov In-Reply-To: <53EB5292.2050307@oracle.com> References: <53EB5292.2050307@oracle.com> Message-ID: <53EDE1A9.9080905@oracle.com> Vote: yes /Erik From Alan.Bateman at oracle.com Fri Aug 15 10:42:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Aug 2014 11:42:15 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDDD47.2010204@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> Message-ID: <53EDE407.8010308@oracle.com> On 15/08/2014 11:13, Magnus Ihse Bursie wrote: > : > > In NetworkingLibraries.gmk: > > * There are multiple instances of this pattern: > ifneq ($(OPENJDK_TARGET_OS), solaris) > LIBNET_EXCLUDE_FILES += solaris_close.c > endif > The correct solution is to move the corresponding files away from the > "unix" directory and into more specific libraries (linux, solaris and > macosx) and include > these directories automatically depending on platform. This will allow > us to remove the exclude expression. > It's good that you giving these changes a thorough review. I agree that this and all the other $OS specific source that you have listed move and the EXCLUDES dropped. As I said in the previous reply then this is not necessary for this initial push. Instead the intention was to establish the new layout and for each area to gradually move any remaining Solaris, Linux and OS X sources from src/$MODULE/unix to src/$MODULE/$OS. It does mean that about 1% of the source files will need to move again once the changes are in jdk9/dev but I don't expect this to be disruptive. -Alan. From erik.joelsson at oracle.com Fri Aug 15 13:17:57 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Aug 2014 15:17:57 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE02EB.5060508@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EE02EB.5060508@oracle.com> Message-ID: <53EE0885.80401@oracle.com> On 2014-08-15 14:54, Maurizio Cimadamore wrote: > I'm looking at the langtools-related changes in build.xml; I what is > the degree of support available in the build.xml ant file for the > Jigsaw world? It seems to me that not all the target would function > and it also seems that some of the properties previously encoded in a > side property file (make/build.properties) have now been inlined in > the build.xml file itself, which seems problematic maintenance-wise. > Am I missing something? > As far as I know, build.xml has so far been supported by the langtools team themselves and all changes to the file in this patch have been made by them. Jon may have something to say? /Erik > Maurizio > > On 12/08/14 15:10, Chris Hegarty wrote: >> This is a review request for the Initial changes for JEP 201: Modular >> Source Code [1]. >> >> There are a number of individuals responsible for these changes. >> Some, possibly not all, are explicitly listed in the To section of >> this mail, and they will help address any comments arising from this >> review request. >> >> For the purposes of review, the actual source file moves have been >> omitted from the webrev below, with the exception of any source file >> that has a change to it?s actual content. The new location of the >> source files can be determined from JEP 201 [1] and JEP 200 "The >> Modular JDK" [2], or by browsing the staging forest [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8054834/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has >> been tentatively reserved for their integration. All comments are >> welcome, although given the nature of the changes then we might have >> to create separate issues in JIRA to address some of them later in >> jdk9/dev.. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >> [3] http://hg.openjdk.java.net/jigsaw/stage > From Alan.Bateman at oracle.com Fri Aug 15 09:27:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Aug 2014 10:27:11 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDC9A4.1030104@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDC9A4.1030104@oracle.com> Message-ID: <53EDD26F.5020400@oracle.com> On 15/08/2014 09:49, Magnus Ihse Bursie wrote: > These are indeed the single most significant changes to the build > system since the "new" build system was introduced. Indeed, some of us have been referring to this as the "new new build". As I recall there was a tail of issues and clean-ups for the JDK 8 "new build" and it will be the case here too. So if there aren't any blocking issues then I think the best thing is to work on those in jdk9/dev once the changes get there, otherwise I suspect we will iterate on this for a long time (and as I'm sure you can appreciate, it is painful to have to keep thousands of lines of make file changes in a side forest while the main line churns). > : > > * When the source code has moved, especially the native libraries, > most of the specific INCLUDE and EXCLUDE statements are, or should be, > unnecessary. Nevertheless, there are still several occasions of such > statements. In some cases, it seems like dead code that can (and > should) be removed. But in some cases, I believe it is an indication > that the source code has still not yet been moved to a suitable > location. I believe the end goal with this shuffling regarding native > library source code is that there should be a one-to-one > correspondance between compiled native library and source code > directory. This is now indeed the case for 99% of the libraries, but > there are still some exceptions. I assume you are referring to the rename of src/solaris to src/unix, something that was long overdue in the jdk repository. The intention is that eventually each area will go through their source files in src/$MODULE/unix and move any source files that are Linux, Solaris or OS X specific to the appropriate src/$MODULE/$OS tree. We've done it for a few libraries (such as libnio) so several EXCLUDE_FILES are already removed, the remainder of the exceptions will happen in time. > : > > * Finally, I'm also not entirely happy with the placement of > modules.xml in the root directory. Erik has told me that the intention > is that this file will ultimately be created dynamically at build > time, and when that happens, it will just be a build by-product which > can be placed elsewhere. If this is indeed the case, I can live with > some temporary extra cluttering of the top-level directory The top-level directory is intentional. It's not worth getting hung up on it because it is temporary (as noted in the JEP) and so will go away once we are further down the road on having a module system in JDK 9. -Alan. From maurizio.cimadamore at oracle.com Fri Aug 15 12:54:03 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Aug 2014 13:54:03 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EE02EB.5060508@oracle.com> I'm looking at the langtools-related changes in build.xml; I what is the degree of support available in the build.xml ant file for the Jigsaw world? It seems to me that not all the target would function and it also seems that some of the properties previously encoded in a side property file (make/build.properties) have now been inlined in the build.xml file itself, which seems problematic maintenance-wise. Am I missing something? Maurizio On 12/08/14 15:10, Chris Hegarty wrote: > This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. > > For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ > > Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8051619 > [2] https://bugs.openjdk.java.net/browse/JDK-8051618 > [3] http://hg.openjdk.java.net/jigsaw/stage From maurizio.cimadamore at oracle.com Fri Aug 15 15:13:26 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Aug 2014 16:13:26 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE0885.80401@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EE02EB.5060508@oracle.com> <53EE0885.80401@oracle.com> Message-ID: <53EE2396.7090402@oracle.com> Quick update: I downloaded the jigsaw stage repo and tried the build. The biggest issue is that it requires Ant 1.9.4 (because of the MuliRootFileSet) to work, but after that is set up, everything works like before. My IntelliJ setup needed few cosmetic changes, to update the source roots, but nothing out of the ordinary. Overall, I'm pretty satisfied with it. Maurizio On 15/08/14 14:17, Erik Joelsson wrote: > > On 2014-08-15 14:54, Maurizio Cimadamore wrote: >> I'm looking at the langtools-related changes in build.xml; I what is >> the degree of support available in the build.xml ant file for the >> Jigsaw world? It seems to me that not all the target would function >> and it also seems that some of the properties previously encoded in a >> side property file (make/build.properties) have now been inlined in >> the build.xml file itself, which seems problematic maintenance-wise. >> Am I missing something? >> > As far as I know, build.xml has so far been supported by the langtools > team themselves and all changes to the file in this patch have been > made by them. Jon may have something to say? > > /Erik > >> Maurizio >> >> On 12/08/14 15:10, Chris Hegarty wrote: >>> This is a review request for the Initial changes for JEP 201: >>> Modular Source Code [1]. >>> >>> There are a number of individuals responsible for these changes. >>> Some, possibly not all, are explicitly listed in the To section of >>> this mail, and they will help address any comments arising from this >>> review request. >>> >>> For the purposes of review, the actual source file moves have been >>> omitted from the webrev below, with the exception of any source file >>> that has a change to it?s actual content. The new location of the >>> source files can be determined from JEP 201 [1] and JEP 200 "The >>> Modular JDK" [2], or by browsing the staging forest [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8054834/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion >>> has been tentatively reserved for their integration. All comments >>> are welcome, although given the nature of the changes then we might >>> have to create separate issues in JIRA to address some of them later >>> in jdk9/dev.. >>> >>> -Chris. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >>> [3] http://hg.openjdk.java.net/jigsaw/stage >> > From mandy.chung at oracle.com Fri Aug 15 15:30:53 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Aug 2014 08:30:53 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDC9A4.1030104@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDC9A4.1030104@oracle.com> Message-ID: <53EE27AD.4010208@oracle.com> On 8/15/2014 1:49 AM, Magnus Ihse Bursie wrote: > *** Issues regarding modules.xml *** > > The new modules.xml and associated Java tools and make files seems > rather confusing to me. I understand some of the mysteries here are > due the the fact that the file has moved around during development. > Nevertheless, such historical relics should be removed when the code > is ready to be pushed to mainline. More concretely: > One thing to say about the modules.xml file is that it's not just for jdeps to use (verifying the module boundaries). It is an essential documentation to describe the module definition for the JDK [1] and will go away once the module system is in place and not all the modules are in the jdk repo and hence it's placed in the top level repo. > * ModulesXml.gmk referes to make/data/checkdeps/modules.xml. This file > does not exist. I believe this should be the $(TOPDIR)/modules.xml. > That reference in the comment that we missed to update when moving the file. Fixed. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8051618 From mandy.chung at oracle.com Fri Aug 15 15:41:11 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Aug 2014 08:41:11 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EE2A17.3000902@oracle.com> On 8/12/2014 7:10 AM, Chris Hegarty wrote: > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ I reviewed the hotspot change. Looks good. One minor point: I think line 1230 can be removed when rt.jar is present. Mandy From omajid at redhat.com Fri Aug 15 15:55:09 2014 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Aug 2014 11:55:09 -0400 Subject: RFR [9] Modular Source Code In-Reply-To: <53EB5BA3.2050504@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5BA3.2050504@oracle.com> Message-ID: <20140815155508.GF21356@redhat.com> Hi, * Alan Bateman [2014-08-13 08:36]: > Just to add to Chris and Erik's mails, I would encourage everyone that > pushes to jdk9/dev or the other jdk9 project integration forests to clone > and build jigsaw/stage and get familiar with the proposed layout, new build > targets, and the very different output emitted during the build. The changes > are arguably as significant as the transition in JDK 8 from the "old build" > to the "new build" so the more people taking the forest for a test drive the > better. If you maintain your our own own IDE project then you'll likely have > to adjust file paths so any issues encountered would be useful to hear about > too. Just one RFE for now: The new build would provide a detailed breakdown of the build time of each repo. With the 'new new build', all I see is an overall time: > ----- Build times ------- > Start 2014-08-15 10:59:27 > End 2014-08-15 11:17:53 > > 00:18:26 TOTAL > ------------------------- Will a detailed breakdown of the build times for each module make a return? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From erik.joelsson at oracle.com Fri Aug 15 15:58:24 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Aug 2014 17:58:24 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <20140815155508.GF21356@redhat.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5BA3.2050504@oracle.com> <20140815155508.GF21356@redhat.com> Message-ID: <53EE2E20.7040304@oracle.com> Hello Omair, No, as I tried to explain in my initial mail on this thread, since the modules are all compiled in parallel, and not sequentially like the current build does with the repositories, it doesn't make much sense timing each module. The numbers would be meaningless. /Erik On 2014-08-15 17:55, Omair Majid wrote: > Hi, > > * Alan Bateman [2014-08-13 08:36]: >> Just to add to Chris and Erik's mails, I would encourage everyone that >> pushes to jdk9/dev or the other jdk9 project integration forests to clone >> and build jigsaw/stage and get familiar with the proposed layout, new build >> targets, and the very different output emitted during the build. The changes >> are arguably as significant as the transition in JDK 8 from the "old build" >> to the "new build" so the more people taking the forest for a test drive the >> better. If you maintain your our own own IDE project then you'll likely have >> to adjust file paths so any issues encountered would be useful to hear about >> too. > Just one RFE for now: > > The new build would provide a detailed breakdown of the build time of > each repo. With the 'new new build', all I see is an overall time: > >> ----- Build times ------- >> Start 2014-08-15 10:59:27 >> End 2014-08-15 11:17:53 >> >> 00:18:26 TOTAL >> ------------------------- > Will a detailed breakdown of the build times for each module make a > return? > > Thanks, > Omair > From harold.seigel at oracle.com Fri Aug 15 16:14:00 2014 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 15 Aug 2014 12:14:00 -0400 Subject: RFR [9] Modular Source Code In-Reply-To: <53EB5771.2010908@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5407.50306@oracle.com> <53EB5771.2010908@oracle.com> Message-ID: <53EE31C8.6020808@oracle.com> Hi Chris, Could you change the comment at the start of expand_entries_to_path in src/share/vm/runtime/os.cpp to: // returns a PATH of all entries in the given directory *that do not start with a '.'* Thanks, Harold On 8/13/2014 8:17 AM, Chris Hegarty wrote: > >> On 2014-08-12 16:10, Chris Hegarty wrote: >>> This is a review request for the Initial changes for JEP 201: Modular >>> Source Code [1]. >>> >>> There are a number of individuals responsible for these changes. Some, >>> possibly not all, are explicitly listed in the To section of this >>> mail, and they will help address any comments arising from this review >>> request. >>> >>> For the purposes of review, the actual source file moves have been >>> omitted from the webrev below, with the exception of any source file >>> that has a change to it?s actual content. The new location of the >>> source files can be determined from JEP 201 [1] and JEP 200 "The >>> Modular JDK" [2], or by browsing the staging forest [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8054834/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion has >>> been tentatively reserved for their integration. All comments are >>> welcome, although given the nature of the changes then we might have >>> to create separate issues in JIRA to address some of them later in >>> jdk9/dev.. >>> >>> -Chris. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >>> [3] http://hg.openjdk.java.net/jigsaw/stage >> From chris.hegarty at oracle.com Fri Aug 15 16:45:55 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 15 Aug 2014 17:45:55 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE31C8.6020808@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5407.50306@oracle.com> <53EB5771.2010908@oracle.com> <53EE31C8.6020808@oracle.com> Message-ID: <53EE3943.4030906@oracle.com> On 15/08/14 17:14, harold seigel wrote: > Hi Chris, > > Could you change the comment at the start of expand_entries_to_path in > src/share/vm/runtime/os.cpp to: > > // returns a PATH of all entries in the given directory *that do not > start with a '.'* Done. http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/091d5820c70d -Chris. > Thanks, Harold > > On 8/13/2014 8:17 AM, Chris Hegarty wrote: >> >>> On 2014-08-12 16:10, Chris Hegarty wrote: >>>> This is a review request for the Initial changes for JEP 201: Modular >>>> Source Code [1]. >>>> >>>> There are a number of individuals responsible for these changes. Some, >>>> possibly not all, are explicitly listed in the To section of this >>>> mail, and they will help address any comments arising from this review >>>> request. >>>> >>>> For the purposes of review, the actual source file moves have been >>>> omitted from the webrev below, with the exception of any source file >>>> that has a change to it?s actual content. The new location of the >>>> source files can be determined from JEP 201 [1] and JEP 200 "The >>>> Modular JDK" [2], or by browsing the staging forest [3]. >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~chegar/8054834/00/ >>>> >>>> Due to the significant impact of these changes, a JDK 9 promotion has >>>> been tentatively reserved for their integration. All comments are >>>> welcome, although given the nature of the changes then we might have >>>> to create separate issues in JIRA to address some of them later in >>>> jdk9/dev.. >>>> >>>> -Chris. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >>>> [3] http://hg.openjdk.java.net/jigsaw/stage >>> > From jonathan.gibbons at oracle.com Fri Aug 15 17:52:32 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 15 Aug 2014 10:52:32 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE0885.80401@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EE02EB.5060508@oracle.com> <53EE0885.80401@oracle.com> Message-ID: <53EE48E0.7020004@oracle.com> Yes, we (the LangTools team) are on our own for this file. Jan Lahoda did some work to update the build.xml file for us. At some point we may want to do more surgery on this file, but that is a discussion for the LangTools team to have. -- Jon On 08/15/2014 06:17 AM, Erik Joelsson wrote: > > On 2014-08-15 14:54, Maurizio Cimadamore wrote: >> I'm looking at the langtools-related changes in build.xml; I what is >> the degree of support available in the build.xml ant file for the >> Jigsaw world? It seems to me that not all the target would function >> and it also seems that some of the properties previously encoded in a >> side property file (make/build.properties) have now been inlined in >> the build.xml file itself, which seems problematic maintenance-wise. >> Am I missing something? >> > As far as I know, build.xml has so far been supported by the langtools > team themselves and all changes to the file in this patch have been > made by them. Jon may have something to say? > > /Erik > >> Maurizio >> >> On 12/08/14 15:10, Chris Hegarty wrote: >>> This is a review request for the Initial changes for JEP 201: >>> Modular Source Code [1]. >>> >>> There are a number of individuals responsible for these changes. >>> Some, possibly not all, are explicitly listed in the To section of >>> this mail, and they will help address any comments arising from this >>> review request. >>> >>> For the purposes of review, the actual source file moves have been >>> omitted from the webrev below, with the exception of any source file >>> that has a change to it?s actual content. The new location of the >>> source files can be determined from JEP 201 [1] and JEP 200 "The >>> Modular JDK" [2], or by browsing the staging forest [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8054834/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion >>> has been tentatively reserved for their integration. All comments >>> are welcome, although given the nature of the changes then we might >>> have to create separate issues in JIRA to address some of them later >>> in jdk9/dev.. >>> >>> -Chris. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >>> [3] http://hg.openjdk.java.net/jigsaw/stage >> > From naoto.sato at oracle.com Fri Aug 15 18:00:15 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 15 Aug 2014 11:00:15 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDDD59.1000502@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD59.1000502@oracle.com> Message-ID: <53EE4AAF.1040801@oracle.com> On 8/15/14, 3:13 AM, Erik Joelsson wrote: >> * GensrcCLDR.gmk is not ideal. It generates source for multiple >> modules, and the output is separated afterwards. Fixing this will >> probably means some modification to the java helper tools. >> > While I think it would be good to split this in principle, I'm not sure > it's worth pursuing. The english locale is in the base module and the > others are in a different module. I would leave this as it is for now. I agree with Erik, as I will be working on this later. So let's leave it as is. Naoto From magnus.ihse.bursie at oracle.com Mon Aug 18 13:47:27 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Aug 2014 15:47:27 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDDD47.2010204@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> Message-ID: <53F203EF.9070907@oracle.com> On 2014-08-15 12:13, Magnus Ihse Bursie wrote: > Here are the more concrete specification of this, for all files except > Awt2dLibraries.gmk, which I'll return to. And here is the jury's verdict on Awt2dLibraries.gmk. :-) libjavajpeg: One of these are not needed: LIBJAVAJPEG_SRC := $(JDK_TOPDIR)/src/java.desktop/share/native/libjavajpeg LIBJAVAJPEG_SRC += $(JDK_TOPDIR)/src/java.desktop/share/native/libjavajpeg libfontmanager: EXCLUDE_FILES := $(LIBFONTMANAGER_EXCLUDE_FILES) \ AccelGlyphCache.c, \ The file AccelGlyphCache.c resides in src/java.desktop/share/native/common/sun/font, which is not included in the source dirs, so the exclude can be safely removed. The following stanza can be removed: ifeq ($(OPENJDK_TARGET_OS), windows) LIBFONTMANAGER_EXCLUDE_FILES += X11FontScaler.c \ X11TextRenderer.c LIBFONTMANAGER_OPTIMIZATION := HIGHEST LIBFONTMANAGER_CFLAGS += -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libawt/sun/windows else ifeq ($(OPENJDK_TARGET_OS), macosx) LIBFONTMANAGER_EXCLUDE_FILES += X11FontScaler.c \ X11TextRenderer.c \ fontpath.c \ lcdglyph.c else LIBFONTMANAGER_EXCLUDE_FILES += fontpath.c \ lcdglyph.c endif The X11*.c files are in the unix directory and the fontpath/lcdglyph files are in the windows directory, so they need to explicit excludes. However, the X11 files stills needs to be excluded on macosx. On the other hand, these two are all that exists in $(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libfontmanager, so we can just exclude that entire directory, or only add it unless we're building for macosx. libkcms: EXCLUDE_FILES := $(BUILD_LIBKCMS_EXCLUDE_FILES), is not needed, since BUILD_LIBKCMS_EXCLUDE_FILES is no longer defined. libjawt: INCLUDE_FILES := $(LIBJAWT_INCLUDE_FILES), and INCLUDE_FILES := $(JAWT_FILES), are not needed, since LIBJAWT_INCLUDE_FILES and JAWT_FILES are not defined. libawt_lwawt: INCLUDE_FILES := $(LIBAWT_LWAWT_FILES), is not needed, since LIBAWT_LWAWT_FILES is not defined. libt2k: According to EXCLUDE_FILES := t2k/orion.c, the file orion.c is never used, so it should be removed instead. Also, the entire library definition should move to closed code. liblcms: The include file picking of LCMS.c would not be needed if the upstream lcms source code were moved into a separate subdirectory of liblcms. libjavajpeg: If the upstream IJG jpeg library were moved into a subdirectory, the explicit includes of imageIOJPEG.c and jpegdecoder.c would not be needed. libmlib_image / libmlib_image_v: The files used for libmlib_image and libmlib_image_v are somewhat chaotic. Four directories are used, in different ways: 1) SHARE-LIB: java.desktop/share/native/libmlib_image 2) UNIX-LIB: java.desktop/unix/native/libmlib_image 3) SHARE-COMMON: java.desktop/share/native/common/sun/awt/medialib 4) UNIX-COMMON: java.desktop/unix/native/common/sun/awt/medialib They are used to build three different libraries: A) libmlib_image. Built on all platforms. Includes SHARE-LIB and SHARE-COMMON B) libmlib_image_v. Built on solaris-sparc only. Includes a subset (using excludes) of SHARE-LIB, UNIX-LIB, SHARE-COMMON and UNIX-COMMON. C) libawt. Uses SHARE-COMMON and UNIX-COMMON, but only when building for solaris-sparc. Maybe this complexity is not needed, but even if it is, there are a number of things that could help improve the situation. * The UNIX-LIB and UNIX-COMMON paths are only used on solaris and should move from "unix" to "solaris". * The SHARE-COMMON and UNIX-COMMON paths should move away from the common/sun/awt directories, since they need to be explicitely excluded by all other users of the common/sun/awt directories, e.g. to common/mlib_image. This would reduce the number of excludes elsewhere significantly. * The code in UNIX-LIB is used to build libmlib_image_v, not libmlib_image, and should thus be renamed so. * The code in SHARE-LIB that is actually shared by libmlib_image and libmlib_image_v should preferably be moved to java.desktop/share/native/common. I don't have any good suggestions though on how this should be handled so as not to collide with the different shared subset found in SHARE-COMMON. These files include basically the mlib_Image*.c files. It also includes the file mlib_c_ImageThresh1_U8.c, while excluding all other mlib_c_*.c. This almost looks like a mistake. * A number of files are hardcoded to always be excluded. These should be removed instead. These files are: In java.desktop/share/native/libmlib_image: mlib_c_ImageBlendTable.c In java.desktop/unix/native/libmlib_image: mlib_v_ImageChannelExtract.c \ mlib_v_ImageChannelExtract_f.c \ mlib_v_ImageChannelInsert_34.c \ mlib_v_ImageChannelInsert.c \ mlib_v_ImageConvIndex3_8_16nw.c \ mlib_v_ImageConvIndex3_8_8nw.c \ mlib_v_ImageCopy.c \ mlib_v_ImageCopy_blk.s \ libawt et al: The relation between libawt, libawt_headless, libjawt, libawt_xawt and libawt_lwawt are hairy enough to make my brain curl up. I believe there are simplifications to be made but I gave up trying to figure them out. /Magnus From magnus.ihse.bursie at oracle.com Mon Aug 18 13:56:45 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Aug 2014 15:56:45 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDDD47.2010204@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> Message-ID: <53F2061D.4000104@oracle.com> I also found these random notes scribbled down that I forgot to add to the previous mails: * In CoreLibraries.gmk, we have dead code defining BUILD_LIBVERIFY_SRC which is not used anymore. * In Tools.gmk, I notice that we copy the files $(JDK_TOPDIR)/src/java.desktop/share/classes/javax/swing/plaf/nimbus/%.template, but if they are only used by our build tools, they should probably live in make/data somewhere. * In SoundLibraries.gmk, the source code splitting is not complete. The directory libjsound is used to build not only libjsound but libjsoundalsa and libjsoundds, and thus needs a complex include/exclude system like before. * In CompileDemos, we create demo/jpda/src.zip. This includes source code from src/demo/share (expected), but also from jdk/src/jdk.jdi/share/classes/com/sun/tools/example/... (unexpected!). Should example code really live in the jdk.jdi package, and not in src/demo? /Magnus From anthony.petrov at oracle.com Mon Aug 18 14:15:08 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 18 Aug 2014 18:15:08 +0400 Subject: RFR [9] Modular Source Code In-Reply-To: <53F203EF.9070907@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> Message-ID: <53F20A6C.7090805@oracle.com> On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote: > libawt et al: > The relation between libawt, libawt_headless, libjawt, libawt_xawt > and libawt_lwawt are hairy enough to make my brain curl up. I believe > there are simplifications to be made but I gave up trying to figure them > out. libawt contains code that is shared between all AWT lib implementations. Depending on what mode/toolkit is requested, it loads a specific variant of the awt native library, such as: - libawt_headless - headless AWT implementation. - libawt_xawt - XToolkit implementation (uses X11 for GUI) - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI) Historically, we were able to choose between lwawt and xawt on Mac in the past, but we no longer support or even build xawt on Mac. Also, in the past there was MToolkit (which used Motif for GUI). Again, we no longer support this toolkit. So, currently we always use xawt on Linux/Solaris and lwawt on Mac. But since we still need to choose between a real toolkit and a headless toolkit, we need the common libawt library. libjawt is a helper library that implements JAWT API and is loaded by applications that use the JAWT interface which allows them to get direct access to the native AWT drawing surface and use native APIs (e.g. OpenGL) to draw on the surface. This library isn't needed for regular AWT/Swing applications. So I'm not sure if the current set of AWT libraries could be simplified any further. Hope this helps. -- best regards, Anthony From mark.reinhold at oracle.com Mon Aug 18 19:04:04 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 18 Aug 2014 12:04:04 -0700 Subject: First batch of JEPs proposed to target JDK 9 In-Reply-To: <20140811091751.593136@eggemoggin.niobe.net> References: <20140811091751.593136@eggemoggin.niobe.net> Message-ID: <20140818120404.807223@eggemoggin.niobe.net> 2014/8/11 9:17 -0700, mark.reinhold at oracle.com: > ... > > Here are the JEPs currently proposed to target JDK 9: > > 102: Process API Updates http://openjdk.java.net/jeps/102 > 143: Improve Contended Locking http://openjdk.java.net/jeps/143 > 197: Segmented Code Cache http://openjdk.java.net/jeps/197 > 198: Light-Weight JSON API http://openjdk.java.net/jeps/198 > 199: Smart Java Compilation, Phase Two http://openjdk.java.net/jeps/199 > 201: Modular Source Code http://openjdk.java.net/jeps/201 > > These JEPs will be targeted to JDK 9 unless reasoned objections are > raised by 19:00 UTC next Monday, 18 August. Hearing no objections, I've targeted all these JEPs to JDK 9. - Mark From mark.reinhold at oracle.com Mon Aug 18 23:05:55 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 18 Aug 2014 16:05:55 -0700 Subject: JDK 9's source code is now modular Message-ID: <20140818160555.956100@eggemoggin.niobe.net> FYI, the changesets for JEP 201: Modular Source Code were merged earlier today, so if you're working on JDK 9 then your forest will have a very different structure after your next pull. See the JEP for details (http://openjdk.java.net/jeps/201); a related subtask has links to the Mercurial changesets (https://bugs.openjdk.java.net/browse/JDK-8054834). My thanks to Alan Bateman and Mandy Chung for their work over the last several years to tease out the modular structure that's been hiding all along inside the massive, monolithic JDK; to Erik Joelsson for rewriting the build system (again!) to accommodate modules; and to Chris Hegarty for wrangling patches and attending to the myriad details of landing this huge change in JDK 9. - Mark From david.holmes at oracle.com Tue Aug 19 02:17:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Aug 2014 12:17:18 +1000 Subject: JDK 9's source code is now modular In-Reply-To: <20140818160555.956100@eggemoggin.niobe.net> References: <20140818160555.956100@eggemoggin.niobe.net> Message-ID: <53F2B3AE.3020301@oracle.com> On 19/08/2014 9:05 AM, mark.reinhold at oracle.com wrote: > FYI, the changesets for JEP 201: Modular Source Code were merged earlier > today, so if you're working on JDK 9 then your forest will have a very > different structure after your next pull. See the JEP for details > (http://openjdk.java.net/jeps/201); a related subtask has links to the > Mercurial changesets (https://bugs.openjdk.java.net/browse/JDK-8054834). I got the following "possible conflict" warnings: pulling from http://hg.openjdk.java.net/jdk9/dev/jdk searching for changes adding changesets adding manifests adding file changes added 6 changesets with 12616 changes to 12554 files note: possible conflict - src/aix/porting/porting_aix.c was renamed multiple times to: src/demo/aix/jvmti/hprof/porting_aix.c src/java.desktop/aix/native/libawt/porting_aix.c note: possible conflict - src/aix/porting/porting_aix.h was renamed multiple times to: src/demo/aix/jvmti/hprof/porting_aix.h src/java.desktop/aix/native/libawt/porting_aix.h note: possible conflict - src/share/classes/java/lang/instrument/package.html was renamed multiple times to: src/java.instrument/share/classes/java/lang/instrument/package.html src/java.management/share/classes/java/lang/management/package.html 12548 files updated, 0 files merged, 12465 files removed, 0 files unresolved Are they harmless and expected? Thanks, David H. > My thanks to Alan Bateman and Mandy Chung for their work over the last > several years to tease out the modular structure that's been hiding all > along inside the massive, monolithic JDK; to Erik Joelsson for rewriting > the build system (again!) to accommodate modules; and to Chris Hegarty > for wrangling patches and attending to the myriad details of landing > this huge change in JDK 9. > > - Mark > From mandy.chung at oracle.com Tue Aug 19 02:38:44 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 18 Aug 2014 19:38:44 -0700 Subject: JDK 9's source code is now modular In-Reply-To: <53F2B3AE.3020301@oracle.com> References: <20140818160555.956100@eggemoggin.niobe.net> <53F2B3AE.3020301@oracle.com> Message-ID: <53F2B8B4.4060203@oracle.com> On 8/18/2014 7:17 PM, David Holmes wrote: > On 19/08/2014 9:05 AM, mark.reinhold at oracle.com wrote: >> FYI, the changesets for JEP 201: Modular Source Code were merged earlier >> today, so if you're working on JDK 9 then your forest will have a very >> different structure after your next pull. See the JEP for details >> (http://openjdk.java.net/jeps/201); a related subtask has links to the >> Mercurial changesets (https://bugs.openjdk.java.net/browse/JDK-8054834). > > I got the following "possible conflict" warnings: > > pulling from http://hg.openjdk.java.net/jdk9/dev/jdk > searching for changes > adding changesets > adding manifests > adding file changes > added 6 changesets with 12616 changes to 12554 files > note: possible conflict - src/aix/porting/porting_aix.c was renamed > multiple times to: > src/demo/aix/jvmti/hprof/porting_aix.c > src/java.desktop/aix/native/libawt/porting_aix.c > note: possible conflict - src/aix/porting/porting_aix.h was renamed > multiple times to: > src/demo/aix/jvmti/hprof/porting_aix.h > src/java.desktop/aix/native/libawt/porting_aix.h I believe src/demo/aix/jvmti/hprof/porting_aix.* should be removed. I'm going to file a bug and fix that. > note: possible conflict - > src/share/classes/java/lang/instrument/package.html was renamed > multiple times to: > src/java.instrument/share/classes/java/lang/instrument/package.html > src/java.management/share/classes/java/lang/management/package.html > 12548 files updated, 0 files merged, 12465 files removed, 0 files > unresolved > These two package.html are the same copy after the source restructuring. > Are they harmless and expected? > AFAIK they are harmless. Mandy > Thanks, > David H. > >> My thanks to Alan Bateman and Mandy Chung for their work over the last >> several years to tease out the modular structure that's been hiding all >> along inside the massive, monolithic JDK; to Erik Joelsson for rewriting >> the build system (again!) to accommodate modules; and to Chris Hegarty >> for wrangling patches and attending to the myriad details of landing >> this huge change in JDK 9. >> >> - Mark >> From david.holmes at oracle.com Tue Aug 19 02:49:19 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Aug 2014 12:49:19 +1000 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE2E20.7040304@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5BA3.2050504@oracle.com> <20140815155508.GF21356@redhat.com> <53EE2E20.7040304@oracle.com> Message-ID: <53F2BB2F.1010808@oracle.com> On 16/08/2014 1:58 AM, Erik Joelsson wrote: > Hello Omair, > > No, as I tried to explain in my initial mail on this thread, since the > modules are all compiled in parallel, and not sequentially like the > current build does with the repositories, it doesn't make much sense > timing each module. The numbers would be meaningless. It would still be nice to see the different times for hotspot, images, any other targets, plus the "everything Java" component. Seeing where our build time gets used up is important to some of us. Thanks, David ----- > /Erik > > On 2014-08-15 17:55, Omair Majid wrote: >> Hi, >> >> * Alan Bateman [2014-08-13 08:36]: >>> Just to add to Chris and Erik's mails, I would encourage everyone that >>> pushes to jdk9/dev or the other jdk9 project integration forests to >>> clone >>> and build jigsaw/stage and get familiar with the proposed layout, new >>> build >>> targets, and the very different output emitted during the build. The >>> changes >>> are arguably as significant as the transition in JDK 8 from the "old >>> build" >>> to the "new build" so the more people taking the forest for a test >>> drive the >>> better. If you maintain your our own own IDE project then you'll >>> likely have >>> to adjust file paths so any issues encountered would be useful to >>> hear about >>> too. >> Just one RFE for now: >> >> The new build would provide a detailed breakdown of the build time of >> each repo. With the 'new new build', all I see is an overall time: >> >>> ----- Build times ------- >>> Start 2014-08-15 10:59:27 >>> End 2014-08-15 11:17:53 >>> >>> 00:18:26 TOTAL >>> ------------------------- >> Will a detailed breakdown of the build times for each module make a >> return? >> >> Thanks, >> Omair >> > From mandy.chung at oracle.com Tue Aug 19 03:00:37 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 18 Aug 2014 20:00:37 -0700 Subject: JDK 9's source code is now modular In-Reply-To: <53F2B8B4.4060203@oracle.com> References: <20140818160555.956100@eggemoggin.niobe.net> <53F2B3AE.3020301@oracle.com> <53F2B8B4.4060203@oracle.com> Message-ID: <53F2BDD5.1020907@oracle.com> On 8/18/2014 7:38 PM, Mandy Chung wrote: > I believe src/demo/aix/jvmti/hprof/porting_aix.* should be removed. > I'm going to file a bug and fix that. Actually AIX hprof used to compile src/aix/porting/porting_aix.c and include its own copy of dladdr in the shared library. So src/aix/porting/porting_aix.* are moved to src/java.desktop/aix/native/libawt/porting_aix.* and also copied to src/demo/aix/jvmti/hprof for libawt and hprof to use. I have yet to find out why it was detected as renamed multiple times. The CompileDemo.gmk needs some adjustment though that I have filed a bug: https://bugs.openjdk.java.net/browse/JDK-8055352 Mandy From chris.hegarty at oracle.com Tue Aug 19 06:29:23 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Aug 2014 07:29:23 +0100 Subject: JDK 9's source code is now modular In-Reply-To: <53F2B8B4.4060203@oracle.com> References: <20140818160555.956100@eggemoggin.niobe.net> <53F2B3AE.3020301@oracle.com> <53F2B8B4.4060203@oracle.com> Message-ID: On 19 Aug 2014, at 03:38, Mandy Chung wrote: >> >> note: possible conflict - src/share/classes/java/lang/instrument/package.html was renamed multiple times to: >> src/java.instrument/share/classes/java/lang/instrument/package.html >> src/java.management/share/classes/java/lang/management/package.html >> 12548 files updated, 0 files merged, 12465 files removed, 0 files unresolved >> > > These two package.html are the same copy after the source restructuring. This is my fault, but is benign. The actual contents of these files is correct, but the history of management/package.html is not. I will file a bug on this, and have it fixed. -Chris. From fweimer at redhat.com Tue Aug 19 12:41:03 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 19 Aug 2014 14:41:03 +0200 Subject: JDK 9's source code is now modular In-Reply-To: <53F2B3AE.3020301@oracle.com> References: <20140818160555.956100@eggemoggin.niobe.net> <53F2B3AE.3020301@oracle.com> Message-ID: <53F345DF.4030708@redhat.com> On 08/19/2014 04:17 AM, David Holmes wrote: > note: possible conflict - src/aix/porting/porting_aix.c was renamed > multiple times to: > src/demo/aix/jvmti/hprof/porting_aix.c > src/java.desktop/aix/native/libawt/porting_aix.c > Are they harmless and expected? Probably, Mercurial is buggy and issues such warnings even if you have never edited anything locally, and there is no way you can avoid the issue being warned about. -- Florian Weimer / Red Hat Product Security From alejandro.murillo at oracle.com Tue Aug 19 20:20:34 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 19 Aug 2014 14:20:34 -0600 Subject: jdk9-dev: HotSpot Message-ID: <53F3B192.30601@oracle.com> jdk9-hs-2014-08-15 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/13255d60e919 http://hg.openjdk.java.net/jdk9/dev/corba/rev/4d704afddadd http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8e575cec7af9 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/3fa16315f4b5 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/9b415daee626 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/57e4d7182890 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75e8065a3e88 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d564abed1e6a Component : VM Status : 0 major failures, 0 minor failures Date : 08/19/2014 at 19:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-08-15-162542.amurillo.jdk9-hs-2014-08-15-jdk9-dev-control Testing: 684 new failures, 3704 known failures, 411695 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6424123: JVM crashes on failed 'strdup' call 8003426: Remove UseFastAccessors and UseFastEmptyMethods except for zero 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot 8034056: assert(_heap_alignment >= _space_alignment) failed: heap_alignment less than space_alignment 8044140: Create NMT (Native Memory Tracking) tests for NMT2 8046598: Scalable Native memory tracking development 8049049: Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp 8050485: super() in a try block in a ctor causes VerifyError 8052170: G1 asserts at collection exit with -XX:-G1DeferredRSUpdate 8054341: Remove some obsolete code in G1CollectedHeap class 8054713: [TESTBUG] runtime/jsig/Test8017498.sh: Execution failed: exit code 1 8054823: Add size_t as a valid VM flag type 8054938: [TESTBUG] Wrong WhiteBox.java was pushed by JDK-8044140 8054952: [TESTBUG] Add missing NMT2 tests -- Alejandro From omajid at redhat.com Tue Aug 19 20:28:21 2014 From: omajid at redhat.com (Omair Majid) Date: Tue, 19 Aug 2014 16:28:21 -0400 Subject: RFR [9] Modular Source Code In-Reply-To: <53F203EF.9070907@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> Message-ID: <20140819202821.GN17998@redhat.com> * Magnus Ihse Bursie [2014-08-18 09:48]: > liblcms: > The include file picking of LCMS.c would not be needed if the upstream > lcms source code were moved into a separate subdirectory of liblcms. > > libjavajpeg: > If the upstream IJG jpeg library were moved into a subdirectory, the > explicit includes of imageIOJPEG.c and jpegdecoder.c would not be needed. Independent of the modular source code changes, I would like to see this change. But there were concerns raised in the past about this: http://mail.openjdk.java.net/pipermail/build-dev/2014-February/012027.html Maybe now is the right time to clean this up, once and for all? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From philip.race at oracle.com Tue Aug 19 23:09:09 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 19 Aug 2014 16:09:09 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53F20A6C.7090805@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> Message-ID: <53F3D915.5030208@oracle.com> On a related note I am scratching my head about why some files destined to be compiled into libawt or libawt_xawt go into a directory called 'common'. Eg OpenGL sources are in common but aren't common to all libs or even to all awt libs, since they would go into libawt on windows and libawt_xawt on unix and not at all into libawt_headless. 'common 'might (guessing here) have started out as place to put interface header files shared between libs but maybe got adopted for other uses ? -phil. On 08/18/2014 07:15 AM, Anthony Petrov wrote: > On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote: >> libawt et al: >> The relation between libawt, libawt_headless, libjawt, libawt_xawt >> and libawt_lwawt are hairy enough to make my brain curl up. I believe >> there are simplifications to be made but I gave up trying to figure them >> out. > > libawt contains code that is shared between all AWT lib > implementations. Depending on what mode/toolkit is requested, it loads > a specific variant of the awt native library, such as: > > - libawt_headless - headless AWT implementation. > - libawt_xawt - XToolkit implementation (uses X11 for GUI) > - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI) > > Historically, we were able to choose between lwawt and xawt on Mac in > the past, but we no longer support or even build xawt on Mac. Also, in > the past there was MToolkit (which used Motif for GUI). Again, we no > longer support this toolkit. So, currently we always use xawt on > Linux/Solaris and lwawt on Mac. But since we still need to choose > between a real toolkit and a headless toolkit, we need the common > libawt library. > > libjawt is a helper library that implements JAWT API and is loaded by > applications that use the JAWT interface which allows them to get > direct access to the native AWT drawing surface and use native APIs > (e.g. OpenGL) to draw on the surface. This library isn't needed for > regular AWT/Swing applications. > > So I'm not sure if the current set of AWT libraries could be > simplified any further. > > Hope this helps. > > -- > best regards, > Anthony From erik.joelsson at oracle.com Wed Aug 20 08:37:09 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Aug 2014 10:37:09 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53F3D915.5030208@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F3D915.5030208@oracle.com> Message-ID: <53F45E35.7030809@oracle.com> Hello, The basic rule for the new source layout is that for each library, there is a directory where all sources for that library go. This was hard to apply to libawt and friends since as you say, some files go in libawt on windows and libawt_xawt on linux and solaris. For now, I put those in common for lack of a better place. /Erik On 2014-08-20 01:09, Phil Race wrote: > On a related note I am scratching my head about why some files > destined to be compiled into libawt or libawt_xawt go into a directory > called 'common'. > Eg OpenGL sources are in common but aren't common to all libs > or even to all awt libs, since they would go into libawt on windows > and libawt_xawt on unix and not at all into libawt_headless. > > 'common 'might (guessing here) have started out as place to put > interface > header files shared between libs but maybe got adopted for other uses ? > > -phil. > > > > On 08/18/2014 07:15 AM, Anthony Petrov wrote: >> On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote: >>> libawt et al: >>> The relation between libawt, libawt_headless, libjawt, libawt_xawt >>> and libawt_lwawt are hairy enough to make my brain curl up. I believe >>> there are simplifications to be made but I gave up trying to figure >>> them >>> out. >> >> libawt contains code that is shared between all AWT lib >> implementations. Depending on what mode/toolkit is requested, it >> loads a specific variant of the awt native library, such as: >> >> - libawt_headless - headless AWT implementation. >> - libawt_xawt - XToolkit implementation (uses X11 for GUI) >> - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI) >> >> Historically, we were able to choose between lwawt and xawt on Mac in >> the past, but we no longer support or even build xawt on Mac. Also, >> in the past there was MToolkit (which used Motif for GUI). Again, we >> no longer support this toolkit. So, currently we always use xawt on >> Linux/Solaris and lwawt on Mac. But since we still need to choose >> between a real toolkit and a headless toolkit, we need the common >> libawt library. >> >> libjawt is a helper library that implements JAWT API and is loaded by >> applications that use the JAWT interface which allows them to get >> direct access to the native AWT drawing surface and use native APIs >> (e.g. OpenGL) to draw on the surface. This library isn't needed for >> regular AWT/Swing applications. >> >> So I'm not sure if the current set of AWT libraries could be >> simplified any further. >> >> Hope this helps. >> >> -- >> best regards, >> Anthony > From magnus.ihse.bursie at oracle.com Wed Aug 20 09:14:10 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 Aug 2014 11:14:10 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53F20A6C.7090805@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> Message-ID: <53F466E2.7070501@oracle.com> On 2014-08-18 16:15, Anthony Petrov wrote: > On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote: >> libawt et al: >> The relation between libawt, libawt_headless, libjawt, libawt_xawt >> and libawt_lwawt are hairy enough to make my brain curl up. I believe >> there are simplifications to be made but I gave up trying to figure them >> out. > > libawt contains code that is shared between all AWT lib > implementations. Depending on what mode/toolkit is requested, it loads > a specific variant of the awt native library, such as: > > - libawt_headless - headless AWT implementation. > - libawt_xawt - XToolkit implementation (uses X11 for GUI) > - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI) > > Historically, we were able to choose between lwawt and xawt on Mac in > the past, but we no longer support or even build xawt on Mac. Also, in > the past there was MToolkit (which used Motif for GUI). Again, we no > longer support this toolkit. So, currently we always use xawt on > Linux/Solaris and lwawt on Mac. But since we still need to choose > between a real toolkit and a headless toolkit, we need the common > libawt library. > > libjawt is a helper library that implements JAWT API and is loaded by > applications that use the JAWT interface which allows them to get > direct access to the native AWT drawing surface and use native APIs > (e.g. OpenGL) to draw on the surface. This library isn't needed for > regular AWT/Swing applications. > > So I'm not sure if the current set of AWT libraries could be > simplified any further. > > Hope this helps. Thank you for the clarification, it was very helpful! While the set of AWT libraries probably cannot be simplified as you say, my gut feeling is still that the current layout of files on disk does not optimally match the actual libraries we build. Armed with the help of your description, I'll look into them once again and see if I can make that statement more concrete. /Magnus From magnus.ihse.bursie at oracle.com Wed Aug 20 10:14:53 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 Aug 2014 12:14:53 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDCA54.2090107@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> Message-ID: <53F4751D.8020006@oracle.com> On 2014-08-15 10:52, Magnus Ihse Bursie wrote: > These are indeed the single most significant changes to the build > system since the "new" build system was introduced. > > Here follows a partial review of the changes in the jdk repo. Even > though it's long, I'm not done. ;-) While this has turned into a post-factum code review, I continue unabashed. :-) In langtooks/make/GensrcLangtools.gmk: The fix from 8026773 was inadvertently reverted in the following line: $(ECHO) Compiling $(words $(PROPSOURCES) v1 v2 v3) properties into resource bundles This might implicate a merge error at some point, so maybe the file should be more thoroughly studied if there are more parts of the fix for 8026773 that has been lost. In make/common/JavaCompilation: The following stanza is incorrectly indented: ifneq (,$$($1_ALL_COPIES)) # Yep, there are files to be copied! $1_ALL_COPY_TARGETS:= $$(foreach i,$$($1_ALL_COPIES),$$(eval $$(call add_file_to_copy,$1,$$i))) # Now we can depend on $$($1_ALL_COPY_TARGETS) to copy all files! endif In make/CompileJavaModules: A typo: ## Service types are required in the classpath when compiing module-info In make/common/support: The ListPathsSafely support files have changed, replacing the first three strings with: s|X01|share/classes|g s|X02|internal|g s|X03|com/sun/org|g While the old replacements did not do anything useful ("shortening" three-letter strings into another three-letter string), this change breaks the old pattern of having the strings sorted in length order. At first, I thought it was just a matter of style (I still think this is a matter of style, and that it should be fixed) but then I realized there also was a reason for this: The strings are matched from longest to shortest (given, of course, that the list is correctly ordered) and thus the string "com/sun" will match and be replaced by X07 before the new string "com/sun/org" will be given the chance. In corba/make and langtools/make: For clarity and consistency, the file corba/make/CompileCorba.gmk should be renamed CompileInterimCorba.gmk and langtools/make/CompileInterim.gmk should be renamed CompileInterimLangtools.gmk. In make/Main.gmk: I'm not entirely happy with the way the following dependencies are encoded: # Declare dependencies from all other -lib to java.base-lib $(foreach t, $(filter-out java.base-libs, $(LIB_TARGETS)), \ $(eval $t: java.base-libs)) # Declare the special case dependency for jdk.deploy.osx where libosx # links against libosxapp. jdk.deploy.osx-libs: java.desktop-libs # This dependency needs to be explicitly declared. jdk.jdi-gensrc generates a # header file used by jdk.jdwp libs. jdk.jdwp-libs: jdk.jdi-gensrc I have discussed this off-line with Erik and concluded that this probably has to do for now, but I believe there should be a better way of describing this kinds of relationships. Alright, now I'm done code reviewing! :-) Lots of kudos to Erik for managing to re-create the build system for the modular source code with such high quality. /Magnus From andrew at andrewash.com Wed Aug 20 22:42:53 2014 From: andrew at andrewash.com (Andrew Ash) Date: Wed, 20 Aug 2014 15:42:53 -0700 Subject: JVM heaps can scale up but not down Message-ID: // please redirect if this is the wrong list Hi JDK devs, I'm occasionally in a situation where I have a JVM running and want to tell it to "scale down" to use less heap than its current active set. This would be in the space between -Xms and -Xmx bounds. Scaling "up" from -Xms towards -Xmx obviously happens automatically, and I've heard conventional wisdom that you can't decrease heap size on a running JVM, but I've never heard of any work being done to make that possible. The use case is when I have a long-running JVM in an Apache Mesos [1] context, and Mesos wants to "take back" some memory resources from a running JVM task. Is there any work being done to make scaling down possible? Cheers, Andrew [1] https://mesos.apache.org/ From jesper.wilhelmsson at oracle.com Thu Aug 21 06:47:13 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Aug 2014 08:47:13 +0200 Subject: JVM heaps can scale up but not down In-Reply-To: References: Message-ID: <53F595F1.1020309@oracle.com> Hi Andrew, The flag -XX:MaxHeapFreeRatio was recently made manageable so that you can change its value during runtime. The motivating use case behind that change was exactly the scenario you describe, that you want to force a running JVM to shrink the heap. Lowering MaxHeapFreeRatio may decrease performance since it will likely increase garbage collection frequency. The way to use it in a production server would probably be to lower the ratio, force a System.gc to shrink the heap and then increase the ratio again. Unfortunately there can never be any guaranties that the heap can shrink unless you force a full GC that compacts the entire heap. The heap has to be allocated as one consecutive memory area and if you're unlucky there can be some long lived object allocated near the top of the heap which makes it impossible to shrink the memory area. Recently there has been plenty of work in the G1 collector to deal with this situation. In 8u20 we started sorting the memory regions to increase the chances of allocating long lived objects at the bottom of the heap. In 8u40 we will introduce the possibility to decommit memory within the heap. This will make it possible to shrink the heap by cutting out a hole somewhere within the heap rather than being forced to only shrink from the top. This change will most likely be pushed to 8u40 within the next few days, it's already present in the JDK 9 repository. These features are all default behavior in G1, so if you haven't already, switch to G1 (-XX:+UseG1GC) and try out the latest bits to see if it solves your problem. Best regards, /Jesper Andrew Ash skrev 21/8/14 00:42: > // please redirect if this is the wrong list > > Hi JDK devs, > > I'm occasionally in a situation where I have a JVM running and want to tell > it to "scale down" to use less heap than its current active set. This > would be in the space between -Xms and -Xmx bounds. Scaling "up" from -Xms > towards -Xmx obviously happens automatically, and I've heard conventional > wisdom that you can't decrease heap size on a running JVM, but I've never > heard of any work being done to make that possible. > > The use case is when I have a long-running JVM in an Apache Mesos [1] > context, and Mesos wants to "take back" some memory resources from a > running JVM task. > > Is there any work being done to make scaling down possible? > > Cheers, > Andrew > > > [1] https://mesos.apache.org/ > From yuri.nesterenko at oracle.com Thu Aug 21 07:16:08 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 21 Aug 2014 11:16:08 +0400 Subject: Result: New jdk9 Committer: Andrei Eremeev Message-ID: <53F59CB8.10209@oracle.com> Voting for Andrei Eremeev (aeremeev) is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thank you, -yan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-August/001158.html From jesper.wilhelmsson at oracle.com Thu Aug 21 11:43:41 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Aug 2014 13:43:41 +0200 Subject: JVM heaps can scale up but not down In-Reply-To: References: <53F595F1.1020309@oracle.com> Message-ID: <53F5DB6D.5090501@oracle.com> Andrew Ash skrev 21/8/14 12:40: > Hi Jesper, > > Many thanks for the extensive answer! > > It sounds like with the newer features the scale-down scenario will be possible. > Here's how I think it could work from the new features: > > 1. Mesos starts a task with X memory of Y memory on a machine > 2. JVM starts with -Xmx=Y and a MinHeapFree ratio of (X-Y)/Y to keep the max > actual utilization at X > 3. Application running in the JVM does work > 4. Mesos decides to take back memory and sends a message to the app that it > should shrink to Z memory (Z < X) > 5. App reduces its memory usage by the appropriate amount > 6. App signals to the JVM to use a lower MaxHeapFreeRatio and triggers Full GC > 7. JVM performs Full GC and shrinks heap > 8. App checks if memory usage is below Z; goto step 5 if not > 9. App tells Mesos it has shrunk its usage > 10. Mesos gives the memory to some other task Seems reasonable. > > The Xmx/MinHeapFree calculation in step 2 is to support increasing the memory > usage up to the maximum of the machine (is Xmx manageable now?). No, Xmx is not manageable. If the JVM decides that the application needs a bigger heap to run with proper performance the heap will grow again. If you want to force the heap to stay small you'd probably have to keep a lower MaxHeapFreeRatio and be willing to pay with lower performance. > > There are some difficulties in step 5 of how the app knows how much memory to > remove. In my motivating case (Apache Spark) the app keeps a pool of cached > data with size estimates, and could potentially drop the appropriate amount of > data from its cache. It would require recalculation but that can be streamed > and never held in a JVM's heap at once. Well I guess only the app developer knows how much memory the app can release and still function properly. If it's a cache then you'd again have to consider performance vs memory usage. > > The combination of step 6 and step 7 are what the recent JDK feature work will > make possible. > > > Is this how you envision the scale-down scenario working in practice? Yes, this is exactly how I envisioned it :) Let me know if it works out IRL. /Jesper > > > Many thanks, > Andrew > > > On Wed, Aug 20, 2014 at 11:47 PM, Jesper Wilhelmsson > > wrote: > > Hi Andrew, > > The flag -XX:MaxHeapFreeRatio was recently made manageable so that you can > change its value during runtime. The motivating use case behind that change > was exactly the scenario you describe, that you want to force a running JVM > to shrink the heap. > > Lowering MaxHeapFreeRatio may decrease performance since it will likely > increase garbage collection frequency. The way to use it in a production > server would probably be to lower the ratio, force a System.gc to shrink the > heap and then increase the ratio again. > > Unfortunately there can never be any guaranties that the heap can shrink > unless you force a full GC that compacts the entire heap. The heap has to be > allocated as one consecutive memory area and if you're unlucky there can be > some long lived object allocated near the top of the heap which makes it > impossible to shrink the memory area. > > Recently there has been plenty of work in the G1 collector to deal with this > situation. In 8u20 we started sorting the memory regions to increase the > chances of allocating long lived objects at the bottom of the heap. In 8u40 > we will introduce the possibility to decommit memory within the heap. This > will make it possible to shrink the heap by cutting out a hole somewhere > within the heap rather than being forced to only shrink from the top. This > change will most likely be pushed to 8u40 within the next few days, it's > already present in the JDK 9 repository. > > These features are all default behavior in G1, so if you haven't already, > switch to G1 (-XX:+UseG1GC) and try out the latest bits to see if it solves > your problem. > > Best regards, > /Jesper > > > Andrew Ash skrev 21/8/14 00:42: > > // please redirect if this is the wrong list > > Hi JDK devs, > > I'm occasionally in a situation where I have a JVM running and want to tell > it to "scale down" to use less heap than its current active set. This > would be in the space between -Xms and -Xmx bounds. Scaling "up" from -Xms > towards -Xmx obviously happens automatically, and I've heard conventional > wisdom that you can't decrease heap size on a running JVM, but I've never > heard of any work being done to make that possible. > > The use case is when I have a long-running JVM in an Apache Mesos [1] > context, and Mesos wants to "take back" some memory resources from a > running JVM task. > > Is there any work being done to make scaling down possible? > > Cheers, > Andrew > > > [1] https://mesos.apache.org/ > > From andrew at andrewash.com Thu Aug 21 10:40:36 2014 From: andrew at andrewash.com (Andrew Ash) Date: Thu, 21 Aug 2014 03:40:36 -0700 Subject: JVM heaps can scale up but not down In-Reply-To: <53F595F1.1020309@oracle.com> References: <53F595F1.1020309@oracle.com> Message-ID: Hi Jesper, Many thanks for the extensive answer! It sounds like with the newer features the scale-down scenario will be possible. Here's how I think it could work from the new features: 1. Mesos starts a task with X memory of Y memory on a machine 2. JVM starts with -Xmx=Y and a MinHeapFree ratio of (X-Y)/Y to keep the max actual utilization at X 3. Application running in the JVM does work 4. Mesos decides to take back memory and sends a message to the app that it should shrink to Z memory (Z < X) 5. App reduces its memory usage by the appropriate amount 6. App signals to the JVM to use a lower MaxHeapFreeRatio and triggers Full GC 7. JVM performs Full GC and shrinks heap 8. App checks if memory usage is below Z; goto step 5 if not 9. App tells Mesos it has shrunk its usage 10. Mesos gives the memory to some other task The Xmx/MinHeapFree calculation in step 2 is to support increasing the memory usage up to the maximum of the machine (is Xmx manageable now?). There are some difficulties in step 5 of how the app knows how much memory to remove. In my motivating case (Apache Spark) the app keeps a pool of cached data with size estimates, and could potentially drop the appropriate amount of data from its cache. It would require recalculation but that can be streamed and never held in a JVM's heap at once. The combination of step 6 and step 7 are what the recent JDK feature work will make possible. Is this how you envision the scale-down scenario working in practice? Many thanks, Andrew On Wed, Aug 20, 2014 at 11:47 PM, Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Hi Andrew, > > The flag -XX:MaxHeapFreeRatio was recently made manageable so that you can > change its value during runtime. The motivating use case behind that change > was exactly the scenario you describe, that you want to force a running JVM > to shrink the heap. > > Lowering MaxHeapFreeRatio may decrease performance since it will likely > increase garbage collection frequency. The way to use it in a production > server would probably be to lower the ratio, force a System.gc to shrink > the heap and then increase the ratio again. > > Unfortunately there can never be any guaranties that the heap can shrink > unless you force a full GC that compacts the entire heap. The heap has to > be allocated as one consecutive memory area and if you're unlucky there can > be some long lived object allocated near the top of the heap which makes it > impossible to shrink the memory area. > > Recently there has been plenty of work in the G1 collector to deal with > this situation. In 8u20 we started sorting the memory regions to increase > the chances of allocating long lived objects at the bottom of the heap. In > 8u40 we will introduce the possibility to decommit memory within the heap. > This will make it possible to shrink the heap by cutting out a hole > somewhere within the heap rather than being forced to only shrink from the > top. This change will most likely be pushed to 8u40 within the next few > days, it's already present in the JDK 9 repository. > > These features are all default behavior in G1, so if you haven't already, > switch to G1 (-XX:+UseG1GC) and try out the latest bits to see if it solves > your problem. > > Best regards, > /Jesper > > > Andrew Ash skrev 21/8/14 00:42: > > // please redirect if this is the wrong list >> >> Hi JDK devs, >> >> I'm occasionally in a situation where I have a JVM running and want to >> tell >> it to "scale down" to use less heap than its current active set. This >> would be in the space between -Xms and -Xmx bounds. Scaling "up" from >> -Xms >> towards -Xmx obviously happens automatically, and I've heard conventional >> wisdom that you can't decrease heap size on a running JVM, but I've never >> heard of any work being done to make that possible. >> >> The use case is when I have a long-running JVM in an Apache Mesos [1] >> context, and Mesos wants to "take back" some memory resources from a >> running JVM task. >> >> Is there any work being done to make scaling down possible? >> >> Cheers, >> Andrew >> >> >> [1] https://mesos.apache.org/ >> >> From alexander.potochkin at oracle.com Fri Aug 22 10:26:41 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Fri, 22 Aug 2014 14:26:41 +0400 Subject: Result: New jdk9 Committer: Dmitry Markov Message-ID: <53F71AE1.6040905@oracle.com> Voting for Dmitry Markov [1] is now closed. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks alexp [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-August/001128.html From alexander.potochkin at oracle.com Fri Aug 22 10:29:04 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Fri, 22 Aug 2014 14:29:04 +0400 Subject: Result: New jdk9 Committer: Anton Nashatyrev Message-ID: <53F71B70.80308@oracle.com> Voting for Anton Nashatyrev [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks alexp [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-August/001136.html From yuri.nesterenko at oracle.com Fri Aug 22 12:07:01 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 22 Aug 2014 16:07:01 +0400 Subject: CFV: New JDK9 Committer: Alexander Stepanov Message-ID: <53F73265.6090903@oracle.com> I hereby nominate Alexander Stepanov (avstepan) to JDK9 Committer. Alexander is a member of Java SQE team. So far, he contributed to jdk some 26 changes[3]. We have now a small team of SQE engineers working on (essentially) open-sourcing of the internal functional suites. The task does involve massive refactoring, proof of multiplatform stability, and careful re-testing of the relevant functionality. Alexander deserves, is totally able and should handle JDK changes himself. Votes are due by September 05, 2014 Only current JDK9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thank you, -yan [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote [3] Some 150 tests refactored from internal suites: http://hg.openjdk.java.net/jdk9/client/jdk/rev/969c9dce2887 http://hg.openjdk.java.net/jdk9/client/jdk/rev/eb8dc6f39e88 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0e36fa13a95a http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/051285a4490c http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/928621062f51 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d4aaf432298a http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/76171168e894 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2e59014ef38f http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca45169cb4eb 4 doclint cleanup changes; http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0b9b525d97bf http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/bf9518ed804f http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/038f4771af6e http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/681ac9f9c452 13 javadoc HTML cleanup changes. http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d75c27eecdfe http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/adaf3b7e6150 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fa4fc23cba16 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/35bbba418241 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ee5dc744fd7a http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/045ed4e4d8bc http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9ebe5a93a91 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ed0f02131ad http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f59b19679950 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7558e4ae79bd http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/183cb0db0389 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0817c69edbd8 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e3044a2279cf From coleen.phillimore at oracle.com Fri Aug 22 13:27:53 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Aug 2014 09:27:53 -0400 Subject: CFV: New JDK9 Committer: Alexander Stepanov In-Reply-To: <53F73265.6090903@oracle.com> References: <53F73265.6090903@oracle.com> Message-ID: <53F74559.5010300@oracle.com> Vote: yes On 8/22/14, 8:07 AM, Yuri Nesterenko wrote: > I hereby nominate Alexander Stepanov (avstepan) to JDK9 Committer. > > Alexander is a member of Java SQE team. > So far, he contributed to jdk some 26 changes[3]. > > We have now a small team of SQE engineers working on > (essentially) open-sourcing of the internal functional suites. > The task does involve massive refactoring, proof of > multiplatform stability, and careful re-testing of the relevant > functionality. Alexander deserves, is totally able and should handle > JDK changes himself. > > Votes are due by September 05, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > -yan > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > Some 150 tests refactored from internal suites: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/969c9dce2887 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/eb8dc6f39e88 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0e36fa13a95a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/051285a4490c > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/928621062f51 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d4aaf432298a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/76171168e894 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2e59014ef38f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca45169cb4eb > > 4 doclint cleanup changes; > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0b9b525d97bf > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/bf9518ed804f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/038f4771af6e > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/681ac9f9c452 > > 13 javadoc HTML cleanup changes. > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d75c27eecdfe > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/adaf3b7e6150 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fa4fc23cba16 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/35bbba418241 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ee5dc744fd7a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/045ed4e4d8bc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9ebe5a93a91 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ed0f02131ad > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f59b19679950 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7558e4ae79bd > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/183cb0db0389 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0817c69edbd8 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e3044a2279cf From vladimir.kozlov at oracle.com Fri Aug 22 15:54:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Aug 2014 08:54:30 -0700 Subject: CFV: New JDK9 Committer: Alexander Stepanov In-Reply-To: <53F73265.6090903@oracle.com> References: <53F73265.6090903@oracle.com> Message-ID: <53F767B6.1030909@oracle.com> Vote: yes On 8/22/14 5:07 AM, Yuri Nesterenko wrote: > I hereby nominate Alexander Stepanov (avstepan) to JDK9 Committer. > > Alexander is a member of Java SQE team. > So far, he contributed to jdk some 26 changes[3]. > > We have now a small team of SQE engineers working on > (essentially) open-sourcing of the internal functional suites. > The task does involve massive refactoring, proof of > multiplatform stability, and careful re-testing of the relevant > functionality. Alexander deserves, is totally able and should handle > JDK changes himself. > > Votes are due by September 05, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > -yan > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > Some 150 tests refactored from internal suites: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/969c9dce2887 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/eb8dc6f39e88 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0e36fa13a95a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/051285a4490c > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/928621062f51 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d4aaf432298a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/76171168e894 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2e59014ef38f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca45169cb4eb > > 4 doclint cleanup changes; > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0b9b525d97bf > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/bf9518ed804f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/038f4771af6e > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/681ac9f9c452 > > 13 javadoc HTML cleanup changes. > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d75c27eecdfe > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/adaf3b7e6150 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fa4fc23cba16 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/35bbba418241 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ee5dc744fd7a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/045ed4e4d8bc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9ebe5a93a91 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ed0f02131ad > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f59b19679950 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7558e4ae79bd > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/183cb0db0389 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0817c69edbd8 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e3044a2279cf From harold.seigel at oracle.com Fri Aug 22 18:08:36 2014 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 22 Aug 2014 14:08:36 -0400 Subject: CFV: New JDK9 Committer: Alexander Stepanov In-Reply-To: <53F73265.6090903@oracle.com> References: <53F73265.6090903@oracle.com> Message-ID: <53F78724.6000105@oracle.com> Vote: yes On 8/22/2014 8:07 AM, Yuri Nesterenko wrote: > I hereby nominate Alexander Stepanov (avstepan) to JDK9 Committer. > > Alexander is a member of Java SQE team. > So far, he contributed to jdk some 26 changes[3]. > > We have now a small team of SQE engineers working on > (essentially) open-sourcing of the internal functional suites. > The task does involve massive refactoring, proof of > multiplatform stability, and careful re-testing of the relevant > functionality. Alexander deserves, is totally able and should handle > JDK changes himself. > > Votes are due by September 05, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > -yan > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > Some 150 tests refactored from internal suites: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/969c9dce2887 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/eb8dc6f39e88 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0e36fa13a95a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/051285a4490c > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/928621062f51 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d4aaf432298a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/76171168e894 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2e59014ef38f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ca45169cb4eb > > 4 doclint cleanup changes; > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0b9b525d97bf > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/bf9518ed804f > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/038f4771af6e > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/681ac9f9c452 > > 13 javadoc HTML cleanup changes. > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d75c27eecdfe > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/adaf3b7e6150 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fa4fc23cba16 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/35bbba418241 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ee5dc744fd7a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/045ed4e4d8bc > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9ebe5a93a91 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ed0f02131ad > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f59b19679950 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7558e4ae79bd > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/183cb0db0389 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0817c69edbd8 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e3044a2279cf From Alan.Bateman at oracle.com Sat Aug 23 18:35:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Aug 2014 19:35:54 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53F2061D.4000104@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F2061D.4000104@oracle.com> Message-ID: <53F8DF0A.3070807@oracle.com> On 18/08/2014 14:56, Magnus Ihse Bursie wrote: > : > > * In CompileDemos, we create demo/jpda/src.zip. This includes source > code from src/demo/share (expected), but also from > jdk/src/jdk.jdi/share/classes/com/sun/tools/example/... (unexpected!). > Should example code really live in the jdk.jdi package, and not in > src/demo? The issue is that the sources to jdb are used for two purposes. This should resolve itself once the JPDA demo is dropped, see JDK-8043981. -Alan. From alexhenrie24 at gmail.com Mon Aug 25 05:59:17 2014 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Sun, 24 Aug 2014 23:59:17 -0600 Subject: [PATCH] Fix right-click detection in Linux and Solaris Message-ID: <20140824235917.938f9f8499555e0c12aef1c3@gmail.com> With this patch applied, only clicks on the mouse's right button and not clicks to the mouse's forward or back buttons trigger a context menu (MouseEvent.isPopupTrigger() == true). Class XWindow tried to map physical mouse buttons to logical mouse buttons, but this unnecessary because that mapping is already handled automatically in Xlib: http://www.x.org/archive/X11R7.5/doc/man/man3/XKeyEvent.3.html Also, XGetPointerMapping returns the total number of physical mouse buttons (16 on my computer), not the value of a map entry: http://www.x.org/archive/X11R7.5/doc/man/man3/XGetPointerMapping.3.html This JDK bug has to be fixed before https://netbeans.org/bugzilla/show_bug.cgi?id=198885 can be fixed. This patch will probably also fix https://bugs.openjdk.java.net/browse/JDK-6624085 A test program is attached. This is my first time contributing code to OpenJDK, so if I've done something wrong, please be nice ;-) -Alex diff --git a/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java b/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java --- a/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java +++ b/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java @@ -50,17 +50,16 @@ class XWindow extends XBaseWindow implem private static final PlatformLogger focusLog = PlatformLogger.getLogger("sun.awt.X11.focus.XWindow"); private static PlatformLogger keyEventLog = PlatformLogger.getLogger("sun.awt.X11.kye.XWindow"); /* If a motion comes in while a multi-click is pending, * allow a smudge factor so that moving the mouse by a small * amount does not wipe out the multi-click state variables. */ private final static int AWT_MULTICLICK_SMUDGE = 4; // ButtonXXX events stuff - static int rbutton = 0; static int lastX = 0, lastY = 0; static long lastTime = 0; static long lastButton = 0; static WeakReference lastWindowRef = null; static int clickCount = 0; // used to check if we need to re-create surfaceData. int oldWidth = -1; @@ -627,33 +626,16 @@ class XWindow extends XBaseWindow implem res |= XToolkit.metaMask; } if ((mods & (InputEvent.ALT_GRAPH_DOWN_MASK | InputEvent.ALT_GRAPH_MASK)) != 0) { res |= XToolkit.modeSwitchMask; } return res; } - /** - * Returns true if this event is disabled and shouldn't be passed to Java. - * Default implementation returns false for all events. - */ - static int getRightButtonNumber() { - if (rbutton == 0) { // not initialized yet - XToolkit.awtLock(); - try { - rbutton = XlibWrapper.XGetPointerMapping(XToolkit.getDisplay(), XlibWrapper.ibuffer, 3); - } - finally { - XToolkit.awtUnlock(); - } - } - return rbutton; - } - static int getMouseMovementSmudge() { //TODO: It's possible to read corresponding settings return AWT_MULTICLICK_SMUDGE; } public void handleButtonPressRelease(XEvent xev) { super.handleButtonPressRelease(xev); XButtonEvent xbe = xev.get_xbutton(); @@ -711,21 +693,17 @@ class XWindow extends XBaseWindow implem lastY = y; } lastTime = when; /* Check for popup trigger !! */ - if (lbutton == getRightButtonNumber() || lbutton > 2) { - popupTrigger = true; - } else { - popupTrigger = false; - } + popupTrigger = (lbutton == 3); } button = XConstants.buttons[lbutton - 1]; // 4 and 5 buttons are usually considered assigned to a first wheel if (lbutton == XConstants.buttons[3] || lbutton == XConstants.buttons[4]) { wheel_mouse = true; } From Alan.Bateman at oracle.com Mon Aug 25 06:49:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Aug 2014 07:49:15 +0100 Subject: [PATCH] Fix right-click detection in Linux and Solaris In-Reply-To: <20140824235917.938f9f8499555e0c12aef1c3@gmail.com> References: <20140824235917.938f9f8499555e0c12aef1c3@gmail.com> Message-ID: <53FADC6B.804@oracle.com> On 25/08/2014 06:59, Alex Henrie wrote: > : > > This is my first time contributing code to OpenJDK, so if I've done > something wrong, please be nice ;-) > The "How to contribute" page [1] is the best place to start, in particular step 0 on becoming a contributor. For this specific issue then the awt-dev mailing list should be the place to discuss it. -Alan. [1] http://openjdk.java.net/contribute/ From alexhenrie24 at gmail.com Mon Aug 25 19:09:09 2014 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Mon, 25 Aug 2014 13:09:09 -0600 Subject: [PATCH] Fix right-click detection in Linux and Solaris In-Reply-To: <53FADC6B.804@oracle.com> References: <20140824235917.938f9f8499555e0c12aef1c3@gmail.com> <53FADC6B.804@oracle.com> Message-ID: 2014-08-25 0:49 GMT-06:00 Alan Bateman : > The "How to contribute" page [1] is the best place to start, in particular > step 0 on becoming a contributor. > > For this specific issue then the awt-dev mailing list should be the place to > discuss it. I already signed the Contributor Agreement and sent it in, but thanks for pointing me to the right mailing list for this bug. -Alex From philip.race at oracle.com Mon Aug 25 21:59:33 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Aug 2014 14:59:33 -0700 Subject: hg diff of changes from before a file move Message-ID: <53FBB1C5.4040002@oracle.com> Since the mega-move I am running into the annoyance that hg diff won't show changes made before the move unless you first work out the full path of the file from before it was moved - eg by finding the changeset that caused the move - and hoping the file only moved once. See full example of this below. Is there a magic hg flag I am missing (I hoped --follow would work for hg diff but it does not) ? Or does anyone have a script that will automate this for you ? Perhaps by running hg log to find the (right) move changeset and parsing the output to get the location prior to the move. -phil. ==================== $ hg diff -r 673c8a68d52d -r f08705540498 src/java.desktop/share/native/liblcms/cmscam02.c diff --git a/src/share/native/sun/java2d/cmm/lcms/cmscam02.c b/src/java.desktop/share/native/liblcms/cmscam02.c copy from src/share/native/sun/java2d/cmm/lcms/cmscam02.c copy to src/java.desktop/share/native/liblcms/cmscam02.c ================= $ hg log --follow src/java.desktop/share/native/liblcms/cmscam02.c changeset: 10520:f08705540498 parent: 10505:88856f58680f user: chegar date: Sun Aug 17 15:54:13 2014 +0100 summary: 8054834: Modular Source Code changeset: 9790:673c8a68d52d user: prr date: Wed Jan 22 09:39:16 2014 -0800 summary: 8029750: Enhance LCMS color processing changeset: 6031:cc998992dc32 parent: 5948:117eed515e42 user: bae date: Wed Oct 24 05:30:34 2012 +0400 summary: 7053526: Upgrade JDK 8 to use Little CMS 2.4 ..... ..... =================== $ hg diff -r cc998992dc32 -r 673c8a68d52d src/java.desktop/share/native/liblcms/cmscam02.c =================== $ hg diff -r cc998992dc32 -r 673c8a68d52d src/share/native/sun/java2d/cmm/lcms/cmscam02.c diff --git a/src/share/native/sun/java2d/cmm/lcms/cmscam02.c b/src/share/native/sun/java2d/cmm/lcms/cmscam02.c --- a/src/share/native/sun/java2d/cmm/lcms/cmscam02.c +++ b/src/share/native/sun/java2d/cmm/lcms/cmscam02.c @@ -467,6 +467,7 @@ CAM02COLOR clr; cmsCIECAM02* lpMod = (cmsCIECAM02*) hModel; + memset(&clr, 0, sizeof(clr)); _cmsAssert(lpMod != NULL); _cmsAssert(pIn != NULL); _cmsAssert(pOut != NULL); @@ -491,6 +492,7 @@ CAM02COLOR clr; cmsCIECAM02* lpMod = (cmsCIECAM02*) hModel; + memset(&clr, 0, sizeof(clr)); _cmsAssert(lpMod != NULL); _cmsAssert(pIn != NULL); _cmsAssert(pOut != NULL); ================== From chris.hegarty at oracle.com Tue Aug 26 08:36:06 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Aug 2014 09:36:06 +0100 Subject: hg diff of changes from before a file move In-Reply-To: <53FBB1C5.4040002@oracle.com> References: <53FBB1C5.4040002@oracle.com> Message-ID: Phil, Yes, it has always been a little annoying to follow renamed files, and now we have a few more of them ;-) $ hg log --follow --patch -r 673c8a68d52d src/java.desktop/share/native/liblcms/cmscam02.c changeset: 9737:673c8a68d52d user: prr date: Wed Jan 22 09:39:16 2014 -0800 summary: 8029750: Enhance LCMS color processing diff --git a/src/share/native/sun/java2d/cmm/lcms/cmscam02.c b/src/share/native/sun/java2d/cmm/lcms/cmscam02.c --- a/src/share/native/sun/java2d/cmm/lcms/cmscam02.c +++ b/src/share/native/sun/java2d/cmm/lcms/cmscam02.c @@ -81,7 +81,7 @@ cmsUInt32Number surround; cmsFloat64Number n, Nbb, Ncb, z, FL, D; - cmsContext ContextID; + cmsContext ContextID; } cmsCIECAM02; @@ -467,6 +467,7 @@ CAM02COLOR clr; cmsCIECAM02* lpMod = (cmsCIECAM02*) hModel; + memset(&clr, 0, sizeof(clr)); _cmsAssert(lpMod != NULL); _cmsAssert(pIn != NULL); _cmsAssert(pOut != NULL); @@ -491,6 +492,7 @@ CAM02COLOR clr; cmsCIECAM02* lpMod = (cmsCIECAM02*) hModel; + memset(&clr, 0, sizeof(clr)); _cmsAssert(lpMod != NULL); _cmsAssert(pIn != NULL); _cmsAssert(pOut != NULL); -Chris. On 25 Aug 2014, at 22:59, Phil Race wrote: > Since the mega-move I am running into the annoyance that hg diff > won't show changes made before the move unless you first work out > the full path of the file from before it was moved - eg by finding the > changeset that caused the move - and hoping the file only moved once. > See full example of this below. > > Is there a magic hg flag I am missing (I hoped --follow would work for hg diff but > it does not) ? > Or does anyone have a script that will automate this for you ? > Perhaps by running hg log to find the (right) move changeset and parsing the output > to get the location prior to the move. > > -phil. > > ==================== > > $ hg diff -r 673c8a68d52d -r f08705540498 src/java.desktop/share/native/liblcms/cmscam02.c > diff --git a/src/share/native/sun/java2d/cmm/lcms/cmscam02.c b/src/java.desktop/share/native/liblcms/cmscam02.c > copy from src/share/native/sun/java2d/cmm/lcms/cmscam02.c > copy to src/java.desktop/share/native/liblcms/cmscam02.c > > ================= > $ hg log --follow src/java.desktop/share/native/liblcms/cmscam02.c > changeset: 10520:f08705540498 > parent: 10505:88856f58680f > user: chegar > date: Sun Aug 17 15:54:13 2014 +0100 > summary: 8054834: Modular Source Code > > changeset: 9790:673c8a68d52d > user: prr > date: Wed Jan 22 09:39:16 2014 -0800 > summary: 8029750: Enhance LCMS color processing > > changeset: 6031:cc998992dc32 > parent: 5948:117eed515e42 > user: bae > date: Wed Oct 24 05:30:34 2012 +0400 > summary: 7053526: Upgrade JDK 8 to use Little CMS 2.4 > > ..... > ..... > =================== > > $ hg diff -r cc998992dc32 -r 673c8a68d52d src/java.desktop/share/native/liblcms/cmscam02.c > > =================== > $ hg diff -r cc998992dc32 -r 673c8a68d52d src/share/native/sun/java2d/cmm/lcms/cmscam02.c > diff --git a/src/share/native/sun/java2d/cmm/lcms/cmscam02.c b/src/share/native/sun/java2d/cmm/lcms/cmscam02.c > --- a/src/share/native/sun/java2d/cmm/lcms/cmscam02.c > +++ b/src/share/native/sun/java2d/cmm/lcms/cmscam02.c > @@ -467,6 +467,7 @@ > CAM02COLOR clr; > cmsCIECAM02* lpMod = (cmsCIECAM02*) hModel; > > + memset(&clr, 0, sizeof(clr)); > _cmsAssert(lpMod != NULL); > _cmsAssert(pIn != NULL); > _cmsAssert(pOut != NULL); > @@ -491,6 +492,7 @@ > CAM02COLOR clr; > cmsCIECAM02* lpMod = (cmsCIECAM02*) hModel; > > + memset(&clr, 0, sizeof(clr)); > _cmsAssert(lpMod != NULL); > _cmsAssert(pIn != NULL); > _cmsAssert(pOut != NULL); > > ================== From alejandro.murillo at oracle.com Tue Aug 26 18:54:43 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 26 Aug 2014 12:54:43 -0600 Subject: jdk9-dev: HotSpot Message-ID: <53FCD7F3.7060809@oracle.com> jdk9-hs-2014-08-22 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/b953531f403d http://hg.openjdk.java.net/jdk9/dev/corba/rev/4d704afddadd http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/41fa2928807a http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/3fa16315f4b5 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/9b415daee626 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ebeeb57242f5 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f2518ce1dabc http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/dbb723e6c54c Component : VM Status : 0 major failures, 0 minor failures Date : 08/19/2014 at 17:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-08-22-170355.amurillo.jdk9-hs-2014-08-22-jdk9-dev-control Testing: 758 new failures, 3253 known failures, 420378 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 7173584: Implement arraycopy as a macro node 8026303: CMS: JVM intermittently crashes with "FreeList of size 258 violates Conservation Principle" assert 8032999: [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job 8038423: G1: Decommit memory within heap 8043284: Optimize signed integer comparison 8043913: remove legacy code in SPARC's VM_Version::platform_features 8044406: JVM crash with JDK8 (build 1.8.0-b132) with G1 GC 8046070: Class Data Sharing clean up and refactoring 8047952: Remove _FORTIFY_SOURCE from fastdebug and slowdebug builds 8048879: "unexpected yanked node" opto/postaloc.cpp:139 8054013: run hotspot JTREG compiler tests only on fastdebug platforms and also on macosx 8054164: solaris makefile 8054224: Recursive method that was compiled by C1 is unable to catch StackOverflowError 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java timeout 8054368: nsk/jdi/VirtualMachine/exit/exit002 crash with detail tracking on (NMT2) 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes 8054547: Re-enable warning for incompatible java launcher 8054711: [TESTBUG] Enable NMT2 tests after NMT2 is integrated 8054818: Refactor HeapRegionSeq to manage heap region and auxiliary data 8054883: Segmentation error while running program 8054927: Missing MemNode::acquire ordering in some volatile Load nodes 8055007: NMT2: emptyStack missing in minimal build 8055051: runtime/NMT/CommandLineEmptyArgument.java fails 8055061: assert at share/vm/services/virtualMemoryTracker.cpp:332 Error: ShouldNotReachHere() when running NMT tests 8055098: WB API should be extended to provide information about size and age of object. 8055153: nsk/stress/jck60/jck60014 crashes on sparc 8055231: ZERO variant build is broken 8055275: Several gc/class_unloading/ tests fail due to missed +UnlockDiagnosticVMOptions flag 8055284: sanity/WhiteBox.java fails with NPE 8055503: Rollback 8054164 changeset 8055525: Bigapp weblogic+medrec fails to startup after JDK-8038423 8055635: Missing include in g1RegionToSpaceMapper.hpp results in unresolved symbol of fastdebug build without precompiled headers -- Alejandro From yuri.nesterenko at oracle.com Thu Aug 28 07:17:13 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 28 Aug 2014 11:17:13 +0400 Subject: Result: New jdk9 Committer: Dmitriy Ermashov Message-ID: <53FED779.8040708@oracle.com> Voting for Dmitriy Ermashov [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thank you! -yan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-August/001182.html From volker.simonis at gmail.com Thu Aug 28 15:22:22 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Aug 2014 17:22:22 +0200 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 Message-ID: Hi, could somebody please review the following small changes to fix the AIX build after the Modular Source Code change 8054834. I've also done a little cleanup which is detailed below: http://cr.openjdk.java.net/~simonis/webrevs/8056246/ https://bugs.openjdk.java.net/browse/JDK-8056246 make/lib/Awt2dLibraries.gmk LIBAWT_CFLAGS contains quite some duplicate include parameters which can be removed. -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt isn't required because the path $(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt is already part of LIBAWT_DIRS and the corresponding include parameter is already generated by $(addprefix -I, $(shell find $(LIBAWT_DIRS) -type d)) $(foreach dir, $(LIBAWT_DIRS), -I$(dir)) isn't required either, because $(addprefix -I, $(shell find $(LIBAWT_DIRS) -type d)) not only creates include parameters for every sub-directory contained in LIBAWT_DIRS, but also for the directories themselves. make/rmic/Rmic-java.management.gmk This change is a little bit hacky, but it's the best I could find for the moment. The problem is that find on AIX (but also GNU find before version 4.2) are buggy in the sense that they will report an error if "-exec \+" is used in cases where the find command won't find any files. Therefore, the following make rule will fail for incremental builds if the $(RMIC_GENSRC_DIR) directory won't contain any *.class files any more. These class files are deleted during the first invocation of the rule. However, the rule will be re-executed for every new build because its target depends on the deleted files. $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC) $(FIND) $(RMIC_GENSRC_DIR) -name "*.class" $(FIND_DELETE) $(TOUCH) $@ I've therefore added the file _the.classes.removed to the find pattern. That way, the find command will always match at least one file and the buggy "-exec \+" won't complain. $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC) $(FIND) $(RMIC_GENSRC_DIR) \( -name "*.class" -o -name $(@F) \) $(FIND_DELETE) $(TOUCH) $@ Notice, that deleting _the.classes.removed is no problem here, because the the file will be recreated by the following touch command. I've build and smoke tested these changes on Linux/x86_64, Linux/ppc64, MacOS X, Solaris10/SPARC and AIX. Thank you and best regards, Volker PS: I would also like to do some further cleanup in NetworkingLibraries.gmk in a follow-up change. I think now that we have all the corresponding directories in place we could rename {solaris,linux,bsd}_close.c to just close.c and move them to $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/native/libnet. We could than get rid of the platform dependent LIBNET_EXCLUDE_FILES in NetworkingLibraries.gmk. What's your opinion? From Alan.Bateman at oracle.com Thu Aug 28 15:45:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Aug 2014 16:45:16 +0100 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: References: Message-ID: <53FF4E8C.6080308@oracle.com> On 28/08/2014 16:22, Volker Simonis wrote: > : > > PS: I would also like to do some further cleanup in > NetworkingLibraries.gmk in a follow-up change. I think now that we > have all the corresponding directories in place we could rename > {solaris,linux,bsd}_close.c to just close.c and move them to > $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/native/libnet. We > could than get rid of the platform dependent LIBNET_EXCLUDE_FILES in > NetworkingLibraries.gmk. What's your opinion? Yes, the goal is to eventually move any sources in src/$MODULE/unix that are specific to Solaris, Linux, AIX, .. to the appropriate src/$MODULE/$OS directory. Some of this was done to test out the new layout, the rest was left to the various areas to work on over time. -Alan From chris.hegarty at oracle.com Thu Aug 28 15:47:02 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Aug 2014 16:47:02 +0100 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: References: Message-ID: <28FC0AE8-6010-4A1A-AE5E-4AC3EDD2A2CF@oracle.com> On 28 Aug 2014, at 16:22, Volker Simonis wrote: > > PS: I would also like to do some further cleanup in > NetworkingLibraries.gmk in a follow-up change. I think now that we > have all the corresponding directories in place we could rename > {solaris,linux,bsd}_close.c to just close.c and move them to > $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/native/libnet. We > could than get rid of the platform dependent LIBNET_EXCLUDE_FILES in > NetworkingLibraries.gmk. What's your opinion? That would be great. I can help with the review and verification of such a change. -Chris. From erik.joelsson at oracle.com Thu Aug 28 15:56:56 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 28 Aug 2014 17:56:56 +0200 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: References: Message-ID: <53FF5148.4060205@oracle.com> Hello Volker, Thanks for cleaning up! On 2014-08-28 17:22, Volker Simonis wrote: > Hi, > > could somebody please review the following small changes to fix the > AIX build after the Modular Source Code change 8054834. I've also done > a little cleanup which is detailed below: > > http://cr.openjdk.java.net/~simonis/webrevs/8056246/ > https://bugs.openjdk.java.net/browse/JDK-8056246 > > make/lib/Awt2dLibraries.gmk > > LIBAWT_CFLAGS contains quite some duplicate include parameters which > can be removed. > > -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt > isn't required because the path > $(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt > is already part of LIBAWT_DIRS and the corresponding include parameter > is already generated by $(addprefix -I, $(shell find $(LIBAWT_DIRS) > -type d)) > $(foreach dir, $(LIBAWT_DIRS), -I$(dir)) isn't required either, > because $(addprefix -I, $(shell find $(LIBAWT_DIRS) -type d)) not only > creates include parameters for every sub-directory contained in > LIBAWT_DIRS, but also for the directories themselves. This all looks good. > make/rmic/Rmic-java.management.gmk > > This change is a little bit hacky, but it's the best I could find for > the moment. The problem is that find on AIX (but also GNU find before > version 4.2) are buggy in the sense that they will report an error if > "-exec \+" is used in cases where the find command won't find any > files. > > Therefore, the following make rule will fail for incremental builds if > the $(RMIC_GENSRC_DIR) directory won't contain any *.class files any > more. These class files are deleted during the first invocation of the > rule. However, the rule will be re-executed for every new build > because its target depends on the deleted files. > > $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC) > $(FIND) $(RMIC_GENSRC_DIR) -name "*.class" $(FIND_DELETE) > $(TOUCH) $@ > > I've therefore added the file _the.classes.removed to the find > pattern. That way, the find command will always match at least one > file and the buggy "-exec \+" won't complain. > > $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC) > $(FIND) $(RMIC_GENSRC_DIR) \( -name "*.class" -o -name $(@F) \) > $(FIND_DELETE) > $(TOUCH) $@ > > Notice, that deleting _the.classes.removed is no problem here, because > the the file will be recreated by the following touch command. This looks safe, but it's not clear why it needs to be done so it certainly warrants a comment. Another approach on this would be to find a different way of expressing FIND_DELETE on AIX that works better. Perhaps an xargs construct? FIND_DELETE is defined in basics.m4 if you would want to give it a shot. > I've build and smoke tested these changes on Linux/x86_64, > Linux/ppc64, MacOS X, Solaris10/SPARC and AIX. > > Thank you and best regards, > Volker > > PS: I would also like to do some further cleanup in > NetworkingLibraries.gmk in a follow-up change. I think now that we > have all the corresponding directories in place we could rename > {solaris,linux,bsd}_close.c to just close.c and move them to > $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/native/libnet. We > could than get rid of the platform dependent LIBNET_EXCLUDE_FILES in > NetworkingLibraries.gmk. What's your opinion? As Alan said, we intend to follow up on these kinds of changes. I would welcome any help in getting them started. /Erik From volker.simonis at gmail.com Thu Aug 28 16:24:45 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Aug 2014 18:24:45 +0200 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: <53FF5148.4060205@oracle.com> References: <53FF5148.4060205@oracle.com> Message-ID: Hi Erik, thanks for reviewing my change! Please find my comments inline: On Thu, Aug 28, 2014 at 5:56 PM, Erik Joelsson wrote: > Hello Volker, > > Thanks for cleaning up! > > > On 2014-08-28 17:22, Volker Simonis wrote: >> >> Hi, >> >> could somebody please review the following small changes to fix the >> AIX build after the Modular Source Code change 8054834. I've also done >> a little cleanup which is detailed below: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8056246/ >> https://bugs.openjdk.java.net/browse/JDK-8056246 >> >> make/lib/Awt2dLibraries.gmk >> >> LIBAWT_CFLAGS contains quite some duplicate include parameters which >> can be removed. >> >> >> -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt >> isn't required because the path >> >> $(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt >> is already part of LIBAWT_DIRS and the corresponding include parameter >> is already generated by $(addprefix -I, $(shell find $(LIBAWT_DIRS) >> -type d)) >> $(foreach dir, $(LIBAWT_DIRS), -I$(dir)) isn't required either, >> because $(addprefix -I, $(shell find $(LIBAWT_DIRS) -type d)) not only >> creates include parameters for every sub-directory contained in >> LIBAWT_DIRS, but also for the directories themselves. > > This all looks good. > >> make/rmic/Rmic-java.management.gmk >> >> This change is a little bit hacky, but it's the best I could find for >> the moment. The problem is that find on AIX (but also GNU find before >> version 4.2) are buggy in the sense that they will report an error if >> "-exec \+" is used in cases where the find command won't find any >> files. >> >> Therefore, the following make rule will fail for incremental builds if >> the $(RMIC_GENSRC_DIR) directory won't contain any *.class files any >> more. These class files are deleted during the first invocation of the >> rule. However, the rule will be re-executed for every new build >> because its target depends on the deleted files. >> >> $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC) >> $(FIND) $(RMIC_GENSRC_DIR) -name "*.class" $(FIND_DELETE) >> $(TOUCH) $@ >> >> I've therefore added the file _the.classes.removed to the find >> pattern. That way, the find command will always match at least one >> file and the buggy "-exec \+" won't complain. >> >> $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC) >> $(FIND) $(RMIC_GENSRC_DIR) \( -name "*.class" -o -name $(@F) \) >> $(FIND_DELETE) >> $(TOUCH) $@ >> >> Notice, that deleting _the.classes.removed is no problem here, because >> the the file will be recreated by the following touch command. > > This looks safe, but it's not clear why it needs to be done so it certainly > warrants a comment. Another approach on this would be to find a different > way of expressing FIND_DELETE on AIX that works better. Perhaps an xargs > construct? FIND_DELETE is defined in basics.m4 if you would want to give it > a shot. I already thought about this possibility, but then again, AIX find/xargs don't support "-print0"/"-O" which is considered a little unsafe (see for example http://stackoverflow.com/questions/896808/find-exec-cmd-vs-xargs). What do you think, change it to xargs on AIX nevertheless or just add a comment to the current version? >> I've build and smoke tested these changes on Linux/x86_64, >> Linux/ppc64, MacOS X, Solaris10/SPARC and AIX. >> >> Thank you and best regards, >> Volker >> >> PS: I would also like to do some further cleanup in >> NetworkingLibraries.gmk in a follow-up change. I think now that we >> have all the corresponding directories in place we could rename >> {solaris,linux,bsd}_close.c to just close.c and move them to >> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/native/libnet. We >> could than get rid of the platform dependent LIBNET_EXCLUDE_FILES in >> NetworkingLibraries.gmk. What's your opinion? > > As Alan said, we intend to follow up on these kinds of changes. I would > welcome any help in getting them started. > Great, thanks. I'll start right after this one is pushed:) Regards, Volker > /Erik From magnus.ihse.bursie at oracle.com Thu Aug 28 17:35:58 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 28 Aug 2014 19:35:58 +0200 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: References: Message-ID: Looks good to me. I agree with Erik that a comment describing the fix for the find/delete issue would be good. Are other uses of FIND_DELETE problematic on AIX as well? I wholeheartedly support all continued cleaning up of native files, and have suggested this fix already. Erik has probably put it in one of the cleanup bugs he created with my Jigsaw code review comments. /Magnus 28 aug 2014 kl. 17:22 skrev Volker Simonis : > Hi, > > could somebody please review the following small changes to fix the > AIX build after the Modular Source Code change 8054834. I've also done > a little cleanup which is detailed below: > > http://cr.openjdk.java.net/~simonis/webrevs/8056246/ > https://bugs.openjdk.java.net/browse/JDK-8056246 > > make/lib/Awt2dLibraries.gmk > > LIBAWT_CFLAGS contains quite some duplicate include parameters which > can be removed. > > -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt > isn't required because the path > $(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt > is already part of LIBAWT_DIRS and the corresponding include parameter > is already generated by $(addprefix -I, $(shell find $(LIBAWT_DIRS) > -type d)) > $(foreach dir, $(LIBAWT_DIRS), -I$(dir)) isn't required either, > because $(addprefix -I, $(shell find $(LIBAWT_DIRS) -type d)) not only > creates include parameters for every sub-directory contained in > LIBAWT_DIRS, but also for the directories themselves. > > make/rmic/Rmic-java.management.gmk > > This change is a little bit hacky, but it's the best I could find for > the moment. The problem is that find on AIX (but also GNU find before > version 4.2) are buggy in the sense that they will report an error if > "-exec \+" is used in cases where the find command won't find any > files. > > Therefore, the following make rule will fail for incremental builds if > the $(RMIC_GENSRC_DIR) directory won't contain any *.class files any > more. These class files are deleted during the first invocation of the > rule. However, the rule will be re-executed for every new build > because its target depends on the deleted files. > > $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC) > $(FIND) $(RMIC_GENSRC_DIR) -name "*.class" $(FIND_DELETE) > $(TOUCH) $@ > > I've therefore added the file _the.classes.removed to the find > pattern. That way, the find command will always match at least one > file and the buggy "-exec \+" won't complain. > > $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC) > $(FIND) $(RMIC_GENSRC_DIR) \( -name "*.class" -o -name $(@F) \) > $(FIND_DELETE) > $(TOUCH) $@ > > Notice, that deleting _the.classes.removed is no problem here, because > the the file will be recreated by the following touch command. > > I've build and smoke tested these changes on Linux/x86_64, > Linux/ppc64, MacOS X, Solaris10/SPARC and AIX. > > Thank you and best regards, > Volker > > PS: I would also like to do some further cleanup in > NetworkingLibraries.gmk in a follow-up change. I think now that we > have all the corresponding directories in place we could rename > {solaris,linux,bsd}_close.c to just close.c and move them to > $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/native/libnet. We > could than get rid of the platform dependent LIBNET_EXCLUDE_FILES in > NetworkingLibraries.gmk. What's your opinion? From lana.steuck at oracle.com Thu Aug 28 22:46:53 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 28 Aug 2014 15:46:53 -0700 (PDT) Subject: jdk9-b28: dev Message-ID: <201408282246.s7SMkrXC003709@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/ea2f7981236f http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/00c31e5eaf26 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/016786f79314 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1828f73b35cf http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/5282a14f131f http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/dc1e26434b3f http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/657294869d7f http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/a00b04ef067e --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8038937 client-libs Validate fields on Swing classes deserialization JDK-6521706 client-libs A switch operator in JFrame.processWindowEvent() should be rewritten JDK-8054157 client-libs Access Bridge; add definitions for bits 8 and 9 for for new accelerator support JDK-8042284 client-libs Add block tags for @return and @param to swing plaf classes JDK-8017284 client-libs Aqua LaF: memory leak when HTML is used for JTabbedPane tab titles JDK-8052396 client-libs Catch exceptions resulting from missing font cmap JDK-8054372 client-libs Cleanup of com.sun.media.sound packages JDK-8033141 client-libs Cleanup of sun.awt.X11 package JDK-8044820 client-libs Consider removing externalization of GUIInitializedMulticaster and TopLevelWindowMulticaster JDK-8051588 client-libs DataTransferer.getInstance throws ClassCastException in headless mode JDK-6521727 client-libs DefaultTreeCellEditor doesn't implement Serializable JDK-8035165 client-libs Expose internal representation in sun.awt.X11 JDK-8050924 client-libs Fix doclint missing tag warnings in javax.swing.plaf.basic parts 5b,6b of 7 JDK-8026497 client-libs Font2DTest demo: unused resource files JDK-8051449 client-libs Incorrect parsing of the default flavor mapping JDK-8049057 client-libs JNI exception pending in jdk/src/windows/native/sun/windows/ JDK-8051359 client-libs JPopupMenu creation in headless mode with JDK9b23 causes NPE JDK-8039274 client-libs Java crashes if calling System.exit(0) while drawing text. JDK-8050852 client-libs Javadoc cleanup of javax.sound.midi package JDK-8046495 client-libs KeyEvent can not be accepted in quick mouse clicking JDK-8048524 client-libs Memory leak in jdk/src/share/native/sun/awt/image/BufImgSurfaceData.c JDK-8052408 client-libs Move AWT_BAT functional tests to OpenJDK (3 of 3) JDK-8054371 client-libs Need to suppress newly added unchecked cast and conversion in Swing code JDK-8037485 client-libs Refactor java.awt.datatransfer to eliminate dependency on AWT JDK-6302052 client-libs Reference to nonexistant Class in javadoc JDK-8054431 client-libs Some of the input validation in the javasound is too strict JDK-8049533 client-libs SwingUtilities.convertMouseEvent misses MouseWheelEvent.preciseWheelRotation JDK-7058700 client-libs Unexpected exceptions and timeouts in SF2 parser code JDK-7058697 client-libs Unexpected exceptions in MID parser code JDK-6521783 client-libs Unnecessary final modifier for a method in a final class JDK-8041982 client-libs Use of animated icon in JLayer causes CPU spin JDK-8051838 client-libs [Findbugs]sun.awt.image.MultiResolutionCachedImage expose internal representation JDK-8047288 client-libs [macosx] Endless loop in EDT on Mac JDK-8044614 client-libs [macosx] Focus issue with 2 applets in firefox JDK-8032864 client-libs [macosx] sigsegv (0Xb) Being Generated When Starting JDev With Voiceover Running JDK-8050885 client-libs move awt automated tests from AWT_Modality to OpenJDK repository - part 4 JDK-8052012 client-libs move awt automated tests from AWT_Modality to OpenJDK repository - part 5 JDK-8054841 core-libs (process) ProcessBuilder leaks native memory JDK-8044629 core-libs (reflect) Constructor.getAnnotatedReceiverType() returns wrong value JDK-8055368 core-libs Ant build broken after modular source code change JDK-8054898 core-libs Avoid creation of empty type info files JDK-8034032 core-libs Check src/macosx/native/java/util/prefs/MacOSXPreferencesFile.m for JNI pending issues JDK-8055042 core-libs Compile-time expression evaluator was missing variables JDK-8046026 core-libs CompiledFunction.relinkComposableInvoker assert is being hit JDK-8055107 core-libs Extension directives to turn on callsite profiling, tracing, AST print and other debug features locally JDK-8054857 core-libs Fix typos in java.lang.** packages JDK-8054651 core-libs Global.initConstructor and ScriptFunction.getPrototype(Object) can have stricter types JDK-8043956 core-libs Make code caching work with optimistic typing and lazy compilation JDK-8050078 core-libs Nashorn ClassFilter Support JDK-8055395 core-libs Nashorn should use source, target to be 1.8 and use ASM5 version for generated code JDK-8055088 core-libs Optimization for locale resources loading isn't working JDK-8055004 core-libs Reduce allocation overhead in java.time.Period/Duration parse methods JDK-8048123 core-libs Replace calendars.properties with another mechanism to specify a new Japanese calendar era JDK-8053910 core-libs ScriptObjectMirror causing havoc with Invocation interface JDK-8054221 core-libs StringJoiner imlementation optimization JDK-8054828 core-libs TEST_BUG: Typos in java/lang/Long/ParsingTest JDK-8054480 core-libs Test java/util/logging/TestLoggerBundleSync.java fails: Unexpected bundle name: null JDK-8051346 core-libs Test262 tests for ECMAScript 5 now in branch "es5-tests" JDK-8055199 core-libs Tidy up Nashorn codebase for code standards (August 2014) JDK-8055262 core-libs Update jdk/test/java/util/Base64 tests to remove use of sun.misc.BASE64Encoder/Decoder JDK-8054118 core-libs java/net/ipv6tests/UdpTest.java failed intermittently JDK-8052403 core-libs java/util/logging/CheckZombieLockTest.java fails with NoSuchFileException JDK-8054555 core-libs javadoc typo clean up JDK-8055034 core-libs jjs exits interactive mode if exception was thrown when trying to print value of last evaluated expression JDK-8044851 core-libs nashorn properties leak memory JDK-8055253 core-libs test/java/util/Currency/PropertiesTest.sh modifies the test JDK JDK-8054503 core-libs test/script/external/test262/test/suite/ch12/12.6/12.6.4/12.6.4-2.js fails with tip JDK-8055139 core-libs test/script/trusted/JDK-8055107.js fails with access control exception JDK-8054993 core-libs type info cache may be disabled for test262 and tests explicitly changing that property should use @fork JDK-8054824 core-svc Clean up ProblemList.txt JDK-8054278 core-svc Refactor jps utility tests JDK-8052961 core-svc Test "com/sun/tools/attach/StartManagementAgent.java" failing intermittently JDK-8053922 core-svc remove closed/sun/management/snmp/tostring/SnmpStringTest.java from closed/ProblemList.txt JDK-8049340 core-svc sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out JDK-8055673 core-svc test/com/sun/jdi/ShellScaffold.sh does not honor -javaoption JDK-8023999 deploy App does not show unsigned warning when loading non-code resource in html applet. JDK-8042626 deploy Exception occurs when writing many texts to java console JDK-8042696 deploy Existing Java method cannot be called from JavaScript in IE JDK-8050016 deploy Improve Java Control Panel support for High DPI JDK-8046709 deploy Java Control Panel Security Level Radio Buttons do not have name, screen read not able to read the name JDK-8050428 deploy JavaFX client authentication dialog is not a JavaFX-based dialog JDK-8032782 deploy Typo of the $SYSTEM_HOME environment variable at com/sun/deploy/config/Config.java JDK-7191857 deploy crossdomin.xml defined in java webstart jnlp file is not taking effect JDK-8050875 deploy regression - java_arguments not accepted after Update to 7u65 JDK-8041641 deploy remove 2 arg version of SecurityBaseline.satisfiesBaselineStrictly() JDK-8055211 docs Incorrect CertPathParameters declaration in JSSE Reference Guide sample code JDK-8029443 hotspot 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation JDK-8054054 hotspot 8040121 is broken JDK-8048269 hotspot Add flag to turn off class unloading after G1 concurrent mark JDK-8054810 hotspot Add missing packages to @build in JFR tests JDK-8054823 hotspot Add size_t as a valid VM flag type JDK-8047977 hotspot Add testcases for DumpJFR SA tool JDK-8040213 hotspot C2 does not put all modified nodes on IGVN worklist JDK-8050973 hotspot CMS/G1 GC: add missing Resource and Handle mark JDK-8050860 hotspot Cleanup TypeTuple and TypeFunc JDK-8054933 hotspot Crash with critical error c0000374 when using JFR JDK-8054081 hotspot Crashes with assert "modified node is not on IGVN._worklist" JDK-8049046 hotspot Deprecated Function in hotspot/src/os/solaris/vm/attachListener_solaris.cpp JDK-8051973 hotspot Eager reclaim leaves marks of marked but reclaimed objects on the next bitmap JDK-8027959 hotspot Early reclamation of large objects in G1 JDK-8052170 hotspot G1 asserts at collection exit with -XX:-G1DeferredRSUpdate JDK-8044521 hotspot JEP C108: Enable JFR Dynamically at Run Time JDK-8011397 hotspot JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot JDK-8051344 hotspot JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on JDK-6424123 hotspot JVM crashes on failed 'strdup' call. JDK-8049043 hotspot Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp JDK-8040121 hotspot Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp, runtime/sharedRuntimeTrans.cpp, utilities/globalDefinitions_visCPP.hpp JDK-8052081 hotspot Optimize code generated by C2 for Intel's Atom processor JDK-8031323 hotspot Optionally align objects copied to survivor spaces JDK-8050942 hotspot PPC64: implement template interpreter for ppc64le JDK-8051012 hotspot Regression in verifier for method call from inside of a branch JDK-8003426 hotspot Remove UseFastAccessors and UseFastEmptyMethods except for zero JDK-8054341 hotspot Remove some obsolete code in G1CollectedHeap class JDK-8051837 hotspot Remove temporary G1UseParallelRSetUpdating and G1UseParallelRSetScanning flags JDK-8054033 hotspot Remove unused references to Compile* JDK-8046598 hotspot Scalable Native Memory Tracking development JDK-8051883 hotspot TEST.groups references missing test: gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java JDK-8051484 hotspot Test compiler/6932496/Test6932496.java failed to compile after JDK-8011044: 1.5 is no longer supported JDK-8043966 hotspot Tests get ClassNotFoundException JDK-8040921 hotspot Uninitialised memory in hotspot/src/share/vm/c1/c1_LinearScan.cpp JDK-8040920 hotspot Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp JDK-8049049 hotspot Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp JDK-8051826 hotspot Update DumpJFR tool to be in sync with the Method content descriptor change JDK-8046233 hotspot VerifyError on backward branch JDK-8049252 hotspot VerifyStack logic in Deoptimization::unpack_frames does not expect to see invoke bc at the top frame during normal deoptimization JDK-8025667 hotspot Warning from b62 for hotspot.agent.src.os.solaris.proc: use after free JDK-8054952 hotspot [TESTBUG] Add missing NMT2 tests JDK-8044140 hotspot [TESTBUG] Create NMT (Native Memory Tracking) tests for NMT2 JDK-8055012 hotspot [TESTBUG] NMTHelper fails to parse NMT output JDK-8053956 hotspot [TESTBUG] Remove @ignore tag from fixed runtime issues JDK-8048555 hotspot [TESTBUG] Remove closed/runtime/5072683/Test5072683.sh JDK-8054938 hotspot [TESTBUG] Wrong WhiteBox.java was pushed by JDK-8044140 JDK-8039373 hotspot [TESTBUG] closed/runtime/hugeAttrLength/HugeAttributeLength.java should be more strict JDK-8054713 hotspot [TESTBUG] runtime/jsig/Test8017498.sh: Execution failed: exit code 1 JDK-8034056 hotspot assert(_heap_alignment >= _space_alignment) failed: heap_alignment less than space_alignment JDK-8046698 hotspot assert(false) failed: only Initialize or AddP expected macro.cpp:943 JDK-8053915 hotspot bigapps assert failure in C2: modified node is not on IGVN._worklist JDK-8050510 hotspot closed/compiler/jsr292/LongLambdaFormStackDepth.java timedout on Win64 in JPRT JDK-8054410 hotspot compiler/7068051/Test7068051.java fails with FileNotFoundException: f3oo.jar JDK-7187999 hotspot dtrace jstack action is broken JDK-8035939 hotspot java/lang/management/MemoryMXBean/MemoryManagement.java timed out on Linux-amd64 JDK-8051896 hotspot jtreg tests don't use $TESTJAVAOPTS JDK-8051398 hotspot jvmti tests fieldacc002, fieldmod002 fail in nightly with errors: (watch#0) wrong location JDK-8054013 hotspot run hotspot JTREG compiler tests only on fastdebug platforms and also on macosx JDK-8050485 hotspot super() in a try block in a ctor may need to cause VerifyError JDK-8054409 hotspot test/closed/compiler/4819903/Test4819903.sh fails with: line 12: ${NULL}: ambiguous redirect JDK-8055405 infrastructure JDK 9 build started failing on ja_JP.UTF-8 locale due to mapping error (encoding=ascii). JDK-8022177 infrastructure Windows/MSYS builds broken JDK-8055497 infrastructure [infra] build failure when building bootcycle images JDK-8055353 infrastructure libsplashscreen build fails on MacOSX Mavericks JDK-8051906 install Apply fixes from l10n team JDK-8054015 install Dll / DllFunction classes need description JDK-8044110 install InstallConfigData should have better design JDK-8053928 install JDK 9 client build failed with signing tmp_au.msi for windows platforms because file format cannot be signed JDK-8049060 install JDK installer "Java Setup" dialog a11y issue JDK-8052161 install JavaScrub cannot uninstall any JRE JDK-8051565 install JavaScrub exe-s size are significantly increased JDK-8048290 install Offline combo build should run as standalone build target JDK-8051629 install Use only one JavaScrub exe file in JUT JDK-8048122 install VPAT: Mnemonics not set for integrated JRE Uninstall Tool buttons JDK-8054311 install [8u20] 64-bit AU removes the 32-bit NEXTVER unexpectedly JDK-8023823 install [GTests] CreateShortCutItem_NULLValue failed JDK-8054082 install [Nightly] An error dialog pops up during AU from 9 to NEXTVER JDK-8054047 install jdk9: jre offline installer is broken JDK-8051395 install removal tool should also remove older non-static versions of the same JRE family being installed JDK-8051639 install require patching and bsdiff for all install builds JDK-8055111 other-libs [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't remove -Xconcgc JDK-8038861 other-libs [javadoc] broken links in org/omg/CORBA/FloatSeqHelper.html JDK-8046343 security-libs (smartcardio) CardTerminal.connect('direct') does not work on MacOSX JDK-8054366 security-libs Broken link in SecureRandom.html JDK-6997010 security-libs Consolidate java.security files into one file with modifications JDK-8054817 security-libs File ccache only recognizes Linux and Solaris defaults JDK-7026255 security-libs Methods of Subject that throw SecurityException do not specify what permissions are required JDK-8043836 security-libs Need new tests for AES cipher JDK-6960855 security-libs Turn off allowUnsafeRenegotiation in SimpleCrossJVM JDK-8055373 security-libs Typo in InquireType.java JDK-8054627 security-libs [TESTBUG] closed\java\lang\SecurityManager\RunStackWalk.java should be changed to work under profiles JDK-8054429 security-libs [TESTBUG]Some of the closed/java/lang/reflect/Proxy should be changed to work under profiles JDK-8054465 tools Add --permit-artifact=bar.txt to sjavac JDK-8054474 tools Add --state-dir=foo to chose location for javac_state file JDK-8054461 tools Add @file support for sjavac command line JDK-8054964 tools Add a test for invalid package annotations JDK-8049127 tools Group 8b: golden files for annotations test in tools/java dir JDK-8049129 tools Group 8c: golden files for annotations test in tools/java dir JDK-8049130 tools Group 8d: golden files for annotations test in tools/java dir JDK-8042251 tools Implement classfile tests for InnerClasses attribute. JDK-8055390 tools IntelliJ langtools project should reflect modular source tree JDK-8055054 tools Remove visitWildcard visitor method from erasure visitor JDK-8044131 tools Restructure client / server protocol code JDK-8055039 tools Sjavac does not print compilation errors to the console JDK-8048457 tools Sjavac should not use portfiles, sockets, etc if background=false JDK-8050429 tools Update/cleanup ToolBox JDK-8054215 tools Use com.sun.tools.javac.util.Assert instead of 'assert' JDK-8055501 tools [javac] ignore test/tools/javac/Paths/AbsolutePathTest.java JDK-8054044 tools [javadoc] javadoc tester must print out the javadoc run arguments. JDK-8055076 tools fix test failures in classfile tests JDK-8054556 tools javac should report the error for default usage as the primary error From erik.joelsson at oracle.com Fri Aug 29 07:22:15 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Aug 2014 09:22:15 +0200 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: References: <53FF5148.4060205@oracle.com> Message-ID: <54002A27.2040207@oracle.com> On 2014-08-28 18:24, Volker Simonis wrote: > >> This looks safe, but it's not clear why it needs to be done so it certainly >> warrants a comment. Another approach on this would be to find a different >> way of expressing FIND_DELETE on AIX that works better. Perhaps an xargs >> construct? FIND_DELETE is defined in basics.m4 if you would want to give it >> a shot. > I already thought about this possibility, but then again, AIX > find/xargs don't support "-print0"/"-O" which is considered a little > unsafe (see for example > http://stackoverflow.com/questions/896808/find-exec-cmd-vs-xargs). > What do you think, change it to xargs on AIX nevertheless or just add > a comment to the current version? > So the problem is that an xargs variant would not support spaces in filenames. Configure already fails before the first printout if there are spaces in the path to the root repo so that shouldn't be an issue. I very much doubt we would make an effort to support that use case. The drawback of the current solution is that if we introduce a new use of FIND_DELETE, we will most likely forget about the error if the find returns nothing and you will have to fix it again for AIX. I'm fine with either solution and will happily leave it for you to decide. I took your patch and ran it through JPRT successfully so it has been tried on all our platforms. /Erik From volker.simonis at gmail.com Fri Aug 29 09:06:49 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Aug 2014 11:06:49 +0200 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: <54002A27.2040207@oracle.com> References: <53FF5148.4060205@oracle.com> <54002A27.2040207@oracle.com> Message-ID: Hi, On Fri, Aug 29, 2014 at 9:22 AM, Erik Joelsson wrote: > > On 2014-08-28 18:24, Volker Simonis wrote: >> >> >>> This looks safe, but it's not clear why it needs to be done so it >>> certainly >>> warrants a comment. Another approach on this would be to find a different >>> way of expressing FIND_DELETE on AIX that works better. Perhaps an xargs >>> construct? FIND_DELETE is defined in basics.m4 if you would want to give >>> it >>> a shot. >> >> I already thought about this possibility, but then again, AIX >> find/xargs don't support "-print0"/"-O" which is considered a little >> unsafe (see for example >> http://stackoverflow.com/questions/896808/find-exec-cmd-vs-xargs). >> What do you think, change it to xargs on AIX nevertheless or just add >> a comment to the current version? >> > So the problem is that an xargs variant would not support spaces in > filenames. Configure already fails before the first printout if there are > spaces in the path to the root repo so that shouldn't be an issue. I very > much doubt we would make an effort to support that use case. The drawback of > the current solution is that if we introduce a new use of FIND_DELETE, we > will most likely forget about the error if the find returns nothing and you > will have to fix it again for AIX. I'm fine with either solution and will > happily leave it for you to decide. > OK, I thought about this all night long :) and came to the same conclusion - we should never ever support spaces in files on AIX! So here's a revised version of my patch: http://cr.openjdk.java.net/~simonis/webrevs/8056246.v2 where I simply removed the changes to Rmic-java.management.gmk OK to push? Of course I will now need your help to review (and push, because it requires the regeneration of generated-configure.sh) the following tiny top-level change which sets FIND_DELETE to "-print | xargs rm" on AIX: http://cr.openjdk.java.net/~simonis/webrevs/8056246_top_level/ > I took your patch and ran it through JPRT successfully so it has been tried > on all our platforms. Thanks a lot, Volker > > /Erik From magnus.ihse.bursie at oracle.com Fri Aug 29 09:17:52 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 29 Aug 2014 11:17:52 +0200 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: References: <53FF5148.4060205@oracle.com> <54002A27.2040207@oracle.com> Message-ID: <54004540.7000405@oracle.com> On 2014-08-29 11:06, Volker Simonis wrote: > Hi, > > On Fri, Aug 29, 2014 at 9:22 AM, Erik Joelsson wrote: >> On 2014-08-28 18:24, Volker Simonis wrote: >>> >>>> This looks safe, but it's not clear why it needs to be done so it >>>> certainly >>>> warrants a comment. Another approach on this would be to find a different >>>> way of expressing FIND_DELETE on AIX that works better. Perhaps an xargs >>>> construct? FIND_DELETE is defined in basics.m4 if you would want to give >>>> it >>>> a shot. >>> I already thought about this possibility, but then again, AIX >>> find/xargs don't support "-print0"/"-O" which is considered a little >>> unsafe (see for example >>> http://stackoverflow.com/questions/896808/find-exec-cmd-vs-xargs). >>> What do you think, change it to xargs on AIX nevertheless or just add >>> a comment to the current version? >>> >> So the problem is that an xargs variant would not support spaces in >> filenames. Configure already fails before the first printout if there are >> spaces in the path to the root repo so that shouldn't be an issue. I very >> much doubt we would make an effort to support that use case. The drawback of >> the current solution is that if we introduce a new use of FIND_DELETE, we >> will most likely forget about the error if the find returns nothing and you >> will have to fix it again for AIX. I'm fine with either solution and will >> happily leave it for you to decide. >> > OK, I thought about this all night long :) and came to the same > conclusion - we should never ever support spaces in files on AIX! > > So here's a revised version of my patch: > > http://cr.openjdk.java.net/~simonis/webrevs/8056246.v2 > > where I simply removed the changes to Rmic-java.management.gmk > > OK to push? > > Of course I will now need your help to review (and push, because it > requires the regeneration of generated-configure.sh) the following > tiny top-level change which sets FIND_DELETE to "-print | xargs rm" on > AIX: > > http://cr.openjdk.java.net/~simonis/webrevs/8056246_top_level/ Looks good to me. I'm glad you came to that conclusion, this sounds much saner. /Magnus From erik.joelsson at oracle.com Fri Aug 29 09:40:59 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Aug 2014 11:40:59 +0200 Subject: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834 In-Reply-To: References: <53FF5148.4060205@oracle.com> <54002A27.2040207@oracle.com> Message-ID: <54004AAB.6020304@oracle.com> Looks good. I will push it for you. /Erik On 2014-08-29 11:06, Volker Simonis wrote: > Hi, > > On Fri, Aug 29, 2014 at 9:22 AM, Erik Joelsson wrote: >> On 2014-08-28 18:24, Volker Simonis wrote: >>> >>>> This looks safe, but it's not clear why it needs to be done so it >>>> certainly >>>> warrants a comment. Another approach on this would be to find a different >>>> way of expressing FIND_DELETE on AIX that works better. Perhaps an xargs >>>> construct? FIND_DELETE is defined in basics.m4 if you would want to give >>>> it >>>> a shot. >>> I already thought about this possibility, but then again, AIX >>> find/xargs don't support "-print0"/"-O" which is considered a little >>> unsafe (see for example >>> http://stackoverflow.com/questions/896808/find-exec-cmd-vs-xargs). >>> What do you think, change it to xargs on AIX nevertheless or just add >>> a comment to the current version? >>> >> So the problem is that an xargs variant would not support spaces in >> filenames. Configure already fails before the first printout if there are >> spaces in the path to the root repo so that shouldn't be an issue. I very >> much doubt we would make an effort to support that use case. The drawback of >> the current solution is that if we introduce a new use of FIND_DELETE, we >> will most likely forget about the error if the find returns nothing and you >> will have to fix it again for AIX. I'm fine with either solution and will >> happily leave it for you to decide. >> > OK, I thought about this all night long :) and came to the same > conclusion - we should never ever support spaces in files on AIX! > > So here's a revised version of my patch: > > http://cr.openjdk.java.net/~simonis/webrevs/8056246.v2 > > where I simply removed the changes to Rmic-java.management.gmk > > OK to push? > > Of course I will now need your help to review (and push, because it > requires the regeneration of generated-configure.sh) the following > tiny top-level change which sets FIND_DELETE to "-print | xargs rm" on > AIX: > > http://cr.openjdk.java.net/~simonis/webrevs/8056246_top_level/ > >> I took your patch and ran it through JPRT successfully so it has been tried >> on all our platforms. > Thanks a lot, > Volker > >> /Erik