From Roger.Riggs at Oracle.com Fri Jan 2 15:25:46 2015 From: Roger.Riggs at Oracle.com (Roger) Date: Fri, 02 Jan 2015 10:25:46 -0500 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <54A6B87A.9040506@Oracle.com> Vote: Yes On 12/25/2014 4:17 AM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. From david.holmes at oracle.com Mon Jan 5 00:23:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 05 Jan 2015 10:23:12 +1000 Subject: Result: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <54A9D970.7000008@oracle.com> Voting for Yasumasa Suenaga [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. David Holmes [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-December/001757.html From david.holmes at oracle.com Mon Jan 5 01:03:05 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 05 Jan 2015 11:03:05 +1000 Subject: Review request: Add barrier set kind for G1 throughput barrier In-Reply-To: <54A304E8.6000508@oracle.com> References: <54A194A2.7040009@oracle.com> <54A2E57E.10902@oracle.com> <54A304E8.6000508@oracle.com> Message-ID: <54A9E2C9.4000608@oracle.com> On 31/12/2014 6:02 AM, Joseph Provino wrote: > Jon, you are right about the bug id being incorrect. > > I think to completely fix the problem described in the real bug report > I also have to add a protected destructor to barrierSet.hpp. > > I'll submit to jprt then send another webrev with the right bug id. Also note that hotspot reviews go on the appropriate hotspot team mailing list (or the general hotspot-dev) not the jdk9-dev alias. David > thanks. > > joe > > PS I'm planning to fix https://bugs.openjdk.java.net/browse/JDK-8067191 > next. > > > On 12/30/2014 12:48 PM, Jon Masamitsu wrote: >> Joe, >> >> Change looks good as long as the bug for this change >> is really >> >> https://bugs.openjdk.java.net/browse/JDK-8064947 >> >> Or maybe the webrev link is not right? >> >> Jon >> >> On 12/29/2014 09:51 AM, Joseph Provino wrote: >>> Can I get reviews for this very small change? I also need a sponsor >>> to push the change. >>> >>> Bug report is here: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8067191 >>> >>> Webrev is here: >>> >>> http://cr.openjdk.java.net/~jprovino/8067191/webrev.00 >>> >>> Testing: jprt >> > From joseph.provino at oracle.com Mon Jan 5 14:50:27 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Mon, 05 Jan 2015 09:50:27 -0500 Subject: Review request: Add barrier set kind for G1 throughput barrier In-Reply-To: <54A2E57E.10902@oracle.com> References: <54A194A2.7040009@oracle.com> <54A2E57E.10902@oracle.com> Message-ID: <54AAA4B3.9000302@oracle.com> Here's an updated webrev with the proper bug id: http://cr.openjdk.java.net/~jprovino/8064947/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8064947 joe On 12/30/2014 12:48 PM, Jon Masamitsu wrote: > Joe, > > Change looks good as long as the bug for this change > is really > > https://bugs.openjdk.java.net/browse/JDK-8064947 > > Or maybe the webrev link is not right? > > Jon > > On 12/29/2014 09:51 AM, Joseph Provino wrote: >> Can I get reviews for this very small change? I also need a sponsor >> to push the change. >> >> Bug report is here: >> >> https://bugs.openjdk.java.net/browse/JDK-8067191 >> >> Webrev is here: >> >> http://cr.openjdk.java.net/~jprovino/8067191/webrev.00 >> >> Testing: jprt > From brian.goetz at oracle.com Mon Jan 5 21:20:18 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 05 Jan 2015 16:20:18 -0500 Subject: JVM struct types In-Reply-To: References: Message-ID: <54AB0012.4010908@oracle.com> See http://cr.openjdk.java.net/~jrose/values/values-0.html for our current thinking on this. Replies to valhalla-dev at openjdk. On 12/30/2014 2:53 AM, Nils Jonsson wrote: > Hi everyone, > > I like the way how .NET handles managed to native interaction via struct > like data types. This is a feature I am missing in the JVM. Even if I like > the JVM more than .NET this is somewhat struggling with me. I'd like to > contribute to the OpenJDK project and implement a similar feature in the > JVM. > > What I am missing is how and where to start. Can somebody give me some > guidance? > > Thanks in advance, > Nils Jonsson > From lana.steuck at oracle.com Wed Jan 7 22:02:27 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 7 Jan 2015 14:02:27 -0800 (PST) Subject: jdk9-b45: dev Message-ID: <201501072202.t07M2Qm4013336@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/3dd628fde208 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/3c2bbeda038a http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/73bbdcf236b2 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9acaa4f57b0b http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/e529374fbe52 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/0dab3e848229 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5dc8184af1e2 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/9e3f2bed80c0 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8067889 core-libs 4 pack200 tests fail on mac since jdk became modular JDK-8068347 core-libs Add java/lang/ClassLoader/deadlock/GetResource.java to ProblemList.txt JDK-8068338 core-libs Better message about incompatible zlib in Deflater.init JDK-8064463 core-libs BigDecimal should populate NumberFormatException message JDK-8066834 core-libs tools/pack200/CommandLineTests.java does not conform ProblemList.txt s JDK-8028357 core-svc Unnecessary allocation in AliasFileParser JDK-8067438 hotspot Add test to verify minimal heap size JDK-8067972 hotspot Bring changes made to WhiteBox.java in 8047290 to that file new locati JDK-8067865 hotspot Changes 8066780/8066782 broke the non-PCH build JDK-8067823 hotspot CheckCompileThresholdScaling.java throws RuntimeException JDK-8067655 hotspot Clean up G1 remembered set oop iteration JDK-8067469 hotspot G1 ignores AlwaysPreTouch JDK-8067499 hotspot G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCT JDK-8054892 hotspot Improve compiler's CLI tests error reporting JDK-8059575 hotspot JEP-JDK-8043304: Test task: Tiered Compilation level transition tests JDK-8066433 hotspot Move Whitebox test library to top level repository JDK-8060025 hotspot Object copy time regressions after JDK-8031323 and JDK-8057536 JDK-8066473 hotspot Port timeout utils from jdk test library into hotspot JDK-8066827 hotspot Remove ReferenceProcessor::clean_up_discovered_references() JDK-8067337 hotspot Remove Whitebox API from hotspot repository JDK-8061611 hotspot Remove deprecated command line flags JDK-8065279 hotspot Remove testlibrary_tests from compact profile in jtreg JDK-8028595 hotspot WhiteBox API for stress testing of TieredCompilation JDK-8067231 hotspot Zero builds fails after JDK-6898462 JDK-8067647 hotspot [TESTBUG] compiler/rangechecks/TestRangeCheckSmearing.java uses wrong JDK-8068036 hotspot assert(is_available(index)) failed in G1 cset JDK-8067338 hotspot compiler/debug/TraceIterativeGVN.java segfaults JDK-8067873 hotspot gc/TestSmallHeap.java does not compile JDK-8067985 hotspot merging hs-comp to hs blocked by some tests not updated in 8054892 JDK-8066964 hotspot ppc64: argument and return type profiling, fix problem with popframe JDK-8067211 hotspot rewrite Utils::fileAsString JDK-8066085 other-libs Need a sanity test for rmic -iiop JDK-8049021 security-libs Add smartcardio tests with APDU buffer JDK-8039921 security-libs SHA1WithDSA with key > 1024 bits not working From albert.noll at oracle.com Thu Jan 8 06:10:22 2015 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 08 Jan 2015 07:10:22 +0100 Subject: CFV: New JDK 9 Committer: Zoltan Majo Message-ID: <54AE1F4E.6040409@oracle.com> I hereby nominate Zoltan Majo to JDK9 Committer. Zoltan is a member of the Hotspot compiler team since 6 months. During the past 6 months, Zoltan worked on various parts of Hotspot, including the interpreter, the compilers, and the code cache. Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 changesets. Votes are due by January 22, 2015. Only current JDK9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Albert [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote [3] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 From albert.noll at oracle.com Thu Jan 8 06:11:44 2015 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 08 Jan 2015 07:11:44 +0100 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54AE1FA0.3010608@oracle.com> Vote: yes Best, Albert On 01/08/2015 07:10 AM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has > 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From bengt.rutisson at oracle.com Thu Jan 8 07:12:41 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 8 Jan 2015 08:12:41 +0100 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <446B470D-74F1-433F-A2F8-DBB0E52BBFBE@oracle.com> Vote: yes Bengt > 8 jan 2015 kl. 07:10 skrev Albert Noll : > > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From volker.simonis at gmail.com Thu Jan 8 08:12:15 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 8 Jan 2015 09:12:15 +0100 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: Vote: yes Regards, Volker On Thu, Jan 8, 2015 at 7:10 AM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 > changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From roland.westrelin at oracle.com Thu Jan 8 08:14:44 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 8 Jan 2015 09:14:44 +0100 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: Vote: yes Roland. > On Jan 8, 2015, at 7:10 AM, Albert Noll wrote: > > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From stefan.karlsson at oracle.com Thu Jan 8 08:59:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 08 Jan 2015 09:59:08 +0100 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54AE46DC.4020704@oracle.com> Vote: yes StefanK On 2015-01-08 07:10, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has > 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From tobias.hartmann at oracle.com Thu Jan 8 09:00:10 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 08 Jan 2015 10:00:10 +0100 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54AE471A.70908@oracle.com> Vote: yes Best, Tobias On 08.01.2015 07:10, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, including > the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From stefan.johansson at oracle.com Thu Jan 8 09:13:35 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 08 Jan 2015 10:13:35 +0100 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54AE4A3F.2070002@oracle.com> Vote: yes Stefan J On 2015-01-08 07:10, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has > 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From coleen.phillimore at oracle.com Thu Jan 8 13:48:33 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 08 Jan 2015 08:48:33 -0500 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54AE8AB1.1010506@oracle.com> Vote: yes On 1/8/15, 1:10 AM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has > 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From vladimir.kozlov at oracle.com Thu Jan 8 16:55:54 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Jan 2015 08:55:54 -0800 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54AEB69A.2080304@oracle.com> Vote: yes On 1/7/15 10:10 PM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, including the interpreter, the compilers, and the > code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to > this mailing list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From John.Coomes at oracle.com Thu Jan 8 17:04:36 2015 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 8 Jan 2015 09:04:36 -0800 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <21678.47268.235637.525148@mykonos.us.oracle.com> Vote: yes -John From david.r.chase at oracle.com Thu Jan 8 18:38:50 2015 From: david.r.chase at oracle.com (David Chase) Date: Thu, 8 Jan 2015 13:38:50 -0500 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: Vote: yes David On 2015-01-08, at 1:10 AM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From mark.reinhold at oracle.com Thu Jan 8 21:53:14 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 08 Jan 2015 13:53:14 -0800 Subject: JEP proposed to target JDK 9 (2015/1/8) Message-ID: <20150108135314.799811@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 217: Annotations Pipeline 2.0 http://openjdk.java.net/jeps/217 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 22:00 UTC next Thursday, 15 January, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From dean.long at oracle.com Thu Jan 8 22:14:51 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 08 Jan 2015 14:14:51 -0800 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54AF015B.10308@oracle.com> Vote: yes dl On 1/7/2015 10:10 PM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has > 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From david.lloyd at redhat.com Fri Jan 9 02:05:31 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 08 Jan 2015 20:05:31 -0600 Subject: JEP proposed to target JDK 9 (2015/1/8) In-Reply-To: <20150108135314.799811@eggemoggin.niobe.net> References: <20150108135314.799811@eggemoggin.niobe.net> Message-ID: <54AF376B.9050704@redhat.com> Having used this API more than a bit, I think it would be super-nice if this enhancement could be extended slightly to add covariant overrides where appropriate in the javax.lang.model API, if it is at all possible to do so in a binary-compatible way. Specifically, where types and elements are converted to one another is a really painful part of this API; for example I'm pretty sure that DeclaredType.asElement() could return a TypeElement rather than an Element and save everyone lots of annoying casting. Not sure if it's possible to keep the compatibility bridge method though in this particular case. But it would be nice to at least briefly explore this path. On 01/08/2015 03:53 PM, mark.reinhold at oracle.com wrote: > The following JEP has been placed into the "Proposed to Target" > state by its owner after discussion and review: > > 217: Annotations Pipeline 2.0 http://openjdk.java.net/jeps/217 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 22:00 UTC next > Thursday, 15 January, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > this JEP to JDK 9. > > (This information is also available on the JDK 9 Project Page [2]). > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > [2] http://openjdk.java.net/projects/jdk9/ > -- - DML From peter.brunet at oracle.com Fri Jan 9 03:01:22 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 08 Jan 2015 21:01:22 -0600 Subject: package java.lang.management does not exist Message-ID: <54AF4482.9040900@oracle.com> Hi, I'd like to use java.lang.management.ManagementFactory.getThreadMXBean.dumpAllThreads(true, true) but when building I get package java.lang.management does not exist. Is there a way to get the build to find this package? Or is there alternative to the dumpAllThreads method in some other package? Thanks, Pete From mandy.chung at oracle.com Fri Jan 9 03:34:50 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 08 Jan 2015 19:34:50 -0800 Subject: package java.lang.management does not exist In-Reply-To: <54AF4482.9040900@oracle.com> References: <54AF4482.9040900@oracle.com> Message-ID: <54AF4C5A.6090706@oracle.com> On 1/8/2015 7:01 PM, Pete Brunet wrote: > Hi, I'd like to use > java.lang.management.ManagementFactory.getThreadMXBean.dumpAllThreads(true, > true) but when building I get package java.lang.management does not > exist. Is there a way to get the build to find this package? Or is > there alternative to the dumpAllThreads method in some other package? Do you see BUILD_OUTPUTDIR/jdk/modules/java.management/java/lang/management/ManagementFactory.class in your jdk build? There is a typo in your statement above - should be getThreadMXBean() - missing "()" would that be the reason? ManagementFactory.getThreadMXBean().dumpAllThreads(true, true); Mandy From peter.brunet at oracle.com Fri Jan 9 03:49:42 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 08 Jan 2015 21:49:42 -0600 Subject: package java.lang.management does not exist In-Reply-To: <54AF4C5A.6090706@oracle.com> References: <54AF4482.9040900@oracle.com> <54AF4C5A.6090706@oracle.com> Message-ID: <54AF4FD6.5020206@oracle.com> HI Mandy, On 1/8/15 9:34 PM, Mandy Chung wrote: > On 1/8/2015 7:01 PM, Pete Brunet wrote: >> Hi, I'd like to use >> java.lang.management.ManagementFactory.getThreadMXBean.dumpAllThreads(true, >> >> true) but when building I get package java.lang.management does not >> exist. Is there a way to get the build to find this package? Or is >> there alternative to the dumpAllThreads method in some other package? > > Do you see > BUILD_OUTPUTDIR/jdk/modules/java.management/java/lang/management/ManagementFactory.class > in your jdk build? That directory is there. > > There is a typo in your statement above - should be getThreadMXBean() > - missing "()" would that be the reason? > > ManagementFactory.getThreadMXBean().dumpAllThreads(true, true); That's a typo in my email. Sorry. It's OK in the code. Here's a snippet from the build output: Compiling 18 files for oracle.accessbridge c:\Users\Pete\JDK9\JDK-8057620\client\jdk\src\closed\oracle.accessbridge\windows \classes\com\sun\java\accessibility\AccessBridge.java:7207: error: package java. lang.management does not exist System.out.println(java.lang.management.ManagementFa ctory.getThreadMXBean().dumpAllThreads(true, true)); ^ Pete > > Mandy From jonathan.gibbons at oracle.com Fri Jan 9 23:44:27 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 09 Jan 2015 15:44:27 -0800 Subject: JEP proposed to target JDK 9 (2015/1/8) In-Reply-To: <54AF376B.9050704@redhat.com> References: <20150108135314.799811@eggemoggin.niobe.net> <54AF376B.9050704@redhat.com> Message-ID: <54B067DB.2000508@oracle.com> David, That's not a goal of this JEP, but it does sound an interesting issue. I would suggest filing an Enhancement Request against the API, so that this can be tracked in its own right. -- Jon On 01/08/2015 06:05 PM, David M. Lloyd wrote: > Having used this API more than a bit, I think it would be super-nice > if this enhancement could be extended slightly to add covariant > overrides where appropriate in the javax.lang.model API, if it is at > all possible to do so in a binary-compatible way. > > Specifically, where types and elements are converted to one another is > a really painful part of this API; for example I'm pretty sure that > DeclaredType.asElement() could return a TypeElement rather than an > Element and save everyone lots of annoying casting. Not sure if it's > possible to keep the compatibility bridge method though in this > particular case. But it would be nice to at least briefly explore > this path. > > On 01/08/2015 03:53 PM, mark.reinhold at oracle.com wrote: >> The following JEP has been placed into the "Proposed to Target" >> state by its owner after discussion and review: >> >> 217: Annotations Pipeline 2.0 http://openjdk.java.net/jeps/217 >> >> Feedback on this proposal is more than welcome, as are reasoned >> objections. If no such objections are raised by 22:00 UTC next >> Thursday, 15 January, or if they're raised and then satisfactorily >> answered, then per the JEP 2.0 process proposal [1] I'll target >> this JEP to JDK 9. >> >> (This information is also available on the JDK 9 Project Page [2]). >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> [2] http://openjdk.java.net/projects/jdk9/ >> > From dean.long at oracle.com Mon Jan 12 04:31:28 2015 From: dean.long at oracle.com (Dean Long) Date: Sun, 11 Jan 2015 20:31:28 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> Message-ID: <54B34E20.5030506@oracle.com> I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell. The problem seems to be with this line: result=`. $DIR/autoconf-config.sub $sub_args "$@"` "dash" doesn't seem to support args passed with ".", so $sub_args "$@" are ignored. dl From igor.ignatyev at oracle.com Mon Jan 12 08:13:24 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 12 Jan 2015 11:13:24 +0300 Subject: Result: New JDK 9 Committer: Filipp Zhinkin Message-ID: <54B38224.3040701@oracle.com> Voting for Filipp Zhinkin [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. -- Thanks, Igor [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-December/001779.html From igor.ignatyev at oracle.com Mon Jan 12 08:23:41 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 12 Jan 2015 11:23:41 +0300 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54B3848D.4070705@oracle.com> Vote: yes Igor On 01/08/2015 09:10 AM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 > changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From Sergey.Bylokhov at oracle.com Mon Jan 12 09:01:34 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Jan 2015 12:01:34 +0300 Subject: New JDK 9 Reviewer: Alexander Zvegintsev Message-ID: <54B38D6E.5090200@oracle.com> Voting for Alexander Zvegintsev [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-December/001770.html -- Best regards, Sergey. From aph at redhat.com Mon Jan 12 10:25:12 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Jan 2015 10:25:12 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B34E20.5030506@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> Message-ID: <54B3A108.9070203@redhat.com> On 12/01/15 04:31, Dean Long wrote: > I found a small problem with the new config.sub wrapper. It works with > the bash shell but not with the dash shell. > The problem seems to be with this line: > > result=`. $DIR/autoconf-config.sub $sub_args "$@"` > > "dash" doesn't seem to support args passed with ".", so $sub_args "$@" > are ignored. Thank you. Sorry for the breakage; I didn't intend to use any non-portable shell idioms. I'm not expert enough to say whether this is a bug in dash, but I don't suppose that matters: we are where we are. There's no reason not to replace the "." with "bash". Do you want me to do anything? Andrew. From magnus.ihse.bursie at oracle.com Mon Jan 12 11:49:34 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Jan 2015 12:49:34 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B34E20.5030506@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> Message-ID: <54B3B4CE.8060804@oracle.com> On 2015-01-12 05:31, Dean Long wrote: > I found a small problem with the new config.sub wrapper. It works > with the bash shell but not with the dash shell. > The problem seems to be with this line: > > result=`. $DIR/autoconf-config.sub $sub_args "$@"` > > "dash" doesn't seem to support args passed with ".", so $sub_args "$@" > are ignored. bash is the required shell for running configure. We do not support non-bash shells. In fact, we go to lengths to try to ensure that we are indeed running under bash. /Magnus From serguei.spitsyn at oracle.com Mon Jan 12 17:45:10 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 12 Jan 2015 09:45:10 -0800 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54B40826.9050605@oracle.com> Vote: yes On 1/7/15 10:10 PM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has > 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From vladimir.x.ivanov at oracle.com Mon Jan 12 18:09:33 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 12 Jan 2015 21:09:33 +0300 Subject: CFV: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54B40DDD.5020500@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 1/8/15 9:10 AM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has 14 > changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From joe.darcy at oracle.com Mon Jan 12 23:44:03 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 12 Jan 2015 15:44:03 -0800 Subject: JEP proposed to target JDK 9 (2015/1/8) In-Reply-To: <54B067DB.2000508@oracle.com> References: <20150108135314.799811@eggemoggin.niobe.net> <54AF376B.9050704@redhat.com> <54B067DB.2000508@oracle.com> Message-ID: <54B45C43.301@oracle.com> Hello, We may have missed some cases, but during the design of the javax.lang.model.* APIs we consciously tried to avoid overuse of covariant overrides. (Such overuse was a lesson learned from the earlier apt API.) A design requirement of this API was that multiple independent implementation would be possible, notably javac and the Java compiler portion of Eclipse. The implementation model of the compiler need not closely resemble the interface hierarchy of javax.lang.model.*; in particular, we needed it to be possible to have one implementation class implement multiple modeling interfaces. This requirement precludes some otherwise helpful covariant returns. HTH, -Joe PS As noted in the documentation of these types, instancesof checks aren't always a reliable way to test what an object really is -- using getKind or calling a visitor are recommended. On 1/9/2015 3:44 PM, Jonathan Gibbons wrote: > David, > > That's not a goal of this JEP, but it does sound an interesting issue. > I would suggest filing an Enhancement Request against the API, so that > this can be tracked in its own right. > > -- Jon > > > On 01/08/2015 06:05 PM, David M. Lloyd wrote: >> Having used this API more than a bit, I think it would be super-nice >> if this enhancement could be extended slightly to add covariant >> overrides where appropriate in the javax.lang.model API, if it is at >> all possible to do so in a binary-compatible way. >> >> Specifically, where types and elements are converted to one another >> is a really painful part of this API; for example I'm pretty sure >> that DeclaredType.asElement() could return a TypeElement rather than >> an Element and save everyone lots of annoying casting. Not sure if >> it's possible to keep the compatibility bridge method though in this >> particular case. But it would be nice to at least briefly explore >> this path. >> >> On 01/08/2015 03:53 PM, mark.reinhold at oracle.com wrote: >>> The following JEP has been placed into the "Proposed to Target" >>> state by its owner after discussion and review: >>> >>> 217: Annotations Pipeline 2.0 http://openjdk.java.net/jeps/217 >>> >>> Feedback on this proposal is more than welcome, as are reasoned >>> objections. If no such objections are raised by 22:00 UTC next >>> Thursday, 15 January, or if they're raised and then satisfactorily >>> answered, then per the JEP 2.0 process proposal [1] I'll target >>> this JEP to JDK 9. >>> >>> (This information is also available on the JDK 9 Project Page [2]). >>> >>> - Mark >>> >>> >>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>> [2] http://openjdk.java.net/projects/jdk9/ >>> >> > From david.lloyd at redhat.com Tue Jan 13 01:22:47 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 12 Jan 2015 19:22:47 -0600 Subject: JEP proposed to target JDK 9 (2015/1/8) In-Reply-To: <54B45C43.301@oracle.com> References: <20150108135314.799811@eggemoggin.niobe.net> <54AF376B.9050704@redhat.com> <54B067DB.2000508@oracle.com> <54B45C43.301@oracle.com> Message-ID: <54B47367.2000603@redhat.com> Makes sense, though it's unfortunate. But really it's not terrible to mitigate using some utility classes, so I guess we'll survive, somehow. :-) On 01/12/2015 05:44 PM, Joseph D. Darcy wrote: > Hello, > > We may have missed some cases, but during the design of the > javax.lang.model.* APIs we consciously tried to avoid overuse of > covariant overrides. (Such overuse was a lesson learned from the earlier > apt API.) > > A design requirement of this API was that multiple independent > implementation would be possible, notably javac and the Java compiler > portion of Eclipse. The implementation model of the compiler need not > closely resemble the interface hierarchy of javax.lang.model.*; in > particular, we needed it to be possible to have one implementation class > implement multiple modeling interfaces. > > This requirement precludes some otherwise helpful covariant returns. > > HTH, > > -Joe > > PS As noted in the documentation of these types, instancesof checks > aren't always a reliable way to test what an object really is -- using > getKind or calling a visitor are recommended. > > On 1/9/2015 3:44 PM, Jonathan Gibbons wrote: >> David, >> >> That's not a goal of this JEP, but it does sound an interesting issue. >> I would suggest filing an Enhancement Request against the API, so that >> this can be tracked in its own right. >> >> -- Jon >> >> >> On 01/08/2015 06:05 PM, David M. Lloyd wrote: >>> Having used this API more than a bit, I think it would be super-nice >>> if this enhancement could be extended slightly to add covariant >>> overrides where appropriate in the javax.lang.model API, if it is at >>> all possible to do so in a binary-compatible way. >>> >>> Specifically, where types and elements are converted to one another >>> is a really painful part of this API; for example I'm pretty sure >>> that DeclaredType.asElement() could return a TypeElement rather than >>> an Element and save everyone lots of annoying casting. Not sure if >>> it's possible to keep the compatibility bridge method though in this >>> particular case. But it would be nice to at least briefly explore >>> this path. >>> >>> On 01/08/2015 03:53 PM, mark.reinhold at oracle.com wrote: >>>> The following JEP has been placed into the "Proposed to Target" >>>> state by its owner after discussion and review: >>>> >>>> 217: Annotations Pipeline 2.0 http://openjdk.java.net/jeps/217 >>>> >>>> Feedback on this proposal is more than welcome, as are reasoned >>>> objections. If no such objections are raised by 22:00 UTC next >>>> Thursday, 15 January, or if they're raised and then satisfactorily >>>> answered, then per the JEP 2.0 process proposal [1] I'll target >>>> this JEP to JDK 9. >>>> >>>> (This information is also available on the JDK 9 Project Page [2]). >>>> >>>> - Mark >>>> >>>> >>>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>>> [2] http://openjdk.java.net/projects/jdk9/ >>>> >>> >> > -- - DML From dean.long at oracle.com Tue Jan 13 08:32:43 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 13 Jan 2015 00:32:43 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B3B4CE.8060804@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3B4CE.8060804@oracle.com> Message-ID: <54B4D82B.3050608@oracle.com> On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote: > On 2015-01-12 05:31, Dean Long wrote: >> I found a small problem with the new config.sub wrapper. It works >> with the bash shell but not with the dash shell. >> The problem seems to be with this line: >> >> result=`. $DIR/autoconf-config.sub $sub_args "$@"` >> >> "dash" doesn't seem to support args passed with ".", so $sub_args >> "$@" are ignored. > > bash is the required shell for running configure. We do not support > non-bash shells. In fact, we go to lengths to try to ensure that we > are indeed running under bash. > > /Magnus I was thinking 'bash configure' was enough, but it turns out 'CONFIG_SHELL=bash bash configure' gives better results. dl From dean.long at oracle.com Tue Jan 13 08:44:04 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 13 Jan 2015 00:44:04 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B3A108.9070203@redhat.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com> Message-ID: <54B4DAD4.5060904@oracle.com> On 1/12/2015 2:25 AM, Andrew Haley wrote: > On 12/01/15 04:31, Dean Long wrote: >> I found a small problem with the new config.sub wrapper. It works with >> the bash shell but not with the dash shell. >> The problem seems to be with this line: >> >> result=`. $DIR/autoconf-config.sub $sub_args "$@"` >> >> "dash" doesn't seem to support args passed with ".", so $sub_args "$@" >> are ignored. > Thank you. Sorry for the breakage; I didn't intend to use any > non-portable shell idioms. I'm not expert enough to say whether this > is a bug in dash, but I don't suppose that matters: we are where we > are. > > There's no reason not to replace the "." with "bash". Do you want me > to do anything? I guess not, since we only support bash. However, I did notice another problem with the same file. "aarch64-linux-gnu" comes out as "aarch64-linux-gnu" instead of "aarch64-unknown-linux-gnu". I came up with a simpler version, where I replace "aarch64-" with "arm-", run autoconf-config.sub, then replace "arm-" back to "aarch64-". dl > Andrew. From aph at redhat.com Tue Jan 13 09:08:19 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Jan 2015 09:08:19 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B4DAD4.5060904@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com> <54B4DAD4.5060904@oracle.com> Message-ID: <54B4E083.9040502@redhat.com> On 13/01/15 08:44, Dean Long wrote: > I came up with a simpler version, where I replace "aarch64-" with > "arm-", run autoconf-config.sub, then replace "arm-" back to > "aarch64-". Thanks. That sounds good to me. Andrew. From alejandro.murillo at oracle.com Tue Jan 13 18:07:41 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 13 Jan 2015 11:07:41 -0700 Subject: jdk9-dev: HotSpot Message-ID: <54B55EED.3060703@oracle.com> jdk9-hs2-2015-01-08 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/378fd58fe406 http://hg.openjdk.java.net/jdk9/dev/corba/rev/326f2068b4a4 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/10385428e37f http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/74eaf7ad9865 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/64ca52b0bda8 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/71a8a36c96f4 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/014b653eafa9 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/65337c25a5e3 Component : VM Status : Go for integration Date : 01/12/2014 at 16:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-01-09-011709.amurillo.jdk9-hs2-2015-01-08-snapshot Testing: http://surl.us.oracle.com/pit_jdk9_b46_summary 158 new failures, 3676 known failures, 359465 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6583051: crash when adding non-static methods to java.lang.Object class 6700100: optimize inline_native_clone() for small objects with exact klass 6977426: sun/tools tests can intermittently fail to find app's Java pid 8048179: Early reclaim of large objects that are referenced by a few objects 8049716: PPC64: Implement SA on Linux/PPC64 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined 8059510: Compact symbol table layout inside shared archive. 8059613: JEP-JDK-8043304: Test task: JMX- tests 8059623: JEP-JDK-8043304: Test task: command line options tests 8059625: JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature 8062012: test/compiler/ciReplay/TestSA.sh should be updated to work w/ modular image build 8064335: Null pointer dereference in hotspot/src/share/vm/classfile/verifier.cpp 8064457: Introduce compressed oops mode disjoint base and improve compressed heap handling. 8066440: Various changes in testlibrary for JDK-8059613 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class 8066864: remove ctw-test from testlibrary/ 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout 8067173: remove Utils::fileAsList 8067291: Need additional vm checks in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking which vm is run 8067295: Need to port Utils chagnes from JDK-8066440 into jdk workspace 8067307: Need custom classloaders(parent-last and filtering one) for JDK-8066625 in testlibrary 8067676: Add applicable closed gc jtreg tests to run in JPRT 8067713: Move clean_weak_method_links for redefinition out of class unloading 8067836: The Universe::flush_foo methods belong in CodeCache. 8067868: Add GCOld as a JTreg test 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols at build time and suppress warning 1540-1639 8067947: Regression test for JDK-6522873 8068018: Clean up friends of G1CollectedHeap 8068183: Add isTieredSupported method to c.o.j.t.Platforms 8068233: java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is still in exclude list 8068242: Quarantine the test IsModifiableClassAgent.java 8068272: Extend WhiteBox API with methods that check monitor state and force safepoint -- Alejandro From dean.long at oracle.com Tue Jan 13 18:56:21 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 13 Jan 2015 10:56:21 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B4E083.9040502@redhat.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com> <54B4DAD4.5060904@oracle.com> <54B4E083.9040502@redhat.com> Message-ID: <54B56A55.3020803@oracle.com> On 1/13/2015 1:08 AM, Andrew Haley wrote: > On 13/01/15 08:44, Dean Long wrote: > >> I came up with a simpler version, where I replace "aarch64-" with >> "arm-", run autoconf-config.sub, then replace "arm-" back to >> "aarch64-". > Thanks. That sounds good to me. > > Andrew. Here's the patch. If it looks good, I can file a bug and push it to the staging repo. dl diff -r b052cb38b985 common/autoconf/build-aux/config.sub --- a/common/autoconf/build-aux/config.sub Thu Dec 11 15:05:06 2014 -0800 +++ b/common/autoconf/build-aux/config.sub Tue Jan 13 13:57:23 2015 -0500 @@ -41,25 +41,8 @@ case $1 in -- ) # Stop option processing shift; break ;; - aarch64-gnu ) - sub_args="$sub_args aarch64-unknown-gnu" - shift; ;; - aarch64-linux ) - sub_args="$sub_args aarch64-unknown-linux-gnu" - shift; ;; - aarch64-*-linux ) - os=`echo $1 | sed 's/aarch64-\(.*\)-linux/\1/'` - config="aarch64-unknown-linux-gnu" - sub_args="$sub_args $config" - shift; ;; - aarch64-*-gnu ) - os=`echo $1 | sed 's/aarch64-\(.*\)-gnu.*$/\1/'` - config="aarch64-unknown-gnu" - sub_args="$sub_args $config" - shift; ;; - aarch64-*-linux-* ) - os=`echo $1 | sed 's/aarch64-\(.*\)-linux-.*$/'` - config="aarch64-unknown-linux-gnu" + aarch64-* ) + config=`echo $1 | sed 's/^aarch64-/arm-/'` sub_args="$sub_args $config" shift; ;; - ) # Use stdin as input. @@ -74,9 +57,7 @@ result=`. $DIR/autoconf-config.sub $sub_args "$@"` exitcode=$? -if [ "x$os" != "x" ] ; then - result=`echo $result | sed "s/-unknown-/-$os-/"` -fi +result=`echo $result | sed "s/^arm-/aarch64-/"` echo $result exit $exitcode From magnus.ihse.bursie at oracle.com Wed Jan 14 13:27:15 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Jan 2015 14:27:15 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B4D82B.3050608@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3B4CE.8060804@oracle.com> <54B4D82B.3050608@oracle.com> Message-ID: <54B66EB3.3020601@oracle.com> On 2015-01-13 09:32, Dean Long wrote: > On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote: >> On 2015-01-12 05:31, Dean Long wrote: >>> I found a small problem with the new config.sub wrapper. It works >>> with the bash shell but not with the dash shell. >>> The problem seems to be with this line: >>> >>> result=`. $DIR/autoconf-config.sub $sub_args "$@"` >>> >>> "dash" doesn't seem to support args passed with ".", so $sub_args >>> "$@" are ignored. >> >> bash is the required shell for running configure. We do not support >> non-bash shells. In fact, we go to lengths to try to ensure that we >> are indeed running under bash. >> >> /Magnus > I was thinking 'bash configure' was enough, but it turns out > 'CONFIG_SHELL=bash bash configure' gives better results. Hm, that's interesting. We were attempting to automatically use bash in the real configure script, regardless of what shell the user had to start the top-level configure wrapper. If you try the patch below, does it work better when you run "dash configure"? diff --git a/common/autoconf/configure b/common/autoconf/configure --- a/common/autoconf/configure +++ b/common/autoconf/configure @@ -36,6 +36,13 @@ shift fi +if test "x$BASH" = x; then + echo "Error: This script must be run using bash." 1>&2 + exit 1 +fi +# Force autoconf to use bash +export CONFIG_SHELL=$BASH + conf_script_dir="$TOPDIR/common/autoconf" if [ "$CUSTOM_CONFIG_DIR" = "" ]; then /Magnus From dean.long at oracle.com Wed Jan 14 22:02:42 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 14 Jan 2015 14:02:42 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B66EB3.3020601@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3B4CE.8060804@oracle.com> <54B4D82B.3050608@oracle.com> <54B66EB3.3020601@oracle.com> Message-ID: <54B6E782.3040405@oracle.com> On 1/14/2015 5:27 AM, Magnus Ihse Bursie wrote: > On 2015-01-13 09:32, Dean Long wrote: >> On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote: >>> On 2015-01-12 05:31, Dean Long wrote: >>>> I found a small problem with the new config.sub wrapper. It works >>>> with the bash shell but not with the dash shell. >>>> The problem seems to be with this line: >>>> >>>> result=`. $DIR/autoconf-config.sub $sub_args "$@"` >>>> >>>> "dash" doesn't seem to support args passed with ".", so $sub_args >>>> "$@" are ignored. >>> >>> bash is the required shell for running configure. We do not support >>> non-bash shells. In fact, we go to lengths to try to ensure that we >>> are indeed running under bash. >>> >>> /Magnus >> I was thinking 'bash configure' was enough, but it turns out >> 'CONFIG_SHELL=bash bash configure' gives better results. > > Hm, that's interesting. We were attempting to automatically use bash > in the real configure script, regardless of what shell the user had to > start the top-level configure wrapper. > > If you try the patch below, does it work better when you run "dash > configure"? > > diff --git a/common/autoconf/configure b/common/autoconf/configure > --- a/common/autoconf/configure > +++ b/common/autoconf/configure > @@ -36,6 +36,13 @@ > shift > fi > > +if test "x$BASH" = x; then > + echo "Error: This script must be run using bash." 1>&2 > + exit 1 > +fi > +# Force autoconf to use bash > +export CONFIG_SHELL=$BASH > + > conf_script_dir="$TOPDIR/common/autoconf" > > if [ "$CUSTOM_CONFIG_DIR" = "" ]; then > > /Magnus > Yes, that patch solves the problem. dl From dean.long at oracle.com Wed Jan 14 23:23:24 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 14 Jan 2015 15:23:24 -0800 Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile Message-ID: <54B6FA6C.40202@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8031064 http://cr.openjdk.java.net/~dlong/8031064/webrev/ This change allows the build_vm_def.sh script to use the $NM chosen by configure rather than "nm", which makes things better if you're cross-compiling. dl From dean.long at oracle.com Wed Jan 14 23:34:15 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 14 Jan 2015 15:34:15 -0800 Subject: AARCH64: RFR (XS) 8068927: AARCH64: better handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes) In-Reply-To: <54B56A55.3020803@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com> <54B4DAD4.5060904@oracle.com> <54B4E083.9040502@redhat.com> <54B56A55.3020803@oracle.com> Message-ID: <54B6FCF7.1010202@oracle.com> Can I get a review for this? https://bugs.openjdk.java.net/browse/JDK-8068927 http://cr.openjdk.java.net/~dlong/8068927/webrev/ thanks, dl On 1/13/2015 10:56 AM, Dean Long wrote: > On 1/13/2015 1:08 AM, Andrew Haley wrote: >> On 13/01/15 08:44, Dean Long wrote: >> >>> I came up with a simpler version, where I replace "aarch64-" with >>> "arm-", run autoconf-config.sub, then replace "arm-" back to >>> "aarch64-". >> Thanks. That sounds good to me. >> >> Andrew. > > Here's the patch. If it looks good, I can file a bug and push it to > the staging repo. > > dl > > > diff -r b052cb38b985 common/autoconf/build-aux/config.sub > --- a/common/autoconf/build-aux/config.sub Thu Dec 11 15:05:06 > 2014 -0800 > +++ b/common/autoconf/build-aux/config.sub Tue Jan 13 13:57:23 > 2015 -0500 > @@ -41,25 +41,8 @@ > case $1 in > -- ) # Stop option processing > shift; break ;; > - aarch64-gnu ) > - sub_args="$sub_args aarch64-unknown-gnu" > - shift; ;; > - aarch64-linux ) > - sub_args="$sub_args aarch64-unknown-linux-gnu" > - shift; ;; > - aarch64-*-linux ) > - os=`echo $1 | sed 's/aarch64-\(.*\)-linux/\1/'` > - config="aarch64-unknown-linux-gnu" > - sub_args="$sub_args $config" > - shift; ;; > - aarch64-*-gnu ) > - os=`echo $1 | sed 's/aarch64-\(.*\)-gnu.*$/\1/'` > - config="aarch64-unknown-gnu" > - sub_args="$sub_args $config" > - shift; ;; > - aarch64-*-linux-* ) > - os=`echo $1 | sed 's/aarch64-\(.*\)-linux-.*$/'` > - config="aarch64-unknown-linux-gnu" > + aarch64-* ) > + config=`echo $1 | sed 's/^aarch64-/arm-/'` > sub_args="$sub_args $config" > shift; ;; > - ) # Use stdin as input. > @@ -74,9 +57,7 @@ > result=`. $DIR/autoconf-config.sub $sub_args "$@"` > exitcode=$? > > -if [ "x$os" != "x" ] ; then > - result=`echo $result | sed "s/-unknown-/-$os-/"` > -fi > +result=`echo $result | sed "s/^arm-/aarch64-/"` > > echo $result > exit $exitcode > From lana.steuck at oracle.com Thu Jan 15 00:25:54 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Jan 2015 16:25:54 -0800 (PST) Subject: jdk9-b46: dev Message-ID: <201501150025.t0F0Psb3006725@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/12f1e276447b http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/2ecf0a617f0f http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/e272d9be5f90 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/efedac7f44ed http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/64ca52b0bda8 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/74eaf7ad9865 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a184ee1d7172 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/326f2068b4a4 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-6481080 core-libs (ann) @Deprecated annotation has no effect on packages JDK-8068507 core-libs (fc) Rename the new jdk.net.enableFastFileTransfer system property to JDK-8068279 core-libs (typo in the spec) javax.script.ScriptEngineFactory.getLanguageName JDK-8068431 core-libs @since and @jdk.Exported are missing in jdk.nashorn.api.scripting clas JDK-8068597 core-libs Add error code to to exception condition message resulting from GetAd JDK-8054565 core-libs FilterOutputStream.close may throw IOException if called twice and und JDK-8068784 core-libs Halve the function object creation code size JDK-8068580 core-libs JavaAdapterFactory.isAutoConvertibleFromFunction should be more robust JDK-8068524 core-libs NashornScriptEngineFactory.getParameter() throws IAE for an unknown ke JDK-4026465 core-libs Provide more byte array constructors for BigInteger JDK-8067316 core-libs TEST_BUG: update RMI test library with better test.timeout.factor hand JDK-8059175 core-libs Zero BigDecimal with negative scale prints leading zeroes in String.fo JDK-8068462 core-libs javax.script.ScriptEngineFactory.getParameter spec is not completely c JDK-8068735 infrastructure Configure fails on Windows if Visual Studio $LIB/$INCLUDE is lower cas JDK-8068664 infrastructure Parfait report generation fails on windows due to cygwin paths JDK-8068726 infrastructure Tab completion of targets fails when current dir is the output dir JDK-8067759 infrastructure Test bundles JDK-8067060 infrastructure build can still fail with spaces following -L on link lines JDK-8047776 other-libs Add module java.transaction to export API javax.transaction JDK-8067151 other-libs [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh JDK-8058912 security-libs Broken link (access denied error) to http://www.rsasecurity.com in RC5 JDK-8048607 security-libs Test key generation of DES and DESEDE JDK-8046724 security-libs XML Signature ECKeyValue elements cannot be marshalled or unmarshalled JDK-8006469 tools Cleanup reflective access of java.lang.annotation.Repeatable JDK-8068759 tools ConstFoldTest fails on Windows JDK-8058542 tools Devise scheme for better diagnostic creation JDK-8058373 tools Group 10a: golden files for tests in tools/javac dir JDK-8067883 tools Javac misses some opportunities for diagnostic simplification JDK-8068639 tools Make certain annotation classfile warnings opt-in JDK-8067914 tools Redundant type cast nodes in AST (follow up from JDK-8043741) JDK-8059977 tools StandardJavaFileManager should support java.nio.file.Path JDK-8043741 tools VerifyError due to missing checkcast JDK-8066871 tools java.lang.VerifyError: Bad local variable type - local final String JDK-8067429 tools java.lang.VerifyError: Inconsistent stackmap frames at branch target JDK-8064857 tools javac generates LVT entry with length 0 for local variable JDK-8067867 xml Subsume module java.xml.soap into module java.xml.ws From david.holmes at oracle.com Thu Jan 15 06:31:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Jan 2015 16:31:17 +1000 Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile In-Reply-To: <54B6FA6C.40202@oracle.com> References: <54B6FA6C.40202@oracle.com> Message-ID: <54B75EB5.3020407@oracle.com> Hi Dean, Code reviews don't go to jdk9-dev. Build-infra is not relevant to this either. You only need hotspot-dev for a hotspot build issue (though build-dev might be useful for more complex changes). On 15/01/2015 9:23 AM, Dean Long wrote: > https://bugs.openjdk.java.net/browse/JDK-8031064 > http://cr.openjdk.java.net/~dlong/8031064/webrev/ > > This change allows the build_vm_def.sh script to use the $NM chosen by > configure rather than "nm", > which makes things better if you're cross-compiling. I'm always wary of things that might be shell specific: vm.def: $(Res_Files) $(Obj_Files) ! NM=$(NM) sh $(GAMMADIR)/make/linux/makefiles/build_vm_def.sh *.o > $@ I use this style of shell script invocation a lot from bash, where it works, but I was under the impression not all shells support it. David > dl From dean.long at oracle.com Thu Jan 15 06:40:27 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 14 Jan 2015 22:40:27 -0800 Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile In-Reply-To: <54B75EB5.3020407@oracle.com> References: <54B6FA6C.40202@oracle.com> <54B75EB5.3020407@oracle.com> Message-ID: <54B760DB.70200@oracle.com> On 1/14/2015 10:31 PM, David Holmes wrote: > Hi Dean, > > Code reviews don't go to jdk9-dev. Build-infra is not relevant to this > either. You only need hotspot-dev for a hotspot build issue (though > build-dev might be useful for more complex changes). > OK. > On 15/01/2015 9:23 AM, Dean Long wrote: >> https://bugs.openjdk.java.net/browse/JDK-8031064 >> http://cr.openjdk.java.net/~dlong/8031064/webrev/ >> >> This change allows the build_vm_def.sh script to use the $NM chosen by >> configure rather than "nm", >> which makes things better if you're cross-compiling. > > I'm always wary of things that might be shell specific: > > vm.def: $(Res_Files) $(Obj_Files) > ! NM=$(NM) sh $(GAMMADIR)/make/linux/makefiles/build_vm_def.sh > *.o > $@ > > I use this style of shell script invocation a lot from bash, where it > works, but I was under the impression not all shells support it. > I thought we require bash, but maybe that's just for confignure. The above should work on all Bourne shell variants, but not csh variants. Any time we use something like '2> /dev/null', it's Bourne-shell specific, so I don't think our linux makefiles will work with csh. However, I can change it to any of the following: 1. env NM=$(NM) sh ... 2. NM=$(NM); export NM; sh ... 3. export NM vm.def: $(Res_Files) $(Obj_Files) sh ... I have another version that moves the awk code from build_vm_def.sh up into vm.make, but I wanted to keep the changes to a minimum. dl > David > >> dl From magnus.ihse.bursie at oracle.com Thu Jan 15 13:41:46 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Jan 2015 14:41:46 +0100 Subject: [aarch64-port-dev ] AARCH64: RFR (XS) 8068927: AARCH64: better handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes) In-Reply-To: <54B6FCF7.1010202@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com> <54B4DAD4.5060904@oracle.com> <54B4E083.9040502@redhat.com> <54B56A55.3020803@oracle.com> <54B6FCF7.1010202@oracle.com> Message-ID: <54B7C39A.1050000@oracle.com> On 2015-01-15 00:34, Dean Long wrote: > Can I get a review for this? > > https://bugs.openjdk.java.net/browse/JDK-8068927 > http://cr.openjdk.java.net/~dlong/8068927/webrev/ Looks good to me. (However, I'm not a formal reviewer for the aarch64-port project) /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 15 13:44:32 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Jan 2015 14:44:32 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54B6E782.3040405@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3B4CE.8060804@oracle.com> <54B4D82B.3050608@oracle.com> <54B66EB3.3020601@oracle.com> <54B6E782.3040405@oracle.com> Message-ID: <54B7C440.7070807@oracle.com> On 2015-01-14 23:02, Dean Long wrote: > On 1/14/2015 5:27 AM, Magnus Ihse Bursie wrote: >> On 2015-01-13 09:32, Dean Long wrote: >>> On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote: >>>> On 2015-01-12 05:31, Dean Long wrote: >>>>> I found a small problem with the new config.sub wrapper. It works >>>>> with the bash shell but not with the dash shell. >>>>> The problem seems to be with this line: >>>>> >>>>> result=`. $DIR/autoconf-config.sub $sub_args "$@"` >>>>> >>>>> "dash" doesn't seem to support args passed with ".", so $sub_args >>>>> "$@" are ignored. >>>> >>>> bash is the required shell for running configure. We do not support >>>> non-bash shells. In fact, we go to lengths to try to ensure that we >>>> are indeed running under bash. >>>> >>>> /Magnus >>> I was thinking 'bash configure' was enough, but it turns out >>> 'CONFIG_SHELL=bash bash configure' gives better results. >> >> Hm, that's interesting. We were attempting to automatically use bash >> in the real configure script, regardless of what shell the user had >> to start the top-level configure wrapper. >> >> If you try the patch below, does it work better when you run "dash >> configure"? >> >> diff --git a/common/autoconf/configure b/common/autoconf/configure >> --- a/common/autoconf/configure >> +++ b/common/autoconf/configure >> @@ -36,6 +36,13 @@ >> shift >> fi >> >> +if test "x$BASH" = x; then >> + echo "Error: This script must be run using bash." 1>&2 >> + exit 1 >> +fi >> +# Force autoconf to use bash >> +export CONFIG_SHELL=$BASH >> + >> conf_script_dir="$TOPDIR/common/autoconf" >> >> if [ "$CUSTOM_CONFIG_DIR" = "" ]; then >> >> /Magnus >> > > Yes, that patch solves the problem. Thank you for testing it! I have opened https://bugs.openjdk.java.net/browse/JDK-8069057 and will integrate the fix to jdk9-dev. /Magnus From joe.darcy at oracle.com Thu Jan 15 17:48:15 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 15 Jan 2015 09:48:15 -0800 Subject: More concise try-with-resources statement now in JDK 9 Message-ID: <54B7FD5F.6070409@oracle.com> Hello, As part of milling Project Coin [1] in JDK 9, the try-with-resources statement has been improved. If you already have a resource as a final or effectively final variable, you can use that variable in the try-with-resources statement without declaring a new variable in the try-with-resources statement. For example, given resource declarations like // A final resource final Resource resource1 = new Resource("resource1"); // An effectively final resource Resource resource2 = new Resource("resource2"); the old way to write the code to manager these resources would be something like: // Original try-with-resources statement from JDK 7 or 8 try (Resource r1 = resource1; Resource r2 = resource2) { // Use of resource1 and resource 2 through r1 and r2. } while the new way can be just // New and improved try-with-resources statement in JDK 9 try (resource1; resource2) { // Use of resource1 and resource 2. } An initial pass [2] has been made over the java.base module in JDK 9 to update the JDK libraries to use this new language feature. Please try out more more concise try-with-resources statement on your code and report any issues to compiler-dev. Thanks, -Joe [1] http://openjdk.java.net/jeps/213 [2] https://bugs.openjdk.java.net/browse/JDK-8068948 From dean.long at oracle.com Thu Jan 15 20:04:51 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 15 Jan 2015 12:04:51 -0800 Subject: [aarch64-port-dev ] AARCH64: RFR (XS) 8068927: AARCH64: better handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes) In-Reply-To: <54B7C39A.1050000@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com> <54B4DAD4.5060904@oracle.com> <54B4E083.9040502@redhat.com> <54B56A55.3020803@oracle.com> <54B6FCF7.1010202@oracle.com> <54B7C39A.1050000@oracle.com> Message-ID: <54B81D63.3050207@oracle.com> On 1/15/2015 5:41 AM, Magnus Ihse Bursie wrote: > On 2015-01-15 00:34, Dean Long wrote: >> Can I get a review for this? >> >> https://bugs.openjdk.java.net/browse/JDK-8068927 >> http://cr.openjdk.java.net/~dlong/8068927/webrev/ > > Looks good to me. (However, I'm not a formal reviewer for the > aarch64-port project) > > /Magnus > You're a Reviewer for jdk9, and this change will be going into 9 after it does its time in aarch64 staging, so I hope that's good enough. dl From mark.reinhold at oracle.com Thu Jan 15 22:24:09 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 15 Jan 2015 14:24:09 -0800 Subject: JEP proposed to target JDK 9 (2015/1/8) In-Reply-To: <20150108135314.799811@eggemoggin.niobe.net> References: <20150108135314.799811@eggemoggin.niobe.net> Message-ID: <20150115142409.792421@eggemoggin.niobe.net> 2015/1/8 1:53 -0800, mark.reinhold at oracle.com: > The following JEP has been placed into the "Proposed to Target" > state by its owner after discussion and review: > > 217: Annotations Pipeline 2.0 http://openjdk.java.net/jeps/217 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 22:00 UTC next > Thursday, 15 January, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > this JEP to JDK 9. Hearing no objections, I've targeted this JEP to JDK 9. - Mark From mark.reinhold at oracle.com Thu Jan 15 22:31:41 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 15 Jan 2015 14:31:41 -0800 Subject: JEPs proposed to target JDK 9 (2015/1/15) Message-ID: <20150115143141.199273@eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their respective owners after discussion and review. 235: Test Class-File Attributes Generated by javac http://openjdk.java.net/jeps/235 236: Parser API for Nashorn http://openjdk.java.net/jeps/236 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Thursday, 22 January, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From forax at univ-mlv.fr Thu Jan 15 22:52:33 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 15 Jan 2015 23:52:33 +0100 Subject: JEPs proposed to target JDK 9 (2015/1/15) In-Reply-To: <20150115143141.199273@eggemoggin.niobe.net> References: <20150115143141.199273@eggemoggin.niobe.net> Message-ID: <54B844B1.1000601@univ-mlv.fr> On 01/15/2015 11:31 PM, mark.reinhold at oracle.com wrote: [...] > 236: Parser API for Nashorn http://openjdk.java.net/jeps/236 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC next > Thursday, 22 January, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. > > (This information is also available on the JDK 9 Project Page [2]). > > - Mark for JEP 236, I'm not sure that we need a visitor anymore along with the AST, now that we have lambdas, a HashMap AST node -> function to execute, is enough. see for an example of usage https://github.com/forax/vmboiler/blob/master/script/src/com/github/forax/vmboiler/sample/script/TypeInferer.java#L46 and the definition of a Visitor https://github.com/forax/vmboiler/blob/master/script/src/com/github/forax/vmboiler/sample/script/Visitor.java Note: that this 'new visitor' doesn't need any support method (usually named 'accept') defined on the AST node. cheers, R?mi From joe.darcy at oracle.com Fri Jan 16 03:36:03 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 15 Jan 2015 19:36:03 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo Message-ID: <54B88723.7030705@oracle.com> Hello, After a small language change to make the effort tractable [1], and another round of code cleanup [2], the deprecation warnings have been eliminated from the build of the jdk repository of JDK 9 [3]. That means that coming after the previous waves of warnings cleanup, *all* the lint warnings are now enabled in the build of the jdk repo! The effort of clearing all these lint warnings has taken place over many months building on the contribution of many people. I'd like to especially recognize Stuart Marks and Alan Bateman for early work cleaning up the libraries, Jan Lahoda for implementing the supporting language change, Jason Uh for help running build jobs, and Phil Race for many reviews of changes to client code. Thanks, -Joe [1] JEP 211: Elide Deprecation Warnings on Import Statements, http://openjdk.java.net/jeps/211 [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, https://bugs.openjdk.java.net/browse/JDK-8066616 [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 From joe.darcy at oracle.com Fri Jan 16 05:00:07 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 15 Jan 2015 21:00:07 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B88723.7030705@oracle.com> References: <54B88723.7030705@oracle.com> Message-ID: <54B89AD7.8040709@oracle.com> PS I few more people whose contributions I meant to call out, Henry Jen was a prolific fixer of many warnings and Jonathan Gibbons built useful tooling which greatly aided managing the at one point quite large backlog of warnings yet to be fixed. Thanks again, -Joe On 1/15/2015 7:36 PM, joe darcy wrote: > Hello, > > After a small language change to make the effort tractable [1], and > another round of code cleanup [2], the deprecation warnings have been > eliminated from the build of the jdk repository of JDK 9 [3]. > > That means that coming after the previous waves of warnings cleanup, > *all* the lint warnings are now enabled in the build of the jdk repo! > > The effort of clearing all these lint warnings has taken place over > many months building on the contribution of many people. I'd like to > especially recognize Stuart Marks and Alan Bateman for early work > cleaning up the libraries, Jan Lahoda for implementing the supporting > language change, Jason Uh for help running build jobs, and Phil Race > for many reviews of changes to client code. > > Thanks, > > -Joe > > [1] JEP 211: Elide Deprecation Warnings on Import Statements, > http://openjdk.java.net/jeps/211 > > [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, > https://bugs.openjdk.java.net/browse/JDK-8066616 > > [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 > From martijnverburg at gmail.com Fri Jan 16 10:28:12 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 16 Jan 2015 10:28:12 +0000 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B89AD7.8040709@oracle.com> References: <54B88723.7030705@oracle.com> <54B89AD7.8040709@oracle.com> Message-ID: Congrats! On a code base this size it's an impressive feat in persistence :-). On Friday, 16 January 2015, joe darcy wrote: > PS I few more people whose contributions I meant to call out, Henry Jen > was a prolific fixer of many warnings and Jonathan Gibbons built useful > tooling which greatly aided managing the at one point quite large backlog > of warnings yet to be fixed. > > Thanks again, > > -Joe > > On 1/15/2015 7:36 PM, joe darcy wrote: > >> Hello, >> >> After a small language change to make the effort tractable [1], and >> another round of code cleanup [2], the deprecation warnings have been >> eliminated from the build of the jdk repository of JDK 9 [3]. >> >> That means that coming after the previous waves of warnings cleanup, >> *all* the lint warnings are now enabled in the build of the jdk repo! >> >> The effort of clearing all these lint warnings has taken place over many >> months building on the contribution of many people. I'd like to especially >> recognize Stuart Marks and Alan Bateman for early work cleaning up the >> libraries, Jan Lahoda for implementing the supporting language change, >> Jason Uh for help running build jobs, and Phil Race for many reviews of >> changes to client code. >> >> Thanks, >> >> -Joe >> >> [1] JEP 211: Elide Deprecation Warnings on Import Statements, >> http://openjdk.java.net/jeps/211 >> >> [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, >> https://bugs.openjdk.java.net/browse/JDK-8066616 >> >> [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 >> >> > -- Cheers, Martijn From magnus.ihse.bursie at oracle.com Fri Jan 16 13:45:17 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 16 Jan 2015 14:45:17 +0100 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B88723.7030705@oracle.com> References: <54B88723.7030705@oracle.com> Message-ID: <54B915ED.6000707@oracle.com> On 2015-01-16 04:36, joe darcy wrote: > Hello, > > After a small language change to make the effort tractable [1], and > another round of code cleanup [2], the deprecation warnings have been > eliminated from the build of the jdk repository of JDK 9 [3]. > > That means that coming after the previous waves of warnings cleanup, > *all* the lint warnings are now enabled in the build of the jdk repo! Fantastic! :) Great work, everyone. Now it's only the warnings in the native libraries left. ;-) /Magnus > > The effort of clearing all these lint warnings has taken place over > many months building on the contribution of many people. I'd like to > especially recognize Stuart Marks and Alan Bateman for early work > cleaning up the libraries, Jan Lahoda for implementing the supporting > language change, Jason Uh for help running build jobs, and Phil Race > for many reviews of changes to client code. > > Thanks, > > -Joe > > [1] JEP 211: Elide Deprecation Warnings on Import Statements, > http://openjdk.java.net/jeps/211 > > [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, > https://bugs.openjdk.java.net/browse/JDK-8066616 > > [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 > From coleen.phillimore at oracle.com Fri Jan 16 16:55:30 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Jan 2015 11:55:30 -0500 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B915ED.6000707@oracle.com> References: <54B88723.7030705@oracle.com> <54B915ED.6000707@oracle.com> Message-ID: <54B94282.2010509@oracle.com> On 1/16/15, 8:45 AM, Magnus Ihse Bursie wrote: > On 2015-01-16 04:36, joe darcy wrote: >> Hello, >> >> After a small language change to make the effort tractable [1], and >> another round of code cleanup [2], the deprecation warnings have been >> eliminated from the build of the jdk repository of JDK 9 [3]. >> >> That means that coming after the previous waves of warnings cleanup, >> *all* the lint warnings are now enabled in the build of the jdk repo! > > Fantastic! :) Great work, everyone. > > Now it's only the warnings in the native libraries left. ;-) +1 Coleen > > /Magnus > >> >> The effort of clearing all these lint warnings has taken place over >> many months building on the contribution of many people. I'd like to >> especially recognize Stuart Marks and Alan Bateman for early work >> cleaning up the libraries, Jan Lahoda for implementing the supporting >> language change, Jason Uh for help running build jobs, and Phil Race >> for many reviews of changes to client code. >> >> Thanks, >> >> -Joe >> >> [1] JEP 211: Elide Deprecation Warnings on Import Statements, >> http://openjdk.java.net/jeps/211 >> >> [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, >> https://bugs.openjdk.java.net/browse/JDK-8066616 >> >> [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 >> > From ron.durbin at oracle.com Fri Jan 16 17:50:43 2015 From: ron.durbin at oracle.com (ron durbin) Date: Fri, 16 Jan 2015 10:50:43 -0700 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B94282.2010509@oracle.com> References: <54B88723.7030705@oracle.com> <54B915ED.6000707@oracle.com> <54B94282.2010509@oracle.com> Message-ID: <54B94F73.4070403@oracle.com> Awesome On 1/16/15 9:55 AM, Coleen Phillimore wrote: > > On 1/16/15, 8:45 AM, Magnus Ihse Bursie wrote: >> On 2015-01-16 04:36, joe darcy wrote: >>> Hello, >>> >>> After a small language change to make the effort tractable [1], and >>> another round of code cleanup [2], the deprecation warnings have >>> been eliminated from the build of the jdk repository of JDK 9 [3]. >>> >>> That means that coming after the previous waves of warnings cleanup, >>> *all* the lint warnings are now enabled in the build of the jdk repo! >> >> Fantastic! :) Great work, everyone. >> >> Now it's only the warnings in the native libraries left. ;-) > > +1 > > Coleen >> >> /Magnus >> >>> >>> The effort of clearing all these lint warnings has taken place over >>> many months building on the contribution of many people. I'd like to >>> especially recognize Stuart Marks and Alan Bateman for early work >>> cleaning up the libraries, Jan Lahoda for implementing the >>> supporting language change, Jason Uh for help running build jobs, >>> and Phil Race for many reviews of changes to client code. >>> >>> Thanks, >>> >>> -Joe >>> >>> [1] JEP 211: Elide Deprecation Warnings on Import Statements, >>> http://openjdk.java.net/jeps/211 >>> >>> [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, >>> https://bugs.openjdk.java.net/browse/JDK-8066616 >>> >>> [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 >>> >> > From jonathan.gibbons at oracle.com Fri Jan 16 18:45:59 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 16 Jan 2015 10:45:59 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B88723.7030705@oracle.com> References: <54B88723.7030705@oracle.com> Message-ID: <54B95C67.609@oracle.com> On 01/15/2015 07:36 PM, joe darcy wrote: > Hello, > > After a small language change to make the effort tractable [1], and > another round of code cleanup [2], the deprecation warnings have been > eliminated from the build of the jdk repository of JDK 9 [3]. > > That means that coming after the previous waves of warnings cleanup, > *all* the lint warnings are now enabled in the build of the jdk repo! > > The effort of clearing all these lint warnings has taken place over > many months building on the contribution of many people. I'd like to > especially recognize Stuart Marks and Alan Bateman for early work > cleaning up the libraries, Jan Lahoda for implementing the supporting > language change, Jason Uh for help running build jobs, and Phil Race > for many reviews of changes to client code. > > Thanks, > > -Joe > > [1] JEP 211: Elide Deprecation Warnings on Import Statements, > http://openjdk.java.net/jeps/211 > > [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, > https://bugs.openjdk.java.net/browse/JDK-8066616 > > [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 > Joe, This is indeed good news, and shows that if you keep chipping away at the backlog, you can get to a satisfactory conclusion. Now that we have achieved this goal, we need to be able to stay there. I presume that along with -Xlint:all, we also have -Werror, to make fatail errors from any future lapses. Also, what is the "score sheet" across the other repos in the forest? -- Jon From joe.darcy at oracle.com Sat Jan 17 01:04:58 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 16 Jan 2015 17:04:58 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B95C67.609@oracle.com> References: <54B88723.7030705@oracle.com> <54B95C67.609@oracle.com> Message-ID: <54B9B53A.6060308@oracle.com> On 1/16/2015 10:45 AM, Jonathan Gibbons wrote: > On 01/15/2015 07:36 PM, joe darcy wrote: >> Hello, >> >> After a small language change to make the effort tractable [1], and >> another round of code cleanup [2], the deprecation warnings have been >> eliminated from the build of the jdk repository of JDK 9 [3]. >> >> That means that coming after the previous waves of warnings cleanup, >> *all* the lint warnings are now enabled in the build of the jdk repo! >> >> The effort of clearing all these lint warnings has taken place over >> many months building on the contribution of many people. I'd like to >> especially recognize Stuart Marks and Alan Bateman for early work >> cleaning up the libraries, Jan Lahoda for implementing the supporting >> language change, Jason Uh for help running build jobs, and Phil Race >> for many reviews of changes to client code. >> >> Thanks, >> >> -Joe >> >> [1] JEP 211: Elide Deprecation Warnings on Import Statements, >> http://openjdk.java.net/jeps/211 >> >> [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, >> https://bugs.openjdk.java.net/browse/JDK-8066616 >> >> [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 >> > > > Joe, > > This is indeed good news, and shows that if you keep chipping away at > the backlog, you can get to a satisfactory conclusion. > > Now that we have achieved this goal, we need to be able to stay there. > I presume that along with -Xlint:all, we also have -Werror, to make > fatail errors from any future lapses. Indeed! > > Also, what is the "score sheet" across the other repos in the forest? > Langtools is compiled with -Xlint:all,-deprecation -Werror. I have not looked in detail, but I wouldn't be surprised if the langtools deprecation warnings couldn't be resolved until JDK 10, using a bootstrap to JDK 9, to take advantage of the language change to elide deprecation warnings on import statements. I have a question out to build-dev to see how to officially run the builds of other repos with different javac options, but in the mean time I've done a stand-alone compile of the sources in the jaxp repo: 5230 total warnings [cast] 160 [dep-ann] 109 [deprecation] 91 [fallthrough] 46 [rawtypes] 2238 [serial] 280 [static] 21 [unchecked] 2285 So we know from a while-JDK perspective, there is still plenty of warnings cleanup work left to do. Thanks, -Joe From jonathan.gibbons at oracle.com Sat Jan 17 01:09:42 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 16 Jan 2015 17:09:42 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B9B53A.6060308@oracle.com> References: <54B88723.7030705@oracle.com> <54B95C67.609@oracle.com> <54B9B53A.6060308@oracle.com> Message-ID: <54B9B656.7090800@oracle.com> On 01/16/2015 05:04 PM, joe darcy wrote: > > Langtools is compiled with -Xlint:all,-deprecation -Werror. I have not > looked in detail, but I wouldn't be surprised if the langtools > deprecation warnings couldn't be resolved until JDK 10, using a > bootstrap to JDK 9, to take advantage of the language change to elide > deprecation warnings on import statements. We could do a trial build of langtools with JDK9 as the bootstrap and -Xlint:all, just to see if there are any warnings that remain. -- Jon From sadhak001 at gmail.com Sat Jan 17 01:34:07 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sat, 17 Jan 2015 01:34:07 +0000 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B9B656.7090800@oracle.com> References: <54B88723.7030705@oracle.com> <54B95C67.609@oracle.com> <54B9B53A.6060308@oracle.com> <54B9B656.7090800@oracle.com> Message-ID: Great news guys! On Sat, Jan 17, 2015 at 1:09 AM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > On 01/16/2015 05:04 PM, joe darcy wrote: > >> >> Langtools is compiled with -Xlint:all,-deprecation -Werror. I have not >> looked in detail, but I wouldn't be surprised if the langtools deprecation >> warnings couldn't be resolved until JDK 10, using a bootstrap to JDK 9, to >> take advantage of the language change to elide deprecation warnings on >> import statements. >> > > We could do a trial build of langtools with JDK9 as the bootstrap and > -Xlint:all, just to see if there are any warnings that remain. > > -- Jon > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From emanuele.tagliaferri at gmail.com Sat Jan 17 16:58:37 2015 From: emanuele.tagliaferri at gmail.com (Emanuel) Date: Sat, 17 Jan 2015 16:58:37 +0000 Subject: ClassCastException on collection generics for jdk8 working code Message-ID: <54BA94BD.3000501@gmail.com> I am at the Adopt OpenJdk hack day organized by the LJC, I am running tests cases of OrientDB (open source java based NoSql) on JDK9 (Build b45 ), and i got some issue with the use of generics. basically this code: List list = new ArrayList<>(); list.add(new Date()); List cList = (List) (List) list; Date date = (Date) cList.get(0); // it fail here on jdk8 it work fine, on jdk9 the code fail in the marked line. the jdk8 bytecode for the failing line is: invokeinterface #7, 2 // InterfaceMethod java/util/List.get:(I)Ljava/lang/Object; checkcast #4 // class java/util/Date instead of on jdk9 is: invokeinterface #7, 2 // InterfaceMethod java/util/List.get:(I)Ljava/lang/Object; checkcast #8 // class ListFail$Foo checkcast #4 // class java/util/Date and is clear that there's a additional cast that is causing the exception. I understand that this code is not the exactly clean and correct conceptually, but it may be a lot of this staff out there that can be break by jdk9. In attachment a couple of simple example for reproduce this issue. Regards Emanuel From martijnverburg at gmail.com Sat Jan 17 17:11:00 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 17 Jan 2015 17:11:00 +0000 Subject: ClassCastException on collection generics for jdk8 working code In-Reply-To: <54BA94BD.3000501@gmail.com> References: <54BA94BD.3000501@gmail.com> Message-ID: Hi Emanuel, Good to see you today! OpenJDK mailing lists strip attachments so you'll need to give a pastebin link or similar. Cheers, Martijn On 17 January 2015 at 16:58, Emanuel wrote: > I am at the Adopt OpenJdk hack day organized by the LJC, I am running > tests cases of OrientDB (open source java based NoSql) on JDK9 (Build > b45 ), and i got some issue with the use of generics. > > basically this code: > List list = new ArrayList<>(); > list.add(new Date()); > > List cList = (List) (List) list; > Date date = (Date) cList.get(0); // it > fail here > > on jdk8 it work fine, on jdk9 the code fail in the marked line. > > the jdk8 bytecode for the failing line is: > invokeinterface #7, 2 // InterfaceMethod > java/util/List.get:(I)Ljava/lang/Object; > checkcast #4 // class java/util/Date > > instead of on jdk9 is: > invokeinterface #7, 2 // InterfaceMethod > java/util/List.get:(I)Ljava/lang/Object; > checkcast #8 // class ListFail$Foo > checkcast #4 // class java/util/Date > > > and is clear that there's a additional cast that is causing the exception. > > I understand that this code is not the exactly clean and correct > conceptually, but it may be a lot of this staff out there that can be > break by jdk9. > > In attachment a couple of simple example for reproduce this issue. > > > Regards > > Emanuel > > > From emanuele.tagliaferri at gmail.com Sat Jan 17 18:51:15 2015 From: emanuele.tagliaferri at gmail.com (Emanuel) Date: Sat, 17 Jan 2015 18:51:15 +0000 Subject: ClassCastException on collection generics for jdk8 working code In-Reply-To: References: <54BA94BD.3000501@gmail.com> Message-ID: <54BAAF23.2020208@gmail.com> Thank you Martijn, i didn't know :) here we go : https://gist.github.com/tglman/02eb98fb1c80386fa3ab https://gist.github.com/tglman/44b0b3fc4239d9229027 Let me add also that OrientDB don't rely in any way on this behavior, it come out just from two not well written legacy test case ;). On 01/17/2015 05:11 PM, Martijn Verburg wrote: > Hi Emanuel, > > Good to see you today! OpenJDK mailing lists strip attachments so > you'll need to give a pastebin link or similar. > > Cheers, > Martijn > > On 17 January 2015 at 16:58, Emanuel > wrote: > > I am at the Adopt OpenJdk hack day organized by the LJC, I am running > tests cases of OrientDB (open source java based NoSql) on JDK9 (Build > b45 ), and i got some issue with the use of generics. > > basically this code: > List list = new ArrayList<>(); > list.add(new Date()); > > List cList = (List) (List) list; > Date date = (Date) cList.get(0); // it > fail here > > on jdk8 it work fine, on jdk9 the code fail in the marked line. > > the jdk8 bytecode for the failing line is: > invokeinterface #7, 2 // InterfaceMethod > java/util/List.get:(I)Ljava/lang/Object; > checkcast #4 // class java/util/Date > > instead of on jdk9 is: > invokeinterface #7, 2 // InterfaceMethod > java/util/List.get:(I)Ljava/lang/Object; > checkcast #8 // class ListFail$Foo > checkcast #4 // class java/util/Date > > > and is clear that there's a additional cast that is causing the > exception. > > I understand that this code is not the exactly clean and correct > conceptually, but it may be a lot of this staff out there that can be > break by jdk9. > > In attachment a couple of simple example for reproduce this issue. > > > Regards > > Emanuel > > > From forax at univ-mlv.fr Sat Jan 17 20:22:44 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 17 Jan 2015 21:22:44 +0100 Subject: ClassCastException on collection generics for jdk8 working code In-Reply-To: <54BAAF23.2020208@gmail.com> References: <54BA94BD.3000501@gmail.com> <54BAAF23.2020208@gmail.com> Message-ID: <54BAC494.40505@univ-mlv.fr> I think this is due to the fix of 8043741 [1]. In my opinion, these legacy tests are buggy and because of a bug in the compiler it was working, and not the other way around. Anyway, it's just my opinion, there is a lot of corner cases around the cast to an interface, asking the experts is a better idea so I've CC compiler-dev. R?mi [1] https://bugs.openjdk.java.net/browse/JDK-8043741 On 01/17/2015 07:51 PM, Emanuel wrote: > Thank you Martijn, i didn't know :) > > here we go : > https://gist.github.com/tglman/02eb98fb1c80386fa3ab > https://gist.github.com/tglman/44b0b3fc4239d9229027 > > Let me add also that OrientDB don't rely in any way on this behavior, it > come out just from two not well written legacy test case ;). > > On 01/17/2015 05:11 PM, Martijn Verburg wrote: >> Hi Emanuel, >> >> Good to see you today! OpenJDK mailing lists strip attachments so >> you'll need to give a pastebin link or similar. >> >> Cheers, >> Martijn >> >> On 17 January 2015 at 16:58, Emanuel > > wrote: >> >> I am at the Adopt OpenJdk hack day organized by the LJC, I am running >> tests cases of OrientDB (open source java based NoSql) on JDK9 (Build >> b45 ), and i got some issue with the use of generics. >> >> basically this code: >> List list = new ArrayList<>(); >> list.add(new Date()); >> >> List cList = (List) (List) list; >> Date date = (Date) cList.get(0); // it >> fail here >> >> on jdk8 it work fine, on jdk9 the code fail in the marked line. >> >> the jdk8 bytecode for the failing line is: >> invokeinterface #7, 2 // InterfaceMethod >> java/util/List.get:(I)Ljava/lang/Object; >> checkcast #4 // class java/util/Date >> >> instead of on jdk9 is: >> invokeinterface #7, 2 // InterfaceMethod >> java/util/List.get:(I)Ljava/lang/Object; >> checkcast #8 // class ListFail$Foo >> checkcast #4 // class java/util/Date >> >> >> and is clear that there's a additional cast that is causing the >> exception. >> >> I understand that this code is not the exactly clean and correct >> conceptually, but it may be a lot of this staff out there that can be >> break by jdk9. >> >> In attachment a couple of simple example for reproduce this issue. >> >> >> Regards >> >> Emanuel >> >> >> From maurizio.cimadamore at oracle.com Sat Jan 17 21:44:49 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 17 Jan 2015 21:44:49 +0000 Subject: ClassCastException on collection generics for jdk8 working code In-Reply-To: <54BAC494.40505@univ-mlv.fr> References: <54BA94BD.3000501@gmail.com> <54BAAF23.2020208@gmail.com> <54BAC494.40505@univ-mlv.fr> Message-ID: <54BAD7D1.7060007@oracle.com> Hi, I think 8043741 got integrated in b46, so I would rule that one out (also judging from the fix [1], which seems very localized to the synthetic nullcheck operators). We'll need to dig a bit deeper on this one - the behavior seems a bit weird, and I'm not sure this is intentional. I'll keep you posted - I agree with Remi that compiler-dev is the right mailing list for this one. Thanks Maurizio On 17/01/15 20:22, Remi Forax wrote: > I think this is due to the fix of 8043741 [1]. > In my opinion, these legacy tests are buggy and because of a bug in > the compiler > it was working, and not the other way around. > > Anyway, it's just my opinion, there is a lot of corner cases around > the cast to an interface, > asking the experts is a better idea so I've CC compiler-dev. > > R?mi > > [1] https://bugs.openjdk.java.net/browse/JDK-8043741 > > On 01/17/2015 07:51 PM, Emanuel wrote: >> Thank you Martijn, i didn't know :) >> >> here we go : >> https://gist.github.com/tglman/02eb98fb1c80386fa3ab >> https://gist.github.com/tglman/44b0b3fc4239d9229027 >> >> Let me add also that OrientDB don't rely in any way on this behavior, it >> come out just from two not well written legacy test case ;). >> >> On 01/17/2015 05:11 PM, Martijn Verburg wrote: >>> Hi Emanuel, >>> >>> Good to see you today! OpenJDK mailing lists strip attachments so >>> you'll need to give a pastebin link or similar. >>> >>> Cheers, >>> Martijn >>> >>> On 17 January 2015 at 16:58, Emanuel >> > wrote: >>> >>> I am at the Adopt OpenJdk hack day organized by the LJC, I am >>> running >>> tests cases of OrientDB (open source java based NoSql) on JDK9 >>> (Build >>> b45 ), and i got some issue with the use of generics. >>> >>> basically this code: >>> List list = new ArrayList<>(); >>> list.add(new Date()); >>> >>> List cList = (List) (List) list; >>> Date date = (Date) cList.get(0); >>> // it >>> fail here >>> >>> on jdk8 it work fine, on jdk9 the code fail in the marked line. >>> >>> the jdk8 bytecode for the failing line is: >>> invokeinterface #7, 2 // InterfaceMethod >>> java/util/List.get:(I)Ljava/lang/Object; >>> checkcast #4 // class java/util/Date >>> >>> instead of on jdk9 is: >>> invokeinterface #7, 2 // InterfaceMethod >>> java/util/List.get:(I)Ljava/lang/Object; >>> checkcast #8 // class ListFail$Foo >>> checkcast #4 // class java/util/Date >>> >>> >>> and is clear that there's a additional cast that is causing the >>> exception. >>> >>> I understand that this code is not the exactly clean and correct >>> conceptually, but it may be a lot of this staff out there that >>> can be >>> break by jdk9. >>> >>> In attachment a couple of simple example for reproduce this issue. >>> >>> >>> Regards >>> >>> Emanuel >>> >>> >>> > From ali.ebrahimi1781 at gmail.com Sat Jan 17 22:26:52 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Sun, 18 Jan 2015 01:56:52 +0330 Subject: ClassCastException on collection generics for jdk8 working code In-Reply-To: <54BAD7D1.7060007@oracle.com> References: <54BA94BD.3000501@gmail.com> <54BAAF23.2020208@gmail.com> <54BAC494.40505@univ-mlv.fr> <54BAD7D1.7060007@oracle.com> Message-ID: I think root cause is same for both sample code: I think one question should clear problem and that is how type inference work here: List list = new ArrayList<>(); list.add(new Date()); List cList = (List) (List) list; Date date = (Date) cList.get(0); What is result of type inference for "cList.get(0)" ? Consider that: Date date = (Date) ((Foo)cList.get(0)); have same result. I think this is expected behavior. On Sun, Jan 18, 2015 at 1:14 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > I think 8043741 got integrated in b46, so I would rule that one out (also > judging from the fix [1], which seems very localized to the synthetic > nullcheck operators). We'll need to dig a bit deeper on this one - the > behavior seems a bit weird, and I'm not sure this is intentional. > > I'll keep you posted - I agree with Remi that compiler-dev is the right > mailing list for this one. > > Thanks > Maurizio > > > On 17/01/15 20:22, Remi Forax wrote: > >> I think this is due to the fix of 8043741 [1]. >> In my opinion, these legacy tests are buggy and because of a bug in the >> compiler >> it was working, and not the other way around. >> >> Anyway, it's just my opinion, there is a lot of corner cases around the >> cast to an interface, >> asking the experts is a better idea so I've CC compiler-dev. >> >> R?mi >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8043741 >> >> On 01/17/2015 07:51 PM, Emanuel wrote: >> >>> Thank you Martijn, i didn't know :) >>> >>> here we go : >>> https://gist.github.com/tglman/02eb98fb1c80386fa3ab >>> https://gist.github.com/tglman/44b0b3fc4239d9229027 >>> >>> Let me add also that OrientDB don't rely in any way on this behavior, it >>> come out just from two not well written legacy test case ;). >>> >>> On 01/17/2015 05:11 PM, Martijn Verburg wrote: >>> >>>> Hi Emanuel, >>>> >>>> Good to see you today! OpenJDK mailing lists strip attachments so >>>> you'll need to give a pastebin link or similar. >>>> >>>> Cheers, >>>> Martijn >>>> >>>> On 17 January 2015 at 16:58, Emanuel >>> > wrote: >>>> >>>> I am at the Adopt OpenJdk hack day organized by the LJC, I am >>>> running >>>> tests cases of OrientDB (open source java based NoSql) on JDK9 >>>> (Build >>>> b45 ), and i got some issue with the use of generics. >>>> >>>> basically this code: >>>> List list = new ArrayList<>(); >>>> list.add(new Date()); >>>> >>>> List cList = (List) (List) list; >>>> Date date = (Date) cList.get(0); // >>>> it >>>> fail here >>>> >>>> on jdk8 it work fine, on jdk9 the code fail in the marked line. >>>> >>>> the jdk8 bytecode for the failing line is: >>>> invokeinterface #7, 2 // InterfaceMethod >>>> java/util/List.get:(I)Ljava/lang/Object; >>>> checkcast #4 // class java/util/Date >>>> >>>> instead of on jdk9 is: >>>> invokeinterface #7, 2 // InterfaceMethod >>>> java/util/List.get:(I)Ljava/lang/Object; >>>> checkcast #8 // class ListFail$Foo >>>> checkcast #4 // class java/util/Date >>>> >>>> >>>> and is clear that there's a additional cast that is causing the >>>> exception. >>>> >>>> I understand that this code is not the exactly clean and correct >>>> conceptually, but it may be a lot of this staff out there that can >>>> be >>>> break by jdk9. >>>> >>>> In attachment a couple of simple example for reproduce this issue. >>>> >>>> >>>> Regards >>>> >>>> Emanuel >>>> >>>> >>>> >>>> >> > -- Best Regards, Ali Ebrahimi From sundararajan.athijegannathan at oracle.com Mon Jan 19 06:45:19 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 19 Jan 2015 12:15:19 +0530 Subject: JEPs proposed to target JDK 9 (2015/1/15) In-Reply-To: <54B844B1.1000601@univ-mlv.fr> References: <20150115143141.199273@eggemoggin.niobe.net> <54B844B1.1000601@univ-mlv.fr> Message-ID: <54BCA7FF.3080109@oracle.com> Hi, If the NodeVisitor interface includes default implementation that calls visitUnknown method, then your scheme could be implemented as visitUnknown override (i.e., Class->lambda selection logic and maintaining state etc). Also, users can implement few selective visitABC methods - as the rest have default implementation - which is one of the advantages your scheme - selectively implement visit for only few types. Thanks, -Sundar On Friday 16 January 2015 04:22 AM, Remi Forax wrote: > On 01/15/2015 11:31 PM, mark.reinhold at oracle.com wrote: > > [...] > >> 236: Parser API for Nashorn http://openjdk.java.net/jeps/236 >> >> Feedback on these proposals is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC next >> Thursday, 22 January, or if they're raised and then satisfactorily >> answered, then per the JEP 2.0 process proposal [1] I'll target >> these JEPs to JDK 9. >> >> (This information is also available on the JDK 9 Project Page [2]). >> >> - Mark > > for JEP 236, I'm not sure that we need a visitor anymore along with > the AST, now that we have lambdas, > a HashMap AST node -> function to execute, is enough. > > see for an example of usage > https://github.com/forax/vmboiler/blob/master/script/src/com/github/forax/vmboiler/sample/script/TypeInferer.java#L46 > > > and the definition of a Visitor > https://github.com/forax/vmboiler/blob/master/script/src/com/github/forax/vmboiler/sample/script/Visitor.java > > > Note: that this 'new visitor' doesn't need any support method (usually > named 'accept') defined on the AST node. > > cheers, > R?mi > From srikanth.adayapalam at oracle.com Mon Jan 19 09:39:31 2015 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 19 Jan 2015 15:09:31 +0530 Subject: ClassCastException on collection generics for jdk8 working code Message-ID: <54BCD0D3.7020304@oracle.com> Hello ! I have raised https://bugs.openjdk.java.net/browse/JDK-8069265 to track this one. This new behaviour got introduced as of JDK9 build b08 as a result of the change made for https://bugs.openjdk.java.net/browse/JDK-8015499. Prima facie, there is no indication that there is a compiler bug here. The compiler is well within its rights to assert what it is asserting which fails due to CCE. But we may want to see if we should/could avoid such gratuitous and inadvertent behaviour change. Thanks! Srikanth -------- Forwarded Message -------- Subject: Re: ClassCastException on collection generics for jdk8 working code Date: Sat, 17 Jan 2015 21:44:49 +0000 From: Maurizio Cimadamore To: Remi Forax , compiler-dev at openjdk.java.net CC: jdk9-dev at openjdk.java.net Hi, I think 8043741 got integrated in b46, so I would rule that one out (also judging from the fix [1], which seems very localized to the synthetic nullcheck operators). We'll need to dig a bit deeper on this one - the behavior seems a bit weird, and I'm not sure this is intentional. I'll keep you posted - I agree with Remi that compiler-dev is the right mailing list for this one. Thanks Maurizio On 17/01/15 20:22, Remi Forax wrote: > I think this is due to the fix of 8043741 [1]. > In my opinion, these legacy tests are buggy and because of a bug in > the compiler > it was working, and not the other way around. > > Anyway, it's just my opinion, there is a lot of corner cases around > the cast to an interface, > asking the experts is a better idea so I've CC compiler-dev. > > R?mi > > [1]https://bugs.openjdk.java.net/browse/JDK-8043741 > > On 01/17/2015 07:51 PM, Emanuel wrote: >> Thank you Martijn, i didn't know :) >> >> here we go : >>https://gist.github.com/tglman/02eb98fb1c80386fa3ab >>https://gist.github.com/tglman/44b0b3fc4239d9229027 >> >> Let me add also that OrientDB don't rely in any way on this behavior, it >> come out just from two not well written legacy test case ;). >> >> On 01/17/2015 05:11 PM, Martijn Verburg wrote: >>> Hi Emanuel, >>> >>> Good to see you today! OpenJDK mailing lists strip attachments so >>> you'll need to give a pastebin link or similar. >>> >>> Cheers, >>> Martijn >>> >>> On 17 January 2015 at 16:58, Emanuel>>> wrote: >>> >>> I am at the Adopt OpenJdk hack day organized by the LJC, I am >>> running >>> tests cases of OrientDB (open source java based NoSql) on JDK9 >>> (Build >>> b45 ), and i got some issue with the use of generics. >>> >>> basically this code: >>> List list = new ArrayList<>(); >>> list.add(new Date()); >>> >>> List cList = (List) (List) list; >>> Date date = (Date) cList.get(0); >>> // it >>> fail here >>> >>> on jdk8 it work fine, on jdk9 the code fail in the marked line. >>> >>> the jdk8 bytecode for the failing line is: >>> invokeinterface #7, 2 // InterfaceMethod >>> java/util/List.get:(I)Ljava/lang/Object; >>> checkcast #4 // class java/util/Date >>> >>> instead of on jdk9 is: >>> invokeinterface #7, 2 // InterfaceMethod >>> java/util/List.get:(I)Ljava/lang/Object; >>> checkcast #8 // class ListFail$Foo >>> checkcast #4 // class java/util/Date >>> >>> >>> and is clear that there's a additional cast that is causing the >>> exception. >>> >>> I understand that this code is not the exactly clean and correct >>> conceptually, but it may be a lot of this staff out there that >>> can be >>> break by jdk9. >>> >>> In attachment a couple of simple example for reproduce this issue. >>> >>> >>> Regards >>> >>> Emanuel >>> >>> >>> > From alejandro.murillo at oracle.com Tue Jan 20 18:37:12 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 20 Jan 2015 11:37:12 -0700 Subject: jdk9-dev: HotSpot Message-ID: <54BEA058.6090304@oracle.com> jdk9-hs2-2015-01-15 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/b6cca3e6175a http://hg.openjdk.java.net/jdk9/dev/corba/rev/ee8447ca632e http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/20946e467375 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/e391de88e69b http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/6c17d648d03e http://hg.openjdk.java.net/jdk9/dev/jdk/rev/562ec0efc6cf http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b58b3cc63bc http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/da0ae09ceff8 Component : VM Status : Go for integration Date : 01/20/2015 at 18:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-01-16-033430.amurillo.jdk9-hs2-2015-01-15-snapshot Testing: 118 new failures, 2675 known failures, 311649 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8027626: assert(Opcode() != Op_If || outcnt() == 2) failed: bad if #1 8027829: CompileCommand does not accept all JLS-conformant class/method names 8049355: compiler/rtm/locking/TestRTMLockingThreshold test may fail if transaction was aborted by interrupt 8058897: Unsafe.reallocateMemory() ignores -XX:MallocMaxTestWords setting 8059342: Add test to cover JDK-8030976 8059551: JEP-JDK-8043304: Test task: stress tests 8060219: [TESTBUG] runtime/7194254/Test7194254.java fails to find jstack with modular image build 8062063: Usage of UseHugeTLBFS, UseLargePagesInMetaspace and huge SurvivorAlignmentInBytes cause crashes in CMBitMapClosure::do_bit 8062450: Timeout in LowMemoryTest.java 8063086: Math.pow yields different results upon repeated calls 8065226: sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be quarantined 8065894: CodeHeap::next_free should be renamed 8067187: -XX:MaxMetaspaceSize=20m -Xshare:dump caused JVM to crash 8067306: Improve STATIC_ASSERT 8067331: Zero: Atomic::xchg and Atomic::xchg_ptr need full memory barrier 8067368: TestConcMarkCycleWB.java crashed at G1CollectedHeap::heap()+0xb 8067941: [TESTBUG] Fix tests for OS with 64K page size. 8068013: [TESTBUG] Aix support in hotspot jtreg tests 8068037: Remove dead code in G1CollectedHeap 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases 8068396: Rename assert() to vmassert() 8068505: interpreter profiling incorrect on PPC64 8068540: [TESTBUG] Exclude failing nightly tests 8068584: Compiler attach tests should be quarantined 8068653: TestSmalllHeap.java fails when the page size is 64k 8068661: Exclude compiler/whitebox/ForceNMethodSweepTest.java from nightly runs 8068718: com/sun/jdi/CatchPatternTest.sh should be quarantined 8068724: ppc64: update assembler: SPR access, CR logic, HTM 8068733: [TESTBUG] runtime/Unsafe/Reallocate.java sometimes fails when running with -Xcomp 8068739: G1CollectoryPolicy uses uninitialized field '_sigma' in the constructor 8068746: Exclude hotspot/test/compiler/codecache/jmx/PoolsIndependenceTest.java from nightly runs 8069021: Exclude compiler/codecache/stress tests from JPRT runs -- Alejandro From joe.darcy at oracle.com Wed Jan 21 19:03:38 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 21 Jan 2015 11:03:38 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54B95C67.609@oracle.com> References: <54B88723.7030705@oracle.com> <54B95C67.609@oracle.com> Message-ID: <54BFF80A.8090405@oracle.com> A follow-up below... On 1/16/2015 10:45 AM, Jonathan Gibbons wrote: > On 01/15/2015 07:36 PM, joe darcy wrote: >> Hello, >> >> After a small language change to make the effort tractable [1], and >> another round of code cleanup [2], the deprecation warnings have been >> eliminated from the build of the jdk repository of JDK 9 [3]. >> >> That means that coming after the previous waves of warnings cleanup, >> *all* the lint warnings are now enabled in the build of the jdk repo! >> >> The effort of clearing all these lint warnings has taken place over >> many months building on the contribution of many people. I'd like to >> especially recognize Stuart Marks and Alan Bateman for early work >> cleaning up the libraries, Jan Lahoda for implementing the supporting >> language change, Jason Uh for help running build jobs, and Phil Race >> for many reviews of changes to client code. >> >> Thanks, >> >> -Joe >> >> [1] JEP 211: Elide Deprecation Warnings on Import Statements, >> http://openjdk.java.net/jeps/211 >> >> [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, >> https://bugs.openjdk.java.net/browse/JDK-8066616 >> >> [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 >> > > > Joe, > > This is indeed good news, and shows that if you keep chipping away at > the backlog, you can get to a satisfactory conclusion. > > Now that we have achieved this goal, we need to be able to stay there. > I presume that along with -Xlint:all, we also have -Werror, to make > fatail errors from any future lapses. > > Also, what is the "score sheet" across the other repos in the forest? > After getting some tips over on build-dev, here are the warning stats for the modules hosted in the other repos: # corba repo: 6664 total warnings java.corba: 5982 total warnings [rawtypes]: 3260 [unchecked]: 1446 [serial]: 544 [cast]: 386 [deprecation]: 309 [static]: 22 [fallthrough]: 12 [dep-ann]: 2 java.sql: 1 total warning [serial]: 1 jdk.rmic: 681 total warnings [unchecked]: 126 [rawtypes]: 494 [cast]: 18 [deprecation]: 40 [fallthrough]: 2 # jaxp repo: 5230 total warnings java.xml: 5230 total warnings [rawtypes]: 2238 [unchecked] 2285 [cast]: 160 [dep-ann]: 109 [deprecation]: 91 [fallthrough]: 46 [serial]: 280 [static]: 21 # jaxws repo: 6021 total warnings java.activation: 169 total warnings [rawtypes]: 100 [unchecked]: 60 [cast]: 2 [dep-ann]: 2 [serial]: 5 java.annotations.common: no warnings java.xml.bind: 1868 total warnings [rawtypes]: 1163 [unchecked]: 504 [cast]: 3 [dep-ann]: 43 [deprecation]: 117 [fallthrough]: 12 [serial]: 25 [static]: 1 java.xml.ws: 1645 total warnings [rawtypes]: 824 [unchecked]: 372 [cast]: 15 [dep-ann]: 142 [deprecation]: 193 [fallthrough]: 4 [serial]: 89 [static]: 6 jdk.xml.bind: 1475 total warnings [rawtypes]: 766 [unchecked]: 570 [cast]: 23 [dep-ann]: 39 [deprecation]: 42 [fallthrough]: 4 [serial]: 31 jdk.xml.ws: 864 total warnings [rawtypes]: 286 [unchecked]: 228 [cast]: 12 [dep-ann]: 7 [deprecation]: 319 [serial]: 12 Fixing warnings is fun and rewarding; luckily there are still plenty of warnings for others to enjoy resolving ;-) As in the jdk repo, the preponderance of the warnings are rawtypes/unchecked. I'd recommend prioritizing fixing the warnings categories other than rawtypes and unchecked. Cheers, -Joe From huizhe.wang at oracle.com Wed Jan 21 21:46:05 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 21 Jan 2015 13:46:05 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54BFF80A.8090405@oracle.com> References: <54B88723.7030705@oracle.com> <54B95C67.609@oracle.com> <54BFF80A.8090405@oracle.com> Message-ID: <54C01E1D.7020004@oracle.com> Hi Joe, Lance reminded me to see this email thread. Looks like jaxp made it to top 3, a plenty of warnings cleanup work indeed :-) Thanks, Joe On 1/21/2015 11:03 AM, joe darcy wrote: > A follow-up below... > > On 1/16/2015 10:45 AM, Jonathan Gibbons wrote: >> On 01/15/2015 07:36 PM, joe darcy wrote: >>> Hello, >>> >>> After a small language change to make the effort tractable [1], and >>> another round of code cleanup [2], the deprecation warnings have >>> been eliminated from the build of the jdk repository of JDK 9 [3]. >>> >>> That means that coming after the previous waves of warnings cleanup, >>> *all* the lint warnings are now enabled in the build of the jdk repo! >>> >>> The effort of clearing all these lint warnings has taken place over >>> many months building on the contribution of many people. I'd like to >>> especially recognize Stuart Marks and Alan Bateman for early work >>> cleaning up the libraries, Jan Lahoda for implementing the >>> supporting language change, Jason Uh for help running build jobs, >>> and Phil Race for many reviews of changes to client code. >>> >>> Thanks, >>> >>> -Joe >>> >>> [1] JEP 211: Elide Deprecation Warnings on Import Statements, >>> http://openjdk.java.net/jeps/211 >>> >>> [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, >>> https://bugs.openjdk.java.net/browse/JDK-8066616 >>> >>> [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 >>> >> >> >> Joe, >> >> This is indeed good news, and shows that if you keep chipping away at >> the backlog, you can get to a satisfactory conclusion. >> >> Now that we have achieved this goal, we need to be able to stay >> there. I presume that along with -Xlint:all, we also have -Werror, to >> make fatail errors from any future lapses. >> >> Also, what is the "score sheet" across the other repos in the forest? >> > > After getting some tips over on build-dev, here are the warning stats > for the modules hosted in the other repos: > > # corba repo: 6664 total warnings > > java.corba: 5982 total warnings > [rawtypes]: 3260 > [unchecked]: 1446 > [serial]: 544 > [cast]: 386 > [deprecation]: 309 > [static]: 22 > [fallthrough]: 12 > [dep-ann]: 2 > > java.sql: 1 total warning > [serial]: 1 > > jdk.rmic: 681 total warnings > [unchecked]: 126 > [rawtypes]: 494 > [cast]: 18 > [deprecation]: 40 > [fallthrough]: 2 > > # jaxp repo: 5230 total warnings > > java.xml: 5230 total warnings > [rawtypes]: 2238 > [unchecked] 2285 > [cast]: 160 > [dep-ann]: 109 > [deprecation]: 91 > [fallthrough]: 46 > [serial]: 280 > [static]: 21 > > # jaxws repo: 6021 total warnings > > java.activation: 169 total warnings > [rawtypes]: 100 > [unchecked]: 60 > [cast]: 2 > [dep-ann]: 2 > [serial]: 5 > > java.annotations.common: no warnings > > java.xml.bind: 1868 total warnings > [rawtypes]: 1163 > [unchecked]: 504 > [cast]: 3 > [dep-ann]: 43 > [deprecation]: 117 > [fallthrough]: 12 > [serial]: 25 > [static]: 1 > > java.xml.ws: 1645 total warnings > [rawtypes]: 824 > [unchecked]: 372 > [cast]: 15 > [dep-ann]: 142 > [deprecation]: 193 > [fallthrough]: 4 > [serial]: 89 > [static]: 6 > > jdk.xml.bind: 1475 total warnings > [rawtypes]: 766 > [unchecked]: 570 > [cast]: 23 > [dep-ann]: 39 > [deprecation]: 42 > [fallthrough]: 4 > [serial]: 31 > > jdk.xml.ws: 864 total warnings > [rawtypes]: 286 > [unchecked]: 228 > [cast]: 12 > [dep-ann]: 7 > [deprecation]: 319 > [serial]: 12 > > Fixing warnings is fun and rewarding; luckily there are still plenty > of warnings for others to enjoy resolving ;-) > > As in the jdk repo, the preponderance of the warnings are > rawtypes/unchecked. I'd recommend prioritizing fixing the warnings > categories other than rawtypes and unchecked. > > Cheers, > > -Joe From lana.steuck at oracle.com Wed Jan 21 22:06:50 2015 From: lana.steuck at oracle.com (Lana Steuck) Date: Wed, 21 Jan 2015 14:06:50 -0800 Subject: jdk9-b47: dev Message-ID: <54C022FA.1010206@oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/b6cca3e6175a http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/29046d42a95e http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/230c13955250 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b641c14730ac http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/6c17d648d03e http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/e391de88e69b http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3b241fb72b89 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/ee8447ca632e --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8069131 client-libs Suppress deprecation warning in oracle.accessbridge JDK-8058793 client-libs Test sun/awt/datatransfer/DataFlavorComparatorTest.java fails with com JDK-8068599 core-libs Add mutability, serializability, and thread-safety, caveat to all Coll JDK-8067344 core-libs Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for rece JDK-8068736 core-libs Avoid synchronization on Executable/Field.declaredAnnotations JDK-8068889 core-libs Calling a @FunctionalInterface from JS leaks internal objects JDK-8068994 core-libs Forgot to add a test model to JDK-8068573 JDK-8042581 core-libs Intermittent failure in java/net/DatagramSocket/InheritHandle.java JDK-8067291 core-libs Need additional vm checks in jdk/test/lib/testlibrary/jdk/testlibrary/ JDK-8067307 core-libs Need custom classloaders(parent-last and filtering one) for JDK-806662 JDK-8067295 core-libs Need to port Utils chagnes from JDK-8066440 into jdk workspace JDK-8068573 core-libs POJO setter using [] syntax throws an exception JDK-8069002 core-libs REGRESSION: test/script/external/test262/test/suite/ch11/11.2/11.2.3/S JDK-8068498 core-libs Remove constructor dependency on line.separator from PrintWriter and B JDK-8068948 core-libs Update java.base module to use new try-with-resources statement JDK-8067471 core-libs Use private static final char[0] for empty Strings JDK-8068985 core-libs Wrong 'this' bound to eval call within a function when caller's 'this' JDK-8061297 core-libs sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JDK-8068233 core-svc java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is still JDK-6977426 core-svc sun/tools tests can intermittently fail to find app's Java pid JDK-8067923 hotspot AIX: link libjvm.so with -bernotok to detect missing symbols at build JDK-8067868 hotspot Add GCOld as a JTreg test JDK-8068183 hotspot Add isTieredSupported method to c.o.j.t.Platforms JDK-8068018 hotspot Clean up friends of G1CollectedHeap JDK-8066122 hotspot CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCI JDK-8059510 hotspot Compact symbol table layout inside shared archive JDK-8048179 hotspot Early reclaim of large objects that are referenced by a few objects JDK-8068272 hotspot Extend WhiteBox API with methods that check monitor state and force sa JDK-8067095 hotspot Fix deprecation warnings in Java Flight Recorder JDK-8064457 hotspot Introduce compressed oops mode "disjoint base" and improve compressed JDK-8059623 hotspot JEP-JDK-8043304: Test task: command line options tests JDK-8067713 hotspot Move clean_weak_method_links for redefinition out of class unloading JDK-8049716 hotspot PPC64: Implement SA on Linux/PPC64 JDK-8068242 hotspot Quarantine the test IsModifiableClassAgent.java JDK-8067836 hotspot The Universe::flush_foo methods belong in CodeCache. JDK-8066497 hotspot Update c.o.j.t.ByteCodeLoader to be able really reload given class JDK-8066896 hotspot Update c.o.j.t.InfiniteLoop to skip zero timeout JDK-8067947 hotspot [TESTBUG] Regression test for JDK-6522873 JDK-8055530 hotspot assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) fai JDK-8050486 hotspot compiler/rtm/ tests fail due to monitor deflation at safepoint synchro JDK-6583051 hotspot crash when adding non-static methods to java.lang.Object class JDK-6700100 hotspot optimize inline_native_clone() for small objects with exact klass. JDK-8067173 hotspot remove Utils::fileAsList JDK-8066864 hotspot remove ctw-test from testlibrary/ JDK-8062012 hotspot test/compiler/ciReplay/TestSA.sh should be updated to work w/ modular JDK-8067099 infrastructure Add deprecation lint warning to build of jdk repository JDK-8069041 infrastructure Bootcycle builds do not work with sjavac JDK-8069057 infrastructure Make sure configure is run by bash JDK-8066769 infrastructure Merge errors following JDK-8049367 (Modular Run-Time Images) JDK-8069063 infrastructure More merge errors following JDK-8049367 (Modular Run-Time Images) JDK-8068902 infrastructure Solaris build fails with new 10u10 devkit JDK-8048603 security-libs Additional tests for MAC algorithms JDK-8059916 security-libs Change default criticality of policy mappings and policy constraints c JDK-8059009 security-libs LDAPCertStore fails to retrieve CRL after LDAP server closes idle conn JDK-8069127 security-libs Suppress deprecation warnings in jdk.deploy.osx module JDK-8069069 tools Build failure because of dependency on generated file JDK-8062358 tools ClassCastException in TransTypes.visitApply JDK-8068995 tools Cleanup method reference lookup code JDK-8069164 tools Fix langtools make build so that diagnostic framework can be used JDK-8066843 tools Messager.printMessage cannot print multiple errors for same source pos JDK-8068254 tools Method reference uses wrong qualifying type JDK-8037546 tools javac -parameters does not emit parameter names for lambda expressions JDK-8027888 tools javac wrongly allows annotations in array-typed class literals From joe.darcy at oracle.com Wed Jan 21 23:24:33 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 21 Jan 2015 15:24:33 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54C01E1D.7020004@oracle.com> References: <54B88723.7030705@oracle.com> <54B95C67.609@oracle.com> <54BFF80A.8090405@oracle.com> <54C01E1D.7020004@oracle.com> Message-ID: <54C03530.1030304@oracle.com> Hi Joe, On 1/21/2015 1:46 PM, huizhe wang wrote: > Hi Joe, > > Lance reminded me to see this email thread. Looks like jaxp made it to > top 3, a plenty of warnings cleanup work indeed :-) Plenty of warnings, but each one is generally very easy to fix :-) Some comments / guidance on the different warning categories: [cast]: These are redundant casts. Since they are in method bodies and checked by javac they are safe and easy to remove, an essentially zero-risk change. [fallthrough]: Indicates a switch has a fall-through condition. If such a code path is not intentional, it can be a serious bug. All such cases should be examined for correctness. [static]: Accessing a static member through an instance variable. Misleading code that should be corrected. [dep-ann]: When @Deprecated annotations aren't properly paired with @deprecated javadoc tags; should be fixed. [serial]: A serializable class without a serialVersionUID defined, often a problem for the serialization contract we maintain the in JDK. The fix is usually just to add a serialVersionUID set to the serialver of the already-shipped version of the class. Extra care must be taken of the class has actually evolved over different releases. [deprecation]: Use of deprecated code. If a rigorous examination is not possible, the warning should at least able to be successfully suppressed now in JDK 9. [rawtypes] & [unchecked] Symptomatic of incomplete generification of APIs. Generics shipped in 2004 with JDK 5; Java code today should be generics aware! I'd be happy to advise and code review warnings fixes in jaxp, jaxws, and corba. Thanks, -Joe > > Thanks, > Joe > > On 1/21/2015 11:03 AM, joe darcy wrote: >> A follow-up below... >> >> On 1/16/2015 10:45 AM, Jonathan Gibbons wrote: >>> On 01/15/2015 07:36 PM, joe darcy wrote: >>>> Hello, >>>> >>>> After a small language change to make the effort tractable [1], and >>>> another round of code cleanup [2], the deprecation warnings have >>>> been eliminated from the build of the jdk repository of JDK 9 [3]. >>>> >>>> That means that coming after the previous waves of warnings >>>> cleanup, *all* the lint warnings are now enabled in the build of >>>> the jdk repo! >>>> >>>> The effort of clearing all these lint warnings has taken place over >>>> many months building on the contribution of many people. I'd like >>>> to especially recognize Stuart Marks and Alan Bateman for early >>>> work cleaning up the libraries, Jan Lahoda for implementing the >>>> supporting language change, Jason Uh for help running build jobs, >>>> and Phil Race for many reviews of changes to client code. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> [1] JEP 211: Elide Deprecation Warnings on Import Statements, >>>> http://openjdk.java.net/jeps/211 >>>> >>>> [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, >>>> https://bugs.openjdk.java.net/browse/JDK-8066616 >>>> >>>> [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 >>>> >>> >>> >>> Joe, >>> >>> This is indeed good news, and shows that if you keep chipping away >>> at the backlog, you can get to a satisfactory conclusion. >>> >>> Now that we have achieved this goal, we need to be able to stay >>> there. I presume that along with -Xlint:all, we also have -Werror, >>> to make fatail errors from any future lapses. >>> >>> Also, what is the "score sheet" across the other repos in the forest? >>> >> >> After getting some tips over on build-dev, here are the warning stats >> for the modules hosted in the other repos: >> >> # corba repo: 6664 total warnings >> >> java.corba: 5982 total warnings >> [rawtypes]: 3260 >> [unchecked]: 1446 >> [serial]: 544 >> [cast]: 386 >> [deprecation]: 309 >> [static]: 22 >> [fallthrough]: 12 >> [dep-ann]: 2 >> >> java.sql: 1 total warning >> [serial]: 1 >> >> jdk.rmic: 681 total warnings >> [unchecked]: 126 >> [rawtypes]: 494 >> [cast]: 18 >> [deprecation]: 40 >> [fallthrough]: 2 >> >> # jaxp repo: 5230 total warnings >> >> java.xml: 5230 total warnings >> [rawtypes]: 2238 >> [unchecked] 2285 >> [cast]: 160 >> [dep-ann]: 109 >> [deprecation]: 91 >> [fallthrough]: 46 >> [serial]: 280 >> [static]: 21 >> >> # jaxws repo: 6021 total warnings >> >> java.activation: 169 total warnings >> [rawtypes]: 100 >> [unchecked]: 60 >> [cast]: 2 >> [dep-ann]: 2 >> [serial]: 5 >> >> java.annotations.common: no warnings >> >> java.xml.bind: 1868 total warnings >> [rawtypes]: 1163 >> [unchecked]: 504 >> [cast]: 3 >> [dep-ann]: 43 >> [deprecation]: 117 >> [fallthrough]: 12 >> [serial]: 25 >> [static]: 1 >> >> java.xml.ws: 1645 total warnings >> [rawtypes]: 824 >> [unchecked]: 372 >> [cast]: 15 >> [dep-ann]: 142 >> [deprecation]: 193 >> [fallthrough]: 4 >> [serial]: 89 >> [static]: 6 >> >> jdk.xml.bind: 1475 total warnings >> [rawtypes]: 766 >> [unchecked]: 570 >> [cast]: 23 >> [dep-ann]: 39 >> [deprecation]: 42 >> [fallthrough]: 4 >> [serial]: 31 >> >> jdk.xml.ws: 864 total warnings >> [rawtypes]: 286 >> [unchecked]: 228 >> [cast]: 12 >> [dep-ann]: 7 >> [deprecation]: 319 >> [serial]: 12 >> >> Fixing warnings is fun and rewarding; luckily there are still plenty >> of warnings for others to enjoy resolving ;-) >> >> As in the jdk repo, the preponderance of the warnings are >> rawtypes/unchecked. I'd recommend prioritizing fixing the warnings >> categories other than rawtypes and unchecked. >> >> Cheers, >> >> -Joe > From huizhe.wang at oracle.com Thu Jan 22 00:59:48 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 21 Jan 2015 16:59:48 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54C03530.1030304@oracle.com> References: <54B88723.7030705@oracle.com> <54B95C67.609@oracle.com> <54BFF80A.8090405@oracle.com> <54C01E1D.7020004@oracle.com> <54C03530.1030304@oracle.com> Message-ID: <54C04B84.8080908@oracle.com> Thanks Joe for the guidance! I'll give it to shot as soon as I have time. I need to kick start some planned works first so that they can get into people's busy schedule. Hope it's "easy" to fix :-) Also, as you referred to JDK 5, time to move the jaxp code base to beyond JDK 1.4 that the upstream source still supports, a bit inconvenient for future update, but maybe not much so. Cheers, Joe On 1/21/2015 3:24 PM, joe darcy wrote: > Hi Joe, > > On 1/21/2015 1:46 PM, huizhe wang wrote: >> Hi Joe, >> >> Lance reminded me to see this email thread. Looks like jaxp made it >> to top 3, a plenty of warnings cleanup work indeed :-) > > Plenty of warnings, but each one is generally very easy to fix :-) > > Some comments / guidance on the different warning categories: > > [cast]: These are redundant casts. Since they are in method bodies and > checked by javac they are safe and easy to remove, an essentially > zero-risk change. > > [fallthrough]: Indicates a switch has a fall-through condition. If > such a code path is not intentional, it can be a serious bug. All such > cases should be examined for correctness. > > [static]: Accessing a static member through an instance variable. > Misleading code that should be corrected. > > [dep-ann]: When @Deprecated annotations aren't properly paired with > @deprecated javadoc tags; should be fixed. > > [serial]: A serializable class without a serialVersionUID defined, > often a problem for the serialization contract we maintain the in JDK. > The fix is usually just to add a serialVersionUID set to the serialver > of the already-shipped version of the class. Extra care must be taken > of the class has actually evolved over different releases. > > [deprecation]: Use of deprecated code. If a rigorous examination is > not possible, the warning should at least able to be successfully > suppressed now in JDK 9. > > [rawtypes] & [unchecked] Symptomatic of incomplete generification of > APIs. Generics shipped in 2004 with JDK 5; Java code today should be > generics aware! > > I'd be happy to advise and code review warnings fixes in jaxp, jaxws, > and corba. > > Thanks, > > -Joe > >> >> Thanks, >> Joe >> >> On 1/21/2015 11:03 AM, joe darcy wrote: >>> A follow-up below... >>> >>> On 1/16/2015 10:45 AM, Jonathan Gibbons wrote: >>>> On 01/15/2015 07:36 PM, joe darcy wrote: >>>>> Hello, >>>>> >>>>> After a small language change to make the effort tractable [1], >>>>> and another round of code cleanup [2], the deprecation warnings >>>>> have been eliminated from the build of the jdk repository of JDK 9 >>>>> [3]. >>>>> >>>>> That means that coming after the previous waves of warnings >>>>> cleanup, *all* the lint warnings are now enabled in the build of >>>>> the jdk repo! >>>>> >>>>> The effort of clearing all these lint warnings has taken place >>>>> over many months building on the contribution of many people. I'd >>>>> like to especially recognize Stuart Marks and Alan Bateman for >>>>> early work cleaning up the libraries, Jan Lahoda for implementing >>>>> the supporting language change, Jason Uh for help running build >>>>> jobs, and Phil Race for many reviews of changes to client code. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> [1] JEP 211: Elide Deprecation Warnings on Import Statements, >>>>> http://openjdk.java.net/jeps/211 >>>>> >>>>> [2] JDK-8066616 Suppress deprecation warnings in jdk libraries, >>>>> https://bugs.openjdk.java.net/browse/JDK-8066616 >>>>> >>>>> [3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985 >>>>> >>>> >>>> >>>> Joe, >>>> >>>> This is indeed good news, and shows that if you keep chipping away >>>> at the backlog, you can get to a satisfactory conclusion. >>>> >>>> Now that we have achieved this goal, we need to be able to stay >>>> there. I presume that along with -Xlint:all, we also have -Werror, >>>> to make fatail errors from any future lapses. >>>> >>>> Also, what is the "score sheet" across the other repos in the forest? >>>> >>> >>> After getting some tips over on build-dev, here are the warning >>> stats for the modules hosted in the other repos: >>> >>> # corba repo: 6664 total warnings >>> >>> java.corba: 5982 total warnings >>> [rawtypes]: 3260 >>> [unchecked]: 1446 >>> [serial]: 544 >>> [cast]: 386 >>> [deprecation]: 309 >>> [static]: 22 >>> [fallthrough]: 12 >>> [dep-ann]: 2 >>> >>> java.sql: 1 total warning >>> [serial]: 1 >>> >>> jdk.rmic: 681 total warnings >>> [unchecked]: 126 >>> [rawtypes]: 494 >>> [cast]: 18 >>> [deprecation]: 40 >>> [fallthrough]: 2 >>> >>> # jaxp repo: 5230 total warnings >>> >>> java.xml: 5230 total warnings >>> [rawtypes]: 2238 >>> [unchecked] 2285 >>> [cast]: 160 >>> [dep-ann]: 109 >>> [deprecation]: 91 >>> [fallthrough]: 46 >>> [serial]: 280 >>> [static]: 21 >>> >>> # jaxws repo: 6021 total warnings >>> >>> java.activation: 169 total warnings >>> [rawtypes]: 100 >>> [unchecked]: 60 >>> [cast]: 2 >>> [dep-ann]: 2 >>> [serial]: 5 >>> >>> java.annotations.common: no warnings >>> >>> java.xml.bind: 1868 total warnings >>> [rawtypes]: 1163 >>> [unchecked]: 504 >>> [cast]: 3 >>> [dep-ann]: 43 >>> [deprecation]: 117 >>> [fallthrough]: 12 >>> [serial]: 25 >>> [static]: 1 >>> >>> java.xml.ws: 1645 total warnings >>> [rawtypes]: 824 >>> [unchecked]: 372 >>> [cast]: 15 >>> [dep-ann]: 142 >>> [deprecation]: 193 >>> [fallthrough]: 4 >>> [serial]: 89 >>> [static]: 6 >>> >>> jdk.xml.bind: 1475 total warnings >>> [rawtypes]: 766 >>> [unchecked]: 570 >>> [cast]: 23 >>> [dep-ann]: 39 >>> [deprecation]: 42 >>> [fallthrough]: 4 >>> [serial]: 31 >>> >>> jdk.xml.ws: 864 total warnings >>> [rawtypes]: 286 >>> [unchecked]: 228 >>> [cast]: 12 >>> [dep-ann]: 7 >>> [deprecation]: 319 >>> [serial]: 12 >>> >>> Fixing warnings is fun and rewarding; luckily there are still plenty >>> of warnings for others to enjoy resolving ;-) >>> >>> As in the jdk repo, the preponderance of the warnings are >>> rawtypes/unchecked. I'd recommend prioritizing fixing the warnings >>> categories other than rawtypes and unchecked. >>> >>> Cheers, >>> >>> -Joe >> > From mark.reinhold at oracle.com Fri Jan 23 00:03:03 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 22 Jan 2015 16:03:03 -0800 Subject: JEPs proposed to target JDK 9 (2015/1/15) In-Reply-To: <20150115143141.199273@eggemoggin.niobe.net> References: <20150115143141.199273@eggemoggin.niobe.net> Message-ID: <20150122160303.734242@eggemoggin.niobe.net> 2015/1/15 2:31 -0800, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" > state by their respective owners after discussion and review. > > 235: Test Class-File Attributes Generated by javac http://openjdk.java.net/jeps/235 > 236: Parser API for Nashorn http://openjdk.java.net/jeps/236 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC next > Thursday, 22 January, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. Hearing no objections, I've targeted these JEPs to JDK 9. - Mark From mark.reinhold at oracle.com Fri Jan 23 17:00:51 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 23 Jan 2015 09:00:51 -0800 Subject: JEP proposed to target JDK 9 (2015/1/23) Message-ID: <20150123090051.158761@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 230: Microbenchmark Suite http://openjdk.java.net/jeps/230 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 18:00 UTC next Friday, 23 January, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From joe.darcy at oracle.com Sun Jan 25 22:55:35 2015 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 25 Jan 2015 14:55:35 -0800 Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo In-Reply-To: <54C04B84.8080908@oracle.com> References: <54B88723.7030705@oracle.com> <54B95C67.609@oracle.com> <54BFF80A.8090405@oracle.com> <54C01E1D.7020004@oracle.com> <54C03530.1030304@oracle.com> <54C04B84.8080908@oracle.com> Message-ID: <54C57467.2060709@oracle.com> PS I've written up a blog entry with some more detailed advice about clearing javac lint warnings: https://blogs.oracle.com/darcy/entry/warnings_removal_advice Cheers, -Joe On 1/21/2015 4:59 PM, huizhe wang wrote: > Thanks Joe for the guidance! I'll give it to shot as soon as I have > time. I need to kick start some planned works first so that they can > get into people's busy schedule. > > Hope it's "easy" to fix :-) Also, as you referred to JDK 5, time to > move the jaxp code base to beyond JDK 1.4 that the upstream source > still supports, a bit inconvenient for future update, but maybe not > much so. > > Cheers, > Joe > > On 1/21/2015 3:24 PM, joe darcy wrote: >> Hi Joe, >> >> On 1/21/2015 1:46 PM, huizhe wang wrote: >>> Hi Joe, >>> >>> Lance reminded me to see this email thread. Looks like jaxp made it >>> to top 3, a plenty of warnings cleanup work indeed :-) >> >> Plenty of warnings, but each one is generally very easy to fix :-) >> >> Some comments / guidance on the different warning categories: >> >> [cast]: These are redundant casts. Since they are in method bodies >> and checked by javac they are safe and easy to remove, an essentially >> zero-risk change. >> >> [fallthrough]: Indicates a switch has a fall-through condition. If >> such a code path is not intentional, it can be a serious bug. All >> such cases should be examined for correctness. >> >> [static]: Accessing a static member through an instance variable. >> Misleading code that should be corrected. >> >> [dep-ann]: When @Deprecated annotations aren't properly paired with >> @deprecated javadoc tags; should be fixed. >> >> [serial]: A serializable class without a serialVersionUID defined, >> often a problem for the serialization contract we maintain the in >> JDK. The fix is usually just to add a serialVersionUID set to the >> serialver of the already-shipped version of the class. Extra care >> must be taken of the class has actually evolved over different releases. >> >> [deprecation]: Use of deprecated code. If a rigorous examination is >> not possible, the warning should at least able to be successfully >> suppressed now in JDK 9. >> >> [rawtypes] & [unchecked] Symptomatic of incomplete generification of >> APIs. Generics shipped in 2004 with JDK 5; Java code today should be >> generics aware! >> >> I'd be happy to advise and code review warnings fixes in jaxp, jaxws, >> and corba. >> >> Thanks, >> >> -Joe >> From albert.noll at oracle.com Mon Jan 26 08:04:43 2015 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 26 Jan 2015 09:04:43 +0100 Subject: Result: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54AE1F4E.6040409@oracle.com> References: <54AE1F4E.6040409@oracle.com> Message-ID: <54C5F51B.3050707@oracle.com> Voting for Zoltan Majo [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Albert Noll [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-January/001809.html On 01/08/2015 07:10 AM, Albert Noll wrote: > I hereby nominate Zoltan Majo to JDK9 Committer. > > Zoltan is a member of the Hotspot compiler team since 6 months. > During the past 6 months, Zoltan worked on various parts of Hotspot, > including the interpreter, the compilers, and the code cache. > > Here is a list of 8 significant changesets [3]. In total, Zoltan has > 14 changesets. > > Votes are due by January 22, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Albert > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > From albert.noll at oracle.com Mon Jan 26 08:08:06 2015 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 26 Jan 2015 09:08:06 +0100 Subject: Result: New JDK 9 Committer: Zoltan Majo In-Reply-To: <54C5F51B.3050707@oracle.com> References: <54AE1F4E.6040409@oracle.com> <54C5F51B.3050707@oracle.com> Message-ID: <54C5F5E6.1080401@oracle.com> Correction to announced results: Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best, Albert On 01/26/2015 09:04 AM, Albert Noll wrote: > Voting for Zoltan Majo [1] is now closed. > > Yes: 15 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. > > Albert Noll > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-January/001809.html > > > On 01/08/2015 07:10 AM, Albert Noll wrote: >> I hereby nominate Zoltan Majo to JDK9 Committer. >> >> Zoltan is a member of the Hotspot compiler team since 6 months. >> During the past 6 months, Zoltan worked on various parts of Hotspot, >> including the interpreter, the compilers, and the code cache. >> >> Here is a list of 8 significant changesets [3]. In total, Zoltan has >> 14 changesets. >> >> Votes are due by January 22, 2015. >> >> Only current JDK9 Committers [1] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this >> mailing list. >> For Lazy Consensus voting instructions, see [2]. >> >> Thanks, >> Albert >> >> [1] http://openjdk.java.net/census#jdk9 >> [2] http://openjdk.java.net/projects#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e2441a0d98f3 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5cb3c079bf70 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2d697acc4e03 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51a2224e845e >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ffe9c8c82350 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8a8f6e7c5180 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0da099111ea0 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 >> > From artem.ananiev at oracle.com Mon Jan 26 10:42:46 2015 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 26 Jan 2015 13:42:46 +0300 Subject: CFV: New jdk9 Reviewer: Alexander Zvegintsev In-Reply-To: <54996785.4090900@oracle.com> References: <54996785.4090900@oracle.com> Message-ID: <54C61A26.7060507@oracle.com> Vote: yes (Is the voting ended?) Artem On 12/23/2014 4:00 PM, Sergey Bylokhov wrote: > I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to > JDK9 Reviewer. > > Alexander is currently a JDK9 Committer and a member of AWT/Swing and > JavaFX teams at Oracle. > > Here is the list of fixes(41 fix): > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=alexander.zvegintsev%40oracle.com > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=azvegint&revcount=200 > > > Votes are due by 17:00 PM CEST, January 6, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From mark.reinhold at oracle.com Mon Jan 26 20:39:17 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 26 Jan 2015 12:39:17 -0800 Subject: JEP proposed to target JDK 9 (2015/1/26) Message-ID: <20150126123917.114071@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 237: Linux/AArch64 Port http://openjdk.java.net/jeps/237 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 22:00 UTC next Monday, 2 February, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From alejandro.murillo at oracle.com Tue Jan 27 18:27:20 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 27 Jan 2015 11:27:20 -0700 Subject: jdk9-dev: HotSpot Message-ID: <54C7D888.2030401@oracle.com> jdk9-hs-2015-01-22 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/a6e8bde6a87e http://hg.openjdk.java.net/jdk9/dev/corba/rev/a13c49c5f289 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6c3831a4a80c http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/036b399b9dfa http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/3b14b7c9c719 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ca5f3a9ed136 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5b102fc29edf http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/f08660f30051 Component : VM Status : Go for integration Date : 01/27/2015 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-01-23-174827.amurillo.jdk9-hs-2015-01-22-snapshot Testing: 126 new failures, 2687 known failures, 323554 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null 7076820: assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData 8035938: Memory leak in JvmtiEnv::GetConstantPool 8040935: -XX:+AggressiveOpts broken: GC triggered before VM initialization completed on several tests 8054494: Remove sun.misc.Unsafe.monitorEnter, monitorExit and tryMonitorEnter 8055146: Split Verifier incorrectly throws VerifyError for getstatic of an array field 8059606: Enable per-method usage of CompileThresholdScaling (per-method compilation thresholds) 8061259: ParNew promotion failed is serialized on a lock 8062961: [TESTBUG] Spurious timeout for runtime/ErrorHandling/ProblematicFrameTest 8065576: Enable pipefail in the shell used by make to better detect build errors 8066312: Add new Node* Node::find_out(int opc) method. 8066875: VirtualSpace does not use large pages 8067374: Use %f instead of %g for LogCompilation output 8067479: verify-modules fails in bootcycle build 8067751: OOMEInReferenceHandler.java fails: Cleaner terminated abnormally 8067982: Some jcmd /gc/heap_dump tests failed: hprof output contains warning or error. 8068026: [TESTBUG] Check for -client in gc/g1/TestHumongousCodeCacheRoots.java 8068231: Several tests are still excluded 8068234: java/lang/instrument/NativeMethodPrefixAgent.java is still in exclude list 8068385: [TESTBUG] hotspot/test/compiler/codecache/jmx/PoolsIndependenceTest.java sometimes fails(unstable behaviour) 8068503: ppc64: Encode/Decode nodes for disjoint cOops mode 8068864: C2 failed: modified node is not on IGVN._worklist 8068881: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat 8068971: A heap region being cleared should not belong to the cset 8069011: gc/TestSmallHeap.java failing in nightly 8069048: (process) Suspend finishing threads when process exits [win] 8069162: quarantine serviceability/dcmd/compiler/CompilerQueueTest.java 8069230: Remove unused G1PostBarrierStub::byte_map_base and friends -- Alejandro From staffan.friberg at oracle.com Wed Jan 28 00:36:41 2015 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 27 Jan 2015 16:36:41 -0800 Subject: Naming the new tree/forest for benchmarks (JEP-230) Message-ID: <54C82F19.70603@oracle.com> Hi, With JEP-230 [1], being proposed to target I wanted to continue the discussion around the benchmark repository. The previous discussion concluded that creating a new top-level repository for benchmarks was the best way to move forward [2]. This time around I would like to get some feedback on naming the repository and microbenchmark directory. The current example in the JEP is the following. /benchmark/microbenchmark I have got some offline feedback that this is a bit too long and it would be great to shorten it a bit. This would be a reasonable short version, while still being clear about the contents of the repository. /benchmark/micro If no one objects I will start planning to use this as the naming for the repository and the microbenchmark sub-directory. Regards, Staffan [1] - http://openjdk.java.net/jeps/230 [2] - http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-December/001647.html From stuart.marks at oracle.com Wed Jan 28 01:01:13 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 27 Jan 2015 17:01:13 -0800 Subject: please review draft, informational JEP to cover @apiNote, @implSpec, @implNote javadoc tags Message-ID: <54C834D9.8090500@oracle.com> Hi all, Please review the following draft JEP: https://bugs.openjdk.java.net/browse/JDK-8068562 This is an informational JEP that's intended to document the new javadoc custom tags that were introduced in JDK 8. Many of you noticed that these tags appeared in the javadoc for JDK 8 and have asked about what they mean and where they're defined. That's what this JEP is intended to do. s'marks From chris.hegarty at oracle.com Wed Jan 28 16:00:56 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 28 Jan 2015 16:00:56 +0000 Subject: please review draft, informational JEP to cover @apiNote, @implSpec, @implNote javadoc tags In-Reply-To: <54C834D9.8090500@oracle.com> References: <54C834D9.8090500@oracle.com> Message-ID: <54C907B8.6010000@oracle.com> On 28/01/15 01:01, Stuart Marks wrote: > Hi all, > > Please review the following draft JEP: > > https://bugs.openjdk.java.net/browse/JDK-8068562 > > This is an informational JEP that's intended to document the new javadoc > custom tags that were introduced in JDK 8. Many of you noticed that > these tags appeared in the javadoc for JDK 8 and have asked about what > they mean and where they're defined. That's what this JEP is intended to > do. Thank you, this is very helpful. -Chris. > s'marks From lana.steuck at oracle.com Wed Jan 28 23:32:27 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 28 Jan 2015 15:32:27 -0800 (PST) Subject: jdk9-b48: dev Message-ID: <201501282332.t0SNWR7O023529@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/0064e246d83f http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/f08660f30051 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/5b102fc29edf http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ebb2eb7f1aec http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/33e7e6998048 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/833051855168 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/cc775a4a24c7 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/a13c49c5f289 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8055489 client-libs Better substitution formats JDK-8067657 client-libs Dead/outdated links in Javadoc of package java.beans JDK-8056276 client-libs Fontmanager feature improvements JDK-8055304 client-libs More boxing for DirectoryComboBoxModel JDK-7180976 client-libs Pending String deadlocks UIDefaults JDK-8068275 client-libs Some tests failed after JDK-8063104 JDK-8056214 client-libs Stop including libjawt in libawt_xawt JDK-4796987 client-libs XP Only: JButton.setBorderPainted() does not work with XP L&F JDK-8054358 client-libs move awt automated tests from AWT_Modality to OpenJDK repository - par JDK-6219960 client-libs null reference in ToolTipManager JDK-8067748 core-libs (process) Child is terminated when parent's console is closed [win] JDK-8069211 core-libs (zipfs) ZipFileSystem creates corrupted zip if entry output stream get JDK-8068732 core-libs Add initial RowSet tests JDK-8060077 core-libs Class.toGenericString specification doesn't mention array types JDK-8061448 core-libs Cleanup sun/misc/JarIndex tests to remove the check for the jre direct JDK-8067880 core-libs Dead typed push methods in ArrayData JDK-8069262 core-libs Doclint regression in java.nio.channels.Channels JDK-8048035 core-libs Ensure proper proxy protocols JDK-8065994 core-libs HTTP Tunnel connection to NTLM proxy reauthenticates instead of using JDK-8068427 core-libs Hashtable deserialization reconstitutes table with wrong capacity JDK-8068795 core-libs HttpServer missing tailing space for some response codes JDK-8068432 core-libs Inconsistent exception handling in CompletableFuture.thenCompose JDK-8062901 core-libs Iterators is spelled incorrectly in the Javadoc for Spliterator JDK-8042262 core-libs Javadoc typo in java.util.Formatter JDK-8056264 core-libs Multicast support improvements JDK-8068603 core-libs NashornScriptEngine.put/get() impls don't conform to NPE, IAE spec ass JDK-8055309 core-libs RMI needs better transportation considerations JDK-8067951 core-libs System.loadLibrary cannot find library when path contains quoted entry JDK-6933879 core-libs URISyntaxException when non-alphanumeric characters are present in sco JDK-8055314 core-libs Update refactoring for new loader JDK-8037394 core-libs ZipFileSystem leaks file descriptor when file is not a valid zip file JDK-8055319 core-svc Update JFR log dates JDK-8038309 core-svc closed/javax/management/openmbean/OpenTypeClassNameTest.java failed be JDK-8047115 deploy Better plug and play for plugins JDK-8050832 deploy Burning Chrome JDK-8068187 deploy Fix Xcode project JDK-8054393 deploy Integrate WebStart options JDK-8068415 deploy JDK-8064477 broke linux build JDK-8059049 deploy Less service for server sockets JDK-8068426 deploy Linux build broken - JDK-8068313 deploy Parsing JNLP file should not cause download of extensions. JDK-8050533 deploy Uniform treatment of Jar file entries JDK-8052111 deploy Update cache refresh policy JDK-8067641 deploy [test] reduce size of javaws/manual/CustomProgress/ JDK-8068539 deploy javaws Dead Native Code Cleanup JDK-8068421 deploy linux build still broken after JDK-8068415 JDK-8064835 deploy testExclude - At this 2 resources should be excluded expected:<2> but JDK-8068407 deploy two deployment junit tests fail in JDK9 due to rt.jar assumptions JDK-8047125 hotspot (ref) More phantom object references JDK-8067187 hotspot -XX:MaxMetaspaceSize=20m -Xshare:dump caused JVM to crash JDK-8059342 hotspot Add test to cover JDK-8030976 JDK-8049253 hotspot Better GC validation JDK-8050807 hotspot Better performing performance data handling JDK-8058982 hotspot Better verification of an exceptional invokespecial JDK-8065894 hotspot CodeHeap::next_free should be renamed JDK-8068584 hotspot Compiler attach tests should be quarantined JDK-8064524 hotspot Compiler code generation improvements JDK-8069021 hotspot Exclude compiler/codecache/stress tests from JPRT runs JDK-8068661 hotspot Exclude compiler/whitebox/ForceNMethodSweepTest.java from nightly runs JDK-8068746 hotspot Exclude hotspot/test/compiler/codecache/jmx/PoolsIndependenceTest.java JDK-8047130 hotspot Fewer escapes from escape analysis JDK-8068739 hotspot G1CollectorPolicy uses uninitialized field '_sigma' in the constructor JDK-8067306 hotspot Improve STATIC_ASSERT JDK-8059551 hotspot JEP-JDK-8043304: Test task: stress tests JDK-8063086 hotspot Math.pow yields different results upon repeated calls JDK-8068269 hotspot RTM tests that assert on non-zero lock statistics are too strict in RT JDK-8068037 hotspot Remove dead code in G1CollectedHeap JDK-8068396 hotspot Rename assert() to vmassert() JDK-8048949 hotspot Requeue queue implementation JDK-8055479 hotspot TLAB stability JDK-8067368 hotspot TestConcMarkCycleWB.java crashed at G1CollectedHeap::heap()+0xb JDK-8068653 hotspot TestSmalllHeap.java fails when the page size is 64k JDK-8062450 hotspot Timeout in LowMemoryTest.java JDK-8058897 hotspot Unsafe.reallocateMemory() ignores -XX:MallocMaxTestWords setting JDK-8062063 hotspot Usage of UseHugeTLBFS, UseLargePagesInMetaspace and huge SurvivorAlign JDK-8067331 hotspot Zero: Atomic::xchg and Atomic::xchg_ptr need full memory barrier JDK-8068013 hotspot [TESTBUG] Aix support in hotspot jtreg tests JDK-8068540 hotspot [TESTBUG] Exclude failing nightly tests JDK-8067941 hotspot [TESTBUG] Fix tests for OS with 64K page size. JDK-8060219 hotspot [TESTBUG] runtime/7194254/Test7194254.java fails to find jstack with JDK-8068733 hotspot [TESTBUG] runtime/Unsafe/Reallocate.java sometimes fails when running JDK-8027626 hotspot assert(Opcode() != Op_If || outcnt() == 2) failed: bad if #1 JDK-8068718 hotspot com/sun/jdi/CatchPatternTest.sh should be quarantined JDK-8049355 hotspot compiler/rtm/locking/TestRTMLockingThreshold test may fail if transact JDK-8068505 hotspot interpreter profiling incorrect on PPC64 JDK-8068724 hotspot ppc64: update assembler: SPR access, CR logic, HTM JDK-8065226 hotspot sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be quarantined JDK-8027829 hotspot CompileCommand does not accept all JLS-conformant class/method names JDK-8064595 install Improved path for installer upgrades JDK-8067251 install RegisterDeploy ping not working correctly JDK-8061210 security-libs Issues in TLS JDK-8057555 security-libs Less cryptic cipher suite management JDK-8059485 security-libs Resolve parsing ambiguity JDK-8047769 security-libs SecureRandom should be more frugal with file descriptors JDK-8069155 security-libs The value of 'KeyStore Type' isn't 'jks' JDK-8046656 security-libs Update protocol support JDK-8069038 security-libs javax/net/ssl/TLS/TLSClientPropertyTest.java needs to be updated for J JDK-8071313 security-libs krb5.conf not read if SCDynamicStore krb5 config is empty JDK-8046977 tools ClassCastException: typing information needed for method reference bri JDK-8068488 tools Facilitate extension of the javac parser -- missing modifier JDK-8070507 tools LambdaLambdaSerialized can fail in -agentvm mode JDK-8069094 tools SuppressWarnings("deprecation") not respected on default clause on ann JDK-8071310 tools Tests missing for checkin for JDK-8046977 JDK-8069254 tools Warning issued despite @SafeVarargs annotation on constructor JDK-8052070 tools javac crashes when there are duplicated type parameters JDK-8069229 tools new .java file with no copyright notice JDK-8054367 xml More references for endpoints