From li.jiang at oracle.com Tue Feb 5 01:35:53 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Tue, 5 Feb 2019 09:35:53 +0800 Subject: [12] RFR 8218411 : JDK 12 L10n resource file update msg drop 20 Message-ID: <27e9e7f7-a9b7-3114-7115-4c126703c8bc@oracle.com> Hi, Please review the changes of l10n resource file update for JDK 12 msg drop 20. As schedule, we run the msg drop 20 to catch the latest changes for l10n. Generally there is no l10n resource file change after this msg drop. If you have changed recently or will change after RDP2, some l10n files, pls let me know. We will run the msg drop 30 only if necessary. Bug: https://bugs.openjdk.java.net/browse/JDK-8218411 Webrev: http://cr.openjdk.java.net/~ljiang/8218411/webrev/read/open/ Thanks, Leo From naoto.sato at oracle.com Tue Feb 5 16:26:49 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 5 Feb 2019 08:26:49 -0800 Subject: [12] RFR 8218411 : JDK 12 L10n resource file update msg drop 20 In-Reply-To: <27e9e7f7-a9b7-3114-7115-4c126703c8bc@oracle.com> References: <27e9e7f7-a9b7-3114-7115-4c126703c8bc@oracle.com> Message-ID: <8a671c4c-ea64-e067-720a-fc4b8af27aa4@oracle.com> Looks good, Leo. BTW, I have some comment on the Japanese translation style. Some sentences end with "??" and others end with "???", which is not very consistent. Can you please check with the translation department about this? Naoto On 2/4/19 5:35 PM, li.jiang at oracle.com wrote: > Hi, > > Please review the changes of l10n resource file update for JDK 12 msg > drop 20. > > As schedule, we run the msg drop 20 to catch the latest changes for > l10n. Generally there is no l10n resource file change after this msg > drop. If you have changed recently or will change after RDP2, some l10n > files, pls let me know. We will run the msg drop 30 only if necessary. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8218411 > > Webrev: > http://cr.openjdk.java.net/~ljiang/8218411/webrev/read/open/ > > Thanks, > Leo From li.jiang at oracle.com Wed Feb 6 08:30:42 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Wed, 6 Feb 2019 16:30:42 +0800 Subject: [12] RFR 8218411 : JDK 12 L10n resource file update msg drop 20 In-Reply-To: <8a671c4c-ea64-e067-720a-fc4b8af27aa4@oracle.com> References: <27e9e7f7-a9b7-3114-7115-4c126703c8bc@oracle.com> <8a671c4c-ea64-e067-720a-fc4b8af27aa4@oracle.com> Message-ID: Thank you for reviewing, Naoto! I will forward your feedback to translation team. Thanks, Leo On 2/6/19 12:26 AM, Naoto Sato wrote: > Looks good, Leo. > > BTW, I have some comment on the Japanese translation style. Some > sentences end with "??" and others end with "???", which is not > very consistent. Can you please check with the translation department > about this? > > Naoto > > On 2/4/19 5:35 PM, li.jiang at oracle.com wrote: >> Hi, >> >> Please review the changes of l10n resource file update for JDK 12 msg >> drop 20. >> >> As schedule, we run the msg drop 20 to catch the latest changes for >> l10n. Generally there is no l10n resource file change after this msg >> drop. If you have changed recently or will change after RDP2, some >> l10n files, pls let me know. We will run the msg drop 30 only if >> necessary. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8218411 >> >> Webrev: >> http://cr.openjdk.java.net/~ljiang/8218411/webrev/read/open/ >> >> Thanks, >> Leo From mark.reinhold at oracle.com Thu Feb 7 08:07:25 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 07 Feb 2019 09:07:25 +0100 Subject: JDK 12 is now in the Release Candidate Phase Message-ID: <20190207090725.735203933@eggemoggin.niobe.net> Per the JDK 12 schedule [1], we are now in the Release Candidate phase. The stabilization repository, jdk/jdk12, is open for P1 bug fixes per the JDK Release Process (JEP 3) [2]. All changes require approval via the Fix-Request Process [3]. If you?re responsible for any bugs that appear on the RC candidate-bug list [4] then please see JEP 3 for guidance on how to handle them. - Mark [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://openjdk.java.net/jeps/3 [3] http://openjdk.java.net/jeps/3#Fix-Request-Process [4] http://j.mp/jdk-rc From mark.reinhold at oracle.com Fri Feb 8 07:20:57 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 08 Feb 2019 08:20:57 +0100 Subject: JDK 12: No Release Candidate, yet Message-ID: <20190208082057.791068114@eggemoggin.niobe.net> We tagged the first Release Candidate build yesterday (jdk-12+31), but since the P1 bug list (https://j.mp/jdk-rc) is not empty, that build is not a Release Candidate. - Mark From chris.hegarty at oracle.com Fri Feb 8 14:52:15 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Feb 2019 14:52:15 +0000 Subject: JDK 12: No Release Candidate, yet In-Reply-To: <20190208082057.791068114@eggemoggin.niobe.net> References: <20190208082057.791068114@eggemoggin.niobe.net> Message-ID: <9E30E302-BEB3-4AD4-911A-F810AAA9811A@oracle.com> > On 8 Feb 2019, at 07:20, mark.reinhold at oracle.com wrote: > > We tagged the first Release Candidate build yesterday (jdk-12+31), > but since the P1 bug list (https://j.mp/jdk-rc) is not empty, that > build is not a Release Candidate. The point about the potential-RC build and tagging still stands, but just to add ... As the engineer responsible for a couple of late P1s, I can say that the changes to fix those issues have been pushed to JDK 12. The P1 bug list is now empty. -Chris. From coleen.phillimore at oracle.com Fri Feb 8 20:10:22 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 8 Feb 2019 15:10:22 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo Message-ID: <743442db-baea-878b-0580-98df95ab755c@oracle.com> I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. Patricio works for Oracle on the Hotspot Runtime team and has contributed 14 changesets [3] most significantly in the areas of locking, synchronization, tests and concurrent unloading of internal hashtables. Votes are due by Friday February 22nd, 2019. Only current JDK 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]. Coleen Phillimore [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() 8210832: Remove sneaky locking in class Monitor 8215050: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run with flag -Xcomp 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is expected 8150689: Thread dump report "waiting to re-lock in wait()" shows incorrectly 8213708: Different #ifdef guards cause incorrect use of Monitor::check_block_state() 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException 8206424: Use locking for cleaning ProtectionDomainTable 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed 8209854: ProblemList MemberNameLeak 8206423: Use locking for cleaning ResolvedMethodTable 8171157: Convert ObjectMonitor_test to GTest 8206470: Incorrect use of os::lasterror in ClassListParser 8134538: Duplicate implementations of os::lasterror 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and NativeMonitorTimeout experimental flags From erik.osterlund at oracle.com Fri Feb 8 20:12:10 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 8 Feb 2019 21:12:10 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <983470A1-0E88-4977-A622-EAA33FF33A40@oracle.com> Vote: yes /Erik > On 8 Feb 2019, at 21:10, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has contributed 14 changesets [3] most significantly in the areas of locking, synchronization, tests and concurrent unloading of internal hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run with flag -Xcomp > 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows incorrectly > 8213708: Different #ifdef guards cause incorrect use of Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and NativeMonitorTimeout experimental flags From coleen.phillimore at oracle.com Fri Feb 8 20:15:40 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 8 Feb 2019 15:15:40 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <499ea084-01cd-fe90-b197-93835799dec2@oracle.com> Vote: yes On 2/8/19 3:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From harold.seigel at oracle.com Fri Feb 8 20:18:28 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Fri, 8 Feb 2019 15:18:28 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: Yes Harold On 2/8/2019 3:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From mikhailo.seledtsov at oracle.com Fri Feb 8 20:21:59 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 8 Feb 2019 12:21:59 -0800 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <51c230f3-fca0-d71f-64f0-432445fb4ec4@oracle.com> Vote: yes Misha On 2/8/19 12:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From zgu at redhat.com Fri Feb 8 20:28:08 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 08 Feb 2019 15:28:08 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <1549657688.31327.267.camel@redhat.com> Vote: yes -Zhengyu On Fri, 2019-02-08 at 15:10 -0500, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK > committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchil > anomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+me > rge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when > run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From vladimir.x.ivanov at oracle.com Fri Feb 8 20:28:37 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 8 Feb 2019 12:28:37 -0800 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <7e0108a5-25bb-17ff-1708-0bc9dbc20a7b@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 08/02/2019 12:10, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > From Roger.Riggs at oracle.com Fri Feb 8 20:29:49 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 8 Feb 2019 15:29:49 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <590ffe2f-15e6-1d4d-d5be-422ae4611e9a@oracle.com> Vote: Yes On 02/08/2019 03:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. From thomas.stuefe at gmail.com Fri Feb 8 20:40:51 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 8 Feb 2019 21:40:51 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes On Fri 8. Feb 2019 at 21:10, wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags > From eric.caspole at oracle.com Fri Feb 8 20:53:26 2019 From: eric.caspole at oracle.com (Eric Caspole) Date: Fri, 8 Feb 2019 15:53:26 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <40a911c0-7000-7078-61f6-bc60af5a50c5@oracle.com> Vote: yes Eric On 2/8/19 15:10, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From calvin.cheung at oracle.com Fri Feb 8 21:19:04 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 08 Feb 2019 13:19:04 -0800 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <5C5DF248.4080509@oracle.com> Vote: yes On 2/8/19, 12:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From daniel.daugherty at oracle.com Fri Feb 8 21:29:45 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Feb 2019 16:29:45 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <909166a8-6844-aee8-4792-ec208421f7bd@oracle.com> Vote: yes Dan On 2/8/19 3:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags > From david.holmes at oracle.com Fri Feb 8 21:57:43 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Feb 2019 07:57:43 +1000 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes David On 9/02/2019 6:10 am, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From erik.gahlin at oracle.com Fri Feb 8 22:00:44 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 8 Feb 2019 23:00:44 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <5C5DFC0C.2030003@oracle.com> Vote: yes Erik > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From karen.kinnear at oracle.com Fri Feb 8 22:55:42 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 8 Feb 2019 17:55:42 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes thanks, Karen > On Feb 8, 2019, at 3:10 PM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has contributed 14 changesets [3] most significantly in the areas of locking, synchronization, tests and concurrent unloading of internal hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run with flag -Xcomp > 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows incorrectly > 8213708: Different #ifdef guards cause incorrect use of Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and NativeMonitorTimeout experimental flags From jianglizhou at google.com Sat Feb 9 17:03:44 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Sat, 9 Feb 2019 09:03:44 -0800 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes Best regards, Jiangli ---------- Forwarded message --------- > From: > Date: Fri, Feb 8, 2019 at 12:11 PM > Subject: CFV: New JDK Committer: Patricio Chilano Mateo > To: > > > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags > From serguei.spitsyn at oracle.com Mon Feb 11 02:26:17 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 10 Feb 2019 18:26:17 -0800 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes From dean.long at oracle.com Mon Feb 11 06:38:05 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 10 Feb 2019 22:38:05 -0800 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes On 2/8/19 12:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From stefan.karlsson at oracle.com Mon Feb 11 07:27:23 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 08:27:23 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes StefanK On 2019-02-08 21:10, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From robin.westberg at oracle.com Mon Feb 11 07:37:53 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 11 Feb 2019 08:37:53 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes Best regards, Robin > On 8 Feb 2019, at 21:10, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has contributed 14 changesets [3] most significantly in the areas of locking, synchronization, tests and concurrent unloading of internal hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run with flag -Xcomp > 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows incorrectly > 8213708: Different #ifdef guards cause incorrect use of Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and NativeMonitorTimeout experimental flags From tobias.hartmann at oracle.com Mon Feb 11 07:56:04 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 11 Feb 2019 08:56:04 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <83f29865-8a09-dfd9-f374-667da6712e23@oracle.com> Vote: yes Best regards, Tobias On 08.02.19 21:10, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has contributed 14 changesets [3] most > significantly in the areas of locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run with flag > -Xcomp > 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is > expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows incorrectly > 8213708: Different #ifdef guards cause incorrect use of Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and NativeMonitorTimeout experimental flags From claes.redestad at oracle.com Mon Feb 11 08:39:41 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 11 Feb 2019 09:39:41 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <1aeb841c-4e60-40bc-72e1-ccdfbbcd30d3@oracle.com> Vote: yes On 2019-02-08 21:10, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. From adinn at redhat.com Mon Feb 11 09:58:32 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 Feb 2019 09:58:32 +0000 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes On 08/02/2019 20:10, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From robbin.ehn at oracle.com Mon Feb 11 10:20:15 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 11 Feb 2019 11:20:15 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <1b04d3e9-b6fc-f77a-bfb4-a1266fc0f4cf@oracle.com> Vote: yes On 2/8/19 9:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has contributed 14 > changesets [3] most significantly in the areas of locking, synchronization, > tests and concurrent unloading of internal hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails > when run with flag -Xcomp > 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is > not doing what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From lois.foltan at oracle.com Mon Feb 11 14:40:56 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 11 Feb 2019 09:40:56 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <73722896-a32c-2ed7-d059-8dabf570cb78@oracle.com> Vote: yes Lois On 2/8/2019 3:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From patric.hedlin at oracle.com Mon Feb 11 15:26:14 2019 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Mon, 11 Feb 2019 16:26:14 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: Vote: yes /Patric On 08/02/2019 21:10, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with > RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not > removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From per.liden at oracle.com Mon Feb 11 21:29:14 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 11 Feb 2019 22:29:14 +0100 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <0bb6b8db-3f68-ca4c-3b65-acef6497ba0a@oracle.com> Vote: yes /Per On 02/08/2019 09:10 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has > contributed 14 changesets [3] most significantly in the areas of > locking, synchronization, tests and concurrent unloading of internal > hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run > with flag -Xcomp > 8214148: [TESTBUG] > serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing > what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows > incorrectly > 8213708: Different #ifdef guards cause incorrect use of > Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and > NativeMonitorTimeout experimental flags From rfscholte at apache.org Tue Feb 12 07:26:14 2019 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 12 Feb 2019 08:26:14 +0100 Subject: [RFE] Control Relative Path Resolution Message-ID: Recently an interesting change has been applied to the codebase of the JDK: Several predefined System properties are now read-only. This makes the runtime more robust, so we consider this as a great improvement. However, this introduces a new challenge, in this case regarding the system property 'user.dir', since it has different purposes. Some Maven plugins change this value in some cases as it is the only way to control the resolution of relative paths. Being able to change the "working directory" gives several interesting benefits, which should not impact other usages of user.dir. TLDR: As a Java User I want a *standard* way to control the resolution of a File with a relative path So that I'm not forced to start a new JVM Backgrounds: # How java.io.File works (from JavaDoc): ... A pathname, whether abstract or in string form, may be either absolute or relative. An absolute pathname is complete in that no other information is required in order to locate the file that it denotes. A relative pathname, in contrast, must be interpreted in terms of information taken from some other pathname. By default the classes in the java.io package always resolve relative pathnames against the current user directory. This directory is named by the system property user.dir, and is typically the directory in which the Java virtual machine was invoked. ... # How Apache Maven works: root - pom.xml \- M1 | - pom.xml \- M2 - pom.xml| \- M3 -pom.xml (when talking about a Maven module, this is a directory with a pom.xml containing instructions, in general to compile sources of one of the subfolders and to package it into a jar) Maven has the concept of a multi-module project, which is a tree of directories containing several pom.xml files. There are in this picture 2 kinds om poms: aggregator-poms to trigger other poms and project-poms to compile,test and package the content of that folder. It is possible to start anywhere in this tree. In fact it is even possible to start outside this tree and run maven like 'mvn -f /path/to/any/pom.xml'. This should clearly explain there's no relation between the starting directory (user.dir) and the working directory. In Maven the best practice is to use relative paths when working with files. This is always relative to the folder containing the pom.xml of that Maven module. This way we can ensure that files are always calculated correctly no matter where and how you start Maven. For instance, IDE's follow the same concept. # In practice What we also see is that people are having problems understanding inputstreams. The following codefragments we see quite often: File f = new File( "src/test/resources/README.md" ); FileReader is = new FileReader( f ); Knowing that files under src/test/resources end up on the classpath, this is the preferred solution: InputStream is = MyClass.class.getResourceAsStream("/README.md"); However, others feel more comfortable with URLs and Files, resulting in: URL url = MyClass.class.getResource("/README.md"); File f = url.getFile(); FileReader is = new FileReader( f ); (this works as long as the compiled classfiles are in a directory and not in a jar) Depending on the knowledge, unexperienced developers tend to fall back to Files when possible. However, they do understand the difference between relative and absolute paths. # Evaluation This topic has been discussed with several OpenJDK developers from Oracle and committers of the Apache Maven team at FOSDEM 2019 and we came to the following conclusions: Consider: File f = new File( "a/b/c" ); Available solutions: * Use the classpath as much as possible - not always possible, in some cases you are forces to work with files. * Start a new JVM from the expected directory Consequences are: - longer execution time (even though the JVM startup time has improved over the years) - more memory consumption (we recently received an email from somebody having a Maven Multimodule project of ~1600 modules, getting close to its limits. For a project like this, being forced to fork has a negative impact) * File f = new File( System.property( "file.basedir", ""), "a/b/c" ); Consequences are: - Developers must rewrite their code, including every time the *same* statement when relative paths are used - The execution framework should provide this 'magic' property and might pick their own name. E.g. in cases of unittests it would be best to have the same name used by Surefire(Maven) and all IDEs, since they all have their own test execution framework. # Proposal All the options above would not require any changes to the JDK. However, after rethinking these solutions with the Maven committers we would like to see a small change in the JDK itself. The Java community would benefit if the JDK would specify 1 *mutable* System property to control the basedir of a File. This property would default to the value of 'user.dir' to keep the current behavior. With this there is exactly 1 way for all to adjust the resolution of relative paths. This would make it possible to remain the original behavior (users don't have to change their code) and to make the JDK more robust by keeping user.dir read-only. With regards, Robert Scholte From Alan.Bateman at oracle.com Tue Feb 12 12:13:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Feb 2019 12:13:10 +0000 Subject: [RFE] Control Relative Path Resolution In-Reply-To: References: Message-ID: On 12/02/2019 07:26, Robert Scholte wrote: > Recently an interesting change has been applied to the codebase of the > JDK: Several predefined System properties are now read-only. This > makes the runtime more robust, so we consider this as a great > improvement. Just to put a bit more context on this. Java SE defines a number of system properties such as java.home and user.dir that provide information about the runtime and the environment. These system properties were never intended to be changed in a running VM but this read-only-ness never enforced (and it still not enforced). Needless to say, code that changes these properties in a running VM creates massive potential for breakage. The recent change that you mention is to improve the robustness of code in java.base by not reading the values of these system properties after startup. If a library changes the value of java.home (and we have seen cases of this) then it will not impact APIs in java.base that are dependent on the location of the runtime. Ideally we should go further and prevent critical system properties from being changed but this is not easy to do after 20+ years of no enforcement. > > However, this introduces a new challenge, in this case regarding the > system property 'user.dir', since it has different purposes. Some > Maven plugins change this value in some cases as it is the only way to > control the resolution of relative paths. Being able to change the > "working directory" gives several interesting benefits, which should > not impact other usages of user.dir. Java SE and the JDK have no support for the equivalent of chdir, it's not clear how such a feature could work reliably in a multi-threaded environment. We have seen attempts by containers to support multiple tenants with different working directories but there are issues and holes in all attempts that I have seen. > : > > # In practice > > What we also see is that people are having problems understanding > inputstreams. The following codefragments we see quite often: > > File f = new File( "src/test/resources/README.md" ); > FileReader is = new FileReader( f ); This seems like a case where the test runner should make available the src location. We use jtreg for JDK tests and it sets test.src so that tests can locate files in the test source tree if they need it. I understand SureFire sets basedir to the directory containing the POM but maybe it needs to set additional properties for tests (if it does then the IDEs would need to create the same environment). For the scenario then an alternative argument is that resources needed by the tests should be copied to the output directory with the test classes and other resources. > > Knowing that files under src/test/resources end up on the classpath, > this is the preferred solution: > InputStream is = MyClass.class.getResourceAsStream("/README.md"); This will locate the resource relative to MyClass.class, as in target/classes or in root directory of the JAR file if packaged. That said, I suspect many developers can't distinguish file paths from resource names (SO seems to be littered with examples of this). > > However, others feel more comfortable with URLs and Files, resulting in: > URL url = MyClass.class.getResource("/README.md"); > File f = url.getFile(); I don't expect this will compile but I think your point is that developers will often make the mistake of using a URL path component as a file path. This is a big hazard. An API note was added to both URI and URL recently to show how to convert file URIs to file paths and it remains to be seen if that helps, it might be that URL::getFile and a few more should be deprecated as they are named in a way that tempts developers to use them the wrong way. > : > > The Java community would benefit if the JDK would specify 1 *mutable* > System property to control the basedir of a File. This property would > default to the value of 'user.dir' to keep the current behavior. With > this there is exactly 1 way for all to adjust the resolution of > relative paths. > This would make it possible to remain the original behavior (users > don't have to change their code) and to make the JDK more robust by > keeping user.dir read-only. > This has the same issues as user.dir. Is there any way to get Surefire, or whatever plugin is executing the test runner, to create system properties so that tests can locate files in the test source or target locations? I understand they have "basedir" today but this doesn't seem to be enough. -Alan From kim.barrett at oracle.com Tue Feb 12 19:56:04 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 12 Feb 2019 14:56:04 -0500 Subject: CFV: New JDK Committer: Patricio Chilano Mateo In-Reply-To: <743442db-baea-878b-0580-98df95ab755c@oracle.com> References: <743442db-baea-878b-0580-98df95ab755c@oracle.com> Message-ID: <2AA74132-702B-4CB7-819B-920DB8AFA847@oracle.com> vote: yes > On Feb 8, 2019, at 3:10 PM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo (pchilanomate) to JDK committer. > > Patricio works for Oracle on the Hotspot Runtime team and has contributed 14 changesets [3] most significantly in the areas of locking, synchronization, tests and concurrent unloading of internal hashtables. > > Votes are due by Friday February 22nd, 2019. > > Only current JDK 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]. > > Coleen Phillimore > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(pchilanomate)+or+desc(%22patricio.chilano.mateo at oracle.com%22))+and+not+merge() > > 8210832: Remove sneaky locking in class Monitor > 8215050: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java fails when run with flag -Xcomp > 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is expected > 8150689: Thread dump report "waiting to re-lock in wait()" shows incorrectly > 8213708: Different #ifdef guards cause incorrect use of Monitor::check_block_state() > 8210300: runtime/MemberName/MemberNameLeak.java fails with RuntimeException > 8206424: Use locking for cleaning ProtectionDomainTable > 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed > 8209854: ProblemList MemberNameLeak > 8206423: Use locking for cleaning ResolvedMethodTable > 8171157: Convert ObjectMonitor_test to GTest > 8206470: Incorrect use of os::lasterror in ClassListParser > 8134538: Duplicate implementations of os::lasterror > 8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and NativeMonitorTimeout experimental flags From rfscholte at apache.org Tue Feb 12 20:18:53 2019 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 12 Feb 2019 21:18:53 +0100 Subject: [RFE] Control Relative Path Resolution In-Reply-To: References: Message-ID: On Tue, 12 Feb 2019 13:13:10 +0100, Alan Bateman wrote: > On 12/02/2019 07:26, Robert Scholte wrote: >> Recently an interesting change has been applied to the codebase of the >> JDK: Several predefined System properties are now read-only. This makes >> the runtime more robust, so we consider this as a great improvement. > Just to put a bit more context on this. Java SE defines a number of > system properties such as java.home and user.dir that provide > information about the runtime and the environment. These system > properties were never intended to be changed in a running VM but this > read-only-ness never enforced (and it still not enforced). Needless to > say, code that changes these properties in a running VM creates massive > potential for breakage. The recent change that you mention is to improve > the robustness of code in java.base by not reading the values of these > system properties after startup. If a library changes the value of > java.home (and we have seen cases of this) then it will not impact APIs > in java.base that are dependent on the location of the runtime. Ideally > we should go further and prevent critical system properties from being > changed but this is not easy to do after 20+ years of no enforcement. > >> >> However, this introduces a new challenge, in this case regarding the >> system property 'user.dir', since it has different purposes. Some Maven >> plugins change this value in some cases as it is the only way to >> control the resolution of relative paths. Being able to change the >> "working directory" gives several interesting benefits, which should >> not impact other usages of user.dir. > Java SE and the JDK have no support for the equivalent of chdir, it's > not clear how such a feature could work reliably in a multi-threaded > environment. We have seen attempts by containers to support multiple > tenants with different working directories but there are issues and > holes in all attempts that I have seen. > >> : >> >> # In practice >> >> What we also see is that people are having problems understanding >> inputstreams. The following codefragments we see quite often: >> >> File f = new File( "src/test/resources/README.md" ); >> FileReader is = new FileReader( f ); > This seems like a case where the test runner should make available the > src location. We use jtreg for JDK tests and it sets test.src so that > tests can locate files in the test source tree if they need it. I > understand SureFire sets basedir to the directory containing the POM but > maybe it needs to set additional properties for tests (if it does then > the IDEs would need to create the same environment). For the scenario > then an alternative argument is that resources needed by the tests > should be copied to the output directory with the test classes and other > resources. > >> >> Knowing that files under src/test/resources end up on the classpath, >> this is the preferred solution: >> InputStream is = MyClass.class.getResourceAsStream("/README.md"); > This will locate the resource relative to MyClass.class, as in > target/classes or in root directory of the JAR file if packaged. That > said, I suspect many developers can't distinguish file paths from > resource names (SO seems to be littered with examples of this). > >> >> However, others feel more comfortable with URLs and Files, resulting in: >> URL url = MyClass.class.getResource("/README.md"); >> File f = url.getFile(); > I don't expect this will compile but I think your point is that > developers will often make the mistake of using a URL path component as > a file path. This is a big hazard. An API note was added to both URI and > URL recently to show how to convert file URIs to file paths and it > remains to be seen if that helps, it might be that URL::getFile and a > few more should be deprecated as they are named in a way that tempts > developers to use them the wrong way. > > >> : >> >> The Java community would benefit if the JDK would specify 1 *mutable* >> System property to control the basedir of a File. This property would >> default to the value of 'user.dir' to keep the current behavior. With >> this there is exactly 1 way for all to adjust the resolution of >> relative paths. >> This would make it possible to remain the original behavior (users >> don't have to change their code) and to make the JDK more robust by >> keeping user.dir read-only. >> > This has the same issues as user.dir. Is there any way to get Surefire, > or whatever plugin is executing the test runner, to create system > properties so that tests can locate files in the test source or target > locations? I understand they have "basedir" today but this doesn't seem > to be enough. Assuming this can be solved without forcing a new JVM to start, we need something like File f = new File( System.property( "file.basedir", ""), "a/b/c" ); Here it is explicit done by the developer, but I would like to see it implicit, where the System.property( "file.basedir", "") is added by the java.io.File implementation in case the File is relative. To me explicit and implicit have the same result, hence I prefer implicit. This will remove the boiler template and it introduces a predefined name for the property, so that tools, IDEs and execution frameworks don't have to decide which property to choose. This should keep the behavior as (un)reliable as it used to be, but with the extra property you can give control and responsibility to the tools/frameworks. Another conclusion could be that new File( System.property( "file.basedir", ""), "a/b/c" ) will never work due to the multithreading issue. I don't know how this is implemented in Surefire, but what I do know is that I can't remember seeing issues about this over the last decade: adjusting the user.dir has worked for us for a long time (as this was the only way to adjust the relative path resolution) thanks, Robert > > -Alan From Alan.Bateman at oracle.com Wed Feb 13 11:02:11 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Feb 2019 11:02:11 +0000 Subject: [RFE] Control Relative Path Resolution In-Reply-To: References: Message-ID: On 12/02/2019 20:18, Robert Scholte wrote: > > Assuming this can be solved without forcing a new JVM to start, we > need something like > ?File f = new File( System.property( "file.basedir", ""), "a/b/c" ); > > Here it is explicit done by the developer, but I would like to see it > implicit, where the System.property( "file.basedir", "") is added by > the java.io.File implementation in case the File is relative. To me > explicit and implicit have the same result, hence I prefer implicit. > This will remove the boiler template and it introduces a predefined > name for the property, so that tools, IDEs and execution frameworks > don't have to decide which property to choose. > > This should keep the behavior as (un)reliable as it used to be, but > with the extra property you can give control and responsibility to the > tools/frameworks. > > Another conclusion could be that new File( System.property( > "file.basedir", ""), "a/b/c" ) will never work due to the > multithreading issue. > > I don't know how this is implemented in Surefire, but what I do know > is that I can't remember seeing issues about this over the last > decade: adjusting the user.dir has worked for us for a long time (as > this was the only way to adjust the relative path resolution) It has always been unpredictable; some APIs picked up the new value, some used the value from startup, others assume the working directory cannot change. I don't think introducing something like "file.basedir" will do anything except bring back all the problems with user.dir. Even without multi-threaded concerns it just takes one component to cache a relative file path to bring back the same problems. For tests that need to reach into src or test directories then it might be best to make those locations available as system properties. That will make it easier to write tests without concern as to whether they are run in a single or multi-module project. -Alan From gromero at linux.vnet.ibm.com Wed Feb 13 18:15:40 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 13 Feb 2019 16:15:40 -0200 Subject: Result: New JDK Committer: Michihiro Horie Message-ID: Voting for Michihiro Horie [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. Thank you, Gustavo [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002565.html From thomas.stuefe at gmail.com Thu Feb 14 11:58:13 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 14 Feb 2019 12:58:13 +0100 Subject: Which JEE server runs on head OpenJDK (if any)? Message-ID: Hi all, If you wanted to test head OpenJDK (13) under a J2EE server, which one would be the least hassle? The farthest I got with was with WildFly 15 but was unable to deploy anything when running atop of head. It works fine on jdk 11. Thanks, Thomas From lance.andersen at oracle.com Thu Feb 14 12:03:57 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 14 Feb 2019 07:03:57 -0500 Subject: Which JEE server runs on head OpenJDK (if any)? In-Reply-To: References: Message-ID: <6448CA89-173E-4C35-B496-4F61E260BA7E@oracle.com> Hi Thomas, I would probably ask that question on the jakarta EE mailing list https://accounts.eclipse.org/mailing-list/jakarta.ee-community Best Lance > On Feb 14, 2019, at 6:58 AM, Thomas St?fe wrote: > > Hi all, > > If you wanted to test head OpenJDK (13) under a J2EE server, which one > would be the least hassle? > > The farthest I got with was with WildFly 15 but was unable to deploy > anything when running atop of head. It works fine on jdk 11. > > Thanks, Thomas Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From thomas.stuefe at gmail.com Thu Feb 14 12:20:04 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 14 Feb 2019 13:20:04 +0100 Subject: Which JEE server runs on head OpenJDK (if any)? In-Reply-To: <6448CA89-173E-4C35-B496-4F61E260BA7E@oracle.com> References: <6448CA89-173E-4C35-B496-4F61E260BA7E@oracle.com> Message-ID: Thank you Lance, I will do so. .. Thomas On Thu, Feb 14, 2019, 13:03 Lance Andersen Hi Thomas, > > I would probably ask that question on the jakarta EE mailing list > https://accounts.eclipse.org/mailing-list/jakarta.ee-community > > Best > Lance > > On Feb 14, 2019, at 6:58 AM, Thomas St?fe wrote: > > Hi all, > > If you wanted to test head OpenJDK (13) under a J2EE server, which one > would be the least hassle? > > The farthest I got with was with WildFly 15 but was unable to deploy > anything when running atop of head. It works fine on jdk 11. > > Thanks, Thomas > > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From fweimer at redhat.com Thu Feb 14 15:01:57 2019 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 14 Feb 2019 16:01:57 +0100 Subject: [RFE] Control Relative Path Resolution References: Message-ID: <871s4apg62.fsf@oldenburg2.str.redhat.com> * Alan Bateman: >> However, this introduces a new challenge, in this case regarding the >> system property 'user.dir', since it has different purposes. Some >> Maven plugins change this value in some cases as it is the only way >> to control the resolution of relative paths. Being able to change >> the "working directory" gives several interesting benefits, which >> should not impact other usages of user.dir. > Java SE and the JDK have no support for the equivalent of chdir, it's > not clear how such a feature could work reliably in a multi-threaded > environment. Several file servers on Linux use unshare(CLONE_FS) to obtain a per-thread current directory (and chroot and umask, but they probably care less about those). I plan to expose this in glibc 2.30 at the level for clarity, but the unshare hack is extremely reliable today, will not go away, and could be used by the JVM on Linux. (Not sure about Solaris or others.) That does not address the question of the higher-level Java behavior regarding file-system-independent pathname resolution, of course. Thanks, Florian From mark.reinhold at oracle.com Fri Feb 15 18:06:53 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Feb 2019 10:06:53 -0800 Subject: JDK 12: First Release Candidate Message-ID: <20190215100653.193002603@eggemoggin.niobe.net> There are no unresolved P1 bugs in build 32, so that is our first JDK 12 Release Candidate. Binaries available here, as usual: https://jdk.java.net/12 - Mark From jbvernee at xs4all.nl Mon Feb 18 18:58:08 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Mon, 18 Feb 2019 19:58:08 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' Message-ID: <16148e879571c48749bd2f546b95c527@xs4all.nl> Hi, I'm trying to use the new jdk micro benchmark suite from JEP 230 [1]. I've read the instructions in doc/testing.html [2] and I'm using the following command: make test-only TEST="micro:java.lang.reflect" However, this results in an error: Error: Unable to access jarfile /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/images/test/micro/benchmarks.jar I've checked and the jar file does exist at that location. I'm on Windows, which is a little stricter with file locks, so if I had to guess I'd say that the code writing the file does not release it in time for other code to read it. Any suggestions? Thanks, Jorn [1] : https://bugs.openjdk.java.net/browse/JDK-8050952 [2] : http://hg.openjdk.java.net/jdk/jdk/raw-file/f0af4b6c4dfd/doc/testing.html#microbenchmarks From claes.redestad at oracle.com Mon Feb 18 20:51:07 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Feb 2019 21:51:07 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <16148e879571c48749bd2f546b95c527@xs4all.nl> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> Message-ID: Hi Jorn, On 2019-02-18 19:58, Jorn Vernee wrote: > Any suggestions? 1. Does running make test rather than make test-only work? 2. Can you run the benchmarks.jar directly? For example (based on your paths): /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/images/jdk/bin/java -jar /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/images/test/micro/benchmarks.jar java.lang.reflect /Claes From jbvernee at xs4all.nl Mon Feb 18 21:34:19 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Mon, 18 Feb 2019 22:34:19 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: References: <16148e879571c48749bd2f546b95c527@xs4all.nl> Message-ID: <4bbd9ce71073a494d211492308321604@xs4all.nl> Hi Claes, > 1. Does running make test rather than make test-only work? No. Same error there. Sorry, I tried that first and then re-ran with `test-only`. I also tried with a clean build FWIW. > 2. Can you run the benchmarks.jar directly? Yes, this is working, thanks. This way I can also pass extra flags to JMH, which is nice :) --- FWIW, I also had some problems when running configure. 1.) I did not get a warning when I was missing --with-jmh for configure, although it looks like there is supposed to be one (without --with-jmh I got the same access error, but the benchmarks.jar did not exist). 2.) My path to the --with-jmh folder had spaces in it, which was causing an error in make/autoconf/lib-tests.m4 on line 76 [1]. But those both had obvious workarounds. --- I was hoping to use the framework for Panama, so I'd likely have some native library as dependency of the benchmark. Is there currently any support for building (native) dependencies automatically? Thanks, Jorn [1] : http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 From aguibert at us.ibm.com Tue Feb 19 17:03:54 2019 From: aguibert at us.ibm.com (Andrew Guibert) Date: Tue, 19 Feb 2019 17:03:54 +0000 Subject: JDK 12: RC feedback Message-ID: Hi all, I am kicking the tires on the JDK 12 release candidate build, and I noticed two major pain points: 1) javac source/target 6 option is no longer supported Looking through the release notes [1] I see no mention of this change. Is it part of some more generic policy that javac will only go back N-5 versions? Dropping source/target 6 specifically is not my primary concern, rather a more general concern of the cadence of the min compliance dropoff (JDK 9 dropped source/target 5 iirc). If this is the case I worry that by JDK 14 (about a year from now), we will no longer be able to compile down to source/target 8, which will still be a very popular runtime version in 1 years time (and still a supported version). 2) The java.class.version has increased (again) Looking through the release notes, I don't see any major bytecode improvements that signal to me that the class file major version needed to be incremented. Is this being incremented as part of some automatic policy? Major class version updates are extremely disruptive to the java ecosystem, mainly because so many things depend on ASM (or other bytecode libs) somewhere in the stack. Given the 6 month release cadence of Java, this is going to cause a lot of churn in the Java community if we have to wait for ASM to cut a new release before the rest of the community can upgrade, severely cutting into the 6 month lifespan of the non-LTS JDKs. I understand that the JDK reserves the right to increase the class major version on each release, but I ask that you do so sparingly (perhaps every other release at most?). [1] https://jdk.java.net/12/release-notes Regards, Andrew Guibert IBM - OpenLiberty / WebSphere Liberty development From joe.darcy at oracle.com Tue Feb 19 17:22:33 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 19 Feb 2019 09:22:33 -0800 Subject: JDK 12: RC feedback In-Reply-To: References: Message-ID: <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com> Hello, On 2/19/2019 9:03 AM, Andrew Guibert wrote: > Hi all, > > I am kicking the tires on the JDK 12 release candidate build, and I noticed two major pain points: > > 1) javac source/target 6 option is no longer supported > Looking through the release notes [1] I see no mention of this change. Is it part of some more generic policy that javac will only go back N-5 versions? Dropping source/target 6 specifically is not my primary concern, rather a more general concern of the cadence of the min compliance dropoff (JDK 9 dropped source/target 5 iirc). If this is the case I worry that by JDK 14 (about a year from now), we will no longer be able to compile down to source/target 8, which will still be a very popular runtime version in 1 years time (and still a supported version). There is a JEP giving a policy for retiring the -source/-target (and now --release) values: ??? JEP 182: Policy for Retiring javac -source and -target Options ??? http://openjdk.java.net/jeps/182 As noted in a comment on the issue, the policy has not be fully updated for the new release model: "Note that with the six month release cadence (http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html) being used starting with JDK 10, the chronical range covered by "one plus three back" would be much shortened. In due course, this policy will be updated accordingly, possibly taking into account LTS (long term support) releases and possibly offering a sparse set of values. For example, one possible policy would be to support the last two LTS release and each release after the most recent LTS, but not the releases between those two LTS releases. " https://bugs.openjdk.java.net/browse/JDK-8046172?focusedCommentId=14145783&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14145783 The possibility of removing -source/-target 6 from JDK 11 was discussed on this alias in May 2018: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001190.html In response to community feedback, the removal was deferred from JDK 11 and implemented in JDK 12. > > 2) The java.class.version has increased (again) The plan is to increase the class file version with each release. The class file version acts as an implicit way to denote the minimum JDK a jar file depends on. Cheers, -Joe From netbeans at post.cz Tue Feb 19 09:31:11 2019 From: netbeans at post.cz (netbeans at post.cz) Date: Tue, 19 Feb 2019 10:31:11 +0100 (CET) Subject: JMX Message-ID: <5L8.3VYTM.5Bqg4rlewje.1SQypV@seznam.cz> Dear Dev. ? 1) MXBeans ? I would like to recommend you simplify MXBeans as currently it is not so easy to use. ? E.g. If you need Map where even Serializable can be simple open types, so like dynamical for dirent key. ? As Map is internal type is hard to modify to properly be each such call converted to open type so I suggest to be possibly extend: ? - @MXBean by adapter that to that will be hand over calls to convert - or even as part of JMX.newMXBeanProxy - option to ignore such calls (as alternative to unsupported opertion in runtime) or even option on runtime auto conversion if returned value or parameter is possible on runtime recognized as simple open type. ? I think that there should be support for that. ? Additionally there is Date, but why it is not there new java.time objects. ? Or maybe MXBeans should be deprecated at all. ? 2) Maps vs MBean ? As you my know there is use e.g. what ever type parameter you choose there is get(Object) and similar to other methods. ? So if you would like to use it as MBean Proxy you need to create new interface extending e.g. Map (even target does it) and you have to explicitly create get(String). If you do not do it. From netbeans at post.cz Tue Feb 19 14:30:00 2019 From: netbeans at post.cz (netbeans at post.cz) Date: Tue, 19 Feb 2019 15:30:00 +0100 (CET) Subject: single source file program (java --source 11 Script.java) Message-ID: <6M6.3VYTV.5BDtwaAJN2h.1SR1Be@seznam.cz> Dear Devs." Suggestions: ? 1) shebang support so ignore first line with "#" ? 2) support to "<" and "|" so to read it from standard input ? 3) extends for two source file ???? ???? //file exec-cmd that it is anywhere on PATH ???? //cjava is just link to java command ???? #!/usr/bin/env cjava --source 11 --delegation cmd ???? public class GeneralCommand { ????????? ??????? onXY() ... ???? } ???? ???? //in working directory in file "cmd" ???? public class Command extends GeneralCommand { ??????? onXY() ... ???? } ? ???? > exec-cmd ???? ???? So after execution as usual compile GeneralCommand class ???? and then regarding to "--delegation" ???? it will be searching for "cmd" in working directory ???? if it finds match then compile it and instead of calling ???? main method of General Command call main method of ???? Command. ???? As this is was even previously easily realizable by jjs ???? via load() to have common share logic for any command, ???? but exact execution-logic or just written custom ???? handlers or configurations separated into more files. ???? So only installation-care is to place exec-cmd somewhere ???? PATH and creation link cjava to exact java and of ???? course write own exact command. And when you ???? extend exect-cmd you just replace it and everything ???? is working (so no need for merging and so on). ???? ???? On Microsoft Windows ???? > exec-cmd //exect-cmd.cmd | .bat ??????????? java --source 11 --delegation %CD%/cmd %~dp0/cmd-exec " From aguibert at us.ibm.com Tue Feb 19 18:05:12 2019 From: aguibert at us.ibm.com (Andrew Guibert) Date: Tue, 19 Feb 2019 18:05:12 +0000 Subject: JDK 12: RC feedback In-Reply-To: <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com> References: <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com>, Message-ID: Regarding JEP 182, is the plan to just retire -source/-target options but leave --release for older versions still in tact? For example, according to `javac --help` a targeted release of '6' should still be allowed (btw '12' is missing too): $ javac --help Usage: javac where possible options include: ... --release Compile for a specific VM version. Supported targets: 6, 7, 8, 9, 10, 11 However, --release 6 is rejected: $ bin/javac --release 6 A.java error: release version 6 not supported Usage: javac Regards, Andy -----Joe Darcy wrote: ----- To: Andrew Guibert , jdk-dev at openjdk.java.net From: Joe Darcy Date: 02/19/2019 11:26AM Subject: Re: JDK 12: RC feedback Hello, On 2/19/2019 9:03 AM, Andrew Guibert wrote: > Hi all, > > I am kicking the tires on the JDK 12 release candidate build, and I noticed two major pain points: > > 1) javac source/target 6 option is no longer supported > Looking through the release notes [1] I see no mention of this change. Is it part of some more generic policy that javac will only go back N-5 versions? Dropping source/target 6 specifically is not my primary concern, rather a more general concern of the cadence of the min compliance dropoff (JDK 9 dropped source/target 5 iirc). If this is the case I worry that by JDK 14 (about a year from now), we will no longer be able to compile down to source/target 8, which will still be a very popular runtime version in 1 years time (and still a supported version). There is a JEP giving a policy for retiring the -source/-target (and now --release) values: JEP 182: Policy for Retiring javac -source and -target Options https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_jeps_182&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=Q9CbjRFyrcQqPVwQlQ_NpoPS2Mm99G1JVf3uLvVH6cw&e= As noted in a comment on the issue, the policy has not be fully updated for the new release model: "Note that with the six month release cadence (https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_discuss_2017-2DSeptember_004281.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=8UwfBqjzEuUzJJekW56nhc8txX1CDw7M2GMW_7s_RSk&e=) being used starting with JDK 10, the chronical range covered by "one plus three back" would be much shortened. In due course, this policy will be updated accordingly, possibly taking into account LTS (long term support) releases and possibly offering a sparse set of values. For example, one possible policy would be to support the last two LTS release and each release after the most recent LTS, but not the releases between those two LTS releases. " https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8046172-3FfocusedCommentId-3D14145783-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-23comment-2D14145783&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=PJJbyVrjddkzjC_lOGMt1t9gCxHjcbv8R_HVLfmwfUY&e= The possibility of removing -source/-target 6 from JDK 11 was discussed on this alias in May 2018: https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_jdk-2Ddev_2018-2DMay_001190.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=VM0GL8fbf8ZML2UxPsGk7TTW7leazpscUpvEoKPtpZk&e= In response to community feedback, the removal was deferred from JDK 11 and implemented in JDK 12. > > 2) The java.class.version has increased (again) The plan is to increase the class file version with each release. The class file version acts as an implicit way to denote the minimum JDK a jar file depends on. Cheers, -Joe From jonathan.gibbons at oracle.com Tue Feb 19 18:33:56 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 19 Feb 2019 10:33:56 -0800 Subject: JDK 12: RC feedback In-Reply-To: References: <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com> Message-ID: <45a54bb6-1a2c-6c0c-a3f3-b87860016cc3@oracle.com> Hi, javac `--release` supports the same set as values as `-source`, `-target`. This is because it is effectively equivalent to setting those options and the platform classes. The issue with the supported targets in the command-line help needs to be investigated. -- Jon On 02/19/2019 10:05 AM, Andrew Guibert wrote: > Regarding JEP 182, is the plan to just retire -source/-target options but leave > --release for older versions still in tact? > > For example, according to `javac --help` a targeted release of '6' should still > be allowed (btw '12' is missing too): > $ javac --help > Usage: javac > where possible options include: > ... > --release > Compile for a specific VM version. Supported targets: 6, 7, 8, 9, 10, 11 > > However, --release 6 is rejected: > $ bin/javac --release 6 A.java > error: release version 6 not supported > Usage: javac > > Regards, > Andy > > -----Joe Darcy wrote: ----- > To: Andrew Guibert , jdk-dev at openjdk.java.net > From: Joe Darcy > Date: 02/19/2019 11:26AM > Subject: Re: JDK 12: RC feedback > > > Hello, > > On 2/19/2019 9:03 AM, Andrew Guibert wrote: >> Hi all, >> >> I am kicking the tires on the JDK 12 release candidate build, and I noticed two major pain points: >> >> 1) javac source/target 6 option is no longer supported >> Looking through the release notes [1] I see no mention of this change. Is it part of some more generic policy that javac will only go back N-5 versions? Dropping source/target 6 specifically is not my primary concern, rather a more general concern of the cadence of the min compliance dropoff (JDK 9 dropped source/target 5 iirc). If this is the case I worry that by JDK 14 (about a year from now), we will no longer be able to compile down to source/target 8, which will still be a very popular runtime version in 1 years time (and still a supported version). > There is a JEP giving a policy for retiring the -source/-target (and now > --release) values: > > JEP 182: Policy for Retiring javac -source and -target Options > https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_jeps_182&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=Q9CbjRFyrcQqPVwQlQ_NpoPS2Mm99G1JVf3uLvVH6cw&e= > > As noted in a comment on the issue, the policy has not be fully updated > for the new release model: > > "Note that with the six month release cadence > (https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_discuss_2017-2DSeptember_004281.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=8UwfBqjzEuUzJJekW56nhc8txX1CDw7M2GMW_7s_RSk&e=) > being used starting with JDK 10, the chronical range covered by "one > plus three back" would be much shortened. In due course, this policy > will be updated accordingly, possibly taking into account LTS (long term > support) releases and possibly offering a sparse set of values. For > example, one possible policy would be to support the last two LTS > release and each release after the most recent LTS, but not the releases > between those two LTS releases. " > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8046172-3FfocusedCommentId-3D14145783-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-23comment-2D14145783&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=PJJbyVrjddkzjC_lOGMt1t9gCxHjcbv8R_HVLfmwfUY&e= > > The possibility of removing -source/-target 6 from JDK 11 was discussed > on this alias in May 2018: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_jdk-2Ddev_2018-2DMay_001190.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=VM0GL8fbf8ZML2UxPsGk7TTW7leazpscUpvEoKPtpZk&e= > > In response to community feedback, the removal was deferred from JDK 11 > and implemented in JDK 12. > > >> >> 2) The java.class.version has increased (again) > > The plan is to increase the class file version with each release. The > class file version acts as an implicit way to denote the minimum JDK a > jar file depends on. > > Cheers, > > -Joe > > > From joe.darcy at oracle.com Tue Feb 19 18:37:55 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 19 Feb 2019 10:37:55 -0800 Subject: JDK 12: RC feedback In-Reply-To: References: <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com> Message-ID: <89f6a9af-223e-dfe8-118a-65433854b23b@oracle.com> Hello, On 2/19/2019 10:05 AM, Andrew Guibert wrote: > Regarding JEP 182, is the plan to just retire -source/-target options but leave > --release for older versions still in tact? No; the intention is that -source/-target and --release would all support the same set of arguments. > > For example, according to `javac --help` a targeted release of '6' should still > be allowed (btw '12' is missing too): > $ javac --help > Usage: javac > where possible options include: > ... > --release > Compile for a specific VM version. Supported targets: 6, 7, 8, 9, 10, 11 > > However, --release 6 is rejected: > $ bin/javac --release 6 A.java > error: release version 6 not supported > Usage: javac I downloaded the latest Linux JDK 12 build from http://jdk.java.net/12/ and "6" is not listed as a valid argument to those options: ? --release ??????? Compile for a specific release. Supported releases: 7, 8, 9, 10, 11, 12 ... ? --source , -source ??????? Provide source compatibility with specified release. Supported releases: 7, 8, 9, 10, 11, 12 ... ? --target , -target ??????? Generate class files for specific VM version. Supported versions: 7, 8, 9, 10, 11, 12 Cheers, -Joe > > Regards, > Andy > > -----Joe Darcy wrote: ----- > To: Andrew Guibert , jdk-dev at openjdk.java.net > From: Joe Darcy > Date: 02/19/2019 11:26AM > Subject: Re: JDK 12: RC feedback > > > Hello, > > On 2/19/2019 9:03 AM, Andrew Guibert wrote: >> Hi all, >> >> I am kicking the tires on the JDK 12 release candidate build, and I noticed two major pain points: >> >> 1) javac source/target 6 option is no longer supported >> Looking through the release notes [1] I see no mention of this change. Is it part of some more generic policy that javac will only go back N-5 versions? Dropping source/target 6 specifically is not my primary concern, rather a more general concern of the cadence of the min compliance dropoff (JDK 9 dropped source/target 5 iirc). If this is the case I worry that by JDK 14 (about a year from now), we will no longer be able to compile down to source/target 8, which will still be a very popular runtime version in 1 years time (and still a supported version). > There is a JEP giving a policy for retiring the -source/-target (and now > --release) values: > > JEP 182: Policy for Retiring javac -source and -target Options > https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_jeps_182&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=Q9CbjRFyrcQqPVwQlQ_NpoPS2Mm99G1JVf3uLvVH6cw&e= > > As noted in a comment on the issue, the policy has not be fully updated > for the new release model: > > "Note that with the six month release cadence > (https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_discuss_2017-2DSeptember_004281.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=8UwfBqjzEuUzJJekW56nhc8txX1CDw7M2GMW_7s_RSk&e=) > being used starting with JDK 10, the chronical range covered by "one > plus three back" would be much shortened. In due course, this policy > will be updated accordingly, possibly taking into account LTS (long term > support) releases and possibly offering a sparse set of values. For > example, one possible policy would be to support the last two LTS > release and each release after the most recent LTS, but not the releases > between those two LTS releases. " > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8046172-3FfocusedCommentId-3D14145783-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-23comment-2D14145783&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=PJJbyVrjddkzjC_lOGMt1t9gCxHjcbv8R_HVLfmwfUY&e= > > The possibility of removing -source/-target 6 from JDK 11 was discussed > on this alias in May 2018: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_jdk-2Ddev_2018-2DMay_001190.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=VM0GL8fbf8ZML2UxPsGk7TTW7leazpscUpvEoKPtpZk&e= > > In response to community feedback, the removal was deferred from JDK 11 > and implemented in JDK 12. > > >> >> 2) The java.class.version has increased (again) > > The plan is to increase the class file version with each release. The > class file version acts as an implicit way to denote the minimum JDK a > jar file depends on. > > Cheers, > > -Joe > > > From daniel.fuchs at oracle.com Tue Feb 19 18:54:18 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Feb 2019 18:54:18 +0000 Subject: JMX In-Reply-To: <5L8.3VYTM.5Bqg4rlewje.1SQypV@seznam.cz> References: <5L8.3VYTM.5Bqg4rlewje.1SQypV@seznam.cz> Message-ID: Hi, JMX related issues are mostly discussed on the serviceability-dev mailing list these days. On 19/02/2019 09:31, netbeans at post.cz wrote: > > Dear Dev. > > 1) MXBeans > > I would like to recommend you simplify MXBeans as currently it is not so > easy to use. > > E.g. If you need Map where even Serializable can be > simple open types, so like dynamical for dirent key. MXBeans are used to map model-specific interfaces to generic openmbeans types. If your model consists of a map with dynamic key value pairs - as opposed to an interface that has a number of specific getters - then MXBeans may not be what you should use. For instance, you can achieve what you describe by reverting to using an OpenMBean directly, and expose your map as a CompositeData instead. See: https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/management/package-summary.html https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/management/MXBean.html and https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/management/openmbean/package-summary.html [...] > Additionally there is Date, but why it is not there new java.time objects. JMX was added in Java 5. java.time in Java 8. Extending the set of open types supported by MXBeans would offer interesting challenges as to maintaining interoperability with applications running on previous version of the JVM. In other words: that might be hard. > Or maybe MXBeans should be deprecated at all. MXBeans work very well for their intended target usage. They do have their limitations, but so have other types of MBeans. It's a trade-off. You can read about the different types of MBeans here: https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/management/package-summary.html > 2) Maps vs MBean > > As you my know there is use e.g. what ever type parameter you choose there > is get(Object) and similar to other methods. > > So if you would like to use it as MBean Proxy you need to create new > interface extending e.g. Map (even target does it) and you > have to explicitly create get(String). > > If you do not do it. I am not sure I have understood all your concerns, but I believe OpenMBeans and CompositeData is what might correspond to your needs. best regards, -- daniel From aguibert at us.ibm.com Tue Feb 19 19:35:09 2019 From: aguibert at us.ibm.com (Andrew Guibert) Date: Tue, 19 Feb 2019 19:35:09 +0000 Subject: JDK 12: RC feedback In-Reply-To: <89f6a9af-223e-dfe8-118a-65433854b23b@oracle.com> References: <89f6a9af-223e-dfe8-118a-65433854b23b@oracle.com>, <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com> Message-ID: Thanks for the clarification on source/target vs. release. Regarding the supported options, I am using the macOS/x64 build in case that helps. $ bin/javac --version javac 12 $ bin/java --version openjdk 12 2019-03-19 OpenJDK Runtime Environment (build 12+32) OpenJDK 64-Bit Server VM (build 12+32, mixed mode, sharing) Looks like you have confirmed things are correct on Linux, so it may just be an issue on the Mac builds. Regards, Andy -----Joe Darcy wrote: ----- To: Andrew Guibert From: Joe Darcy Date: 02/19/2019 12:38PM Cc: jdk-dev at openjdk.java.net Subject: Re: JDK 12: RC feedback Hello, On 2/19/2019 10:05 AM, Andrew Guibert wrote: > Regarding JEP 182, is the plan to just retire -source/-target options but leave > --release for older versions still in tact? No; the intention is that -source/-target and --release would all support the same set of arguments. > > For example, according to `javac --help` a targeted release of '6' should still > be allowed (btw '12' is missing too): > $ javac --help > Usage: javac > where possible options include: > ... > --release > Compile for a specific VM version. Supported targets: 6, 7, 8, 9, 10, 11 > > However, --release 6 is rejected: > $ bin/javac --release 6 A.java > error: release version 6 not supported > Usage: javac I downloaded the latest Linux JDK 12 build from https://urldefense.proofpoint.com/v2/url?u=http-3A__jdk.java.net_12_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=38NMHM9XU9_seSzS2_0KJZ_y_M_bt87S2201seMv3Ts&s=qOAbIa12-WTJZ-opXyuRuGJT4UHjxQBzLN96qsbWp2s&e= and "6" is not listed as a valid argument to those options: --release Compile for a specific release. Supported releases: 7, 8, 9, 10, 11, 12 ... --source , -source Provide source compatibility with specified release. Supported releases: 7, 8, 9, 10, 11, 12 ... --target , -target Generate class files for specific VM version. Supported versions: 7, 8, 9, 10, 11, 12 Cheers, -Joe > > Regards, > Andy > > -----Joe Darcy wrote: ----- > To: Andrew Guibert , jdk-dev at openjdk.java.net > From: Joe Darcy > Date: 02/19/2019 11:26AM > Subject: Re: JDK 12: RC feedback > > > Hello, > > On 2/19/2019 9:03 AM, Andrew Guibert wrote: >> Hi all, >> >> I am kicking the tires on the JDK 12 release candidate build, and I noticed two major pain points: >> >> 1) javac source/target 6 option is no longer supported >> Looking through the release notes [1] I see no mention of this change. Is it part of some more generic policy that javac will only go back N-5 versions? Dropping source/target 6 specifically is not my primary concern, rather a more general concern of the cadence of the min compliance dropoff (JDK 9 dropped source/target 5 iirc). If this is the case I worry that by JDK 14 (about a year from now), we will no longer be able to compile down to source/target 8, which will still be a very popular runtime version in 1 years time (and still a supported version). > There is a JEP giving a policy for retiring the -source/-target (and now > --release) values: > > JEP 182: Policy for Retiring javac -source and -target Options > https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_jeps_182&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=Q9CbjRFyrcQqPVwQlQ_NpoPS2Mm99G1JVf3uLvVH6cw&e= > > As noted in a comment on the issue, the policy has not be fully updated > for the new release model: > > "Note that with the six month release cadence > (https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_discuss_2017-2DSeptember_004281.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=8UwfBqjzEuUzJJekW56nhc8txX1CDw7M2GMW_7s_RSk&e=) > being used starting with JDK 10, the chronical range covered by "one > plus three back" would be much shortened. In due course, this policy > will be updated accordingly, possibly taking into account LTS (long term > support) releases and possibly offering a sparse set of values. For > example, one possible policy would be to support the last two LTS > release and each release after the most recent LTS, but not the releases > between those two LTS releases. " > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8046172-3FfocusedCommentId-3D14145783-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-23comment-2D14145783&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=PJJbyVrjddkzjC_lOGMt1t9gCxHjcbv8R_HVLfmwfUY&e= > > The possibility of removing -source/-target 6 from JDK 11 was discussed > on this alias in May 2018: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_jdk-2Ddev_2018-2DMay_001190.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=VM0GL8fbf8ZML2UxPsGk7TTW7leazpscUpvEoKPtpZk&e= > > In response to community feedback, the removal was deferred from JDK 11 > and implemented in JDK 12. > > >> >> 2) The java.class.version has increased (again) > > The plan is to increase the class file version with each release. The > class file version acts as an implicit way to denote the minimum JDK a > jar file depends on. > > Cheers, > > -Joe > > > From jonathan.gibbons at oracle.com Tue Feb 19 19:47:32 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 19 Feb 2019 11:47:32 -0800 Subject: JDK 12: RC feedback In-Reply-To: References: <89f6a9af-223e-dfe8-118a-65433854b23b@oracle.com> <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com> Message-ID: <1965b3b3-6542-662b-75a0-c0c5adade547@oracle.com> Andrew, The macOS builds look OK to me: $ jdk-12.jdk/Contents/Home/bin/javac --help | grep source.*release | grep -v preview ? --source , -source ??????? Provide source compatibility with specified release. Supported releases: 7, 8, 9, 10, 11, 12 $ jdk-12.jdk/Contents/Home/bin/javac -version javac 12 $ jdk-12.jdk/Contents/Home/bin/java -version openjdk version "12" 2019-03-19 OpenJDK Runtime Environment (build 12+32) OpenJDK 64-Bit Server VM (build 12+32, mixed mode, sharing) -- Jon On 2/19/19 11:35 AM, Andrew Guibert wrote: > Thanks for the clarification on source/target vs. release. > > Regarding the supported options, I am using the macOS/x64 build in case that helps. > > $ bin/javac --version > javac 12 > > $ bin/java --version > openjdk 12 2019-03-19 > OpenJDK Runtime Environment (build 12+32) > OpenJDK 64-Bit Server VM (build 12+32, mixed mode, sharing) > > Looks like you have confirmed things are correct on Linux, so it may just be an > issue on the Mac builds. > > Regards, > Andy > > -----Joe Darcy wrote: ----- > To: Andrew Guibert > From: Joe Darcy > Date: 02/19/2019 12:38PM > Cc: jdk-dev at openjdk.java.net > Subject: Re: JDK 12: RC feedback > > > Hello, > > On 2/19/2019 10:05 AM, Andrew Guibert wrote: >> Regarding JEP 182, is the plan to just retire -source/-target options but leave >> --release for older versions still in tact? > > No; the intention is that -source/-target and --release would all > support the same set of arguments. > > >> For example, according to `javac --help` a targeted release of '6' should still >> be allowed (btw '12' is missing too): >> $ javac --help >> Usage: javac >> where possible options include: >> ... >> --release >> Compile for a specific VM version. Supported targets: 6, 7, 8, 9, 10, 11 >> >> However, --release 6 is rejected: >> $ bin/javac --release 6 A.java >> error: release version 6 not supported >> Usage: javac > I downloaded the latest Linux JDK 12 build from https://urldefense.proofpoint.com/v2/url?u=http-3A__jdk.java.net_12_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=38NMHM9XU9_seSzS2_0KJZ_y_M_bt87S2201seMv3Ts&s=qOAbIa12-WTJZ-opXyuRuGJT4UHjxQBzLN96qsbWp2s&e= > and "6" is not listed as a valid argument to those options: > > --release > Compile for a specific release. Supported releases: 7, 8, 9, > 10, 11, 12 > ... > --source , -source > Provide source compatibility with specified release. Supported > releases: 7, 8, 9, 10, 11, 12 > ... > --target , -target > Generate class files for specific VM version. Supported > versions: 7, 8, 9, 10, 11, 12 > > Cheers, > > -Joe > > >> Regards, >> Andy >> >> -----Joe Darcy wrote: ----- >> To: Andrew Guibert , jdk-dev at openjdk.java.net >> From: Joe Darcy >> Date: 02/19/2019 11:26AM >> Subject: Re: JDK 12: RC feedback >> >> >> Hello, >> >> On 2/19/2019 9:03 AM, Andrew Guibert wrote: >>> Hi all, >>> >>> I am kicking the tires on the JDK 12 release candidate build, and I noticed two major pain points: >>> >>> 1) javac source/target 6 option is no longer supported >>> Looking through the release notes [1] I see no mention of this change. Is it part of some more generic policy that javac will only go back N-5 versions? Dropping source/target 6 specifically is not my primary concern, rather a more general concern of the cadence of the min compliance dropoff (JDK 9 dropped source/target 5 iirc). If this is the case I worry that by JDK 14 (about a year from now), we will no longer be able to compile down to source/target 8, which will still be a very popular runtime version in 1 years time (and still a supported version). >> There is a JEP giving a policy for retiring the -source/-target (and now >> --release) values: >> >> JEP 182: Policy for Retiring javac -source and -target Options >> https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_jeps_182&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=Q9CbjRFyrcQqPVwQlQ_NpoPS2Mm99G1JVf3uLvVH6cw&e= >> >> As noted in a comment on the issue, the policy has not be fully updated >> for the new release model: >> >> "Note that with the six month release cadence >> (https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_discuss_2017-2DSeptember_004281.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=8UwfBqjzEuUzJJekW56nhc8txX1CDw7M2GMW_7s_RSk&e=) >> being used starting with JDK 10, the chronical range covered by "one >> plus three back" would be much shortened. In due course, this policy >> will be updated accordingly, possibly taking into account LTS (long term >> support) releases and possibly offering a sparse set of values. For >> example, one possible policy would be to support the last two LTS >> release and each release after the most recent LTS, but not the releases >> between those two LTS releases. " >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8046172-3FfocusedCommentId-3D14145783-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-23comment-2D14145783&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=PJJbyVrjddkzjC_lOGMt1t9gCxHjcbv8R_HVLfmwfUY&e= >> >> The possibility of removing -source/-target 6 from JDK 11 was discussed >> on this alias in May 2018: >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_jdk-2Ddev_2018-2DMay_001190.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1YPTKCwyTI-UsomOHDHVT2KCzhgAyrNIOkzMBdrxRsY&m=YtYjdyMRDxKWeDLxGIcIsDY-dbzr0d7cH5SmpTVO36E&s=VM0GL8fbf8ZML2UxPsGk7TTW7leazpscUpvEoKPtpZk&e= >> >> In response to community feedback, the removal was deferred from JDK 11 >> and implemented in JDK 12. >> >> >>> >>> 2) The java.class.version has increased (again) >> The plan is to increase the class file version with each release. The >> class file version acts as an implicit way to denote the minimum JDK a >> jar file depends on. >> >> Cheers, >> >> -Joe >> >> >> > From Alan.Bateman at oracle.com Tue Feb 19 19:55:00 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2019 19:55:00 +0000 Subject: JDK 12: RC feedback In-Reply-To: References: <89f6a9af-223e-dfe8-118a-65433854b23b@oracle.com> <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com> Message-ID: <98dbb6e6-8e43-6736-a6b3-13b74d4a4339@oracle.com> On 19/02/2019 19:35, Andrew Guibert wrote: > Thanks for the clarification on source/target vs. release. > > Regarding the supported options, I am using the macOS/x64 build in case that helps. > > $ bin/javac --version > javac 12 > > $ bin/java --version > openjdk 12 2019-03-19 > OpenJDK Runtime Environment (build 12+32) > OpenJDK 64-Bit Server VM (build 12+32, mixed mode, sharing) > > Looks like you have confirmed things are correct on Linux, so it may just be an > issue on the Mac builds. > I checked the macOS build on jdk.java.net/12 and the javac -help output includes: ? --release ??????? Compile for a specific release. Supported releases: 7, 8, 9, 10, 11, 12 ? --source , -source ??????? Provide source compatibility with specified release. Supported releases: 7, 8, 9, 10, 11, 12 ? --target , -target ??????? Generate class files for specific VM version. Supported versions: 7, 8, 9, 10, 11, 12 The `java -version` output is slightly different to your output so maybe you have something else. -Alan From alex.buckley at oracle.com Tue Feb 19 20:23:18 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 19 Feb 2019 12:23:18 -0800 Subject: JDK 12: RC feedback In-Reply-To: References: Message-ID: <5C6C65B6.1070505@oracle.com> On 2/19/2019 9:03 AM, Andrew Guibert wrote: > 2) The java.class.version has increased (again) Looking through the > release notes, I don't see any major bytecode improvements that > signal to me that the class file major version needed to be > incremented. Is this being incremented as part of some automatic > policy? Yes. The class file format's major version is tied to the Java SE Platform version, which is incremented every six months. I recall some discussion of the policy of tying versions, but do not have it to hand. As to the forthcoming release: the Java SE 12 Platform standardizes the concept of _preview features_ [1], and this concept has consequences for the abstract Java Virtual Machine [2]. Namely, it is necessary to introduce a new major version because the semantics of the minor version are changed going forward. Alex [1] http://cr.openjdk.java.net/~iris/se/12/latestSpec/index.html#Preview-features [2] http://cr.openjdk.java.net/~iris/se/12/latestSpec/java-se-12-annex-3.html -- see JVMS12 ?4.1 From joe.darcy at oracle.com Tue Feb 19 21:30:20 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 19 Feb 2019 13:30:20 -0800 Subject: JDK 12: RC feedback In-Reply-To: <98dbb6e6-8e43-6736-a6b3-13b74d4a4339@oracle.com> References: <89f6a9af-223e-dfe8-118a-65433854b23b@oracle.com> <6b5a64db-a1e2-120b-fe98-30359b090595@oracle.com> <98dbb6e6-8e43-6736-a6b3-13b74d4a4339@oracle.com> Message-ID: Also note that the JDK includes a regression tests that explicitly checks that retired source versions are not supported: ??? test/langtools/tools/javac/versions/Versions.java and the test has been passing on macos and all other platforms. -Joe On 2/19/2019 11:55 AM, Alan Bateman wrote: > On 19/02/2019 19:35, Andrew Guibert wrote: >> Thanks for the clarification on source/target vs. release. >> >> Regarding the supported options, I am using the macOS/x64 build in >> case that helps. >> >> $ bin/javac --version >> javac 12 >> >> $ bin/java --version >> openjdk 12 2019-03-19 >> OpenJDK Runtime Environment (build 12+32) >> OpenJDK 64-Bit Server VM (build 12+32, mixed mode, sharing) >> >> Looks like you have confirmed things are correct on Linux, so it may >> just be an >> issue on the Mac builds. >> > I checked the macOS build on jdk.java.net/12 and the javac -help > output includes: > > ? --release > ??????? Compile for a specific release. Supported releases: 7, 8, 9, > 10, 11, 12 > ? --source , -source > ??????? Provide source compatibility with specified release. Supported > releases: 7, 8, 9, 10, 11, 12 > ? --target , -target > ??????? Generate class files for specific VM version. Supported > versions: 7, 8, 9, 10, 11, 12 > > The `java -version` output is slightly different to your output so > maybe you have something else. > > -Alan From igor.ignatyev at oracle.com Wed Feb 20 06:23:18 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 22:23:18 -0800 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 Message-ID: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219417/webrev.00/index.html > 34 lines changed: 3 ins; 0 del; 31 mod; Hi all, could you please review this small fix which bumps jtreg requiredVersion to 4.2-b14 in all the test suites and disables smart action args in jdk and hotspot test suite till corresponding RFEs[1,2] are fixed (this is needed b/c jtreg enables smart action args by default when requiredVersion>=4.2-b14)? JBS: https://bugs.openjdk.java.net/browse/JDK-8219417 webrev: http://cr.openjdk.java.net/~iignatyev//8219417/webrev.00/index.html [1] https://bugs.openjdk.java.net/browse/JDK-8219408 [2] https://bugs.openjdk.java.net/browse/JDK-8219140 Thanks, -- Igor From david.holmes at oracle.com Wed Feb 20 06:48:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2019 16:48:00 +1000 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> Message-ID: Hi Igor, On 20/02/2019 4:23 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219417/webrev.00/index.html >> 34 lines changed: 3 ins; 0 del; 31 mod; > > Hi all, > > could you please review this small fix which bumps jtreg requiredVersion to 4.2-b14 in all the test suites and disables smart action args in jdk and hotspot test suite till corresponding RFEs[1,2] are fixed (this is needed b/c jtreg enables smart action args by default when requiredVersion>=4.2-b14)? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219417 > webrev: http://cr.openjdk.java.net/~iignatyev//8219417/webrev.00/index.html test/jdk/sanity/client/TEST.ROOT.template test/jdk/sanity/client/TEST.properties Note the above still refer to version 4.1 not 4.2 so I do not think you want to make any change there. That said only the locations where tests will use the new TEST.ROOT property need to have their required version updated to 4.2 b14. And that seems to be restricted to hotspot so far. I would suggest that rather than having this bug bump the requiredVersion everywhere, it should only be bumped within bugs that are adding changes that require the new minimum version ie just do it as part of 8219158. Thanks, David > [1] https://bugs.openjdk.java.net/browse/JDK-8219408 > [2] https://bugs.openjdk.java.net/browse/JDK-8219140 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Wed Feb 20 06:59:21 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 22:59:21 -0800 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> Message-ID: fair enough, I'm withdrawing this RFR then. -- Igor > On Feb 19, 2019, at 10:48 PM, David Holmes wrote: > > Hi Igor, > > On 20/02/2019 4:23 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219417/webrev.00/index.html >>> 34 lines changed: 3 ins; 0 del; 31 mod; >> Hi all, >> could you please review this small fix which bumps jtreg requiredVersion to 4.2-b14 in all the test suites and disables smart action args in jdk and hotspot test suite till corresponding RFEs[1,2] are fixed (this is needed b/c jtreg enables smart action args by default when requiredVersion>=4.2-b14)? >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219417 >> webrev: http://cr.openjdk.java.net/~iignatyev//8219417/webrev.00/index.html > > test/jdk/sanity/client/TEST.ROOT.template > test/jdk/sanity/client/TEST.properties > > Note the above still refer to version 4.1 not 4.2 so I do not think you want to make any change there. > > That said only the locations where tests will use the new TEST.ROOT property need to have their required version updated to 4.2 b14. And that seems to be restricted to hotspot so far. > > I would suggest that rather than having this bug bump the requiredVersion everywhere, it should only be bumped within bugs that are adding changes that require the new minimum version ie just do it as part of 8219158. > > Thanks, > David > >> [1] https://bugs.openjdk.java.net/browse/JDK-8219408 >> [2] https://bugs.openjdk.java.net/browse/JDK-8219140 >> Thanks, >> -- Igor From Alan.Bateman at oracle.com Wed Feb 20 07:25:28 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 07:25:28 +0000 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> Message-ID: <30ff3e33-868f-b57e-5bbb-c69353488d5f@oracle.com> On 20/02/2019 06:48, David Holmes wrote: > : > > I would suggest that rather than having this bug bump the > requiredVersion everywhere, it should only be bumped within bugs that > are adding changes that require the new minimum version ie just do it > as part of 8219158. > > I think it's important that everyone is using the same minium version of jtreg when running the tests. If some people are using b14 (by way of using jib) then they may end up pushing test changes that fail for the those of us that run jtreg directly. So I think it is better to just bump the required version everywhere, after socialization of course as it takes a bit of time to build or find a pre-built jtreg. -Alan From lovejavaee888 at gmail.com Wed Feb 20 07:56:09 2019 From: lovejavaee888 at gmail.com (Soft Jason) Date: Wed, 20 Feb 2019 15:56:09 +0800 Subject: submissions Message-ID: submissions From david.holmes at oracle.com Wed Feb 20 08:44:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2019 18:44:01 +1000 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: <30ff3e33-868f-b57e-5bbb-c69353488d5f@oracle.com> References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> <30ff3e33-868f-b57e-5bbb-c69353488d5f@oracle.com> Message-ID: <334a580d-ee17-0cad-c2cc-37c77986d23b@oracle.com> On 20/02/2019 5:25 pm, Alan Bateman wrote: > On 20/02/2019 06:48, David Holmes wrote: >> : >> >> I would suggest that rather than having this bug bump the >> requiredVersion everywhere, it should only be bumped within bugs that >> are adding changes that require the new minimum version ie just do it >> as part of 8219158. >> >> > I think it's important that everyone is using the same minium version of > jtreg when running the tests. If some people are using b14 (by way of > using jib) then they may end up pushing test changes that fail for the > those of us that run jtreg directly. So I think it is better to just > bump the required version everywhere, after socialization of course as > it takes a bit of time to build or find a pre-built jtreg. I don't really care either way, but that's not what has been happening to-date. Client area in particular still seems to be requiring only 4.1. David > -Alan From Alan.Bateman at oracle.com Wed Feb 20 09:10:09 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 09:10:09 +0000 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: <334a580d-ee17-0cad-c2cc-37c77986d23b@oracle.com> References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> <30ff3e33-868f-b57e-5bbb-c69353488d5f@oracle.com> <334a580d-ee17-0cad-c2cc-37c77986d23b@oracle.com> Message-ID: On 20/02/2019 08:44, David Holmes wrote: > > I don't really care either way, but that's not what has been happening > to-date. Client area in particular still seems to be requiring only 4.1. It can be tricky to track down issues that stem from using different versions of the test runner so I think we should fix that and have both infrastructure and local testing use the same min version if possible. The tests for client-libs are under test/jdk where the TEST.ROOT has 4.2 b13 as the required version. There are a sanity tests that gatekeepers use to run SwingSet demos as sanity tests - Phil might be able to saw more about those and whether those tests care about the jtreg version or not. -Alan From aph at redhat.com Thu Feb 21 10:38:40 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Feb 2019 10:38:40 +0000 Subject: Result: new JDK Committer: Ningsheng Jian (njian) In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: <30d8b81c-4f01-5382-12b5-70f5fbc2f02c@redhat.com> Voting for Ningsheng Jian [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Andrew Haley [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002538.html -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jai.forums2013 at gmail.com Thu Feb 21 14:35:25 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 21 Feb 2019 20:05:25 +0530 Subject: Is it a feature abuse to introduce default methods in new interfaces? Message-ID: I have been trying to find some authoritative answer on when _not_ to use default methods on interfaces (a feature introduced in Java 8). The official documentation in Java, about this feature, talks about the motivation[1] behind introducing this feature and explains how _existing_ interfaces can be changed to add default methods without breaking binary compatibility: "Default methods enable you to add new functionality to the interfaces of your libraries and ensure binary compatibility with code written for older versions of those interfaces." This and some other docs don't mention whether it's an accepted practice or abuse of default methods feature, when dealing with new interfaces. Is it fine to introduce new interfaces with default methods? I have tried searching the mailing list archives to see if it's discussed previously but my search terms haven't found anything relevant. Any previous authoritative answer, similar to Stuart Mark's reply on stackoverflow (on a different topic) about Optional usage[2], is also good enough. [1] https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html [2] https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 -Jaikiran From daniel.fuchs at oracle.com Thu Feb 21 14:54:41 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 21 Feb 2019 14:54:41 +0000 Subject: Is it a feature abuse to introduce default methods in new interfaces? In-Reply-To: References: Message-ID: <50d78e39-407a-4f1c-5107-8e6f8b8ab1f3@oracle.com> Hi Jaikiran, I don't think this is an abuse, and I'd say that the decision on whether to provide a default implementation for a new interface probably depends on how well you estimate that the default implementation will match what concrete subclass would have to implement. Even if that's not an authoritative answer ;-) I don't know if that's representative but Stream.Builder for instance, came with a default add( ) method: https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.Builder.html best regards, -- daniel On 21/02/2019 14:35, Jaikiran Pai wrote: > I have been trying to find some authoritative answer on when _not_ to > use default methods on interfaces (a feature introduced in Java 8). The > official documentation in Java, about this feature, talks about the > motivation[1] behind introducing this feature and explains how > _existing_ interfaces can be changed to add default methods without > breaking binary compatibility: > > "Default methods enable you to add new functionality to the interfaces > of your libraries and ensure binary compatibility with code written for > older versions of those interfaces." > > This and some other docs don't mention whether it's an accepted practice > or abuse of default methods feature, when dealing with new interfaces. > Is it fine to introduce new interfaces with default methods? I have > tried searching the mailing list archives to see if it's discussed > previously but my search terms haven't found anything relevant. Any > previous authoritative answer, similar to Stuart Mark's reply on > stackoverflow (on a different topic) about Optional usage[2], is also > good enough. > > [1] https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html > > [2] > https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 > > -Jaikiran > > From jonathan.gibbons at oracle.com Thu Feb 21 17:08:10 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 21 Feb 2019 09:08:10 -0800 Subject: jtreg 4.2-b14 Message-ID: <12528e93-df6e-6bb9-3d45-82c067b18c0b@oracle.com> Some of you may have noticed that a new version of jtreg is available (jtreg4.2-b14) and is now being required in various JDK test suites. There are two note-worthy features in this update. 1. Action tags (like `@compile` or `@run main`) now support variable substitution in command arguments, using the syntax `${name}`. The set of names is the same as that for the `@requires` tag.? The feature is enabled by default for test suites that specify the use of jtreg4.2-b14 or later. 2. Support is now available for using Windows Subsystem for Linux (WSL) as an alternative to Cygwin to run shell tests on Windows 10. This complements the recent new ability to build OpenJDK using WSL. Note that shell tests will also need to be updated in order to use this feature: a discussion of the issues and some recommendations have been posted on the OpenJDK website: https://openjdk.java.net/jtreg/shellTests.html Many of the updates have been changes to the documentation, such as the jtreg FAQ: https://openjdk.java.net/jtreg/faq.html A full list of changes can be found here: http://hg.openjdk.java.net/code-tools/jtreg/search/?rev=%22jtreg4.2-b13%22%3A%22jtreg4.2-b14%22&revcount=80 -- Jon From igor.ignatyev at oracle.com Thu Feb 21 22:07:05 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Feb 2019 14:07:05 -0800 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> <30ff3e33-868f-b57e-5bbb-c69353488d5f@oracle.com> <334a580d-ee17-0cad-c2cc-37c77986d23b@oracle.com> Message-ID: David, I tend to agree w/ Alan here, I'd also prefer us to have required version bumped in all test suites together as it decreases differences in observed test behavior and simplifies test failure analyses. w/ that being, test/jdk/sanity/client/ is a different beast, it's not a real test suite, it's unclear if TEST.ROOT.template is ever used, and requiredVersion is commented out in TEST.properties. I've filed 8219552 [1] and assigned it to Muneer(cc'ed), who runs and maintains these tests, to deal w/ these files separately. [2] is the webrev w/ TEST.ROOT files updated in all the test suites. unless there are other comments, suggestions, objections, I'd like to process w/ reviewing of this patch. Side note: all (two) well-known publishers of jtreg builds have been notified about the new version and have already created and published binaries at their usual location. [1] https://bugs.openjdk.java.net/browse/JDK-8219552 [2] http://cr.openjdk.java.net/~iignatyev//8219417/webrev.01/index.html Thanks, -- Igor > On Feb 20, 2019, at 1:10 AM, Alan Bateman wrote: > > On 20/02/2019 08:44, David Holmes wrote: >> >> On 20/02/2019 5:25 pm, Alan Bateman wrote: >>> I think it's important that everyone is using the same minium version of jtreg when running the tests. If some people are using b14 (by way of using jib) then they may end up pushing test changes that fail for the those of us that run jtreg directly. So I think it is better to just bump the required version everywhere, after socialization of course as it takes a bit of time to build or find a pre-built jtreg. >> I don't really care either way, but that's not what has been happening to-date. Client area in particular still seems to be requiring only 4.1. > It can be tricky to track down issues that stem from using different versions of the test runner so I think we should fix that and have both infrastructure and local testing use the same min version if possible. The tests for client-libs are under test/jdk where the TEST.ROOT has 4.2 b13 as the required version. There are a sanity tests that gatekeepers use to run SwingSet demos as sanity tests - Phil might be able to saw more about those and whether those tests care about the jtreg version or not. > > -Alan From joe.darcy at oracle.com Fri Feb 22 01:15:33 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 21 Feb 2019 17:15:33 -0800 Subject: Is it a feature abuse to introduce default methods in new interfaces? In-Reply-To: <50d78e39-407a-4f1c-5107-8e6f8b8ab1f3@oracle.com> References: <50d78e39-407a-4f1c-5107-8e6f8b8ab1f3@oracle.com> Message-ID: <5C6F4D35.6090605@oracle.com> Hello, FWIW, I wouldn't necessarily consider default methods on a new interface an abuse. The existence of default methods on interfaces changes the trade-offs between having an interface paired with an abstract helper implementation vs an interface with default methods. HTH, -Joe On 2/21/2019 6:54 AM, Daniel Fuchs wrote: > Hi Jaikiran, > > I don't think this is an abuse, and I'd say that the decision on > whether to provide a default implementation for a new interface > probably depends on how well you estimate that the default > implementation will match what concrete subclass would have to > implement. Even if that's not an authoritative answer ;-) > > I don't know if that's representative but Stream.Builder for > instance, came with a default add( ) method: > > https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.Builder.html > > > best regards, > > -- daniel > > On 21/02/2019 14:35, Jaikiran Pai wrote: >> I have been trying to find some authoritative answer on when _not_ to >> use default methods on interfaces (a feature introduced in Java 8). The >> official documentation in Java, about this feature, talks about the >> motivation[1] behind introducing this feature and explains how >> _existing_ interfaces can be changed to add default methods without >> breaking binary compatibility: >> >> "Default methods enable you to add new functionality to the interfaces >> of your libraries and ensure binary compatibility with code written for >> older versions of those interfaces." >> >> This and some other docs don't mention whether it's an accepted practice >> or abuse of default methods feature, when dealing with new interfaces. >> Is it fine to introduce new interfaces with default methods? I have >> tried searching the mailing list archives to see if it's discussed >> previously but my search terms haven't found anything relevant. Any >> previous authoritative answer, similar to Stuart Mark's reply on >> stackoverflow (on a different topic) about Optional usage[2], is also >> good enough. >> >> [1] >> https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html >> >> [2] >> https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 >> >> >> -Jaikiran >> >> > From susmaryosep80 at gmail.com Fri Feb 22 02:51:50 2019 From: susmaryosep80 at gmail.com (Mary Rose de Vega) Date: Fri, 22 Feb 2019 10:51:50 +0800 Subject: jdk-dev Digest, Vol 17, Issue 21 In-Reply-To: References: Message-ID: what else do you want me to do there it said close fro development they still investigating i wonder what those research team are doing this time why they getting that long to find me to its funny to think of them to be sitting and let me do their job On Fri, Feb 22, 2019 at 9:16 AM wrote: > Send jdk-dev mailing list submissions to > jdk-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.openjdk.java.net/mailman/listinfo/jdk-dev > or, via email, send a message with subject or body 'help' to > jdk-dev-request at openjdk.java.net > > You can reach the person managing the list at > jdk-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of jdk-dev digest..." > > > Today's Topics: > > 1. Is it a feature abuse to introduce default methods in new > interfaces? (Jaikiran Pai) > 2. Re: Is it a feature abuse to introduce default methods in new > interfaces? (Daniel Fuchs) > 3. jtreg 4.2-b14 (Jonathan Gibbons) > 4. Re: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 > (Igor Ignatyev) > 5. Re: Is it a feature abuse to introduce default methods in new > interfaces? (Joseph D. Darcy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Feb 2019 20:05:25 +0530 > From: Jaikiran Pai > To: jdk-dev at openjdk.java.net > Subject: Is it a feature abuse to introduce default methods in new > interfaces? > Message-ID: > Content-Type: text/plain; charset=utf-8 > > I have been trying to find some authoritative answer on when _not_ to > use default methods on interfaces (a feature introduced in Java 8). The > official documentation in Java, about this feature, talks about the > motivation[1] behind introducing this feature and explains how > _existing_ interfaces can be changed to add default methods without > breaking binary compatibility: > > "Default methods enable you to add new functionality to the interfaces > of your libraries and ensure binary compatibility with code written for > older versions of those interfaces." > > This and some other docs don't mention whether it's an accepted practice > or abuse of default methods feature, when dealing with new interfaces. > Is it fine to introduce new interfaces with default methods? I have > tried searching the mailing list archives to see if it's discussed > previously but my search terms haven't found anything relevant. Any > previous authoritative answer, similar to Stuart Mark's reply on > stackoverflow (on a different topic) about Optional usage[2], is also > good enough. > > [1] https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html > > [2] > > https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 > > -Jaikiran > > > > > ------------------------------ > > Message: 2 > Date: Thu, 21 Feb 2019 14:54:41 +0000 > From: Daniel Fuchs > To: Jaikiran Pai , jdk-dev at openjdk.java.net > Subject: Re: Is it a feature abuse to introduce default methods in new > interfaces? > Message-ID: <50d78e39-407a-4f1c-5107-8e6f8b8ab1f3 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Jaikiran, > > I don't think this is an abuse, and I'd say that the decision on > whether to provide a default implementation for a new interface > probably depends on how well you estimate that the default > implementation will match what concrete subclass would have to > implement. Even if that's not an authoritative answer ;-) > > I don't know if that's representative but Stream.Builder for > instance, came with a default add( ) method: > > > https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.Builder.html > > best regards, > > -- daniel > > On 21/02/2019 14:35, Jaikiran Pai wrote: > > I have been trying to find some authoritative answer on when _not_ to > > use default methods on interfaces (a feature introduced in Java 8). The > > official documentation in Java, about this feature, talks about the > > motivation[1] behind introducing this feature and explains how > > _existing_ interfaces can be changed to add default methods without > > breaking binary compatibility: > > > > "Default methods enable you to add new functionality to the interfaces > > of your libraries and ensure binary compatibility with code written for > > older versions of those interfaces." > > > > This and some other docs don't mention whether it's an accepted practice > > or abuse of default methods feature, when dealing with new interfaces. > > Is it fine to introduce new interfaces with default methods? I have > > tried searching the mailing list archives to see if it's discussed > > previously but my search terms haven't found anything relevant. Any > > previous authoritative answer, similar to Stuart Mark's reply on > > stackoverflow (on a different topic) about Optional usage[2], is also > > good enough. > > > > [1] > https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html > > > > [2] > > > https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 > > > > -Jaikiran > > > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Feb 2019 09:08:10 -0800 > From: Jonathan Gibbons > To: "jdk-dev at openjdk.java.net" , > "jtreg-use at openjdk.java.net" > Subject: jtreg 4.2-b14 > Message-ID: <12528e93-df6e-6bb9-3d45-82c067b18c0b at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Some of you may have noticed that a new version of jtreg is available > (jtreg4.2-b14) and is now being required in various JDK test suites. > > There are two note-worthy features in this update. > > 1. Action tags (like `@compile` or `@run main`) now support variable > substitution in command arguments, using the syntax `${name}`. The > set of names is the same as that for the `@requires` tag.? The > feature is enabled by default for test suites that specify the use > of jtreg4.2-b14 or later. > > 2. Support is now available for using Windows Subsystem for Linux (WSL) > as an alternative to Cygwin to run shell tests on Windows 10. This > complements the recent new ability to build OpenJDK using WSL. Note > that shell tests will also need to be updated in order to use this > feature: a discussion of the issues and some recommendations have > been posted on the OpenJDK website: > https://openjdk.java.net/jtreg/shellTests.html > > Many of the updates have been changes to the documentation, such as the > jtreg FAQ: > https://openjdk.java.net/jtreg/faq.html > > A full list of changes can be found here: > > http://hg.openjdk.java.net/code-tools/jtreg/search/?rev=%22jtreg4.2-b13%22%3A%22jtreg4.2-b14%22&revcount=80 > > -- Jon > > > > ------------------------------ > > Message: 4 > Date: Thu, 21 Feb 2019 14:07:05 -0800 > From: Igor Ignatyev > To: David Holmes > Cc: jdk-dev > Subject: Re: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 > Message-ID: > Content-Type: text/plain; charset=us-ascii > > David, > > I tend to agree w/ Alan here, I'd also prefer us to have required version > bumped in all test suites together as it decreases differences in observed > test behavior and simplifies test failure analyses. w/ that being, > test/jdk/sanity/client/ is a different beast, it's not a real test suite, > it's unclear if TEST.ROOT.template is ever used, and requiredVersion is > commented out in TEST.properties. I've filed 8219552 [1] and assigned it to > Muneer(cc'ed), who runs and maintains these tests, to deal w/ these files > separately. > > [2] is the webrev w/ TEST.ROOT files updated in all the test suites. > unless there are other comments, suggestions, objections, I'd like to > process w/ reviewing of this patch. > > Side note: all (two) well-known publishers of jtreg builds have been > notified about the new version and have already created and published > binaries at their usual location. > > [1] https://bugs.openjdk.java.net/browse/JDK-8219552 < > https://bugs.openjdk.java.net/browse/JDK-8219552> > [2] http://cr.openjdk.java.net/~iignatyev//8219417/webrev.01/index.html < > http://cr.openjdk.java.net/~iignatyev//8219417/webrev.01/index.html> > > Thanks, > -- Igor > > > On Feb 20, 2019, at 1:10 AM, Alan Bateman > wrote: > > > > On 20/02/2019 08:44, David Holmes wrote: > >> > >> On 20/02/2019 5:25 pm, Alan Bateman wrote: > >>> I think it's important that everyone is using the same minium version > of jtreg when running the tests. If some people are using b14 (by way of > using jib) then they may end up pushing test changes that fail for the > those of us that run jtreg directly. So I think it is better to just bump > the required version everywhere, after socialization of course as it takes > a bit of time to build or find a pre-built jtreg. > >> I don't really care either way, but that's not what has been happening > to-date. Client area in particular still seems to be requiring only 4.1. > > It can be tricky to track down issues that stem from using different > versions of the test runner so I think we should fix that and have both > infrastructure and local testing use the same min version if possible. The > tests for client-libs are under test/jdk where the TEST.ROOT has 4.2 b13 as > the required version. There are a sanity tests that gatekeepers use to run > SwingSet demos as sanity tests - Phil might be able to saw more about those > and whether those tests care about the jtreg version or not. > > > > -Alan > > > > ------------------------------ > > Message: 5 > Date: Thu, 21 Feb 2019 17:15:33 -0800 > From: "Joseph D. Darcy" > To: Daniel Fuchs , Jaikiran Pai > , jdk-dev at openjdk.java.net > Subject: Re: Is it a feature abuse to introduce default methods in new > interfaces? > Message-ID: <5C6F4D35.6090605 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hello, > > FWIW, I wouldn't necessarily consider default methods on a new interface > an abuse. The existence of default methods on interfaces changes the > trade-offs between having an interface paired with an abstract helper > implementation vs an interface with default methods. > > HTH, > > -Joe > > > On 2/21/2019 6:54 AM, Daniel Fuchs wrote: > > Hi Jaikiran, > > > > I don't think this is an abuse, and I'd say that the decision on > > whether to provide a default implementation for a new interface > > probably depends on how well you estimate that the default > > implementation will match what concrete subclass would have to > > implement. Even if that's not an authoritative answer ;-) > > > > I don't know if that's representative but Stream.Builder for > > instance, came with a default add( ) method: > > > > > https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.Builder.html > > > > > > best regards, > > > > -- daniel > > > > On 21/02/2019 14:35, Jaikiran Pai wrote: > >> I have been trying to find some authoritative answer on when _not_ to > >> use default methods on interfaces (a feature introduced in Java 8). The > >> official documentation in Java, about this feature, talks about the > >> motivation[1] behind introducing this feature and explains how > >> _existing_ interfaces can be changed to add default methods without > >> breaking binary compatibility: > >> > >> "Default methods enable you to add new functionality to the interfaces > >> of your libraries and ensure binary compatibility with code written for > >> older versions of those interfaces." > >> > >> This and some other docs don't mention whether it's an accepted practice > >> or abuse of default methods feature, when dealing with new interfaces. > >> Is it fine to introduce new interfaces with default methods? I have > >> tried searching the mailing list archives to see if it's discussed > >> previously but my search terms haven't found anything relevant. Any > >> previous authoritative answer, similar to Stuart Mark's reply on > >> stackoverflow (on a different topic) about Optional usage[2], is also > >> good enough. > >> > >> [1] > >> https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html > >> > >> [2] > >> > https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 > >> > >> > >> -Jaikiran > >> > >> > > > > > > End of jdk-dev Digest, Vol 17, Issue 21 > *************************************** > -- Hot Momma From david.holmes at oracle.com Fri Feb 22 03:53:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2019 13:53:16 +1000 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> <30ff3e33-868f-b57e-5bbb-c69353488d5f@oracle.com> <334a580d-ee17-0cad-c2cc-37c77986d23b@oracle.com> Message-ID: <5ca4ecb4-bc7f-faa9-7f79-7382270fa9e8@oracle.com> On 22/02/2019 8:07 am, Igor Ignatyev wrote: > David, > > I tend to agree w/ Alan here, I'd also prefer us to have?required > version bumped in all test suites together as it decreases differences > in observed test behavior and simplifies test failure analyses. w/ that > being, test/jdk/sanity/client/ is a different beast, it's not a real > test suite, it's unclear if TEST.ROOT.template is ever used, and > requiredVersion is commented out in TEST.properties. I've filed 8219552 > [1] and assigned it to Muneer(cc'ed), who runs and maintains these > tests, to deal w/ these files separately. Okay. If that's the new policy that's fine. > [2] is the webrev w/ TEST.ROOT files updated in all the test suites. > unless there are other comments, suggestions, objections, I'd like to > process w/ reviewing of this patch. > > Side note: all (two) well-known publishers of jtreg builds have been > notified about the new version and have already created and published > binaries at their usual location. > > [1] https://bugs.openjdk.java.net/browse/JDK-8219552 > [2] http://cr.openjdk.java.net/~iignatyev//8219417/webrev.01/index.html Changes looks good. Thanks, David > Thanks, > -- Igor > >> On Feb 20, 2019, at 1:10 AM, Alan Bateman > > wrote: >> >> On 20/02/2019 08:44, David Holmes wrote: >>> >>> On 20/02/2019 5:25 pm, Alan Bateman wrote: >>>> I think it's important that everyone is using the same minium >>>> version of jtreg when running the tests. If some people are using >>>> b14 (by way of using jib) then they may end up pushing test changes >>>> that fail for the those of us that run jtreg directly. So I think it >>>> is better to just bump the required version everywhere, after >>>> socialization of course as it takes a bit of time to build or find a >>>> pre-built jtreg. >>> I don't really care either way, but that's not what has been >>> happening to-date. Client area in particular still seems to be >>> requiring only 4.1. >> It can be tricky to track down issues that stem from using different >> versions of the test runner so I think we should fix that and have >> both infrastructure and local testing use the same min version if >> possible. The tests for client-libs are under test/jdk where the >> TEST.ROOT has 4.2 b13 as the required version. There are a sanity >> tests that gatekeepers use to run SwingSet demos as sanity tests - >> Phil might be able to saw more about those and whether those tests >> care about the jtreg version or not. >> >> -Alan > From Alan.Bateman at oracle.com Fri Feb 22 17:00:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Feb 2019 17:00:54 +0000 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: <5ca4ecb4-bc7f-faa9-7f79-7382270fa9e8@oracle.com> References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> <30ff3e33-868f-b57e-5bbb-c69353488d5f@oracle.com> <334a580d-ee17-0cad-c2cc-37c77986d23b@oracle.com> <5ca4ecb4-bc7f-faa9-7f79-7382270fa9e8@oracle.com> Message-ID: <06bc521f-5dcf-769c-83df-8b83a136c88f@oracle.com> On 22/02/2019 03:53, David Holmes wrote: > On 22/02/2019 8:07 am, Igor Ignatyev wrote: >> David, >> >> I tend to agree w/ Alan here, I'd also prefer us to have?required >> version bumped in all test suites together as it decreases >> differences in observed test behavior and simplifies test failure >> analyses. w/ that being, test/jdk/sanity/client/ is a different >> beast, it's not a real test suite, it's unclear if TEST.ROOT.template >> is ever used, and requiredVersion is commented out in >> TEST.properties. I've filed 8219552 [1] and assigned it to >> Muneer(cc'ed), who runs and maintains these tests, to deal w/ these >> files separately. > > Okay. If that's the new policy that's fine. The changes look good to me too. -Alan From igor.ignatyev at oracle.com Fri Feb 22 17:48:28 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 22 Feb 2019 09:48:28 -0800 Subject: RFR(S) : 8219417 : bump jtreg requiredVersion to b14 In-Reply-To: <06bc521f-5dcf-769c-83df-8b83a136c88f@oracle.com> References: <1B797B0F-BED1-447D-8D17-9F0CDE05F7A1@oracle.com> <30ff3e33-868f-b57e-5bbb-c69353488d5f@oracle.com> <334a580d-ee17-0cad-c2cc-37c77986d23b@oracle.com> <5ca4ecb4-bc7f-faa9-7f79-7382270fa9e8@oracle.com> <06bc521f-5dcf-769c-83df-8b83a136c88f@oracle.com> Message-ID: <035D792A-E8CA-4ADA-ACF0-ED14DCB65386@oracle.com> Alan/David, thanks for your review. pushed. -- Igor > On Feb 22, 2019, at 9:00 AM, Alan Bateman wrote: > > On 22/02/2019 03:53, David Holmes wrote: >> On 22/02/2019 8:07 am, Igor Ignatyev wrote: >>> David, >>> >>> I tend to agree w/ Alan here, I'd also prefer us to have required version bumped in all test suites together as it decreases differences in observed test behavior and simplifies test failure analyses. w/ that being, test/jdk/sanity/client/ is a different beast, it's not a real test suite, it's unclear if TEST.ROOT.template is ever used, and requiredVersion is commented out in TEST.properties. I've filed 8219552 [1] and assigned it to Muneer(cc'ed), who runs and maintains these tests, to deal w/ these files separately. >> >> Okay. If that's the new policy that's fine. > The changes look good to me too. > > -Alan > > From talden at gmail.com Sat Feb 23 09:28:28 2019 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Sat, 23 Feb 2019 22:28:28 +1300 Subject: Is it a feature abuse to introduce default methods in new interfaces? In-Reply-To: <5C6F4D35.6090605@oracle.com> References: <50d78e39-407a-4f1c-5107-8e6f8b8ab1f3@oracle.com> <5C6F4D35.6090605@oracle.com> Message-ID: We've used default methods in Spring-Data repositories where the obvious implementation of a method is really just a preprocessing of arguments to express the result in terms of the other interface methods (which are dynamically generated) - eg two methods differing only by their date-range-boundary exclusivity. -- Aaron Scott-Boddendijk On Fri, Feb 22, 2019 at 2:16 PM Joseph D. Darcy wrote: > Hello, > > FWIW, I wouldn't necessarily consider default methods on a new interface > an abuse. The existence of default methods on interfaces changes the > trade-offs between having an interface paired with an abstract helper > implementation vs an interface with default methods. > > HTH, > > -Joe > > > On 2/21/2019 6:54 AM, Daniel Fuchs wrote: > > Hi Jaikiran, > > > > I don't think this is an abuse, and I'd say that the decision on > > whether to provide a default implementation for a new interface > > probably depends on how well you estimate that the default > > implementation will match what concrete subclass would have to > > implement. Even if that's not an authoritative answer ;-) > > > > I don't know if that's representative but Stream.Builder for > > instance, came with a default add( ) method: > > > > > https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.Builder.html > > > > > > best regards, > > > > -- daniel > > > > On 21/02/2019 14:35, Jaikiran Pai wrote: > >> I have been trying to find some authoritative answer on when _not_ to > >> use default methods on interfaces (a feature introduced in Java 8). The > >> official documentation in Java, about this feature, talks about the > >> motivation[1] behind introducing this feature and explains how > >> _existing_ interfaces can be changed to add default methods without > >> breaking binary compatibility: > >> > >> "Default methods enable you to add new functionality to the interfaces > >> of your libraries and ensure binary compatibility with code written for > >> older versions of those interfaces." > >> > >> This and some other docs don't mention whether it's an accepted practice > >> or abuse of default methods feature, when dealing with new interfaces. > >> Is it fine to introduce new interfaces with default methods? I have > >> tried searching the mailing list archives to see if it's discussed > >> previously but my search terms haven't found anything relevant. Any > >> previous authoritative answer, similar to Stuart Mark's reply on > >> stackoverflow (on a different topic) about Optional usage[2], is also > >> good enough. > >> > >> [1] > >> https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html > >> > >> [2] > >> > https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 > >> > >> > >> -Jaikiran > >> > >> > > > > From brian.goetz at oracle.com Sat Feb 23 14:00:16 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 23 Feb 2019 09:00:16 -0500 Subject: Is it a feature abuse to introduce default methods in new interfaces? In-Reply-To: References: Message-ID: <50369E7D-23CD-4163-8BE3-54C733F95690@oracle.com> Here?s an authoritative answer: it depends :) More seriously, while the proximate motivation for adding default methods to Java was to ease the evolution of already-published APIs, there are plenty of good reasons to use it in new code as well. (However, there are also some possible abuses.) I addressed a similar question in this post (relevant excerpts quoted below): https://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 ? A key design goal was that, from the perspective of the client of an interface, default methods should be indistinguishable from "regular" interface methods. The default-ness of a method, therefore, is only interesting to the designer and implementor of the interface. Here are some use cases that are well within the design goals: ? Interface evolution. Here, we are adding a new method to an existing interface, which has a sensible default implementation in terms of existing methods on that interface. An example would be adding the forEach method to Collection, where the default implementation is written in terms of the iterator() method. ? "Optional" methods. Here, the designer of an interface is saying "Implementors need not implement this method if they are willing to live with the limitations in functionality that entails". For example, Iterator.remove was given a default which throws UnsupportedOperationException; since the vast majority of implementations of Iterator have this behavior anyway, the default makes this method essentially optional. (If the behavior from AbstractCollection were expressed as defaults on Collection, we might do the same for the mutative methods.) ? Convenience methods. These are methods that are strictly for convenience, again generally implemented in terms of non-default methods on the class. (Usually these methods are similar to existing non-default methods, but have fewer arguments.) ? Combinators. These are compositional methods that instantiate new instances of the interface based on the current instance. For example, the methods Predicate.and() or Comparator.thenComparing() are examples of combinators. If you provide a default implementation, you should also provide some specification for the default (in the JDK, we use the @implSpec javadoc tag for this) to aid implementors in understanding whether they want to override the method or not. Some defaults, like convenience methods and combinators, are almost never overridden; others, like optional methods, are often overridden. You need to provide enough specification (not just documentation) about what the default promises to do, so the implementor can make a sensible decision about whether they need to override it. > On Feb 21, 2019, at 9:35 AM, Jaikiran Pai wrote: > > I have been trying to find some authoritative answer on when _not_ to > use default methods on interfaces (a feature introduced in Java 8). The > official documentation in Java, about this feature, talks about the > motivation[1] behind introducing this feature and explains how > _existing_ interfaces can be changed to add default methods without > breaking binary compatibility: > > "Default methods enable you to add new functionality to the interfaces > of your libraries and ensure binary compatibility with code written for > older versions of those interfaces." > > This and some other docs don't mention whether it's an accepted practice > or abuse of default methods feature, when dealing with new interfaces. > Is it fine to introduce new interfaces with default methods? I have > tried searching the mailing list archives to see if it's discussed > previously but my search terms haven't found anything relevant. Any > previous authoritative answer, similar to Stuart Mark's reply on > stackoverflow (on a different topic) about Optional usage[2], is also > good enough. > > [1] https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html > > [2] > https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 > > -Jaikiran > > From jai.forums2013 at gmail.com Mon Feb 25 14:15:43 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 25 Feb 2019 19:45:43 +0530 Subject: Is it a feature abuse to introduce default methods in new interfaces? In-Reply-To: <50369E7D-23CD-4163-8BE3-54C733F95690@oracle.com> References: <50369E7D-23CD-4163-8BE3-54C733F95690@oracle.com> Message-ID: <3cb21cd0-2f59-1eee-9418-f4594486b5ca@gmail.com> Brian, Daniel, Joe and Aaron, thank you for responding and providing the examples and rationale behind these usages. These answers are authoritative enough for me :) -Jaikiran On 23/02/19 7:30 PM, Brian Goetz wrote: > Here?s an authoritative answer: it depends :) > > More seriously, while the proximate motivation for adding default methods to Java was to ease the evolution of already-published APIs, there are plenty of good reasons to use it in new code as well. (However, there are also some possible abuses.) > > I addressed a similar question in this post (relevant excerpts quoted below): > > https://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 > > ? > > A key design goal was that, from the perspective of the client of an interface, default methods should be indistinguishable from "regular" interface methods. The default-ness of a method, therefore, is only interesting to the designer and implementor of the interface. > > Here are some use cases that are well within the design goals: > > ? Interface evolution. Here, we are adding a new method to an existing interface, which has a sensible default implementation in terms of existing methods on that interface. An example would be adding the forEach method to Collection, where the default implementation is written in terms of the iterator() method. > > ? "Optional" methods. Here, the designer of an interface is saying "Implementors need not implement this method if they are willing to live with the limitations in functionality that entails". For example, Iterator.remove was given a default which throws UnsupportedOperationException; since the vast majority of implementations of Iterator have this behavior anyway, the default makes this method essentially optional. (If the behavior from AbstractCollection were expressed as defaults on Collection, we might do the same for the mutative methods.) > > ? Convenience methods. These are methods that are strictly for convenience, again generally implemented in terms of non-default methods on the class. (Usually these methods are similar to existing non-default methods, but have fewer arguments.) > > ? Combinators. These are compositional methods that instantiate new instances of the interface based on the current instance. For example, the methods Predicate.and() or Comparator.thenComparing() are examples of combinators. > > If you provide a default implementation, you should also provide some specification for the default (in the JDK, we use the @implSpec javadoc tag for this) to aid implementors in understanding whether they want to override the method or not. Some defaults, like convenience methods and combinators, are almost never overridden; others, like optional methods, are often overridden. You need to provide enough specification (not just documentation) about what the default promises to do, so the implementor can make a sensible decision about whether they need to override it. > > >> On Feb 21, 2019, at 9:35 AM, Jaikiran Pai wrote: >> >> I have been trying to find some authoritative answer on when _not_ to >> use default methods on interfaces (a feature introduced in Java 8). The >> official documentation in Java, about this feature, talks about the >> motivation[1] behind introducing this feature and explains how >> _existing_ interfaces can be changed to add default methods without >> breaking binary compatibility: >> >> "Default methods enable you to add new functionality to the interfaces >> of your libraries and ensure binary compatibility with code written for >> older versions of those interfaces." >> >> This and some other docs don't mention whether it's an accepted practice >> or abuse of default methods feature, when dealing with new interfaces. >> Is it fine to introduce new interfaces with default methods? I have >> tried searching the mailing list archives to see if it's discussed >> previously but my search terms haven't found anything relevant. Any >> previous authoritative answer, similar to Stuart Mark's reply on >> stackoverflow (on a different topic) about Optional usage[2], is also >> good enough. >> >> [1] https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html >> >> [2] >> https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794 >> >> -Jaikiran >> >> From mark.reinhold at oracle.com Mon Feb 25 17:50:20 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 25 Feb 2019 09:50:20 -0800 Subject: JDK 12: Second Release Candidate Message-ID: <20190225095020.974099084@eggemoggin.niobe.net> We fixed one bug after build 32 [1], so build 33 is our second JDK 12 Release Candidate. Binaries available here, as usual: https://jdk.java.net/12 - Mark [1] https://bugs.openjdk.java.net/browse/JDK-8219151 From stanislav.smirnov at oracle.com Mon Feb 25 21:32:34 2019 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Mon, 25 Feb 2019 16:32:34 -0500 Subject: jdk-submit branches processing is temporarily down Message-ID: <672F0C59-FFB7-4DAC-9556-0425FC6E12A4@oracle.com> Hello, Due to an internal server outage the jdk-submit branches processing is temporarily down. You can still push your changes, but no build&test will be triggered. Sorry for the inconvenience. We will let you know as soon as the system is back online. Best regards, Stanislav Smirnov From stanislav.smirnov at oracle.com Mon Feb 25 22:37:36 2019 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Mon, 25 Feb 2019 17:37:36 -0500 Subject: [RESOLVED] Re: jdk-submit branches processing is temporarily down In-Reply-To: <672F0C59-FFB7-4DAC-9556-0425FC6E12A4@oracle.com> References: <672F0C59-FFB7-4DAC-9556-0425FC6E12A4@oracle.com> Message-ID: Hello, system is back online. Best regards, Stanislav Smirnov > On Feb 25, 2019, at 4:32 PM, Stanislav Smirnov wrote: > > Hello, > > Due to an internal server outage the jdk-submit branches processing is temporarily down. > You can still push your changes, but no build&test will be triggered. > Sorry for the inconvenience. > We will let you know as soon as the system is back online. > > Best regards, > Stanislav Smirnov From coleen.phillimore at oracle.com Tue Feb 26 21:44:48 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 26 Feb 2019 16:44:48 -0500 Subject: Result: New JDK Committer: Patricio Chilano Mateo Message-ID: <09f28691-f5f4-8f72-1287-e1d6221b1eef@oracle.com> Voting for Patricio Chilano Mateo (pchilanomate) [1] is now closed. Yes: 27 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Coleen [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002586.html From dkwakkel at gmail.com Thu Feb 28 12:13:57 2019 From: dkwakkel at gmail.com (Donald Kwakkel) Date: Thu, 28 Feb 2019 13:13:57 +0100 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs Message-ID: Hi All, This is my first contribution to openjdk, so hope to learn a lot! I created a fix + tests for https://bugs.openjdk.java.net/browse/JDK-8218268. Now the manifest classpath is behaving the same in javac and java for file paths. This fixes: 1. The Java Compiler treats the entries as URLs, according to spec: https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute 2. The behavior of the JVM ClassLoader and the Java Compiler is equal (for file urls) 3. The behavior is backwards compatible (it was broken in javac 9-13) The current patch contains a System.err because I do not know how to (debug) log information in the jdk. Hope someone can explain how to do this the right way. See below the patch. Looking forward for a sponsor to adopt/work on my change! Kind Regards, Donald Kwakkel diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java @@ -26,7 +26,10 @@ package com.sun.tools.javac.file; import java.io.IOException; -import java.nio.file.FileSystems; +import java.net.MalformedURLException; +import java.net.URI; +import java.net.URISyntaxException; +import java.net.URL; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.spi.FileSystemProvider; @@ -90,7 +93,6 @@ } public List getJarClassPath(Path file) throws IOException { - Path parent = file.getParent(); try (JarFile jarFile = new JarFile(file.toFile())) { Manifest man = jarFile.getManifest(); if (man == null) @@ -100,22 +102,27 @@ if (attr == null) return Collections.emptyList(); - String path = attr.getValue(Attributes.Name.CLASS_PATH); - if (path == null) + String classpath = attr.getValue(Attributes.Name.CLASS_PATH); + if (classpath == null) return Collections.emptyList(); - List list = new ArrayList<>(); + // TODO: Must use the same code as jdk.internal.loader.URLClassPath.JarLoader.parseClassPath(base, path) + StringTokenizer st = new StringTokenizer(classpath); + List paths = new ArrayList<>(st.countTokens()); + while (st.hasMoreTokens()) { + String path = st.nextToken(); + try { + // Use getCanonicalFile just as jdk.internal.loader.URLClassPath.toFileURL + URL base = file.toFile().getCanonicalFile().toURI().toURL(); + URI uri = new URL(base, path).toURI(); - for (StringTokenizer st = new StringTokenizer(path); - st.hasMoreTokens(); ) { - String elt = st.nextToken(); - Path f = FileSystems.getDefault().getPath(elt); - if (!f.isAbsolute() && parent != null) - f = parent.resolve(f).toAbsolutePath(); - list.add(f); + // Should return uri, see comment on com.sun.tools.javac.file.Locations.SearchPath.addJarClassPath + paths.add(Path.of(uri)); + } catch (MalformedURLException | URISyntaxException e) { + System.err.println("Class-Path entry: \"" + path + "\" ignored in JAR file \"" + file + "\": " + e.getMessage()); + } } - - return list; + return paths; } } diff --git a/test/langtools/tools/javac/Paths/UrlClassPath.sh b/test/langtools/tools/javac/Paths/UrlClassPath.sh new file mode 100755 --- /dev/null +++ b/test/langtools/tools/javac/Paths/UrlClassPath.sh @@ -0,0 +1,112 @@ +#!/bin/sh +# +# Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved. +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# This code is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License version 2 only, as +# published by the Free Software Foundation. +# +# This code is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# version 2 for more details (a copy is included in the LICENSE file that +# accompanied this code). +# +# You should have received a copy of the GNU General Public License version +# 2 along with this work; if not, write to the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA +# or visit www.oracle.com if you need additional information or have any +# questions. +# + +# @test +# @bug 8218268 +# @summary Test handling of urls (with spaces) in the Class-Path attribute in jar file manifests +# @author Donald Kwakkel +# +# @run shell UrlClassPath.sh + +# To run this test manually, simply do ./UrlClassPath.sh + +. ${TESTSRC-.}/Util.sh + +set -u + +Cleanup() { + Sys rm -rf "x y" z Hello.java Hello.class Main.java Main.class MANIFEST.MF hellocp.jar +} + +Cleanup +Sys mkdir "x y" + +#---------------------------------------------------------------- +# Create mutually referential jar files +#---------------------------------------------------------------- +cat >Hello.java <Main.java < References: Message-ID: On 28/02/2019 12:13, Donald Kwakkel wrote: > Hi All, > > This is my first contribution to openjdk, so hope to learn a lot! > > I created a fix + tests for https://bugs.openjdk.java.net/browse/JDK-8218268. > Now the manifest classpath is behaving the same in javac and java for > file paths. > > This fixes: > 1. The Java Compiler treats the entries as URLs, according to spec: > https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute > 2. The behavior of the JVM ClassLoader and the Java Compiler is equal > (for file urls) > The compiler-dev mailing list is the best place to discuss changes to javac. However in this case you are going into a topic with a lot of sad history and where there is ongoing work to get the JAR file specification and the runtime support aligned [1][2]. So I think include the core-libs-dev list in the discussion to understand the changes there and how javac might be updated to align with that. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8217215 [2] https://bugs.openjdk.java.net/browse/JDK-8216401 From jonathan.gibbons at oracle.com Thu Feb 28 15:39:19 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 28 Feb 2019 07:39:19 -0800 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: Message-ID: <8de947ec-971c-19b8-077a-b7512de0f98d@oracle.com> On 2/28/19 5:05 AM, Alan Bateman wrote: > On 28/02/2019 12:13, Donald Kwakkel wrote: >> Hi All, >> >> This is my first contribution to openjdk, so hope to learn a lot! >> >> I created a fix + tests for >> https://bugs.openjdk.java.net/browse/JDK-8218268. >> Now the manifest classpath is behaving the same in javac and java for >> file paths. >> >> This fixes: >> 1. The Java Compiler treats the entries as URLs, according to spec: >> https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute >> >> 2. The behavior of the JVM ClassLoader and the Java Compiler is equal >> (for file urls) >> > The compiler-dev mailing list is the best place to discuss changes to > javac. However in this case you are going into a topic with a lot of > sad history and where there is ongoing work to get the JAR file > specification and the runtime support aligned [1][2]. So I think > include the core-libs-dev list in the discussion to understand the > changes there and how javac might be updated to align with that. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8217215 > [2] https://bugs.openjdk.java.net/browse/JDK-8216401 In addition to Alan's comments, I note that although you provided a test (which is good), you wrote it as a shell test (which is not so good.) Depending on how this work may proceed, it would be better to replace the test with a Java test, perhaps using the test/langtools toolbox classes, which were specifically written for this sort of use. However, I strongly recommend that we sort out the spec issues first, before working on any changes to the test. -- Jon