From bengt.rutisson at oracle.com Wed Oct 1 08:56:41 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 01 Oct 2014 10:56:41 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs Message-ID: <542BC1C9.9000204@oracle.com> Hi everyone, (This is a patch for webrev, but I am cross posting to the JDK 9 dev list since I'm not sure how many are on the webrev-dev list and most JDK developers might have opinions about this change.) Can I get a couple of reviews for this small enhancement to the webrev tool? CODETOOLS-7901044: Add next/prev links to navigate between diffs https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 Webrev: http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ Background: When browsing review requests that span many files it is quite time consuming to have to go back to the index page to view to the next or previous file. This patch adds links to the next and previous files in the diff views (including frames). The above webrev is generated with this new version, but since it only contains a single file it is not that interesting. Here is an example of what the new webrev looks like for a larger change (the G1 class unloading change): http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ Thanks, Bengt From daniel.fuchs at oracle.com Wed Oct 1 13:53:38 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 01 Oct 2014 15:53:38 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542BC1C9.9000204@oracle.com> References: <542BC1C9.9000204@oracle.com> Message-ID: <542C0762.5070700@oracle.com> Hi Bengt, This is a really cool feature! I have downloaded your patch and applied it in my local webrev repo - and played with the new webrev in a couple of repositories where I have pending uncommitted changes. This seems to work well. I have used: webrev -fN from top level repo webrev -N from jdk repo webrev -fN from jdk repo (with changes in test/closed) I also had a cursory look at your patch. The only thing I noticed is that 'typeset' is not consistently used in the original webrev file. I'm not sure whether that's intended or not. I believe that's ok - but I've been bitten by not using typeset before ;-( - maybe - for the sake of uniformity - you could use typeset at least in those functions that already use it for their parameters? For instance lines 532-534, and possibly line 560 as well? Or did you intentionally not used it? Also you should increment the version of webrev. IIRC that would be 25.6: - WEBREV_UPDATED=25.5-hg+openjdk.java.net + WEBREV_UPDATED=25.6-hg+openjdk.java.net best regards, -- daniel On 01/10/14 10:56, Bengt Rutisson wrote: > > Hi everyone, > > (This is a patch for webrev, but I am cross posting to the JDK 9 dev > list since I'm not sure how many are on the webrev-dev list and most JDK > developers might have opinions about this change.) > > Can I get a couple of reviews for this small enhancement to the webrev > tool? > > CODETOOLS-7901044: Add next/prev links to navigate between diffs > https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 > > Webrev: > http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ > > > Background: > When browsing review requests that span many files it is quite time > consuming to have to go back to the index page to view to the next or > previous file. This patch adds links to the next and previous files in > the diff views (including frames). > > The above webrev is generated with this new version, but since it only > contains a single file it is not that interesting. Here is an example of > what the new webrev looks like for a larger change (the G1 class > unloading change): > > http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ > > Thanks, > Bengt > From david.r.chase at oracle.com Wed Oct 1 13:59:54 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 1 Oct 2014 09:59:54 -0400 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542BC1C9.9000204@oracle.com> References: <542BC1C9.9000204@oracle.com> Message-ID: I thought we had that in what I know of as ?webrev-new?, see for example: http://cr.openjdk.java.net/~drchase/8037816/webrev-9.05-09b/src/cpu/x86/vm/c1_LinearScan_x86.cpp.sdiff.html But yours is also nice :-). David On 2014-10-01, at 4:56 AM, Bengt Rutisson wrote: > > Hi everyone, > > (This is a patch for webrev, but I am cross posting to the JDK 9 dev list since I'm not sure how many are on the webrev-dev list and most JDK developers might have opinions about this change.) > > Can I get a couple of reviews for this small enhancement to the webrev tool? > > CODETOOLS-7901044: Add next/prev links to navigate between diffs > https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 > > Webrev: > http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ > > > Background: > When browsing review requests that span many files it is quite time consuming to have to go back to the index page to view to the next or previous file. This patch adds links to the next and previous files in the diff views (including frames). > > The above webrev is generated with this new version, but since it only contains a single file it is not that interesting. Here is an example of what the new webrev looks like for a larger change (the G1 class unloading change): > > http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ > > Thanks, > Bengt > From bengt.rutisson at oracle.com Wed Oct 1 13:57:18 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 01 Oct 2014 15:57:18 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542C0762.5070700@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> Message-ID: <542C083E.40208@oracle.com> Hi Daniel, Thanks for looking at this! On 2014-10-01 15:53, Daniel Fuchs wrote: > Hi Bengt, > > This is a really cool feature! Thanks! > > I have downloaded your patch and applied it in my > local webrev repo - and played with the new > webrev in a couple of repositories where I have > pending uncommitted changes. > > This seems to work well. > > I have used: > > webrev -fN from top level repo > webrev -N from jdk repo > webrev -fN from jdk repo (with changes in test/closed) > Great that you tired it out. > I also had a cursory look at your patch. The only thing > I noticed is that 'typeset' is not consistently used in > the original webrev file. I'm not sure whether that's > intended or not. > I believe that's ok - but I've been bitten by not using > typeset before ;-( - maybe - for the sake of uniformity - > you could use typeset at least in those functions that > already use it for their parameters? For instance > lines 532-534, and possibly line 560 as well? > Or did you intentionally not used it? I also noticed the inconsistent use of typeset. I fixed the lines you pointed out. I wasn't sure which way to go. But I think your suggestion is good. > > Also you should increment the version of webrev. > IIRC that would be 25.6: > > - WEBREV_UPDATED=25.5-hg+openjdk.java.net > + WEBREV_UPDATED=25.6-hg+openjdk.java.net Thanks, didn't think of that. New webrev: http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ Diff compared to the first version: http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ Thanks, Bengt > > best regards, > > -- daniel > > On 01/10/14 10:56, Bengt Rutisson wrote: >> >> Hi everyone, >> >> (This is a patch for webrev, but I am cross posting to the JDK 9 dev >> list since I'm not sure how many are on the webrev-dev list and most JDK >> developers might have opinions about this change.) >> >> Can I get a couple of reviews for this small enhancement to the webrev >> tool? >> >> CODETOOLS-7901044: Add next/prev links to navigate between diffs >> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >> >> >> Background: >> When browsing review requests that span many files it is quite time >> consuming to have to go back to the index page to view to the next or >> previous file. This patch adds links to the next and previous files in >> the diff views (including frames). >> >> The above webrev is generated with this new version, but since it only >> contains a single file it is not that interesting. Here is an example of >> what the new webrev looks like for a larger change (the G1 class >> unloading change): >> >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >> >> >> Thanks, >> Bengt >> > From bengt.rutisson at oracle.com Wed Oct 1 14:00:42 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 01 Oct 2014 16:00:42 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: References: <542BC1C9.9000204@oracle.com> Message-ID: <542C090A.5030901@oracle.com> Hi David, On 2014-10-01 15:59, David Chase wrote: > I thought we had that in what I know of as ?webrev-new?, see for example: > > http://cr.openjdk.java.net/~drchase/8037816/webrev-9.05-09b/src/cpu/x86/vm/c1_LinearScan_x86.cpp.sdiff.html This looks like the version I know as "Tom's webrev" :) I think it is nice too. But it does not have next/prev for frames. The main problem with it, though, is that as far as I know there is no official policy that this is the preferred tool. I'd like to get this feature in to the official tool, which as far as I know is in the code-tools repo. > > But yours is also nice :-). Thanks. :) Bengt > > David > > On 2014-10-01, at 4:56 AM, Bengt Rutisson wrote: > >> Hi everyone, >> >> (This is a patch for webrev, but I am cross posting to the JDK 9 dev list since I'm not sure how many are on the webrev-dev list and most JDK developers might have opinions about this change.) >> >> Can I get a couple of reviews for this small enhancement to the webrev tool? >> >> CODETOOLS-7901044: Add next/prev links to navigate between diffs >> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >> >> >> Background: >> When browsing review requests that span many files it is quite time consuming to have to go back to the index page to view to the next or previous file. This patch adds links to the next and previous files in the diff views (including frames). >> >> The above webrev is generated with this new version, but since it only contains a single file it is not that interesting. Here is an example of what the new webrev looks like for a larger change (the G1 class unloading change): >> >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >> >> Thanks, >> Bengt >> From daniel.fuchs at oracle.com Wed Oct 1 14:27:16 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 01 Oct 2014 16:27:16 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542C083E.40208@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> Message-ID: <542C0F44.1000009@oracle.com> Hi Bengt, The new version looks good to me, but I am not a reviewer fore CODE_TOOLS. Hopefully someone who is will step in :-) best regards, -- daniel On 01/10/14 15:57, Bengt Rutisson wrote: > > Hi Daniel, > > Thanks for looking at this! > > On 2014-10-01 15:53, Daniel Fuchs wrote: >> Hi Bengt, >> >> This is a really cool feature! > > Thanks! > >> >> I have downloaded your patch and applied it in my >> local webrev repo - and played with the new >> webrev in a couple of repositories where I have >> pending uncommitted changes. >> >> This seems to work well. >> >> I have used: >> >> webrev -fN from top level repo >> webrev -N from jdk repo >> webrev -fN from jdk repo (with changes in test/closed) >> > > Great that you tired it out. > >> I also had a cursory look at your patch. The only thing >> I noticed is that 'typeset' is not consistently used in >> the original webrev file. I'm not sure whether that's >> intended or not. >> I believe that's ok - but I've been bitten by not using >> typeset before ;-( - maybe - for the sake of uniformity - >> you could use typeset at least in those functions that >> already use it for their parameters? For instance >> lines 532-534, and possibly line 560 as well? >> Or did you intentionally not used it? > > I also noticed the inconsistent use of typeset. I fixed the lines you > pointed out. I wasn't sure which way to go. But I think your suggestion > is good. > >> >> Also you should increment the version of webrev. >> IIRC that would be 25.6: >> >> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >> + WEBREV_UPDATED=25.6-hg+openjdk.java.net > > Thanks, didn't think of that. > > New webrev: > http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ > > Diff compared to the first version: > http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ > > Thanks, > Bengt > >> >> best regards, >> >> -- daniel >> >> On 01/10/14 10:56, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev >>> list since I'm not sure how many are on the webrev-dev list and most JDK >>> developers might have opinions about this change.) >>> >>> Can I get a couple of reviews for this small enhancement to the webrev >>> tool? >>> >>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>> >>> >>> Background: >>> When browsing review requests that span many files it is quite time >>> consuming to have to go back to the index page to view to the next or >>> previous file. This patch adds links to the next and previous files in >>> the diff views (including frames). >>> >>> The above webrev is generated with this new version, but since it only >>> contains a single file it is not that interesting. Here is an example of >>> what the new webrev looks like for a larger change (the G1 class >>> unloading change): >>> >>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>> >>> >>> Thanks, >>> Bengt >>> >> > From coleen.phillimore at oracle.com Wed Oct 1 15:52:18 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Oct 2014 11:52:18 -0400 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542C0F44.1000009@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> Message-ID: <542C2332.3060508@oracle.com> Bengt, Thanks for doing this. I filed an issue for this a long time ago, that you can close as a duplicate. https://bugs.openjdk.java.net/browse/CODETOOLS-7900314 Does it work for added and deleted files? Coleen On 10/1/14, 10:27 AM, Daniel Fuchs wrote: > Hi Bengt, > > The new version looks good to me, but I am not a reviewer > fore CODE_TOOLS. Hopefully someone who is will step in :-) > > best regards, > > -- daniel > > On 01/10/14 15:57, Bengt Rutisson wrote: >> >> Hi Daniel, >> >> Thanks for looking at this! >> >> On 2014-10-01 15:53, Daniel Fuchs wrote: >>> Hi Bengt, >>> >>> This is a really cool feature! >> >> Thanks! >> >>> >>> I have downloaded your patch and applied it in my >>> local webrev repo - and played with the new >>> webrev in a couple of repositories where I have >>> pending uncommitted changes. >>> >>> This seems to work well. >>> >>> I have used: >>> >>> webrev -fN from top level repo >>> webrev -N from jdk repo >>> webrev -fN from jdk repo (with changes in test/closed) >>> >> >> Great that you tired it out. >> >>> I also had a cursory look at your patch. The only thing >>> I noticed is that 'typeset' is not consistently used in >>> the original webrev file. I'm not sure whether that's >>> intended or not. >>> I believe that's ok - but I've been bitten by not using >>> typeset before ;-( - maybe - for the sake of uniformity - >>> you could use typeset at least in those functions that >>> already use it for their parameters? For instance >>> lines 532-534, and possibly line 560 as well? >>> Or did you intentionally not used it? >> >> I also noticed the inconsistent use of typeset. I fixed the lines you >> pointed out. I wasn't sure which way to go. But I think your suggestion >> is good. >> >>> >>> Also you should increment the version of webrev. >>> IIRC that would be 25.6: >>> >>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >> >> Thanks, didn't think of that. >> >> New webrev: >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >> >> Diff compared to the first version: >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >> >> >> Thanks, >> Bengt >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>> >>>> Hi everyone, >>>> >>>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev >>>> list since I'm not sure how many are on the webrev-dev list and >>>> most JDK >>>> developers might have opinions about this change.) >>>> >>>> Can I get a couple of reviews for this small enhancement to the webrev >>>> tool? >>>> >>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>> >>>> >>>> Background: >>>> When browsing review requests that span many files it is quite time >>>> consuming to have to go back to the index page to view to the next or >>>> previous file. This patch adds links to the next and previous files in >>>> the diff views (including frames). >>>> >>>> The above webrev is generated with this new version, but since it only >>>> contains a single file it is not that interesting. Here is an >>>> example of >>>> what the new webrev looks like for a larger change (the G1 class >>>> unloading change): >>>> >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>> >>>> >>>> >>>> Thanks, >>>> Bengt >>>> >>> >> > From bengt.rutisson at oracle.com Wed Oct 1 21:11:13 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 01 Oct 2014 23:11:13 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542C0F44.1000009@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> Message-ID: <542C6DF1.1060409@oracle.com> Hi Daniel, On 10/1/14 4:27 PM, Daniel Fuchs wrote: > Hi Bengt, > > The new version looks good to me, but I am not a reviewer > fore CODE_TOOLS. Thanks for looking at this Daniel! > Hopefully someone who is will step in :-) Yes, and I am not a committer in code-tools so I need a sponsor for the patch too. Thanks, Bengt > > best regards, > > -- daniel > > On 01/10/14 15:57, Bengt Rutisson wrote: >> >> Hi Daniel, >> >> Thanks for looking at this! >> >> On 2014-10-01 15:53, Daniel Fuchs wrote: >>> Hi Bengt, >>> >>> This is a really cool feature! >> >> Thanks! >> >>> >>> I have downloaded your patch and applied it in my >>> local webrev repo - and played with the new >>> webrev in a couple of repositories where I have >>> pending uncommitted changes. >>> >>> This seems to work well. >>> >>> I have used: >>> >>> webrev -fN from top level repo >>> webrev -N from jdk repo >>> webrev -fN from jdk repo (with changes in test/closed) >>> >> >> Great that you tired it out. >> >>> I also had a cursory look at your patch. The only thing >>> I noticed is that 'typeset' is not consistently used in >>> the original webrev file. I'm not sure whether that's >>> intended or not. >>> I believe that's ok - but I've been bitten by not using >>> typeset before ;-( - maybe - for the sake of uniformity - >>> you could use typeset at least in those functions that >>> already use it for their parameters? For instance >>> lines 532-534, and possibly line 560 as well? >>> Or did you intentionally not used it? >> >> I also noticed the inconsistent use of typeset. I fixed the lines you >> pointed out. I wasn't sure which way to go. But I think your suggestion >> is good. >> >>> >>> Also you should increment the version of webrev. >>> IIRC that would be 25.6: >>> >>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >> >> Thanks, didn't think of that. >> >> New webrev: >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >> >> Diff compared to the first version: >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >> >> >> Thanks, >> Bengt >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>> >>>> Hi everyone, >>>> >>>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev >>>> list since I'm not sure how many are on the webrev-dev list and >>>> most JDK >>>> developers might have opinions about this change.) >>>> >>>> Can I get a couple of reviews for this small enhancement to the webrev >>>> tool? >>>> >>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>> >>>> >>>> Background: >>>> When browsing review requests that span many files it is quite time >>>> consuming to have to go back to the index page to view to the next or >>>> previous file. This patch adds links to the next and previous files in >>>> the diff views (including frames). >>>> >>>> The above webrev is generated with this new version, but since it only >>>> contains a single file it is not that interesting. Here is an >>>> example of >>>> what the new webrev looks like for a larger change (the G1 class >>>> unloading change): >>>> >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>> >>>> >>>> >>>> Thanks, >>>> Bengt >>>> >>> >> > From bengt.rutisson at oracle.com Wed Oct 1 21:24:25 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 01 Oct 2014 23:24:25 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542C2332.3060508@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C2332.3060508@oracle.com> Message-ID: <542C7109.7040502@oracle.com> Coleen, On 10/1/14 5:52 PM, Coleen Phillimore wrote: > > Bengt, > > Thanks for doing this. I filed an issue for this a long time ago, > that you can close as a duplicate. > https://bugs.openjdk.java.net/browse/CODETOOLS-7900314 Thanks for pointing that out. Didn't know about that issue. Should probably have used that instead of filing a new one. I closed CODETOOLS-7900314 as a duplicate. > > Does it work for added and deleted files? Probably not the way you would like :) It works in the sense that the webrev will be correctly generated, but I haven't added next/prev links to the "new" and "old" views. And it wasn't really clear to me what the "next" link should do once you pass the last diff view. Should you jump to the "new" view even though you had selected to view, say udiff? Instead of trying to solve that I opted to just have next/prev links for the diff views (cdiff, udiff, sdiff and frames). These all come first in the file list for normally generated webrevs. So, when there are only added and removed files left the next button takes you back to the index page. Hopefully this solves the most common use cases. And for the others - webrevs with lots of new or deleted files - my change does not help but also does not make things worse than before. Thanks, Bengt > > Coleen > > On 10/1/14, 10:27 AM, Daniel Fuchs wrote: >> Hi Bengt, >> >> The new version looks good to me, but I am not a reviewer >> fore CODE_TOOLS. Hopefully someone who is will step in :-) >> >> best regards, >> >> -- daniel >> >> On 01/10/14 15:57, Bengt Rutisson wrote: >>> >>> Hi Daniel, >>> >>> Thanks for looking at this! >>> >>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>> Hi Bengt, >>>> >>>> This is a really cool feature! >>> >>> Thanks! >>> >>>> >>>> I have downloaded your patch and applied it in my >>>> local webrev repo - and played with the new >>>> webrev in a couple of repositories where I have >>>> pending uncommitted changes. >>>> >>>> This seems to work well. >>>> >>>> I have used: >>>> >>>> webrev -fN from top level repo >>>> webrev -N from jdk repo >>>> webrev -fN from jdk repo (with changes in test/closed) >>>> >>> >>> Great that you tired it out. >>> >>>> I also had a cursory look at your patch. The only thing >>>> I noticed is that 'typeset' is not consistently used in >>>> the original webrev file. I'm not sure whether that's >>>> intended or not. >>>> I believe that's ok - but I've been bitten by not using >>>> typeset before ;-( - maybe - for the sake of uniformity - >>>> you could use typeset at least in those functions that >>>> already use it for their parameters? For instance >>>> lines 532-534, and possibly line 560 as well? >>>> Or did you intentionally not used it? >>> >>> I also noticed the inconsistent use of typeset. I fixed the lines you >>> pointed out. I wasn't sure which way to go. But I think your suggestion >>> is good. >>> >>>> >>>> Also you should increment the version of webrev. >>>> IIRC that would be 25.6: >>>> >>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>> >>> Thanks, didn't think of that. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>> >>> Diff compared to the first version: >>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>> >>> >>> Thanks, >>> Bengt >>> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev >>>>> list since I'm not sure how many are on the webrev-dev list and >>>>> most JDK >>>>> developers might have opinions about this change.) >>>>> >>>>> Can I get a couple of reviews for this small enhancement to the >>>>> webrev >>>>> tool? >>>>> >>>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>> >>>>> >>>>> Background: >>>>> When browsing review requests that span many files it is quite time >>>>> consuming to have to go back to the index page to view to the next or >>>>> previous file. This patch adds links to the next and previous >>>>> files in >>>>> the diff views (including frames). >>>>> >>>>> The above webrev is generated with this new version, but since it >>>>> only >>>>> contains a single file it is not that interesting. Here is an >>>>> example of >>>>> what the new webrev looks like for a larger change (the G1 class >>>>> unloading change): >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Oct 1 21:38:01 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Oct 2014 17:38:01 -0400 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542C7109.7040502@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C2332.3060508@oracle.com> <542C7109.7040502@oracle.com> Message-ID: <542C7439.50307@oracle.com> On 10/1/14, 5:24 PM, Bengt Rutisson wrote: > > Coleen, > > On 10/1/14 5:52 PM, Coleen Phillimore wrote: >> >> Bengt, >> >> Thanks for doing this. I filed an issue for this a long time ago, >> that you can close as a duplicate. >> https://bugs.openjdk.java.net/browse/CODETOOLS-7900314 > > Thanks for pointing that out. Didn't know about that issue. Should > probably have used that instead of filing a new one. I closed > CODETOOLS-7900314 as a duplicate. > >> >> Does it work for added and deleted files? > > Probably not the way you would like :) That's ok. The next person can enhance that. Thanks for adding the navigation. Coleen > > It works in the sense that the webrev will be correctly generated, but > I haven't added next/prev links to the "new" and "old" views. And it > wasn't really clear to me what the "next" link should do once you pass > the last diff view. Should you jump to the "new" view even though you > had selected to view, say udiff? > > Instead of trying to solve that I opted to just have next/prev links > for the diff views (cdiff, udiff, sdiff and frames). These all come > first in the file list for normally generated webrevs. So, when there > are only added and removed files left the next button takes you back > to the index page. > > Hopefully this solves the most common use cases. And for the others - > webrevs with lots of new or deleted files - my change does not help > but also does not make things worse than before. > > Thanks, > Bengt > >> >> Coleen >> >> On 10/1/14, 10:27 AM, Daniel Fuchs wrote: >>> Hi Bengt, >>> >>> The new version looks good to me, but I am not a reviewer >>> fore CODE_TOOLS. Hopefully someone who is will step in :-) >>> >>> best regards, >>> >>> -- daniel >>> >>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>> >>>> Hi Daniel, >>>> >>>> Thanks for looking at this! >>>> >>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>> Hi Bengt, >>>>> >>>>> This is a really cool feature! >>>> >>>> Thanks! >>>> >>>>> >>>>> I have downloaded your patch and applied it in my >>>>> local webrev repo - and played with the new >>>>> webrev in a couple of repositories where I have >>>>> pending uncommitted changes. >>>>> >>>>> This seems to work well. >>>>> >>>>> I have used: >>>>> >>>>> webrev -fN from top level repo >>>>> webrev -N from jdk repo >>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>> >>>> >>>> Great that you tired it out. >>>> >>>>> I also had a cursory look at your patch. The only thing >>>>> I noticed is that 'typeset' is not consistently used in >>>>> the original webrev file. I'm not sure whether that's >>>>> intended or not. >>>>> I believe that's ok - but I've been bitten by not using >>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>> you could use typeset at least in those functions that >>>>> already use it for their parameters? For instance >>>>> lines 532-534, and possibly line 560 as well? >>>>> Or did you intentionally not used it? >>>> >>>> I also noticed the inconsistent use of typeset. I fixed the lines you >>>> pointed out. I wasn't sure which way to go. But I think your >>>> suggestion >>>> is good. >>>> >>>>> >>>>> Also you should increment the version of webrev. >>>>> IIRC that would be 25.6: >>>>> >>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>> >>>> Thanks, didn't think of that. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>> >>>> Diff compared to the first version: >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev >>>>>> list since I'm not sure how many are on the webrev-dev list and >>>>>> most JDK >>>>>> developers might have opinions about this change.) >>>>>> >>>>>> Can I get a couple of reviews for this small enhancement to the >>>>>> webrev >>>>>> tool? >>>>>> >>>>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>> >>>>>> >>>>>> Background: >>>>>> When browsing review requests that span many files it is quite time >>>>>> consuming to have to go back to the index page to view to the >>>>>> next or >>>>>> previous file. This patch adds links to the next and previous >>>>>> files in >>>>>> the diff views (including frames). >>>>>> >>>>>> The above webrev is generated with this new version, but since it >>>>>> only >>>>>> contains a single file it is not that interesting. Here is an >>>>>> example of >>>>>> what the new webrev looks like for a larger change (the G1 class >>>>>> unloading change): >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>> >>>> >>> >> > From John.Coomes at oracle.com Wed Oct 1 23:08:32 2014 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 1 Oct 2014 16:08:32 -0700 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542C6DF1.1060409@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> Message-ID: <21548.35184.576946.43474@mykonos.us.oracle.com> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > > Hi Daniel, > > On 10/1/14 4:27 PM, Daniel Fuchs wrote: > > Hi Bengt, > > > > The new version looks good to me, but I am not a reviewer > > fore CODE_TOOLS. > > Thanks for looking at this Daniel! > > > Hopefully someone who is will step in :-) > > Yes, and I am not a committer in code-tools so I need a sponsor for the > patch too. Looks good to me; I'll sponsor it. Send me (privately) the result of "hg export --git" and I'll push that. -John > > best regards, > > > > -- daniel > > > > On 01/10/14 15:57, Bengt Rutisson wrote: > >> > >> Hi Daniel, > >> > >> Thanks for looking at this! > >> > >> On 2014-10-01 15:53, Daniel Fuchs wrote: > >>> Hi Bengt, > >>> > >>> This is a really cool feature! > >> > >> Thanks! > >> > >>> > >>> I have downloaded your patch and applied it in my > >>> local webrev repo - and played with the new > >>> webrev in a couple of repositories where I have > >>> pending uncommitted changes. > >>> > >>> This seems to work well. > >>> > >>> I have used: > >>> > >>> webrev -fN from top level repo > >>> webrev -N from jdk repo > >>> webrev -fN from jdk repo (with changes in test/closed) > >>> > >> > >> Great that you tired it out. > >> > >>> I also had a cursory look at your patch. The only thing > >>> I noticed is that 'typeset' is not consistently used in > >>> the original webrev file. I'm not sure whether that's > >>> intended or not. > >>> I believe that's ok - but I've been bitten by not using > >>> typeset before ;-( - maybe - for the sake of uniformity - > >>> you could use typeset at least in those functions that > >>> already use it for their parameters? For instance > >>> lines 532-534, and possibly line 560 as well? > >>> Or did you intentionally not used it? > >> > >> I also noticed the inconsistent use of typeset. I fixed the lines you > >> pointed out. I wasn't sure which way to go. But I think your suggestion > >> is good. > >> > >>> > >>> Also you should increment the version of webrev. > >>> IIRC that would be 25.6: > >>> > >>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net > >>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net > >> > >> Thanks, didn't think of that. > >> > >> New webrev: > >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ > >> > >> Diff compared to the first version: > >> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ > >> > >> > >> Thanks, > >> Bengt > >> > >>> > >>> best regards, > >>> > >>> -- daniel > >>> > >>> On 01/10/14 10:56, Bengt Rutisson wrote: > >>>> > >>>> Hi everyone, > >>>> > >>>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev > >>>> list since I'm not sure how many are on the webrev-dev list and > >>>> most JDK > >>>> developers might have opinions about this change.) > >>>> > >>>> Can I get a couple of reviews for this small enhancement to the webrev > >>>> tool? > >>>> > >>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs > >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ > >>>> > >>>> > >>>> Background: > >>>> When browsing review requests that span many files it is quite time > >>>> consuming to have to go back to the index page to view to the next or > >>>> previous file. This patch adds links to the next and previous files in > >>>> the diff views (including frames). > >>>> > >>>> The above webrev is generated with this new version, but since it only > >>>> contains a single file it is not that interesting. Here is an > >>>> example of > >>>> what the new webrev looks like for a larger change (the G1 class > >>>> unloading change): > >>>> > >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> Bengt > >>>> > >>> > >> > > > From lana.steuck at oracle.com Thu Oct 2 03:23:05 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 1 Oct 2014 20:23:05 -0700 (PDT) Subject: jdk9-b33: dev Message-ID: <201410020323.s923N5ek026020@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/e4ba01b726e2 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/b374d8910e7f http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/e891e0c4edc5 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/60fe681c30bc http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/77a45995dd3b http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/46b360454dad http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9b3f5e4f3372 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/cfdac5887952 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8041465 client-libs BMPImageReader read error using ImageReadParam with set sourceRectangle JDK-8056213 client-libs Clean up unix/native/common/sun/awt JDK-8055326 client-libs Fix typos in client-related packages JDK-6588417 client-libs Incorrect javadoc: no @throws or @exception tag in javax.* JDK-8057940 client-libs JCK test api/java_awt/Image/renderable/ParameterBlock fails with StackOverflowError JDK-8057977 client-libs Java Access Bridge, regression, NPE, occurs randomly JDK-8058248 client-libs LittleCMS: Missing checks for NULL returns from memory allocation functions JDK-8057819 client-libs No CCC approving removing final modifier from javax.swing.SwingUtilities.isRectangleContainingRectangle static method JDK-8056991 client-libs Provide OSInfo functionality to regression tests JDK-8046191 client-libs Re-examine the need of access-bridge-32.jar and access-bridge.jar in 32-bit JDK JDK-8056216 client-libs Remove "sun" directory layer from libawt and common JDK-8058136 client-libs Test api/java_awt/SplashScreen/index.html\#ClosedSplashScreenTests fails because of java.lang.IllegalStateException was not thrown JDK-8058653 client-libs Test java/awt/Graphics2D/DrawString/DrawStringCrash.java fails with OutOfMemoryError JDK-8058635 client-libs Test sun/awt/datatransfer/SuplementaryCharactersTransferTest.java fails with compilation error JDK-8058726 client-libs Update regtests using sun.awt.OSInfo, part 1 JDK-8057934 client-libs Upgrade to LittleCMS 2.6 breaks AIX build JDK-8048110 client-libs Using tables in JTextPane leads to infinite loop in FlowLayout.layoutRow JDK-8057770 client-libs api/javax_swing/JScrollPane/indexTGF.html#UpdateUI failed with MotifLookAndFeel on all platform JDK-8054877 client-libs javadoc issues in javax.print JDK-8058099 core-libs (fc) Cleanup in FileChannel/FileDispatcher native implementation [win] JDK-8058643 core-libs (str) Improve String.hashCode implementation JDK-8058550 core-libs Clarify that TimerTasks are not reusable JDK-8043740 core-libs Doubles with large exponents overflow to Infinity incorrectly JDK-8055032 core-libs Improve numerical parsing in java.net and sun.net JDK-8047764 core-libs Indexed or polymorphic set on global affects Object.prototype JDK-8046202 core-libs Make persistent code store more flexible JDK-8059132 core-libs Nashorn broke JDK9 build, because JDK make of Nasgen has bootstrapping problems JDK-8057779 core-libs Nashorn: Tests failed on Windows when in output contains path to script JDK-8058561 core-libs NullPointerException at jdk.nashorn.internal.codegen.LocalVariableTypesCalculator.symbolIsUsed(LocalVariableTypesCalculator.java:224) JDK-8050142 core-libs Optimize java.util.Formatter JDK-8025435 core-libs Specialized library functions for optimistic typing JDK-8058728 core-libs TEST_BUG: Make java/lang/invoke/LFCaching/LFGarbageCollectedTest.java skip arrayElementSetter and arrayElementGetter methods JDK-8058520 core-libs jar xf does not work on zip files with leading garbage JDK-4477961 core-libs java.lang.Math.toDegrees(double) could be optimized JDK-8059034 core-svc ProcessTools.startProcess() might leak processes JDK-8058899 core-svc Put test 'java/lang/instrument/NativeMethodPrefixAgent.java' on ProblemList JDK-8058651 core-svc com/sun/jdi/RedefinePop.sh should be quarantined JDK-8058649 core-svc java/lang/management/ThreadMXBean/FindDeadlocks.java should be quarantined JDK-8058652 core-svc java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java should be quarantined JDK-8058647 core-svc sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java should be quarantined JDK-8057149 core-svc sun/management/jmxremote/startstop/JMXStartStopTest.java fails with "Starting agent on port ... should report port in use" JDK-8029579 deploy "Application Error" dialog will show up after click "OK" on "Application Blocked" dialog JDK-8046501 deploy DRS - cert based run rule doesn't work when running offline JDK-8025917 deploy JDK demo applets not running with >=7u40 or (JDK 8 and JDK 9) JDK-8051890 deploy Java Web Start raises "Unable to create a shortcut for " dialog JDK-8057593 deploy Using const SECURITY_LEVEL_TEXT_DESCRIPTION_COLUMNS in JDK9 ScurityPanel.java to keep related code in sync with JDK8 and JDK7 JDK-8056972 deploy java-vm-args don't respect -D options JDK-8057744 hotspot (process) Synchronize exiting of threads and process [win] JDK-8048721 hotspot -XX:+PrintCompilation prints negative bci for non entrant OSR methods JDK-8041946 hotspot CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap JDK-8055719 hotspot Clean out support for old VC versions from ProjectCreator JDK-8052172 hotspot Evacuation failure handling in G1 does not evacuate all objects if -XX:-G1DeferredRSUpdate is set JDK-8057799 hotspot G1: Unnecessary NULL check in G1KeepAliveClosure JDK-8056039 hotspot Hotspot does not compile with clang 3.4 on Linux JDK-8058729 hotspot JFR tests should not leave temporary files behind JDK-8057564 hotspot JVM hangs at getAgentProperties after attaching to VM with lower JDK-8057768 hotspot Make heap region region type in G1 HeapRegion explicit JDK-8058475 hotspot TestCMSClassUnloadingEnabledHWM.java fails with '.*CMS Initial Mark.*' missing from stdout/stderr JDK-8049864 hotspot TestParallelHeapSizeFlags fails with unexpected heap size JDK-8022865 hotspot [TESTBUG] Compressed Oops testing needs to be revised JDK-8058241 hotspot [TESTBUG] Many AppCDS tests fail if JTREG is invoked with -javaoption:-XX:-UseCompressedOops JDK-8057165 hotspot [TESTBUG] Need a test to cover JDK-8054883 JDK-8058504 hotspot [TESTBUG] Temporarily disable failing test runtime/NMT/MallocTrackingVerify.java JDK-8056237 hotspot [TESTBUG] gc/g1/TestHumongousShrinkHeap.java fails due to OOM JDK-8055145 hotspot [TESTBUG] runtime/7158988/FieldMonitor.java fails with VMDisconnectedException JDK-8058452 hotspot ciInstanceKlass::non_static_fields() can be removed JDK-8057107 hotspot cleanup indent white space issues prior to Contended Locking reorder and cache line bucket JDK-8057109 hotspot manual cleanup of white space issues prior to Contended Locking reorder and cache line bucket JDK-8054174 hotspot minor buglet in computation of end of pc descs in libjvm_db.c JDK-8049536 hotspot os::commit_memory on Solaris uses aligment_hint as page size JDK-8056183 hotspot os::is_MP() always reports true when NMT is enabled JDK-8058763 infrastructure /deploy/make/plugin/nsstub should be excluded from jdk9 source bundles JDK-8058797 infrastructure Building with sjavac broken after JDK-8058118 JDK-8055189 infrastructure Cleanup gensrc after source code restructure JDK-8058579 infrastructure Copy-java.base.gmk no longer needs to differentiate win32 and win64 java.policy JDK-8058775 infrastructure JDK 9 client builds failed with deploy/test/shared directory missing for linux (32 and 64bits) and Mac OSX platforms JDK-8056999 infrastructure Make hotspot builds less verbose on default log level JDK-8058756 infrastructure OpenJDK builds fail on Windows - cannot copy freetype.dll JDK-8047933 infrastructure Race between jdk/make/scripts/genExceptions.sh and com.sun.tools.javadoc.Main JDK-8059101 infrastructure unshuffle_patch.sh should be able to deal with stdin/stdout JDK-8058487 install JRE installer fails if older jre is on the system with MSI 1603 error. System error 183 JDK-8055172 install Java Access Bridge: install access-bridge.jar instead of access-bridge-32/64.jar JDK-8057549 install Localize changes in 8051835 JDK-8047223 security-libs Add algorithm parameter to EncodedKeySpec class and its two subclasses JDK-8056026 security-libs Debug security logging should print Provider used for each crypto operation JDK-8048614 tools Add TypeMetadata to contain type annotations and other type information JDK-8057794 tools Compiler Error when obtaining .class property JDK-8058101 tools Integrate new version of Java VisualVM based on VisualVM 1.3.8 into JDK JDK-8058755 tools Update tools/javadoc/6227454 to add head tag JDK-8050117 tools add to javac test Versions.java tests that show correct operation for source/target options pre 1.9 JDK-8058708 tools java.lang.AssertionError compiling source code JDK-8038966 xml JAX-WS handles wrongly xsd:any arguments for Web services From bengt.rutisson at oracle.com Thu Oct 2 06:38:31 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 02 Oct 2014 08:38:31 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <21548.35184.576946.43474@mykonos.us.oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> Message-ID: <542CF2E7.3010202@oracle.com> On 2014-10-02 01:08, John Coomes wrote: > Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >> Hi Daniel, >> >> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>> Hi Bengt, >>> >>> The new version looks good to me, but I am not a reviewer >>> fore CODE_TOOLS. >> Thanks for looking at this Daniel! >> >>> Hopefully someone who is will step in :-) >> Yes, and I am not a committer in code-tools so I need a sponsor for the >> patch too. > Looks good to me; I'll sponsor it. Send me (privately) the result of > "hg export --git" and I'll push that. Thanks for looking at this, John! And thanks for sponsoring the change. I'll send you the export in a separate email. Bengt > > -John > >>> best regards, >>> >>> -- daniel >>> >>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>> Hi Daniel, >>>> >>>> Thanks for looking at this! >>>> >>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>> Hi Bengt, >>>>> >>>>> This is a really cool feature! >>>> Thanks! >>>> >>>>> I have downloaded your patch and applied it in my >>>>> local webrev repo - and played with the new >>>>> webrev in a couple of repositories where I have >>>>> pending uncommitted changes. >>>>> >>>>> This seems to work well. >>>>> >>>>> I have used: >>>>> >>>>> webrev -fN from top level repo >>>>> webrev -N from jdk repo >>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>> >>>> Great that you tired it out. >>>> >>>>> I also had a cursory look at your patch. The only thing >>>>> I noticed is that 'typeset' is not consistently used in >>>>> the original webrev file. I'm not sure whether that's >>>>> intended or not. >>>>> I believe that's ok - but I've been bitten by not using >>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>> you could use typeset at least in those functions that >>>>> already use it for their parameters? For instance >>>>> lines 532-534, and possibly line 560 as well? >>>>> Or did you intentionally not used it? >>>> I also noticed the inconsistent use of typeset. I fixed the lines you >>>> pointed out. I wasn't sure which way to go. But I think your suggestion >>>> is good. >>>> >>>>> Also you should increment the version of webrev. >>>>> IIRC that would be 25.6: >>>>> >>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>> Thanks, didn't think of that. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>> >>>> Diff compared to the first version: >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>> Hi everyone, >>>>>> >>>>>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev >>>>>> list since I'm not sure how many are on the webrev-dev list and >>>>>> most JDK >>>>>> developers might have opinions about this change.) >>>>>> >>>>>> Can I get a couple of reviews for this small enhancement to the webrev >>>>>> tool? >>>>>> >>>>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>> >>>>>> >>>>>> Background: >>>>>> When browsing review requests that span many files it is quite time >>>>>> consuming to have to go back to the index page to view to the next or >>>>>> previous file. This patch adds links to the next and previous files in >>>>>> the diff views (including frames). >>>>>> >>>>>> The above webrev is generated with this new version, but since it only >>>>>> contains a single file it is not that interesting. Here is an >>>>>> example of >>>>>> what the new webrev looks like for a larger change (the G1 class >>>>>> unloading change): >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> From aph at redhat.com Thu Oct 2 15:50:45 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 02 Oct 2014 16:50:45 +0100 Subject: RFD: Add Linux/AArch64 to the set of supported OpenJDK platforms Message-ID: <542D7455.3020807@redhat.com> https://bugs.openjdk.java.net/browse/JDK-8044552 http://openjdk.java.net/jeps/8044552 The AArch64 port has been complete for some time, and the rate of churn has slowed to the point where I believe it is stable enough to be moved into the mainline sources. It has passed the full JCK on JDK 7 and 8, but as yet there is no JCK 9, so I can say nothing about that. We are regularly testing using jtreg, Hadoop, and a bunch of other tests, and our results are similar to the same tests on x86. I hope that this process will be less involved and require less effort from approvers (at Oracle and elsewhere) than that for the Power PC port. I believe this because there are few changes to shared code beyond the trivial #ifdefs for header files which appear in many places. In a few places we've had to #ifdef out code which is in src/share but makes architectural assumptions which are not valid on AArch64. So, our proposal as detailed in the JEP is to create a staging forest which at the start will be a clone of the current JDK9. This staging forest will have jcheck fully enabled (unlike the AArch64 development repositories). We will then submit webrevs for approval to the appropriate groups, and then check them in to the staging forest. I presume that for each webrev it will be necessary to create a Jira Issue. A few questions arise: To which mailing lists should requests for approval be sent? I'm guessing hotspot-dev for the HotSpot patches, and jdk9-dev for everything else. What should the granularity of the webrevs be? I don't think that any subset of the src/cpu/aarch64 directory would make sense, but it's a big bite to chew. The JEP, which was based on that for the Power PC, talks about a more detailed Integration Plan in the AArch64 Port OpenJDK Wiki Space, but I have no plans beyond submitting webrevs for approval. Is there anything else we should do before creating issues and submitting webrevs? Thanks, Andrew. From John.Coomes at oracle.com Thu Oct 2 21:39:07 2014 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 2 Oct 2014 14:39:07 -0700 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542CF2E7.3010202@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> Message-ID: <21549.50683.903473.289915@mykonos.us.oracle.com> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > > On 2014-10-02 01:08, John Coomes wrote: > > Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > >> Hi Daniel, > >> > >> On 10/1/14 4:27 PM, Daniel Fuchs wrote: > >>> Hi Bengt, > >>> > >>> The new version looks good to me, but I am not a reviewer > >>> fore CODE_TOOLS. > >> Thanks for looking at this Daniel! > >> > >>> Hopefully someone who is will step in :-) > >> Yes, and I am not a committer in code-tools so I need a sponsor for the > >> patch too. > > Looks good to me; I'll sponsor it. Send me (privately) the result of > > "hg export --git" and I'll push that. > > Thanks for looking at this, John! And thanks for sponsoring the change. > I'll send you the export in a separate email. Got it; it's been pushed. -John > >>> best regards, > >>> > >>> -- daniel > >>> > >>> On 01/10/14 15:57, Bengt Rutisson wrote: > >>>> Hi Daniel, > >>>> > >>>> Thanks for looking at this! > >>>> > >>>> On 2014-10-01 15:53, Daniel Fuchs wrote: > >>>>> Hi Bengt, > >>>>> > >>>>> This is a really cool feature! > >>>> Thanks! > >>>> > >>>>> I have downloaded your patch and applied it in my > >>>>> local webrev repo - and played with the new > >>>>> webrev in a couple of repositories where I have > >>>>> pending uncommitted changes. > >>>>> > >>>>> This seems to work well. > >>>>> > >>>>> I have used: > >>>>> > >>>>> webrev -fN from top level repo > >>>>> webrev -N from jdk repo > >>>>> webrev -fN from jdk repo (with changes in test/closed) > >>>>> > >>>> Great that you tired it out. > >>>> > >>>>> I also had a cursory look at your patch. The only thing > >>>>> I noticed is that 'typeset' is not consistently used in > >>>>> the original webrev file. I'm not sure whether that's > >>>>> intended or not. > >>>>> I believe that's ok - but I've been bitten by not using > >>>>> typeset before ;-( - maybe - for the sake of uniformity - > >>>>> you could use typeset at least in those functions that > >>>>> already use it for their parameters? For instance > >>>>> lines 532-534, and possibly line 560 as well? > >>>>> Or did you intentionally not used it? > >>>> I also noticed the inconsistent use of typeset. I fixed the lines you > >>>> pointed out. I wasn't sure which way to go. But I think your suggestion > >>>> is good. > >>>> > >>>>> Also you should increment the version of webrev. > >>>>> IIRC that would be 25.6: > >>>>> > >>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net > >>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net > >>>> Thanks, didn't think of that. > >>>> > >>>> New webrev: > >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ > >>>> > >>>> Diff compared to the first version: > >>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ > >>>> > >>>> > >>>> Thanks, > >>>> Bengt > >>>> > >>>>> best regards, > >>>>> > >>>>> -- daniel > >>>>> > >>>>> On 01/10/14 10:56, Bengt Rutisson wrote: > >>>>>> Hi everyone, > >>>>>> > >>>>>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev > >>>>>> list since I'm not sure how many are on the webrev-dev list and > >>>>>> most JDK > >>>>>> developers might have opinions about this change.) > >>>>>> > >>>>>> Can I get a couple of reviews for this small enhancement to the webrev > >>>>>> tool? > >>>>>> > >>>>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs > >>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 > >>>>>> > >>>>>> Webrev: > >>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ > >>>>>> > >>>>>> > >>>>>> Background: > >>>>>> When browsing review requests that span many files it is quite time > >>>>>> consuming to have to go back to the index page to view to the next or > >>>>>> previous file. This patch adds links to the next and previous files in > >>>>>> the diff views (including frames). > >>>>>> > >>>>>> The above webrev is generated with this new version, but since it only > >>>>>> contains a single file it is not that interesting. Here is an > >>>>>> example of > >>>>>> what the new webrev looks like for a larger change (the G1 class > >>>>>> unloading change): > >>>>>> > >>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Bengt > >>>>>> > From bengt.rutisson at oracle.com Fri Oct 3 07:58:32 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 03 Oct 2014 09:58:32 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <21549.50683.903473.289915@mykonos.us.oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> Message-ID: <542E5728.8010709@oracle.com> On 2014-10-02 23:39, John Coomes wrote: > Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >> On 2014-10-02 01:08, John Coomes wrote: >>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>> Hi Daniel, >>>> >>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>> Hi Bengt, >>>>> >>>>> The new version looks good to me, but I am not a reviewer >>>>> fore CODE_TOOLS. >>>> Thanks for looking at this Daniel! >>>> >>>>> Hopefully someone who is will step in :-) >>>> Yes, and I am not a committer in code-tools so I need a sponsor for the >>>> patch too. >>> Looks good to me; I'll sponsor it. Send me (privately) the result of >>> "hg export --git" and I'll push that. >> Thanks for looking at this, John! And thanks for sponsoring the change. >> I'll send you the export in a separate email. > Got it; it's been pushed. Thanks for pushing this, John! Bengt > > -John > >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>> Hi Daniel, >>>>>> >>>>>> Thanks for looking at this! >>>>>> >>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> This is a really cool feature! >>>>>> Thanks! >>>>>> >>>>>>> I have downloaded your patch and applied it in my >>>>>>> local webrev repo - and played with the new >>>>>>> webrev in a couple of repositories where I have >>>>>>> pending uncommitted changes. >>>>>>> >>>>>>> This seems to work well. >>>>>>> >>>>>>> I have used: >>>>>>> >>>>>>> webrev -fN from top level repo >>>>>>> webrev -N from jdk repo >>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>> >>>>>> Great that you tired it out. >>>>>> >>>>>>> I also had a cursory look at your patch. The only thing >>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>> the original webrev file. I'm not sure whether that's >>>>>>> intended or not. >>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>> you could use typeset at least in those functions that >>>>>>> already use it for their parameters? For instance >>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>> Or did you intentionally not used it? >>>>>> I also noticed the inconsistent use of typeset. I fixed the lines you >>>>>> pointed out. I wasn't sure which way to go. But I think your suggestion >>>>>> is good. >>>>>> >>>>>>> Also you should increment the version of webrev. >>>>>>> IIRC that would be 25.6: >>>>>>> >>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>> Thanks, didn't think of that. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>> >>>>>> Diff compared to the first version: >>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> (This is a patch for webrev, but I am cross posting to the JDK 9 dev >>>>>>>> list since I'm not sure how many are on the webrev-dev list and >>>>>>>> most JDK >>>>>>>> developers might have opinions about this change.) >>>>>>>> >>>>>>>> Can I get a couple of reviews for this small enhancement to the webrev >>>>>>>> tool? >>>>>>>> >>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Background: >>>>>>>> When browsing review requests that span many files it is quite time >>>>>>>> consuming to have to go back to the index page to view to the next or >>>>>>>> previous file. This patch adds links to the next and previous files in >>>>>>>> the diff views (including frames). >>>>>>>> >>>>>>>> The above webrev is generated with this new version, but since it only >>>>>>>> contains a single file it is not that interesting. Here is an >>>>>>>> example of >>>>>>>> what the new webrev looks like for a larger change (the G1 class >>>>>>>> unloading change): >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> From vladimir.kozlov at oracle.com Fri Oct 3 18:46:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 11:46:56 -0700 Subject: RFD: Add Linux/AArch64 to the set of supported OpenJDK platforms In-Reply-To: <542D7455.3020807@redhat.com> References: <542D7455.3020807@redhat.com> Message-ID: <542EEF20.2020309@oracle.com> On 10/2/14 8:50 AM, Andrew Haley wrote: > https://bugs.openjdk.java.net/browse/JDK-8044552 > http://openjdk.java.net/jeps/8044552 > > The AArch64 port has been complete for some time, and the rate of > churn has slowed to the point where I believe it is stable enough to > be moved into the mainline sources. It has passed the full JCK on JDK > 7 and 8, but as yet there is no JCK 9, so I can say nothing about > that. We are regularly testing using jtreg, Hadoop, and a bunch of > other tests, and our results are similar to the same tests on x86. > > I hope that this process will be less involved and require less effort > from approvers (at Oracle and elsewhere) than that for the Power PC > port. I believe this because there are few changes to shared code > beyond the trivial #ifdefs for header files which appear in many > places. In a few places we've had to #ifdef out code which is in > src/share but makes architectural assumptions which are not valid on > AArch64. > > So, our proposal as detailed in the JEP is to create a staging forest > which at the start will be a clone of the current JDK9. This staging > forest will have jcheck fully enabled (unlike the AArch64 development > repositories). We will then submit webrevs for approval to the > appropriate groups, and then check them in to the staging forest. > > I presume that for each webrev it will be necessary to create a Jira > Issue. Yes and please add 'AARCH64:' prefix to jbs Summary line, like next for ppc64: PPC64: (part 220): ConstantTableBase for calls between args and jvms > > A few questions arise: > > To which mailing lists should requests for approval be sent? I'm > guessing hotspot-dev for the HotSpot patches, and jdk9-dev for > everything else. Correct. > > What should the granularity of the webrevs be? I don't think that any > subset of the src/cpu/aarch64 directory would make sense, but it's a > big bite to chew. You can at least separate assembler/macroassembler+interpreter+runtime and c1+c2+stubs code. As I remember your shared changes are not big (mostly ifdefs) so it could be one. > > The JEP, which was based on that for the Power PC, talks about a more > detailed Integration Plan in the AArch64 Port OpenJDK Wiki Space, but I > have no plans beyond submitting webrevs for approval. > > Is there anything else we should do before creating issues and > submitting webrevs? Yes, I think the rest is our side. We need to create stage repo and assign our sponsor. Thanks, Vladimir > > Thanks, > Andrew. > From bradford.wetmore at oracle.com Fri Oct 3 20:18:12 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 03 Oct 2014 13:18:12 -0700 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <5390E52A.10308@oracle.com> References: <5390E52A.10308@oracle.com> Message-ID: <542F0484.5080207@oracle.com> Sorry for the wide distribution, but there is an important followup to a message from June. If you are not building on Solaris, you can skip this. > For JDK 9 we will upgrade the build platforms and compilers used at > Oracle to build the JDK. > > In this cycle, our target combinations are: > ...deleted... > - Solaris X86 - 11.1 / Oracle Solaris Studio 12.3 > - Solaris SPARC - 11.1 / Oracle Solaris Studio 12.3 A recent change to a hotspot CC invocation now requires the new Solaris Studio 12.3 compilers be found in your PATH/ when running "configure", or else the hotspot build will fail: Linking vm... ... /java/devtools/i586/SUNWspro/SS12u3/bin/CC -m64 ... -Wl,-z,defs \ -o libjvm.so ...lots of .so files and libraries... changeset: 7135:5051bb01fa2b user: mgerdin date: Thu Sep 25 10:01:53 2014 +0200 summary: 8055141: Catch linker errors earlier in the JVM build by not allowing unresolved externals + LFLAGS_VM += -Wl,-z,defs For Oracle folks, the usual tree has the new compilers under the SS12u3 directory. WARNING, there is currently *no check* for this requirement in configure. I know at least one other person who has run into this, so hopefully this saves others some time. Brad On 6/5/2014 2:46 PM, Tim Bell wrote: > All- > > For JDK 9 we will upgrade the build platforms and compilers used at > Oracle to build the JDK. > > In this cycle, our target combinations are: > > - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 > - Mac OS X - 10.9.2 (Mavericks) 64-bit / XCode 5.1.1 / clang > - Solaris X86 - 11.1 / Oracle Solaris Studio 12.3 > - Solaris SPARC - 11.1 / Oracle Solaris Studio 12.3 > - Windows - Windows Server 2012 R2 64-bit / Microsoft Visual Studio 2013 > > For Linux and Windows, the 64-bit platform will also build 32-bit > binaries. > > The Mac OS X and Solaris builds are already 64-bit only. > > Status of the project: > > At this point, both the Solaris and Linux platforms build using the > new platforms and tools. They also passed an initial round of > testing. Performance testing is still in progress. > > For Windows and Mac OS X, we are working on a few stopper bugs. > > We will need to integrate a set of fixes as part of doing the compiler > upgrades in order for us to be able to build the JDK using the new > compilers. > > Upgrades are currently planned for Linux and Solaris platforms next > week (June 9). A JDK 9 build will be promoted containing only these > changes. > > Mac OS X and Windows will follow when the stopper bugs are fixed and > we are ready. At this point, we are estimating the end of June. We > will send an email to this list with confirmation of the dates for > these two platforms once the blockers have been resolved. > > We will send an update to the list when we start the upgrade. > > It is important to keep as few things as possible moving during the > special promotion cycle. We will work with the integrators to ensure > no changes apart from those needed for the compiler upgrades are > integrated into the master. > > We will notify you when the upgrade has been completed and will also > let you know where to find the build that was done after the compiler > upgrades. > > Feedback is welcome. Please send to jdk9-dev at openjdk.java.net > > Tim > From vladimir.kozlov at oracle.com Fri Oct 3 22:33:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 15:33:26 -0700 Subject: New staging repository for AArch64 open port Message-ID: <542F2436.7070608@oracle.com> Hi Iris, aarch64 (arm64) open port JEP is reviewed and endorsed: https://bugs.openjdk.java.net/browse/JDK-8044552 Could you, please, create jdk9 staging forest (including closed repos) for it? Something like: http://hg.openjdk.java.net/aarch64-port/stage It should be child of jdk9/dev forest. Push notifications for open changes could be sent to: aarch64-port-dev at openjdk.java.net Initial committers will be Andrew Haley (aph) and me, Vladimir Kozlov (kvn). We may add more committers later. Best regards, Vladimir From volker.simonis at gmail.com Mon Oct 6 13:50:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 6 Oct 2014 15:50:33 +0200 Subject: Result: New jdk9 Reviewer: Goetz Lindenmaier Message-ID: Voting for Goetz Lindenmaier [1] is now closed. Yes: 26 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Volker Simonis [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-September/thread.html#1297 From iris.clark at oracle.com Mon Oct 6 17:48:07 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 6 Oct 2014 10:48:07 -0700 (PDT) Subject: New staging repository for AArch64 open port In-Reply-To: <542F2436.7070608@oracle.com> References: <542F2436.7070608@oracle.com> Message-ID: <5c11c4f0-8850-4b7f-a851-e969608976fb@default> Hi, Andrew. As the Lead of the AArch64 Project, do you approve of the request to create this staging forest? Do you want jcheck fully enabled (formatted changeset comment, Reviewers, etc.) so that you can preserve your history similar to what was done for the PPC/AIX Port? Assuming that you do, then I'm going to need to investigate how to handle that configuration. Minimally, if Vladimir needs to push he needs to be at least a Committer to the AArch64 Project. Who do you anticipate the changeset authors to be? They'd need to be at least Authors in both JDK 9 and AArch64. Thanks, iris -----Original Message----- From: Vladimir Kozlov Sent: Friday, October 03, 2014 3:33 PM To: Iris Clark Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; jdk9-dev at openjdk.java.net; Andrew Haley Subject: New staging repository for AArch64 open port Hi Iris, aarch64 (arm64) open port JEP is reviewed and endorsed: https://bugs.openjdk.java.net/browse/JDK-8044552 Could you, please, create jdk9 staging forest (including closed repos) for it? Something like: http://hg.openjdk.java.net/aarch64-port/stage It should be child of jdk9/dev forest. Push notifications for open changes could be sent to: aarch64-port-dev at openjdk.java.net Initial committers will be Andrew Haley (aph) and me, Vladimir Kozlov (kvn). We may add more committers later. Best regards, Vladimir From aph at redhat.com Mon Oct 6 18:41:47 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 06 Oct 2014 19:41:47 +0100 Subject: New staging repository for AArch64 open port In-Reply-To: <5c11c4f0-8850-4b7f-a851-e969608976fb@default> References: <542F2436.7070608@oracle.com> <5c11c4f0-8850-4b7f-a851-e969608976fb@default> Message-ID: <5432E26B.2070406@redhat.com> On 10/06/2014 06:48 PM, Iris Clark wrote: > > As the Lead of the AArch64 Project, do you approve of the request to > create this staging forest? Do you want jcheck fully enabled > (formatted changeset comment, Reviewers, etc.) so that you can > preserve your history similar to what was done for the PPC/AIX Port? Yes. I'm putting myself in the hands of Vladimir here, but I'm pretty sure we need jcheck. I know that our existing revision history is not jcheck-compliant, so it wouldn't be acceptable, but I am prepared to lose the history because I'll be submitting clean webrevs. The aarch64-project tree will always be there for the archaeologists. > Assuming that you do, then I'm going to need to investigate how to > handle that configuration. Minimally, if Vladimir needs to push he > needs to be at least a Committer to the AArch64 Project. Who do you > anticipate the changeset authors to be? They'd need to be at least > Authors in both JDK 9 and AArch64. I can't even remember if I am a JDK9 author, but at least me and Andrew Dinn. Edward Nevill is a major AArch64 contributor, but I don't think he is a JDK9 author. Thanks, Andrew. From bradford.wetmore at oracle.com Mon Oct 6 18:49:15 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 06 Oct 2014 11:49:15 -0700 Subject: Coming soon: JDK 9 Platform/Compiler upgrades at Oracle In-Reply-To: <542F0484.5080207@oracle.com> References: <5390E52A.10308@oracle.com> <542F0484.5080207@oracle.com> Message-ID: <5432E42B.1000108@oracle.com> If you are not building on Linux, you can skip this. I don't know how recent this change is, but when compiling the *OPEN* repositories using the stock gcc 4.4.7 installed by default on Oracle Linux 6.4, you will probably see this compiler error: https://bugs.openjdk.java.net/browse/JDK-8059698 open-dev/hotspot/src/share/vm/services/classLoadingService.cpp: In static member function ?static void ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)?: open-dev/hotspot/src/share/vm/services/classLoadingService.cpp:144: error: cannot reload integer constant operand in ?asm? > > For JDK 9 we will upgrade the build platforms and compilers used at > > Oracle to build the JDK. > > > > In this cycle, our target combinations are: ...deleted... > > - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 I was able to get a clean build using 4.8.2. (For Oracle folks, 6.4 is the standard image from PDIT DevOps. If you look on our internal wiki, there is a link to a 4.8.2 devkit which can be used.) Brad P.S. Nothing like discovering build problems while trying to debug an emergency fix. ;) On 10/3/2014 1:18 PM, Bradford Wetmore wrote: > Sorry for the wide distribution, but there is an important followup to a > message from June. If you are not building on Solaris, you can skip this. > > > For JDK 9 we will upgrade the build platforms and compilers used at > > Oracle to build the JDK. > > > > In this cycle, our target combinations are: > > ...deleted... > > - Solaris X86 - 11.1 / Oracle Solaris Studio 12.3 > > - Solaris SPARC - 11.1 / Oracle Solaris Studio 12.3 > > A recent change to a hotspot CC invocation now requires the new Solaris > Studio 12.3 compilers be found in your PATH/ when running "configure", > or else the hotspot build will fail: > > Linking vm... > ... > /java/devtools/i586/SUNWspro/SS12u3/bin/CC -m64 ... -Wl,-z,defs \ > -o libjvm.so ...lots of .so files and libraries... > > changeset: 7135:5051bb01fa2b > user: mgerdin > date: Thu Sep 25 10:01:53 2014 +0200 > summary: 8055141: Catch linker errors earlier in the JVM build by > not allowing unresolved externals > > + LFLAGS_VM += -Wl,-z,defs > > For Oracle folks, the usual tree has the new compilers under the SS12u3 > directory. > > WARNING, there is currently *no check* for this requirement in configure. > > I know at least one other person who has run into this, so hopefully > this saves others some time. > > Brad > > > > > > > On 6/5/2014 2:46 PM, Tim Bell wrote: >> All- >> >> For JDK 9 we will upgrade the build platforms and compilers used at >> Oracle to build the JDK. >> >> In this cycle, our target combinations are: >> >> - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 >> - Mac OS X - 10.9.2 (Mavericks) 64-bit / XCode 5.1.1 / clang >> - Solaris X86 - 11.1 / Oracle Solaris Studio 12.3 >> - Solaris SPARC - 11.1 / Oracle Solaris Studio 12.3 >> - Windows - Windows Server 2012 R2 64-bit / Microsoft Visual Studio 2013 >> >> For Linux and Windows, the 64-bit platform will also build 32-bit >> binaries. >> >> The Mac OS X and Solaris builds are already 64-bit only. >> >> Status of the project: >> >> At this point, both the Solaris and Linux platforms build using the >> new platforms and tools. They also passed an initial round of >> testing. Performance testing is still in progress. >> >> For Windows and Mac OS X, we are working on a few stopper bugs. >> >> We will need to integrate a set of fixes as part of doing the compiler >> upgrades in order for us to be able to build the JDK using the new >> compilers. >> >> Upgrades are currently planned for Linux and Solaris platforms next >> week (June 9). A JDK 9 build will be promoted containing only these >> changes. >> >> Mac OS X and Windows will follow when the stopper bugs are fixed and >> we are ready. At this point, we are estimating the end of June. We >> will send an email to this list with confirmation of the dates for >> these two platforms once the blockers have been resolved. >> >> We will send an update to the list when we start the upgrade. >> >> It is important to keep as few things as possible moving during the >> special promotion cycle. We will work with the integrators to ensure >> no changes apart from those needed for the compiler upgrades are >> integrated into the master. >> >> We will notify you when the upgrade has been completed and will also >> let you know where to find the build that was done after the compiler >> upgrades. >> >> Feedback is welcome. Please send to jdk9-dev at openjdk.java.net >> >> Tim >> From vladimir.kozlov at oracle.com Mon Oct 6 19:47:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Oct 2014 12:47:35 -0700 Subject: New staging repository for AArch64 open port In-Reply-To: <5432E26B.2070406@redhat.com> References: <542F2436.7070608@oracle.com> <5c11c4f0-8850-4b7f-a851-e969608976fb@default> <5432E26B.2070406@redhat.com> Message-ID: <5432F1D7.4000001@oracle.com> On 10/6/14 11:41 AM, Andrew Haley wrote: > On 10/06/2014 06:48 PM, Iris Clark wrote: >> >> As the Lead of the AArch64 Project, do you approve of the request to >> create this staging forest? Do you want jcheck fully enabled >> (formatted changeset comment, Reviewers, etc.) so that you can >> preserve your history similar to what was done for the PPC/AIX Port? > > Yes. I'm putting myself in the hands of Vladimir here, but I'm pretty > sure we need jcheck. Yes, staging repo should have jcheck fully enabled. > I know that our existing revision history is not jcheck-compliant, so > it wouldn't be acceptable, but I am prepared to lose the history > because I'll be submitting clean webrevs. The aarch64-project tree > will always be there for the archaeologists. > >> Assuming that you do, then I'm going to need to investigate how to >> handle that configuration. Minimally, if Vladimir needs to push he >> needs to be at least a Committer to the AArch64 Project. Who do you Do I really need to be Committer to the AArch64 Project? Can jdk9 Committer status be enough? The staging forest is child of jdk9 forest. I may be not the only one from Oracle side who will help with sponsoring pushes. It would be nice if you allow any jdk9 committer to push into aarch64 stage forest. >> anticipate the changeset authors to be? They'd need to be at least >> Authors in both JDK 9 and AArch64. > > I can't even remember if I am a JDK9 author, but at least me and > Andrew Dinn. Edward Nevill is a major AArch64 contributor, but I > don't think he is a JDK9 author. http://openjdk.java.net/census Andrew, you are JDK9 Committer which includes Author status. So you can be author and you can push into the staging forest. Andrew Dinn and Edward Nevill are not JDK9 authors. They should be listed in "Contributed-by: ". Their changes have to be sponsored (pushed) by us, Oracle, or by you, Andrew. Thanks, Vladimir > > Thanks, > Andrew. > From iris.clark at oracle.com Mon Oct 6 20:18:49 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 6 Oct 2014 13:18:49 -0700 (PDT) Subject: New staging repository for AArch64 open port In-Reply-To: <5432F1D7.4000001@oracle.com> References: <542F2436.7070608@oracle.com> <5c11c4f0-8850-4b7f-a851-e969608976fb@default> <5432E26B.2070406@redhat.com> <5432F1D7.4000001@oracle.com> Message-ID: Hi, Vladimir. >> Assuming that you do, then I'm going to need to investigate how to >> handle that configuration. Minimally, if Vladimir needs to push he >> needs to be at least a Committer to the AArch64 Project. Who do you > Do I really need to be Committer to the AArch64 Project? Can jdk9 Committer status be enough? The staging forest is child of jdk9 forest. I may be not the only one from Oracle side who will help with sponsoring pushes. It would be nice if you allow any jdk9 committer to push into aarch64 stage forest. Yes, you really need to be a AArch64 Committer. The AArch64 Project is the owner of the forest regardless of how it was originally created/cloned. I can create a limited-access forest as requested, but the people on that list (in this case Andrew Haley and you) must be a subset of the owning Project's Census entry. Any Oracle employee who wishes to push changes into the open portion of aarch64/stage must be an AArch64 Committer. Thanks, iris From vladimir.kozlov at oracle.com Mon Oct 6 21:02:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Oct 2014 14:02:10 -0700 Subject: New staging repository for AArch64 open port In-Reply-To: References: <542F2436.7070608@oracle.com> <5c11c4f0-8850-4b7f-a851-e969608976fb@default> <5432E26B.2070406@redhat.com> <5432F1D7.4000001@oracle.com> Message-ID: <54330352.2050900@oracle.com> Okay, thank you for clarifying it, Iris. Vladimir On 10/6/14 1:18 PM, Iris Clark wrote: > Hi, Vladimir. > >>> Assuming that you do, then I'm going to need to investigate how to >>> handle that configuration. Minimally, if Vladimir needs to push he >>> needs to be at least a Committer to the AArch64 Project. Who do you > >> Do I really need to be Committer to the AArch64 Project? Can jdk9 Committer status be enough? The staging forest is child of jdk9 forest. > I may be not the only one from Oracle side who will help with sponsoring pushes. It would be nice if you allow any jdk9 committer to push into > aarch64 stage forest. > > Yes, you really need to be a AArch64 Committer. The AArch64 Project is the owner of the forest regardless of how it was originally created/cloned. I can create a limited-access forest as requested, but the people on that list (in this case Andrew Haley and you) must be a subset of the owning Project's Census entry. Any Oracle employee who wishes to push changes into the open portion of aarch64/stage must be an AArch64 Committer. > > Thanks, > iris > From John.Coomes at oracle.com Tue Oct 7 23:06:57 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 7 Oct 2014 16:06:57 -0700 Subject: jdk9-dev: HotSpot Message-ID: <21556.29201.631053.633950@mykonos.us.oracle.com> jdk9-hs-2014-10-03 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/6085f9633d8c http://hg.openjdk.java.net/jdk9/dev/corba/rev/24a0bad5910f http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8e576352f831 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/6b343b9b7a70 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/28ea43d925f1 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cd3fcf4bcf98 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/69d7812dabcc http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/559ddc6be0fe Component : VM Status : Go for integration Date : 10/07/2014 at 19:00 MSK Tested By : VM SQE & dmitry.fazunenko at oracle.com Bundles : 2014-10-03-130258.amurillo.jdk9-hs-2014-10-03-snapshot Testing: http://surl.us.oracle.com/pit_jdk9_b34_summary 254 new failures, 3015 known failures, 391657 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8058880: Introduce identifier TEMP_DEF for effects in adl. 8058536: java/lang/instrument/NativeMethodPrefixAgent.java fails due to VirtualMachineError: out of space in CodeCache for method handle intrinsic 8058737: CodeCache::find_blob fails with 'unsafe access to zombie method' 8058968: Compiler time traces should be improved 8058578: -XX:+TraceDependencies is broken for call_site_target_value dependency type 8025606: [TESTBUG] Move ctw-tests to /testlibrary_tests 8038098: [TESTBUG] remove explicit set build flavor from hotspot/test/compiler/* tests 8058825: EA: ConnectionGraph::split_unique_types does incorrect scalar replacement 8059137: MemoryPoolMXBeans for different code heaps should contain 'Code heap' in their names 8059468: Fix PrintCodeCache output changed by JDK-8059137 8058919: Add sanity test for minimal VM in test/Makefile 8058936: hotspot/test/Makefile should use jtreg script from $JT_HOME/bin/jreg (instead of $JT_HOME/win32/bin/jtreg) 8057925: PrintSymbolTableSizeHistogram prints misleading output 8054194: jstack crash: assert(handle != NULL) failed: JNI handle should not be null 8058818: Allocation of more then 1G of memory using Unsafe.allocateMemory is still causing a fatal error on 32bit platforms 8058927: ATG throws ClassNotFoundException 8057846: ClassVerifier::change_sig_to_verificationType temporary symbol creation code is hot 8047976: Ergonomics for GC thread counts should update the flags 8043766: CMM Testing: 8u40 Decommit auxiliary data structures 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints 8059452: G1: Change the default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent 8059474: Clean up vm/utilities/Bitmap type uses 8049599: MetaspaceGC::_capacity_until_GC can overflow 8059527: Disallow ParallelGCThreads=0 for G1 8058891: serviceability/dcmd/CodelistTest.java - fails on all platforms 8059390: code cache fills up for bigapps/Weblogic+medrec/nowarnings 8058828: Wrong ciConstant type for arrays from ConstantPool::_resolved_reference 8059556: C2: crash while inlining MethodHandle invocation w/ null receiver 8059596: VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set 8059651: Tests specify -XX:+UseG1GC and -XX:ParallelGCThreads=0 8059105: Add better failure reporting to com/sun/jdi/RunToExit.java test From volker.simonis at gmail.com Wed Oct 8 16:43:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Oct 2014 18:43:33 +0200 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() Message-ID: Hi, I wonder why the implementations of Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() are different . It seems to me that this is simply copy/paste error since the very first 1.4 version. Here's what we currently have: Inet4AddressImpl_getLocalHostName() if (gethostname(hostname, NI_MAXHOST)) { /* Something went wrong, maybe networking is not setup? */ strcpy(hostname, "localhost"); } else { ... error = getaddrinfo(hostname, NULL, &hints, &res); ... error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, ... } We first call gethostname(). If that succeeds we call getaddrinfo() with the host name returned by gethostname() and if that succeeds again we call getnameinfo() with the address returned by getaddrinfo() to get the final hostname. This is uniformly done on all Unix platforms. And here's how the corresponding IPv6 version looks like: Inet6AddressImpl_getLocalHostName() ret = gethostname(hostname, NI_MAXHOST); #if defined(__solaris__) && defined(AF_INET6) ... error = getaddrinfo(hostname, NULL, &hints, &res); ... error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, #endif As you can see, for the IPv6 version we only do the getaddrinfo()/getnameinfo() roundtrip on Solaris although there is no evidence that the inovolved system calls behave differently for IPv4 and IPv6. Instead I think the IPv6 version is just a leftover of the very first implementation which hasn't been updated in the same way like its IPv4 counterpart. Notice the comment in the IPv6 version which says "Solaris doesn't want to give us a fully qualified domain name". But that holds true for the Linux version as well - gethostname() on Linux returns "uname -n" which is usually unqualified. The comment further notices that even the reverse lookup may not return a fully qualified name which is true because that's highly system and name service dependent. I think we can therefore safely use the same implementation for both, Inet4AddressImpl_getLocalHostName() and Inet6AddressImpl_getLocalHostName(). We should actually refactor this implementation into its own function to avoid differences in the future. There's also a funny punchline in this whole story: trough a bug introduced by the Mac OS port, the two implementations have been semanticall equal for a while. But then this has been changed back as a fix for "7166687: InetAddress.getLocalHost().getHostName() returns FQDN " (https://bugs.openjdk.java.net/browse/JDK-7166687 , http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b26c04717735). But I'm pretty sure that change didn't really fixed the problem described in the bug report (maybe just incidentally worked around). Here's why: getLocalHostName() is used by InetAddress.getLocalHost(), but it's result (i.e. the host name) is immediately converted back into an address (i.e. InetAddress) on which subsequently getHostName() is called. The result of getHostName() only depends on the available name services and not on the fact if getLocalHostName() returned a simple or a fully qualified host name. However the resolution of a host name to an IP-address may be different depending on whether we have a simple (may resolve trough /etc/hosts) or fully qualified name (may resolve through name service like DNS). The hacky way to fix issue 7166687 would be to have the corresponding entries in your /etc/hosts (i.e. short names for both, IPv4 and IPv6 interfaces). The right way to handle it would be to actually expect both, simple and full qualified host names as return values from InetAddress.getHostName(). Notice the InetAddress.getLocalHost() isn't guaranteed to not return the loopback address. If you have configured your system such that /etc/hosts associates your host name with the loopback device and /etc/resolve.conf in such a way to first query /etc/hosts before doing a name service lookup (which is not unusual) than InetAddress.getLocalHost() will do just that - return the address of your loopback device! So to finally cut a long story short, I propose the following: - refactor the implementation of Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() into a single function which corresponds to the current Inet4AddressImpl_getLocalHostName() implementation. - it may be also possible to complete omit the call to getnameinfo() in that new implementation, because as far as I can see the 'ai_canonname' field of the first addrinfo structure returned by getaddrinfo() already contains the canonical name of the host if we pass AI_CANONNAME as 'hints' to getaddrinfo (which we already do). What do you think? Regards, Volker From Alan.Bateman at oracle.com Wed Oct 8 16:56:49 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Oct 2014 09:56:49 -0700 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() In-Reply-To: References: Message-ID: <54356CD1.5080800@oracle.com> On 08/10/2014 09:43, Volker Simonis wrote: > Hi, > > I wonder why the implementations of > Inet6AddressImpl_getLocalHostName() and > Inet4AddressImpl_getLocalHostName() are different . It seems to me > that this is simply copy/paste error since the very first 1.4 version. > It's best to bring this up on net-dev. There is a long history where the implementations were very different as getnameinfo/getaddrinfo weren't available on all platforms when support for IPv6 was added. The OS X port resulted in some complications. It's definitely worth re-visiting now, there is a lot of native code in this area that can be consolidated or re-written in java. -Alan From volker.simonis at gmail.com Wed Oct 8 17:01:29 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Oct 2014 19:01:29 +0200 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() In-Reply-To: <54356CD1.5080800@oracle.com> References: <54356CD1.5080800@oracle.com> Message-ID: Hi Alan, I've reposted the question to net-dev as suggested by you. I therefore close this thread here on jdk9-dev. Should you have any comments, please reply to the mail on the net-dev list. Thank you and best regards, Volker On Wed, Oct 8, 2014 at 6:56 PM, Alan Bateman wrote: > On 08/10/2014 09:43, Volker Simonis wrote: >> >> Hi, >> >> I wonder why the implementations of >> Inet6AddressImpl_getLocalHostName() and >> Inet4AddressImpl_getLocalHostName() are different . It seems to me >> that this is simply copy/paste error since the very first 1.4 version. >> > It's best to bring this up on net-dev. There is a long history where the > implementations were very different as getnameinfo/getaddrinfo weren't > available on all platforms when support for IPv6 was added. The OS X port > resulted in some complications. It's definitely worth re-visiting now, there > is a lot of native code in this area that can be consolidated or re-written > in java. > > -Alan From lana.steuck at oracle.com Wed Oct 8 17:35:18 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 8 Oct 2014 10:35:18 -0700 (PDT) Subject: jdk9-b34: dev Message-ID: <201410081735.s98HZIvN002085@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/087b23f35631 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/4ece2dad8c37 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/e18407fcede8 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/21568031434d http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/28ea43d925f1 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/6b343b9b7a70 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/821164b0131a http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/24a0bad5910f --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8059211 core-libs ArrayData.length() function is now a protected field, we should explicitly use it internally JDK-8059371 core-libs Code duplication in handling of break and continue JDK-8059372 core-libs Code duplication in split emitter JDK-8042126 core-libs DateTimeFormatter "MMMMM" returns English value in Japanese locale JDK-8025690 core-libs Default FileHandler constructor doesn't throw NullPointerException if pattern is empty and count > 1 JDK-8059269 core-libs FileHandler may throw NPE if pattern is a simple name and the lock file already exists JDK-8059450 core-libs Not quite correct code sample in javadoc JDK-8043306 core-libs Provide a replacement for the API that allowed to listen for LogManager configuration changes JDK-8059321 core-libs Significant parser/frontend overhead in recompilation of avatar.js JDK-8059346 core-libs Single class loader is used to load compiled bytecode JDK-8059370 core-libs Unnecessary work in deoptimizing recompilation JDK-8058695 core-libs [TESTBUG] Reinvokers with arity >253 can't be cached JDK-8058932 core-libs java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist JDK-8033140 core-svc 8 tests fail with OpenJDK8 b126 JDK-8057827 hotspot notify an obj when allocation context stats are available JDK-8059002 hotspot 8058744 needs a test case JDK-8055744 hotspot 8u-dev nightly solaris builds failed on 08/20 JDK-8058716 hotspot Add include missing in 8015774 JDK-8050407 hotspot Add jtreg compiler tests to Hotspot JPRT jobs JDK-8015774 hotspot Add support for multiple code heaps JDK-8053919 hotspot AppCDS: closed/runtime/AppCDS/UseAppCDS.java fails on Mac with NoClassDefFoundError: UseAppCDS JDK-8057628 hotspot Automatically enable g1 when ResourceTracking is enabled JDK-8055141 hotspot Catch linker errors earlier in the JVM build by not allowing unresolved externals JDK-8057845 hotspot ClassVerifier::verify_exception_handler_targets reconstructs the ExceptionTable in a loop JDK-8035729 hotspot Code using assert(is_oop_or_null) needs better error messages JDK-8055091 hotspot CollectedHeap::_reserved usage should be cleaned up JDK-8058744 hotspot Crash in C1 OSRed method w/ Unsafe usage JDK-8057713 hotspot Destroy resource context and clean out allocation context JDK-8058448 hotspot Disable JPRT submissions from the hotspot repo JDK-8057658 hotspot Enable G1 FullGC extensions JDK-8058881 hotspot Exclude resource management tests until JDK parts of feature are ported to jdk9 JDK-8036116 hotspot Fix thread-id types in G1 remembered set implementations JDK-8058495 hotspot G1: normalize names for isHumongous() and friends JDK-8055005 hotspot GC should react to memory pressure JDK-8053998 hotspot Hot card cache flush chunk size too coarse grained JDK-8027450 hotspot Improve time reporting in G1 remark JDK-8057790 hotspot JVM_GetManagementExt missing from mapfiles JDK-8057710 hotspot Refactor G1 heap region default sizes JDK-8057536 hotspot Refactor G1 to allow context specific allocations JDK-8058345 hotspot Refactor native stack printing from vmError.cpp to debug.cpp to make it available in gdb as well JDK-8058583 hotspot Remove CompilationRepeat JDK-8058534 hotspot Remove HeapRegion::_orig_end JDK-8056056 hotspot Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile JDK-8057916 hotspot Sort includes and verify copyright for new files JDK-8055006 hotspot Store original value of Min/MaxHeapFreeRatio JDK-8058843 hotspot TEST.groups has runtime/runtime/7158988/FieldMonitor.java JDK-8058564 hotspot Tiered compilation performance drop in PIT JDK-8057752 hotspot WhiteBox extension support for testing JDK-8058827 hotspot XCode 6.0 (Clang) warning "operator new' should not return a null pointer unless..." JDK-8058490 hotspot [TESTBUG] AppCDS tests filename mismatch on Cygwin JDK-8053923 hotspot [TESTBUG] AppCDS: make sure tests account for inability to map shared archive to a specified address JDK-8057730 hotspot [TESTBUG] Create AppCDS additional command line flag combo tests JDK-8058597 hotspot [TESTBUG] Disable failing AppCDS tests until the bugs are resolved JDK-8058369 hotspot [TESTBUG] runtime/CompressedOops/UseCompressedOops.java Exception java.lang.RuntimeException: 'Zero based' missing from stdout/stderr JDK-8058712 hotspot [TESTBUG] serviceability/dcmd/CodeCacheTest.java fails with java.lang.Exception JDK-8058479 hotspot [Testbug] serviceability/dcmd/CodeCacheTest.java fails due to java.lang.NumberFormatException: For input string: "fffffd7febc00000" JDK-8057535 hotspot add a thread extension class JDK-8057623 hotspot add an extension class for argument handling JDK-8057818 hotspot collect allocation context statistics at gc pauses JDK-8057785 hotspot g1 not automatically enabled by -XX:+ResourceTracking JDK-8054970 hotspot gc src file exclusion should exclude alternative sources JDK-8058235 hotspot identify GCs initiated to update allocation context stats JDK-8058863 hotspot jdk9/hs-comp fails in jprt with "-testset hotspot" from top-level JDK-8050022 hotspot linux-sparcv9: assert(SharedSkipVerify || obj->is_oop()) failed: sanity check JDK-8057824 hotspot methods to copy allocation context statistics JDK-8057531 hotspot refactor gc argument processing code slightly JDK-8058461 hotspot serviceability/dcmd/CodelistTest.java and serviceability/dcmd/CompilerQueueTest.java SIGSEGV JDK-8058636 hotspot test case for 8057758 JDK-8058347 hotspot update allocation context stats when accuracy==highest JDK-8059657 infrastructure Bump version of cobundles in /java to 9 JDK-8059662 infrastructure JPRT not bundling up install or deploy images JDK-8059135 infrastructure New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? JDK-8057985 other-libs Command line options should be renamed JDK-8049389 other-libs Move orb.idl and ir.idl to JDK include directory JDK-8058657 security-libs Add @jdk.Exported to com.sun.jarsigner.ContentSigner API JDK-8059313 security-libs Enable keytool NSS test on Mac JDK-8059307 security-libs OpenJDK build problem with JDK-8058845 JDK-8058844 security-libs Oracle JCE build environment: Phases 1/2 JDK-8059462 security-libs Typo in keytool resource file JDK-8048512 security-libs Uninitialised memory in jdk/src/share/native/sun/security/ec/ECC_JNI.cpp JDK-8058845 security-libs Update JCE environment for build improvements JDK-8031191 security-libs Warning exception when XMLSignature logging is enabled JDK-8055783 tools Group 9e: golden files for tests in tools/javac dir JDK-8048351 tools tidy errors for attribute href, name for langtools javadoc tests needs investigation From jonathan.gibbons at oracle.com Thu Oct 9 01:54:42 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 08 Oct 2014 18:54:42 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda Message-ID: <5435EAE2.2030605@oracle.com> I hereby nominate Jan Lahoda to jdk9 Reviewer. Jan has had many years experience working on javac, while working on NetBeans and since joining the javac team. He has contributed over 90 changesets and participated in many reviews as well. Some of his more significant contributions are listed below. Votes are due by 22 Oct 2014. Only current jdk9 Reviewers [1] are eiligible 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]. -Alan. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea 8043643: Add an crules analyzer avoiding string concatenation in messages of Assert checks. Summary: Generalizing the crules infrastructure, adding a new analyzer to check String concatenation in Assert calls. Reviewed-by: jjg, vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 6707032: Division by zero warning not suppressed properly in some cases Summary: Delay reporting of the division by zero warning until annotations are resolved, so that @SuppressWarnings works correctly. Reviewed-by: vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a 8046916: Type parameter annotations don't work with multiple type parameters Summary: When reading type variable's annotations out of the owner's type annotations, use the type variable's index in owner to exclude annotations belonging to other type variables. Reviewed-by: jfranck, emc http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails Summary: The result of String.toLowerCase.indexOf does not always point at the start of the given string in the non-lowercased text. Reviewed-by: jjg, bpatel http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf 8041663: Sensitive dependence on location of nested interface Summary: Adding a method among ambiguous candidates only if it is more specific than some of the existing candidates. Reviewed-by: dlsmith, vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 8040822: Duplicated notifications can be sent to TaskListener Summary: The analyze finished event must only be sent on the first call to JavaCompiler.flow for a given class. Reviewed-by: jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 8041695: Update the NetBeans build script and metadata Summary: Various improvements to the NetBeans project for langtools, adding formatting/import setting for langtools. Reviewed-by: ksrini http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb 8038788: javac behaves incorrectly for annotations after method type parameters in some cases Reviewed-by: jjg, emc http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd 8038455: Use single Context for all rounds of annotation processing Summary: One set of javac services, as well as created ClassSymbols, is reused for all rounds of processing now. Reviewed-by: jjg, jfranck, darcy, vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 8035890: jdk8 javac -source 7 compiles test case it should not Summary: Ensuring source level checks are performed in two additional cases related to type annotations, adding specialized error message for annotations after method type parameters. Reviewed-by: jfranck, jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 8034854: outer_class_info_index of synthetic class is not zero Summary: Auxiliary synthetic anonymous classes should not have an outer class specified in the InnerClasses attribute. Reviewed-by: vromero, jjg, abuckley http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f 8033961: Formatting of -Xlint: command line help Summary: Improving formatting of command line help for -Xlint, including a short description of each lint. Reviewed-by: jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 8033421: @SuppressWarnings("deprecation") does not work when overriding deprecated method Summary: When the overrides deprecated method warning is being reported, need to do that in the lint context of the method. Reviewed-by: vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 8030091: Request to update error messages from javac for negative varargs test cases Summary: Introducing a new error message for vararg parameter not being the last parameter, improving error message for unexpected character after a parameter. Reviewed-by: jjg, sogoel http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception parameters when not generating debuging info Summary: The exception parameters with type annotations need to be added into the varBuffer even if not generating debug info Reviewed-by: jjg, emc http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements Summary: Match the required and actual annotations using Element equivalence rather than TypeMirror equivalence, to avoid trouble with erroneous types. Reviewed-by: darcy http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 8029376: Full attribution of unresolvable annotations 8029161: javac crashing when processing broken annotations Summary: Attributing values of annotation attributes regardless how broken the annotation is. Reviewed-by: jjg, jfranck http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 8028235: Better error recovery for parsing 'void' as a type of the lambda parameter Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. Reviewed-by: vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when passed a Character. Summary: JCLiteral for char must contain an Integer, not the provided Character. Reviewed-by: jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e 8029800: Flags.java uses String.toLowerCase without specifying Locale Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on the default locale, converting almost all usages of String.toLowerCase/toUpperCase to use the new methods. Reviewed-by: jjg, bpatel http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 8027789: Access method for Outer.super.m() references indirect superclass Summary: Internally convert the qualified super access to an equivalent of an unqualified super access inside the access method. Reviewed-by: vromero, jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 8026374: javac accepts void as a method parameter Summary: Changing Check.validate to reject void types. Reviewed-by: jjg, vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 8027142: Invokedynamic instructions don't get line number table entries Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos. Reviewed-by: jjg, jrose, ksrini, vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests Summary: When invoking interface default method via a superclass, use the direct superclass in the reference. Reviewed-by: vromero, dlsmith, jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 8027310: Annotation Processor crashes with NPE Summary: JCAnnotation.attribute is null when annotation type is unavailable Reviewed-by: jjg, jfranck http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a 8026861: Wrong LineNumberTable for variable declarations in lambdas Summary: Setting or correcting positions for many trees produced by LambdaToMethod. Reviewed-by: vromero, rfield http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures Reviewed-by: jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb 8014016: javac is too late detecting invalid annotation usage Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter Reviewed-by: jjg, emc, jfranck http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type Reviewed-by: darcy, jfranck, jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 8025087: Annotation processing api returns default modifier for interface static method Summary: ClassReader must not set Flags.DEFAULT for interface static methods Reviewed-by: vromero, jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) Summary: Should not generate non-public $assertionsDisabled field into interfaces Reviewed-by: jjg, vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 8025118: Annotation processing api returns default modifier for interface without default methods Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT Reviewed-by: darcy, jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 8022765: Compiler crashes with exception on wrong usage of an annotation. Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately Reviewed-by: jfranck, jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 8023835: TreeMaker.QualIdent() too leafy Reviewed-by: jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d 8022567: Javac Should Generate Warnings For Raw Array Type Reviewed-by: jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f 8021112: Spurious unchecked warning reported by javac 6480588: No way to suppress deprecation warnings when implementing deprecated interface Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings Reviewed-by: jjg, vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 8019521: Enhanced rethrow disabled in lambdas Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas Reviewed-by: mcimadamore, jjg http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 8022508: javac crashes if the generics arity of a base class is wrong Reviewed-by: mcimadamore, vromero http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda Reviewed-by: mcimadamore http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c 8021338: Diamond finder may mark a required type argument as unnecessary Reviewed-by: mcimadamore http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac 8020689: Missing LineNumberTable entries in compiled class files Reviewed-by: ksrini, mcimadamore http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d 8020586: Warning produced for an incorrect file Summary: Always using DeferredLintHandler.immediateHandler when processing import classes Reviewed-by: mcimadamore http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 8004504: ListBuffer could reuse List.nil() as the sentinel element Summary: ListBuffer.last now points to the last elements with client data, or null if none. Reviewed-by: jjg, mcimadamore From joe.darcy at oracle.com Thu Oct 9 01:57:07 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 08 Oct 2014 18:57:07 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <5435EB73.8020509@oracle.com> Vote: yes -Joe On 10/8/2014 6:54 PM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in > messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer > to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until > annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type > parameters > Summary: When reading type variable's annotations out of the owner's > type annotations, use the type variable's index in owner to exclude > annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always > point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first > call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, > adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, > is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional > cases related to type annotations, adding specialized error message > for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an > outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, > including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when > overriding deprecated method > Summary: When the overrides deprecated method warning is being > reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative > varargs test cases > Summary: Introducing a new error message for vararg parameter not > being the last parameter, improving error message for unexpected > character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception > parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be > added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong > elements > Summary: Match the required and actual annotations using Element > equivalence rather than TypeMirror equivalence, to avoid trouble with > erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how > broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the > lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when > passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent > on the default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an > equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write > pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself > does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use > the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is > unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting > againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the > found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for > interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static > methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class > (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for > interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - > ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings > are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small > cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught > exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared > exceptions inside lambda expressions, rather than one error for the > whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when > processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client > data, or null if none. > Reviewed-by: jjg, mcimadamore > From brian.goetz at oracle.com Thu Oct 9 01:58:17 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 8 Oct 2014 20:58:17 -0500 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <867D160A-CCDC-42AF-988D-7965BFE8C634@oracle.com> Vote: yes On Oct 8, 2014, at 8:54 PM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on NetBeans and since joining the javac team. He has contributed over 90 changesets and participated in many reviews as well. Some of his more significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type parameters > Summary: When reading type variable's annotations out of the owner's type annotations, use the type variable's index in owner to exclude annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional cases related to type annotations, adding specialized error message for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when overriding deprecated method > Summary: When the overrides deprecated method warning is being reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative varargs test cases > Summary: Introducing a new error message for vararg parameter not being the last parameter, improving error message for unexpected character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements > Summary: Match the required and actual annotations using Element equivalence rather than TypeMirror equivalence, to avoid trouble with erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on the default locale, converting almost all usages of String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) > Summary: Should not generate non-public $assertionsDisabled field into interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client data, or null if none. > Reviewed-by: jjg, mcimadamore > From xuelei.fan at oracle.com Thu Oct 9 02:05:18 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 09 Oct 2014 10:05:18 +0800 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <5435ED5E.2030009@oracle.com> Vote: yes Xuelei On 10/9/2014 9:54 AM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in > messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer > to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until > annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type > parameters > Summary: When reading type variable's annotations out of the owner's > type annotations, use the type variable's index in owner to exclude > annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always point > at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first call > to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, > adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, is > reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional > cases related to type annotations, adding specialized error message for > annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an outer > class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, including > a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when overriding > deprecated method > Summary: When the overrides deprecated method warning is being reported, > need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative > varargs test cases > Summary: Introducing a new error message for vararg parameter not being > the last parameter, improving error message for unexpected character > after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception > parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be added > into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements > Summary: Match the required and actual annotations using Element > equivalence rather than TypeMirror equivalence, to avoid trouble with > erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how > broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the > lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when > passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on > the default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an equivalent > of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write pendingStatPos, > if set, into the LineNumberTable. Invokedynamic itself does not set the > pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use > the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting > againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the found > type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for > interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static > methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for > interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - > ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings are > reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small > cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught exceptions > in lambda expression > Summary: Producing individual errors for uncaught undeclared exceptions > inside lambda expressions, rather than one error for the whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when > processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client > data, or null if none. > Reviewed-by: jjg, mcimadamore > From Alan.Bateman at oracle.com Thu Oct 9 02:35:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Oct 2014 19:35:48 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <5435F484.1010801@oracle.com> Vote: yes From mandy.chung at oracle.com Thu Oct 9 03:08:12 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 Oct 2014 20:08:12 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <5435FC1C.9030604@oracle.com> Vote: yes On 10/8/2014 6:54 PM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in > messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer > to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until > annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type > parameters > Summary: When reading type variable's annotations out of the owner's > type annotations, use the type variable's index in owner to exclude > annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always > point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first > call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, > adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, > is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional > cases related to type annotations, adding specialized error message > for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an > outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, > including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when > overriding deprecated method > Summary: When the overrides deprecated method warning is being > reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative > varargs test cases > Summary: Introducing a new error message for vararg parameter not > being the last parameter, improving error message for unexpected > character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception > parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be > added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong > elements > Summary: Match the required and actual annotations using Element > equivalence rather than TypeMirror equivalence, to avoid trouble with > erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how > broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the > lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when > passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent > on the default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an > equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write > pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself > does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use > the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is > unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting > againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the > found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for > interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static > methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class > (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for > interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - > ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings > are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small > cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught > exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared > exceptions inside lambda expressions, rather than one error for the > whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when > processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client > data, or null if none. > Reviewed-by: jjg, mcimadamore > From vicente.romero at oracle.com Thu Oct 9 03:13:14 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 08 Oct 2014 20:13:14 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <5435FD4A.40903@oracle.com> Vote: yes Vicente On 10/08/2014 06:54 PM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in > messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer > to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until > annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type > parameters > Summary: When reading type variable's annotations out of the owner's > type annotations, use the type variable's index in owner to exclude > annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always > point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first > call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, > adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, > is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional > cases related to type annotations, adding specialized error message > for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an > outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, > including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when > overriding deprecated method > Summary: When the overrides deprecated method warning is being > reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative > varargs test cases > Summary: Introducing a new error message for vararg parameter not > being the last parameter, improving error message for unexpected > character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception > parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be > added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong > elements > Summary: Match the required and actual annotations using Element > equivalence rather than TypeMirror equivalence, to avoid trouble with > erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how > broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the > lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when > passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent > on the default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an > equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write > pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself > does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use > the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is > unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting > againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the > found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for > interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static > methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class > (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for > interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - > ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings > are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small > cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught > exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared > exceptions inside lambda expressions, rather than one error for the > whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when > processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client > data, or null if none. > Reviewed-by: jjg, mcimadamore > From Roger.Riggs at Oracle.com Thu Oct 9 03:59:17 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 08 Oct 2014 20:59:17 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <54360815.6050500@Oracle.com> Vote: yes On 10/8/14 6:54 PM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. From alexander.zuev at oracle.com Thu Oct 9 04:14:31 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 9 Oct 2014 08:14:31 +0400 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: Vote: yes /Alex > On 09 Oct 2014, at 05:54, Jonathan Gibbons wrote: > > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on NetBeans and since joining the javac team. He has contributed over 90 changesets and participated in many reviews as well. Some of his more significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type parameters > Summary: When reading type variable's annotations out of the owner's type annotations, use the type variable's index in owner to exclude annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional cases related to type annotations, adding specialized error message for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when overriding deprecated method > Summary: When the overrides deprecated method warning is being reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative varargs test cases > Summary: Introducing a new error message for vararg parameter not being the last parameter, improving error message for unexpected character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements > Summary: Match the required and actual annotations using Element equivalence rather than TypeMirror equivalence, to avoid trouble with erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on the default locale, converting almost all usages of String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) > Summary: Should not generate non-public $assertionsDisabled field into interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client data, or null if none. > Reviewed-by: jjg, mcimadamore > From daniel.fuchs at oracle.com Thu Oct 9 06:27:45 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 09 Oct 2014 08:27:45 +0200 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <54362AE1.2010401@oracle.com> Vote: yes -- daniel On 10/9/14 3:54 AM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > From staffan.larsen at oracle.com Thu Oct 9 06:51:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 9 Oct 2014 08:51:57 +0200 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <346E836A-60ED-4521-8402-3E23FC8AFC83@oracle.com> Vote: yes. On 9 okt 2014, at 03:54, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on NetBeans and since joining the javac team. He has contributed over 90 changesets and participated in many reviews as well. Some of his more significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type parameters > Summary: When reading type variable's annotations out of the owner's type annotations, use the type variable's index in owner to exclude annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional cases related to type annotations, adding specialized error message for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when overriding deprecated method > Summary: When the overrides deprecated method warning is being reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative varargs test cases > Summary: Introducing a new error message for vararg parameter not being the last parameter, improving error message for unexpected character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements > Summary: Match the required and actual annotations using Element equivalence rather than TypeMirror equivalence, to avoid trouble with erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on the default locale, converting almost all usages of String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) > Summary: Should not generate non-public $assertionsDisabled field into interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client data, or null if none. > Reviewed-by: jjg, mcimadamore > From jaroslav.bachorik at oracle.com Thu Oct 9 07:17:56 2014 From: jaroslav.bachorik at oracle.com (-JB-) Date: Thu, 09 Oct 2014 09:17:56 +0200 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: Vote: Yes -JB- On October 9, 2014 3:54:42 AM CEST, Jonathan Gibbons wrote: >I hereby nominate Jan Lahoda to jdk9 Reviewer. > >Jan has had many years experience working on javac, while working on >NetBeans and since joining the javac team. He has contributed over 90 >changesets and participated in many reviews as well. Some of his more >significant contributions are listed below. > >Votes are due by 22 Oct 2014. > >Only current jdk9 Reviewers [1] are eiligible 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]. > >-Alan. > >[1] http://openjdk.java.net/census >[2] http://openjdk.java.net/projects/#reviewer-vote > > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea >8043643: Add an crules analyzer avoiding string concatenation in >messages of Assert checks. >Summary: Generalizing the crules infrastructure, adding a new analyzer >to check String concatenation in Assert calls. >Reviewed-by: jjg, vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 >6707032: Division by zero warning not suppressed properly in some cases >Summary: Delay reporting of the division by zero warning until >annotations are resolved, so that @SuppressWarnings works correctly. >Reviewed-by: vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a >8046916: Type parameter annotations don't work with multiple type >parameters >Summary: When reading type variable's annotations out of the owner's >type annotations, use the type variable's index in owner to exclude >annotations belonging to other type variables. >Reviewed-by: jfranck, emc > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 >8043186: javac test langtools/tools/javac/util/StringUtilsTest.java >fails >Summary: The result of String.toLowerCase.indexOf does not always point > >at the start of the given string in the non-lowercased text. >Reviewed-by: jjg, bpatel > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf >8041663: Sensitive dependence on location of nested interface >Summary: Adding a method among ambiguous candidates only if it is more >specific than some of the existing candidates. >Reviewed-by: dlsmith, vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 >8040822: Duplicated notifications can be sent to TaskListener >Summary: The analyze finished event must only be sent on the first call > >to JavaCompiler.flow for a given class. >Reviewed-by: jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 >8041695: Update the NetBeans build script and metadata >Summary: Various improvements to the NetBeans project for langtools, >adding formatting/import setting for langtools. >Reviewed-by: ksrini > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb >8038788: javac behaves incorrectly for annotations after method type >parameters in some cases >Reviewed-by: jjg, emc > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd >8038455: Use single Context for all rounds of annotation processing >Summary: One set of javac services, as well as created ClassSymbols, is > >reused for all rounds of processing now. >Reviewed-by: jjg, jfranck, darcy, vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 >8035890: jdk8 javac -source 7 compiles test case it should not >Summary: Ensuring source level checks are performed in two additional >cases related to type annotations, adding specialized error message for > >annotations after method type parameters. >Reviewed-by: jfranck, jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 >8034854: outer_class_info_index of synthetic class is not zero >Summary: Auxiliary synthetic anonymous classes should not have an outer > >class specified in the InnerClasses attribute. >Reviewed-by: vromero, jjg, abuckley > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f >8033961: Formatting of -Xlint: command line help >Summary: Improving formatting of command line help for -Xlint, >including >a short description of each lint. >Reviewed-by: jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 >8033421: @SuppressWarnings("deprecation") does not work when overriding > >deprecated method >Summary: When the overrides deprecated method warning is being >reported, >need to do that in the lint context of the method. >Reviewed-by: vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 >8030091: Request to update error messages from javac for negative >varargs test cases >Summary: Introducing a new error message for vararg parameter not being > >the last parameter, improving error message for unexpected character >after a parameter. >Reviewed-by: jjg, sogoel > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 >8028576: Incorrect RuntimeVisibleTypeAnnotations for exception >parameters when not generating debuging info >Summary: The exception parameters with type annotations need to be >added >into the varBuffer even if not generating debug info >Reviewed-by: jjg, emc > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea >8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong >elements >Summary: Match the required and actual annotations using Element >equivalence rather than TypeMirror equivalence, to avoid trouble with >erroneous types. >Reviewed-by: darcy > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 >8029376: Full attribution of unresolvable annotations >8029161: javac crashing when processing broken annotations >Summary: Attributing values of annotation attributes regardless how >broken the annotation is. >Reviewed-by: jjg, jfranck > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 >8028235: Better error recovery for parsing 'void' as a type of the >lambda parameter >Summary: Handle "void" as a primitive type in >JavacParser.analyzeParens. >Reviewed-by: vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 >8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when >passed a Character. >Summary: JCLiteral for char must contain an Integer, not the provided >Character. >Reviewed-by: jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e >8029800: Flags.java uses String.toLowerCase without specifying Locale >Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on > >the default locale, converting almost all usages of >String.toLowerCase/toUpperCase to use the new methods. >Reviewed-by: jjg, bpatel > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 >8027789: Access method for Outer.super.m() references indirect >superclass >Summary: Internally convert the qualified super access to an equivalent > >of an unqualified super access inside the access method. >Reviewed-by: vromero, jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 >8026374: javac accepts void as a method parameter >Summary: Changing Check.validate to reject void types. >Reviewed-by: jjg, vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 >8027142: Invokedynamic instructions don't get line number table entries >Summary: When emitting invokedynamic instruction, write pendingStatPos, > >if set, into the LineNumberTable. Invokedynamic itself does not set the > >pendingStatPos. >Reviewed-by: jjg, jrose, ksrini, vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 >8027281: Incorrect invokespecial generated for JCK lang >EXPR/expr636/expr63602m* tests >Summary: When invoking interface default method via a superclass, use >the direct superclass in the reference. >Reviewed-by: vromero, dlsmith, jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 >8027310: Annotation Processor crashes with NPE >Summary: JCAnnotation.attribute is null when annotation type is >unavailable >Reviewed-by: jjg, jfranck > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a >8026861: Wrong LineNumberTable for variable declarations in lambdas >Summary: Setting or correcting positions for many trees produced by >LambdaToMethod. >Reviewed-by: vromero, rfield > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 >8026180: com.sun.source.tree.NewArrayTree refers to >com.sun.tools.javac.util.List >Summary: Correcting import in NewArrayTree, adding test protecting >againts improper types in API signatures >Reviewed-by: jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb >8014016: javac is too late detecting invalid annotation usage >Summary: Adding new queue to Annotate for validation tasks, performing >annotation validation during enter >Reviewed-by: jjg, emc, jfranck > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 >6278240: Exception from AnnotationValue.getValue() should list the >found >type not the required type >Reviewed-by: darcy, jfranck, jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 >8025087: Annotation processing api returns default modifier for >interface static method >Summary: ClassReader must not set Flags.DEFAULT for interface static >methods >Reviewed-by: vromero, jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b >8025141: java.lang.ClassFormatError: Illegal field modifiers in class >(...) >Summary: Should not generate non-public $assertionsDisabled field into >interfaces >Reviewed-by: jjg, vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 >8025118: Annotation processing api returns default modifier for >interface without default methods >Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT >Reviewed-by: darcy, jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 >8022765: Compiler crashes with exception on wrong usage of an >annotation. >Summary: Error recovery for incorrect annotation attribute values - >ensure the values are always attributed appropriately >Reviewed-by: jfranck, jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 >8023835: TreeMaker.QualIdent() too leafy >Reviewed-by: jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d >8022567: Javac Should Generate Warnings For Raw Array Type >Reviewed-by: jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f >8021112: Spurious unchecked warning reported by javac >6480588: No way to suppress deprecation warnings when implementing >deprecated interface >Summary: Fixing DeferredLintHandler configuration, so lint warnings are > >reported with correct @SuppressWarnings settings >Reviewed-by: jjg, vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 >8019521: Enhanced rethrow disabled in lambdas >Summary: Fixing effectively final detection inside lambdas, small >cleanup related to thrown types detection in lambdas >Reviewed-by: mcimadamore, jjg > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 >8022508: javac crashes if the generics arity of a base class is wrong >Reviewed-by: mcimadamore, vromero > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 >8015809: More user friendly compile-time errors for uncaught exceptions > >in lambda expression >Summary: Producing individual errors for uncaught undeclared exceptions > >inside lambda expressions, rather than one error for the whole lambda >Reviewed-by: mcimadamore > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c >8021338: Diamond finder may mark a required type argument as >unnecessary >Reviewed-by: mcimadamore > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac >8020689: Missing LineNumberTable entries in compiled class files >Reviewed-by: ksrini, mcimadamore > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d >8020586: Warning produced for an incorrect file >Summary: Always using DeferredLintHandler.immediateHandler when >processing import classes >Reviewed-by: mcimadamore > >http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 >8004504: ListBuffer could reuse List.nil() as the sentinel element >Summary: ListBuffer.last now points to the last elements with client >data, or null if none. >Reviewed-by: jjg, mcimadamore -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From kumar.x.srinivasan at oracle.com Thu Oct 9 13:32:11 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 09 Oct 2014 06:32:11 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <54368E5B.4040506@oracle.com> Vote: yes On 10/8/2014 6:54 PM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in > messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer > to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until > annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type > parameters > Summary: When reading type variable's annotations out of the owner's > type annotations, use the type variable's index in owner to exclude > annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always > point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first > call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, > adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, > is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional > cases related to type annotations, adding specialized error message > for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an > outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, > including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when > overriding deprecated method > Summary: When the overrides deprecated method warning is being > reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative > varargs test cases > Summary: Introducing a new error message for vararg parameter not > being the last parameter, improving error message for unexpected > character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception > parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be > added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong > elements > Summary: Match the required and actual annotations using Element > equivalence rather than TypeMirror equivalence, to avoid trouble with > erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how > broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the > lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when > passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent > on the default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an > equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write > pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself > does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use > the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is > unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting > againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the > found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for > interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static > methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class > (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for > interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - > ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings > are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small > cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught > exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared > exceptions inside lambda expressions, rather than one error for the > whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when > processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client > data, or null if none. > Reviewed-by: jjg, mcimadamore > From paul.sandoz at oracle.com Thu Oct 9 15:26:21 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Oct 2014 08:26:21 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <7B62EF72-87F0-4A49-B166-0DB6C54B2744@oracle.com> Vote: yes Paul. From mparchet at sunrise.ch Thu Oct 9 16:03:33 2014 From: mparchet at sunrise.ch (=?utf-8?Q?Parchet_Micha=C3=ABl?=) Date: Thu, 9 Oct 2014 18:03:33 +0200 Subject: Fwd: CFV: New jdk9 Reviewer: Jan Lahoda References: <6E5F1C08-CF24-476B-B4FB-FC9D3E516B41@sunrise.ch> Message-ID: D?but du message transf?r? : > Exp?diteur: Parchet Micha?l > Date: 9 octobre 2014 18:00:03 UTC+2 > Destinataire: Paul Sandoz > Objet: R?p : CFV: New jdk9 Reviewer: Jan Lahoda > > Hello, > > Excuse me. What's the CFV project ? > Thanks for your answer > Best regards > mparchet > > > >> Le 9 oct. 2014 ? 17:26, Paul Sandoz a ?crit : >> >> Vote: yes >> >> Paul. From robert.field at oracle.com Thu Oct 9 17:55:12 2014 From: robert.field at oracle.com (Robert Field) Date: Thu, 09 Oct 2014 10:55:12 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <5436CC00.4080607@oracle.com> Vote: yes -Robert On 10/08/14 18:54, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in > messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer > to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until > annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type > parameters > Summary: When reading type variable's annotations out of the owner's > type annotations, use the type variable's index in owner to exclude > annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always > point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first > call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, > adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, > is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional > cases related to type annotations, adding specialized error message > for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an > outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, > including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when > overriding deprecated method > Summary: When the overrides deprecated method warning is being > reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative > varargs test cases > Summary: Introducing a new error message for vararg parameter not > being the last parameter, improving error message for unexpected > character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception > parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be > added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong > elements > Summary: Match the required and actual annotations using Element > equivalence rather than TypeMirror equivalence, to avoid trouble with > erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how > broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the > lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when > passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent > on the default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an > equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write > pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself > does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use > the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is > unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting > againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the > found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for > interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static > methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class > (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for > interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - > ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings > are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small > cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught > exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared > exceptions inside lambda expressions, rather than one error for the > whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when > processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client > data, or null if none. > Reviewed-by: jjg, mcimadamore > From joel.franck at oracle.com Fri Oct 10 11:49:46 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 10 Oct 2014 13:49:46 +0200 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <8E9E9810-29CF-41B2-869F-16E6200E36A9@oracle.com> Vote: yes cheers /Joel On 9 okt 2014, at 03:54, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on NetBeans and since joining the javac team. He has contributed over 90 changesets and participated in many reviews as well. Some of his more significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type parameters > Summary: When reading type variable's annotations out of the owner's type annotations, use the type variable's index in owner to exclude annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional cases related to type annotations, adding specialized error message for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when overriding deprecated method > Summary: When the overrides deprecated method warning is being reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative varargs test cases > Summary: Introducing a new error message for vararg parameter not being the last parameter, improving error message for unexpected character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements > Summary: Match the required and actual annotations using Element equivalence rather than TypeMirror equivalence, to avoid trouble with erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on the default locale, converting almost all usages of String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) > Summary: Should not generate non-public $assertionsDisabled field into interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client data, or null if none. > Reviewed-by: jjg, mcimadamore > From joel.franck at oracle.com Fri Oct 10 12:10:33 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 10 Oct 2014 14:10:33 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad Message-ID: I hereby nominate Claes Redestad to JDK 9 Committer. Claes is a member of the Java SE Performance team. He has contributed 16 changesets to JDK 9, out of which at least 10 can be considered significant[1]. Votes are due by 1600 CET, October 24, 2014. Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thank you, Joel Borggr?n-Franck [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 [2] http://openjdk.java.net/census#jdk9 [3] http://openjdk.java.net/projects#committer-vote [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From alejandro.murillo at oracle.com Fri Oct 10 12:21:27 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 10 Oct 2014 06:21:27 -0600 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437CF47.2010300@oracle.com> vote: yes On 10/10/2014 6:10 AM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. -- Alejandro From stefan.karlsson at oracle.com Fri Oct 10 12:10:41 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 Oct 2014 14:10:41 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437CCC1.2000801@oracle.com> Vote: yes StefanK On 2014-10-10 14:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From jesper.wilhelmsson at oracle.com Fri Oct 10 12:26:32 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 10 Oct 2014 14:26:32 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437D078.3030401@oracle.com> Vote: Yes /Jesper Joel Borggr?n-Franck skrev 10/10/14 14:10: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html > From thomas.schatzl at oracle.com Fri Oct 10 13:26:58 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 10 Oct 2014 15:26:58 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <1412947618.2687.7.camel@cirrus> Vote: yes From roger.riggs at oracle.com Fri Oct 10 13:36:50 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 Oct 2014 09:36:50 -0400 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437E0F2.40705@oracle.com> Vote: Yes On 10/10/2014 8:10 AM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > From daniel.daugherty at oracle.com Fri Oct 10 13:38:44 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 10 Oct 2014 07:38:44 -0600 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437E164.4090707@oracle.com> Vote: yes Dan On 10/10/14 6:10 AM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html > From erik.gahlin at oracle.com Fri Oct 10 13:46:13 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 10 Oct 2014 15:46:13 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437E325.4000805@oracle.com> Vote: yes Erik Joel Borggr?n-Franck skrev 2014-10-10 14:10: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From mikael.gerdin at oracle.com Fri Oct 10 13:41:35 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 10 Oct 2014 15:41:35 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437E20F.4070308@oracle.com> Vote: yes On 10/10/2014 02:10 PM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html > From magnus.ihse.bursie at oracle.com Fri Oct 10 14:03:14 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 10 Oct 2014 16:03:14 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437E722.3080408@oracle.com> Vote: yes /Magnus On 2014-10-10 14:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From erik.joelsson at oracle.com Fri Oct 10 13:59:15 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 Oct 2014 15:59:15 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437E633.6090905@oracle.com> Vote: yes From vladimir.x.ivanov at oracle.com Fri Oct 10 15:06:59 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Oct 2014 19:06:59 +0400 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <5437F613.3080907@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 10/9/14, 5:54 AM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in > messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer > to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until > annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type > parameters > Summary: When reading type variable's annotations out of the owner's > type annotations, use the type variable's index in owner to exclude > annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always point > at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first call > to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, > adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, is > reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional > cases related to type annotations, adding specialized error message for > annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an outer > class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, including > a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when overriding > deprecated method > Summary: When the overrides deprecated method warning is being reported, > need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative > varargs test cases > Summary: Introducing a new error message for vararg parameter not being > the last parameter, improving error message for unexpected character > after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception > parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be added > into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements > Summary: Match the required and actual annotations using Element > equivalence rather than TypeMirror equivalence, to avoid trouble with > erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how > broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the > lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when > passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on > the default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an equivalent > of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write pendingStatPos, > if set, into the LineNumberTable. Invokedynamic itself does not set the > pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use > the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting > againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the found > type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for > interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static > methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for > interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - > ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings are > reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small > cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught exceptions > in lambda expression > Summary: Producing individual errors for uncaught undeclared exceptions > inside lambda expressions, rather than one error for the whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when > processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client > data, or null if none. > Reviewed-by: jjg, mcimadamore > From vladimir.x.ivanov at oracle.com Fri Oct 10 15:07:08 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Oct 2014 19:07:08 +0400 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5437F61C.4010903@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 10/10/14, 4:10 PM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html > From joe.darcy at oracle.com Fri Oct 10 15:59:01 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 Oct 2014 08:59:01 -0700 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <54380245.2000607@oracle.com> Vote: yes -Joe On 10/10/2014 5:10 AM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From brent.christian at oracle.com Fri Oct 10 16:02:08 2014 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 10 Oct 2014 09:02:08 -0700 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <54380300.7090801@oracle.com> Vote: yes On 10/10/14 5:10 AM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html > From lance.andersen at oracle.com Fri Oct 10 16:35:32 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 10 Oct 2014 12:35:32 -0400 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: <5437E164.4090707@oracle.com> References: <5437E164.4090707@oracle.com> Message-ID: vote: Yes On Oct 10, 2014, at 9:38 AM, "Daniel D. Daugherty" wrote: > Vote: yes > > Dan > > > On 10/10/14 6:10 AM, Joel Borggr?n-Franck wrote: >> I hereby nominate Claes Redestad to JDK 9 Committer. >> >> Claes is a member of the Java SE Performance team. >> He has contributed 16 changesets to JDK 9, out of which at least >> 10 can be considered significant[1]. >> >> Votes are due by 1600 CET, October 24, 2014. >> >> Only current JDK 9 Committers [2] are eligible to vote on this >> nomination. Votes must be cast in the open by replying >> to this mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thank you, >> Joel Borggr?n-Franck >> >> [1] >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 >> >> [2] http://openjdk.java.net/census#jdk9 >> >> [3] http://openjdk.java.net/projects#committer-vote >> >> [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Fri Oct 10 16:36:21 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 Oct 2014 09:36:21 -0700 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <54380B05.3070200@oracle.com> Vote: yes Mandy From neugens.limasoftware at gmail.com Fri Oct 10 17:45:58 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 10 Oct 2014 19:45:58 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: Vote: Yes, Mario 2014-10-10 14:10 GMT+02:00 Joel Borggr?n-Franck : > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From staffan.larsen at oracle.com Fri Oct 10 17:52:29 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 10 Oct 2014 19:52:29 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: Vote: yes On 10 okt 2014, at 14:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From henry.jen at oracle.com Fri Oct 10 19:14:35 2014 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 10 Oct 2014 12:14:35 -0700 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5438301B.6060503@oracle.com> Vote: Yes Cheers, Henry On 10/10/2014 05:10 AM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > From ivan.gerasimov at oracle.com Fri Oct 10 19:19:09 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 10 Oct 2014 23:19:09 +0400 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <5438312D.80303@oracle.com> Vote: yes Ivan On 10.10.2014 16:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html > From jonathan.gibbons at oracle.com Fri Oct 10 19:49:07 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 10 Oct 2014 12:49:07 -0700 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <54383833.5070104@oracle.com> Vote: yes On 10/10/2014 05:10 AM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From openjdk at duigou.org Sat Oct 11 06:16:47 2014 From: openjdk at duigou.org (Mike Duigou) Date: Fri, 10 Oct 2014 23:16:47 -0700 Subject: CFV: New jdk9 Reviewer: Jan Lahoda Message-ID: Vote: YES Mike Duigou (mduigou) From openjdk at duigou.org Sat Oct 11 06:26:11 2014 From: openjdk at duigou.org (Mike Duigou) Date: Fri, 10 Oct 2014 23:26:11 -0700 Subject: CFV: New JDK 9 Committer: Claes Redestad Message-ID: Vote: YES From erik.helin at oracle.com Mon Oct 13 08:14:05 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 13 Oct 2014 10:14:05 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <543B89CD.8000008@oracle.com> Vote: yes Thanks, Erik On 2014-10-10 14:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html > From stefan.johansson at oracle.com Mon Oct 13 08:37:23 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 13 Oct 2014 10:37:23 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <543B8F43.8030106@oracle.com> Vote: yes Stefan On 2014-10-10 14:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From bengt.rutisson at oracle.com Mon Oct 13 08:54:40 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 13 Oct 2014 10:54:40 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <543B9350.4010306@oracle.com> Vote: yes Bengt On 2014-10-10 14:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From paul.sandoz at oracle.com Mon Oct 13 13:25:56 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 13 Oct 2014 15:25:56 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <9E5BA9A1-E680-41DB-A586-308A11A2499D@oracle.com> Vote: yes. Paul. From serguei.spitsyn at oracle.com Mon Oct 13 16:12:37 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 Oct 2014 09:12:37 -0700 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <543BF9F5.2000206@oracle.com> Vote: yes On 10/10/14 5:10 AM, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From jonathan.gibbons at oracle.com Mon Oct 13 22:20:33 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 Oct 2014 15:20:33 -0700 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <542E5728.8010709@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> Message-ID: <543C5031.2020000@oracle.com> Bengt, There may be problems with the latest version of webrev. Eric McCorkle is reporting syntax errors from his version of ksh. patch cdiffs udiffs sdiffs frames old new src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ../../tl/make/scripts/webrev.ksh[2241]: build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic syntax error -- Jon On 10/03/2014 12:58 AM, Bengt Rutisson wrote: > > On 2014-10-02 23:39, John Coomes wrote: >> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>> On 2014-10-02 01:08, John Coomes wrote: >>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>> Hi Daniel, >>>>> >>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> The new version looks good to me, but I am not a reviewer >>>>>> fore CODE_TOOLS. >>>>> Thanks for looking at this Daniel! >>>>> >>>>>> Hopefully someone who is will step in :-) >>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>> for the >>>>> patch too. >>>> Looks good to me; I'll sponsor it. Send me (privately) the result of >>>> "hg export --git" and I'll push that. >>> Thanks for looking at this, John! And thanks for sponsoring the change. >>> I'll send you the export in a separate email. >> Got it; it's been pushed. > > Thanks for pushing this, John! > > Bengt > >> >> -John >> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>> Hi Daniel, >>>>>>> >>>>>>> Thanks for looking at this! >>>>>>> >>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> This is a really cool feature! >>>>>>> Thanks! >>>>>>> >>>>>>>> I have downloaded your patch and applied it in my >>>>>>>> local webrev repo - and played with the new >>>>>>>> webrev in a couple of repositories where I have >>>>>>>> pending uncommitted changes. >>>>>>>> >>>>>>>> This seems to work well. >>>>>>>> >>>>>>>> I have used: >>>>>>>> >>>>>>>> webrev -fN from top level repo >>>>>>>> webrev -N from jdk repo >>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>> >>>>>>> Great that you tired it out. >>>>>>> >>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>> intended or not. >>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>> you could use typeset at least in those functions that >>>>>>>> already use it for their parameters? For instance >>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>> Or did you intentionally not used it? >>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>> lines you >>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>> suggestion >>>>>>> is good. >>>>>>> >>>>>>>> Also you should increment the version of webrev. >>>>>>>> IIRC that would be 25.6: >>>>>>>> >>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>> Thanks, didn't think of that. >>>>>>> >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>> >>>>>>> Diff compared to the first version: >>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>>> best regards, >>>>>>>> >>>>>>>> -- daniel >>>>>>>> >>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> (This is a patch for webrev, but I am cross posting to the JDK >>>>>>>>> 9 dev >>>>>>>>> list since I'm not sure how many are on the webrev-dev list and >>>>>>>>> most JDK >>>>>>>>> developers might have opinions about this change.) >>>>>>>>> >>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>> the webrev >>>>>>>>> tool? >>>>>>>>> >>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Background: >>>>>>>>> When browsing review requests that span many files it is quite >>>>>>>>> time >>>>>>>>> consuming to have to go back to the index page to view to the >>>>>>>>> next or >>>>>>>>> previous file. This patch adds links to the next and previous >>>>>>>>> files in >>>>>>>>> the diff views (including frames). >>>>>>>>> >>>>>>>>> The above webrev is generated with this new version, but since >>>>>>>>> it only >>>>>>>>> contains a single file it is not that interesting. Here is an >>>>>>>>> example of >>>>>>>>> what the new webrev looks like for a larger change (the G1 class >>>>>>>>> unloading change): >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> > From yumin.qi at oracle.com Mon Oct 13 22:58:38 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 13 Oct 2014 15:58:38 -0700 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError Message-ID: <543C591E.8010602@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ the bug marked as confidential so post the webrev internally. Problem: The test case tries to load a class from the same jar via agent in the middle of loading another class from the jar via same class loader in same thread. The call happens in transform which is a rare case --- in middle of loading class, loading another class. The result is a CircularityError. When first class is in loading, in vm we put JarLoader$2 on place holder table, then we start the defineClass, which calls transform, begins loading the second class so go along the same routine for loading JarLoader$2 first, found it already in placeholder table. A CircularityError is thrown. Fix: The test case should not call loading class with same class loader in same thread from same jar in 'transform' method. I modify it loading with system class loader and we expect see ClassNotFoundException. Detail see bug comments. Thanks Yumin * From david.holmes at oracle.com Tue Oct 14 02:30:54 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Oct 2014 12:30:54 +1000 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <543C591E.8010602@oracle.com> References: <543C591E.8010602@oracle.com> Message-ID: <543C8ADE.5000309@oracle.com> Hi Yumin, jdk9-dev is not the best place for code review requests. serviceability-dev would be better for this test. On 14/10/2014 8:58 AM, Yumin Qi wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8038468 > webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ > > the bug marked as confidential so post the webrev internally. Not any more :) > Problem: The test case tries to load a class from the same jar via agent > in the middle of loading another class from the jar via same class > loader in same thread. The call happens in transform which is a rare > case --- in middle of loading class, loading another class. The result > is a CircularityError. When first class is in loading, in vm we put > JarLoader$2 on place holder table, then we start the defineClass, which > calls transform, begins loading the second class so go along the same > routine for loading JarLoader$2 first, found it already in placeholder > table. A CircularityError is thrown. > Fix: The test case should not call loading class with same class loader > in same thread from same jar in 'transform' method. I modify it loading > with system class loader and we expect see ClassNotFoundException. > Detail see bug comments. It is not clear to me that the test is incorrect. It is also unclear why such an old test is now failing - we must have changed something. And it's unclear whether what the test does with your change is actually testing what the test wanted to test. It seems to me that the actual problem in the test is the reference to the "main" thread ie: if (!tName.equals("main")) The test knows not to do the loading in the main thread, but has overlooked the fact that the main thread, upon the end of main() becomes the DestroyJavaVM thread - and it is that thread which encounters the ClassCircularityError: Starting test with 1000 iterations Thread 'DestroyJavaVM' has called transform() So perhaps the right fix is to expand the above to: if (!tName.equals("main") && !tName.equals("DestroyJavaVM")) ? I admit I'm having trouble seeing the full picture in this test. Looking at your change, don't leave commented out lines in the code: 115 // ClassLoader loader = ParallelTransformerLoaderAgent.getClassLoader(); 118 //Class.forName("TestClass" + index, true, loader); Thanks, David > Thanks > Yumin * From daniel.fuchs at oracle.com Tue Oct 14 09:05:25 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Oct 2014 11:05:25 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543C5031.2020000@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> Message-ID: <543CE755.6060900@oracle.com> On 14/10/14 00:20, Jonathan Gibbons wrote: > Bengt, > > There may be problems with the latest version of webrev. > > Eric McCorkle is reporting syntax errors from his version of ksh. > > patch cdiffs udiffs sdiffs frames old new > src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java > ../../tl/make/scripts/webrev.ksh[2241]: > build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic > syntax error Hi Jon, These line numbers do not seem to correspond to the latest version of webrev.ksh. line 2241 is a comment line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial (an not in build_old_new) line 1666 is ' fi' in look_for_prog (an not build_old_new_mercurial) Could you maybe check that we're speaking of the same version of webrev.ksh? best regards, -- daniel > > -- Jon > > On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >> >> On 2014-10-02 23:39, John Coomes wrote: >>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>> On 2014-10-02 01:08, John Coomes wrote: >>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>> Hi Daniel, >>>>>> >>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>> fore CODE_TOOLS. >>>>>> Thanks for looking at this Daniel! >>>>>> >>>>>>> Hopefully someone who is will step in :-) >>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>> for the >>>>>> patch too. >>>>> Looks good to me; I'll sponsor it. Send me (privately) the result of >>>>> "hg export --git" and I'll push that. >>>> Thanks for looking at this, John! And thanks for sponsoring the change. >>>> I'll send you the export in a separate email. >>> Got it; it's been pushed. >> >> Thanks for pushing this, John! >> >> Bengt >> >>> >>> -John >>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>> Hi Daniel, >>>>>>>> >>>>>>>> Thanks for looking at this! >>>>>>>> >>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>> Hi Bengt, >>>>>>>>> >>>>>>>>> This is a really cool feature! >>>>>>>> Thanks! >>>>>>>> >>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>> local webrev repo - and played with the new >>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>> pending uncommitted changes. >>>>>>>>> >>>>>>>>> This seems to work well. >>>>>>>>> >>>>>>>>> I have used: >>>>>>>>> >>>>>>>>> webrev -fN from top level repo >>>>>>>>> webrev -N from jdk repo >>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>> >>>>>>>> Great that you tired it out. >>>>>>>> >>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>> intended or not. >>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>> you could use typeset at least in those functions that >>>>>>>>> already use it for their parameters? For instance >>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>> Or did you intentionally not used it? >>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>> lines you >>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>> suggestion >>>>>>>> is good. >>>>>>>> >>>>>>>>> Also you should increment the version of webrev. >>>>>>>>> IIRC that would be 25.6: >>>>>>>>> >>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>> Thanks, didn't think of that. >>>>>>>> >>>>>>>> New webrev: >>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>> >>>>>>>> Diff compared to the first version: >>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> >>>>>>>>> best regards, >>>>>>>>> >>>>>>>>> -- daniel >>>>>>>>> >>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> (This is a patch for webrev, but I am cross posting to the JDK >>>>>>>>>> 9 dev >>>>>>>>>> list since I'm not sure how many are on the webrev-dev list and >>>>>>>>>> most JDK >>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>> >>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>> the webrev >>>>>>>>>> tool? >>>>>>>>>> >>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate between diffs >>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Background: >>>>>>>>>> When browsing review requests that span many files it is quite >>>>>>>>>> time >>>>>>>>>> consuming to have to go back to the index page to view to the >>>>>>>>>> next or >>>>>>>>>> previous file. This patch adds links to the next and previous >>>>>>>>>> files in >>>>>>>>>> the diff views (including frames). >>>>>>>>>> >>>>>>>>>> The above webrev is generated with this new version, but since >>>>>>>>>> it only >>>>>>>>>> contains a single file it is not that interesting. Here is an >>>>>>>>>> example of >>>>>>>>>> what the new webrev looks like for a larger change (the G1 class >>>>>>>>>> unloading change): >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bengt >>>>>>>>>> >> > From marcus.lagergren at oracle.com Tue Oct 14 13:23:23 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 14 Oct 2014 15:23:23 +0200 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <239FC874-113F-43A3-BDDF-45D3D8BEC226@oracle.com> Vote: yes /M On 09 Oct 2014, at 03:54, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on NetBeans and since joining the javac team. He has contributed over 90 changesets and participated in many reviews as well. Some of his more significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type parameters > Summary: When reading type variable's annotations out of the owner's type annotations, use the type variable's index in owner to exclude annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional cases related to type annotations, adding specialized error message for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when overriding deprecated method > Summary: When the overrides deprecated method warning is being reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative varargs test cases > Summary: Introducing a new error message for vararg parameter not being the last parameter, improving error message for unexpected character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements > Summary: Match the required and actual annotations using Element equivalence rather than TypeMirror equivalence, to avoid trouble with erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on the default locale, converting almost all usages of String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) > Summary: Should not generate non-public $assertionsDisabled field into interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client data, or null if none. > Reviewed-by: jjg, mcimadamore > From marcus.lagergren at oracle.com Tue Oct 14 13:23:38 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 14 Oct 2014 15:23:38 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <764AD469-67BB-4206-B1AB-E991BEA6ED32@oracle.com> Vote: yes /M On 10 Oct 2014, at 14:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Joel Borggr?n-Franck > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70fab1ef5e04 (misattributed see: [4]) > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/42cf719516d0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f1601dc3d229 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e785dfef65ce > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b2909def0a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/362a6ea9bc84 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b298c230549 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/30acbdbdb04e > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/127da56ff224 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6de4be4b64e7 > > [2] http://openjdk.java.net/census#jdk9 > > [3] http://openjdk.java.net/projects#committer-vote > > [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028904.html From daniel.fuchs at oracle.com Tue Oct 14 13:25:14 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Oct 2014 15:25:14 +0200 Subject: CFV: New JDK 9 Committer: Claes Redestad In-Reply-To: References: Message-ID: <543D243A.8000507@oracle.com> Vote: yes -- daniel On 10/10/14 14:10, Joel Borggr?n-Franck wrote: > I hereby nominate Claes Redestad to JDK 9 Committer. > > Claes is a member of the Java SE Performance team. > He has contributed 16 changesets to JDK 9, out of which at least > 10 can be considered significant[1]. > > Votes are due by 1600 CET, October 24, 2014. From alejandro.murillo at oracle.com Tue Oct 14 13:44:43 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 14 Oct 2014 07:44:43 -0600 Subject: jdk9-dev: HotSpot Message-ID: <543D28CB.3050809@oracle.com> jdk9-hs-2014-10-10 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/c173ba994245 http://hg.openjdk.java.net/jdk9/dev/corba/rev/9bc2dbd3dfb8 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/fe314365bfc5 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/507d4f7efba6 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/afe0c89e2edb http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f504cac61abf http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6f666e88a0f4 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ca67ae7c46cb Component : VM Status : Go for integration Date : 10/14/2014 at 13:00 MSK Tested By : VM SQE &leonid.mesnik at oracle.com Bundles : 2014-10-10-093031.amurillo.jdk9-hs-2014-10-10-snapshot Testing:http://surl.us.oracle.com/pit_jdk-10-10 133 new failures, 2982 known failures, 395240 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8059595: Verifier::verify is wasting time before is_eligible_for_verification check 8059621: JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw 8059735: make_not_entrant_or_zombie sees zombies -- Alejandro From bengt.rutisson at oracle.com Tue Oct 14 18:47:31 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 14 Oct 2014 20:47:31 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543CE755.6060900@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> Message-ID: <543D6FC3.7020604@oracle.com> On 10/14/14 11:05 AM, Daniel Fuchs wrote: > On 14/10/14 00:20, Jonathan Gibbons wrote: >> Bengt, >> >> There may be problems with the latest version of webrev. >> >> Eric McCorkle is reporting syntax errors from his version of ksh. >> >> patch cdiffs udiffs sdiffs frames old new >> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >> ../../tl/make/scripts/webrev.ksh[2241]: >> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >> syntax error > > Hi Jon, > > These line numbers do not seem to correspond to the latest version > of webrev.ksh. > > line 2241 is a comment > line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial > (an not in build_old_new) > line 1666 is ' fi' in look_for_prog > (an not build_old_new_mercurial) > > Could you maybe check that we're speaking of the same version of > webrev.ksh? Daniel, Thanks for pointing this out. It also does not seem to be the lines that I changed. Jon, I'm running the webrev script with ksh and it seems to work fine. Do you know which version ksh and which platform Eric is using? Thanks, Bengt > > best regards, > > -- daniel > > > > >> >> -- Jon >> >> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>> >>> On 2014-10-02 23:39, John Coomes wrote: >>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>> Hi Daniel, >>>>>>> >>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>> fore CODE_TOOLS. >>>>>>> Thanks for looking at this Daniel! >>>>>>> >>>>>>>> Hopefully someone who is will step in :-) >>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>>> for the >>>>>>> patch too. >>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>> result of >>>>>> "hg export --git" and I'll push that. >>>>> Thanks for looking at this, John! And thanks for sponsoring the >>>>> change. >>>>> I'll send you the export in a separate email. >>>> Got it; it's been pushed. >>> >>> Thanks for pushing this, John! >>> >>> Bengt >>> >>>> >>>> -John >>>> >>>>>>>> best regards, >>>>>>>> >>>>>>>> -- daniel >>>>>>>> >>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>> Hi Daniel, >>>>>>>>> >>>>>>>>> Thanks for looking at this! >>>>>>>>> >>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>> Hi Bengt, >>>>>>>>>> >>>>>>>>>> This is a really cool feature! >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>> pending uncommitted changes. >>>>>>>>>> >>>>>>>>>> This seems to work well. >>>>>>>>>> >>>>>>>>>> I have used: >>>>>>>>>> >>>>>>>>>> webrev -fN from top level repo >>>>>>>>>> webrev -N from jdk repo >>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>>> >>>>>>>>> Great that you tired it out. >>>>>>>>> >>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>> intended or not. >>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>> Or did you intentionally not used it? >>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>> lines you >>>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>>> suggestion >>>>>>>>> is good. >>>>>>>>> >>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>> >>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>> Thanks, didn't think of that. >>>>>>>>> >>>>>>>>> New webrev: >>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>> >>>>>>>>> Diff compared to the first version: >>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>>> best regards, >>>>>>>>>> >>>>>>>>>> -- daniel >>>>>>>>>> >>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>> Hi everyone, >>>>>>>>>>> >>>>>>>>>>> (This is a patch for webrev, but I am cross posting to the JDK >>>>>>>>>>> 9 dev >>>>>>>>>>> list since I'm not sure how many are on the webrev-dev list and >>>>>>>>>>> most JDK >>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>> >>>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>>> the webrev >>>>>>>>>>> tool? >>>>>>>>>>> >>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate between >>>>>>>>>>> diffs >>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Background: >>>>>>>>>>> When browsing review requests that span many files it is quite >>>>>>>>>>> time >>>>>>>>>>> consuming to have to go back to the index page to view to the >>>>>>>>>>> next or >>>>>>>>>>> previous file. This patch adds links to the next and previous >>>>>>>>>>> files in >>>>>>>>>>> the diff views (including frames). >>>>>>>>>>> >>>>>>>>>>> The above webrev is generated with this new version, but since >>>>>>>>>>> it only >>>>>>>>>>> contains a single file it is not that interesting. Here is an >>>>>>>>>>> example of >>>>>>>>>>> what the new webrev looks like for a larger change (the G1 >>>>>>>>>>> class >>>>>>>>>>> unloading change): >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Bengt >>>>>>>>>>> >>> >> > From jonathan.gibbons at oracle.com Tue Oct 14 19:12:52 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 14 Oct 2014 12:12:52 -0700 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543D6FC3.7020604@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> Message-ID: <543D75B4.8060708@oracle.com> Eric, Can you provide info on the OS and version of ksh you are using that caused the problems you experienced with webrev? -- Jon On 10/14/2014 11:47 AM, Bengt Rutisson wrote: > On 10/14/14 11:05 AM, Daniel Fuchs wrote: >> On 14/10/14 00:20, Jonathan Gibbons wrote: >>> Bengt, >>> >>> There may be problems with the latest version of webrev. >>> >>> Eric McCorkle is reporting syntax errors from his version of ksh. >>> >>> patch cdiffs udiffs sdiffs frames old new >>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >>> ../../tl/make/scripts/webrev.ksh[2241]: >>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >>> syntax error >> >> Hi Jon, >> >> These line numbers do not seem to correspond to the latest version >> of webrev.ksh. >> >> line 2241 is a comment >> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial >> (an not in build_old_new) >> line 1666 is ' fi' in look_for_prog >> (an not build_old_new_mercurial) >> >> Could you maybe check that we're speaking of the same version of >> webrev.ksh? > > Daniel, Thanks for pointing this out. > > It also does not seem to be the lines that I changed. > > Jon, I'm running the webrev script with ksh and it seems to work > fine. Do you know which version ksh and which platform Eric is using? > > Thanks, > Bengt > > >> >> best regards, >> >> -- daniel >> >> >> >> >>> >>> -- Jon >>> >>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>>> >>>> On 2014-10-02 23:39, John Coomes wrote: >>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>> Hi Daniel, >>>>>>>> >>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>>> Hi Bengt, >>>>>>>>> >>>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>>> fore CODE_TOOLS. >>>>>>>> Thanks for looking at this Daniel! >>>>>>>> >>>>>>>>> Hopefully someone who is will step in :-) >>>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>>>> for the >>>>>>>> patch too. >>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>>> result of >>>>>>> "hg export --git" and I'll push that. >>>>>> Thanks for looking at this, John! And thanks for sponsoring the >>>>>> change. >>>>>> I'll send you the export in a separate email. >>>>> Got it; it's been pushed. >>>> >>>> Thanks for pushing this, John! >>>> >>>> Bengt >>>> >>>>> >>>>> -John >>>>> >>>>>>>>> best regards, >>>>>>>>> >>>>>>>>> -- daniel >>>>>>>>> >>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>>> Hi Daniel, >>>>>>>>>> >>>>>>>>>> Thanks for looking at this! >>>>>>>>>> >>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>>> Hi Bengt, >>>>>>>>>>> >>>>>>>>>>> This is a really cool feature! >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>>> pending uncommitted changes. >>>>>>>>>>> >>>>>>>>>>> This seems to work well. >>>>>>>>>>> >>>>>>>>>>> I have used: >>>>>>>>>>> >>>>>>>>>>> webrev -fN from top level repo >>>>>>>>>>> webrev -N from jdk repo >>>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>>>> >>>>>>>>>> Great that you tired it out. >>>>>>>>>> >>>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>>> intended or not. >>>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>>> Or did you intentionally not used it? >>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>>> lines you >>>>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>>>> suggestion >>>>>>>>>> is good. >>>>>>>>>> >>>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>>> >>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>>> Thanks, didn't think of that. >>>>>>>>>> >>>>>>>>>> New webrev: >>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Diff compared to the first version: >>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>>> best regards, >>>>>>>>>>> >>>>>>>>>>> -- daniel >>>>>>>>>>> >>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>>> Hi everyone, >>>>>>>>>>>> >>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to the JDK >>>>>>>>>>>> 9 dev >>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev list >>>>>>>>>>>> and >>>>>>>>>>>> most JDK >>>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>>> >>>>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>>>> the webrev >>>>>>>>>>>> tool? >>>>>>>>>>>> >>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate between >>>>>>>>>>>> diffs >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Background: >>>>>>>>>>>> When browsing review requests that span many files it is quite >>>>>>>>>>>> time >>>>>>>>>>>> consuming to have to go back to the index page to view to the >>>>>>>>>>>> next or >>>>>>>>>>>> previous file. This patch adds links to the next and previous >>>>>>>>>>>> files in >>>>>>>>>>>> the diff views (including frames). >>>>>>>>>>>> >>>>>>>>>>>> The above webrev is generated with this new version, but since >>>>>>>>>>>> it only >>>>>>>>>>>> contains a single file it is not that interesting. Here is an >>>>>>>>>>>> example of >>>>>>>>>>>> what the new webrev looks like for a larger change (the G1 >>>>>>>>>>>> class >>>>>>>>>>>> unloading change): >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Bengt >>>>>>>>>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Tue Oct 14 19:55:09 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Oct 2014 21:55:09 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543D75B4.8060708@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> <543D75B4.8060708@oracle.com> Message-ID: <543D7F9D.2000908@oracle.com> On 10/14/14 9:12 PM, Jonathan Gibbons wrote: > Eric, > > Can you provide info on the OS and version of ksh you are using that > caused the problems you experienced with webrev? And also the version of webrev please :-) -- daniel > > -- Jon > > On 10/14/2014 11:47 AM, Bengt Rutisson wrote: >> On 10/14/14 11:05 AM, Daniel Fuchs wrote: >>> On 14/10/14 00:20, Jonathan Gibbons wrote: >>>> Bengt, >>>> >>>> There may be problems with the latest version of webrev. >>>> >>>> Eric McCorkle is reporting syntax errors from his version of ksh. >>>> >>>> patch cdiffs udiffs sdiffs frames old new >>>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >>>> ../../tl/make/scripts/webrev.ksh[2241]: >>>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >>>> syntax error >>> >>> Hi Jon, >>> >>> These line numbers do not seem to correspond to the latest version >>> of webrev.ksh. >>> >>> line 2241 is a comment >>> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial >>> (an not in build_old_new) >>> line 1666 is ' fi' in look_for_prog >>> (an not build_old_new_mercurial) >>> >>> Could you maybe check that we're speaking of the same version of >>> webrev.ksh? >> >> Daniel, Thanks for pointing this out. >> >> It also does not seem to be the lines that I changed. >> >> Jon, I'm running the webrev script with ksh and it seems to work >> fine. Do you know which version ksh and which platform Eric is using? >> >> Thanks, >> Bengt >> >> >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> >>> >>>> >>>> -- Jon >>>> >>>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>>>> >>>>> On 2014-10-02 23:39, John Coomes wrote: >>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>> Hi Daniel, >>>>>>>>> >>>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>>>> Hi Bengt, >>>>>>>>>> >>>>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>>>> fore CODE_TOOLS. >>>>>>>>> Thanks for looking at this Daniel! >>>>>>>>> >>>>>>>>>> Hopefully someone who is will step in :-) >>>>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>>>>> for the >>>>>>>>> patch too. >>>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>>>> result of >>>>>>>> "hg export --git" and I'll push that. >>>>>>> Thanks for looking at this, John! And thanks for sponsoring the >>>>>>> change. >>>>>>> I'll send you the export in a separate email. >>>>>> Got it; it's been pushed. >>>>> >>>>> Thanks for pushing this, John! >>>>> >>>>> Bengt >>>>> >>>>>> >>>>>> -John >>>>>> >>>>>>>>>> best regards, >>>>>>>>>> >>>>>>>>>> -- daniel >>>>>>>>>> >>>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>>>> Hi Daniel, >>>>>>>>>>> >>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>> >>>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>> >>>>>>>>>>>> This is a really cool feature! >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>>>> pending uncommitted changes. >>>>>>>>>>>> >>>>>>>>>>>> This seems to work well. >>>>>>>>>>>> >>>>>>>>>>>> I have used: >>>>>>>>>>>> >>>>>>>>>>>> webrev -fN from top level repo >>>>>>>>>>>> webrev -N from jdk repo >>>>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>>>>> >>>>>>>>>>> Great that you tired it out. >>>>>>>>>>> >>>>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>>>> intended or not. >>>>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>>>> Or did you intentionally not used it? >>>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>>>> lines you >>>>>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>>>>> suggestion >>>>>>>>>>> is good. >>>>>>>>>>> >>>>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>>>> >>>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>>>> Thanks, didn't think of that. >>>>>>>>>>> >>>>>>>>>>> New webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Diff compared to the first version: >>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Bengt >>>>>>>>>>> >>>>>>>>>>>> best regards, >>>>>>>>>>>> >>>>>>>>>>>> -- daniel >>>>>>>>>>>> >>>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>> >>>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to the >>>>>>>>>>>>> JDK >>>>>>>>>>>>> 9 dev >>>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev >>>>>>>>>>>>> list and >>>>>>>>>>>>> most JDK >>>>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>>>> >>>>>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>>>>> the webrev >>>>>>>>>>>>> tool? >>>>>>>>>>>>> >>>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate between >>>>>>>>>>>>> diffs >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Background: >>>>>>>>>>>>> When browsing review requests that span many files it is >>>>>>>>>>>>> quite >>>>>>>>>>>>> time >>>>>>>>>>>>> consuming to have to go back to the index page to view to the >>>>>>>>>>>>> next or >>>>>>>>>>>>> previous file. This patch adds links to the next and previous >>>>>>>>>>>>> files in >>>>>>>>>>>>> the diff views (including frames). >>>>>>>>>>>>> >>>>>>>>>>>>> The above webrev is generated with this new version, but >>>>>>>>>>>>> since >>>>>>>>>>>>> it only >>>>>>>>>>>>> contains a single file it is not that interesting. Here is an >>>>>>>>>>>>> example of >>>>>>>>>>>>> what the new webrev looks like for a larger change (the G1 >>>>>>>>>>>>> class >>>>>>>>>>>>> unloading change): >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Bengt >>>>>>>>>>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Tue Oct 14 20:22:43 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 14 Oct 2014 13:22:43 -0700 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543D7F9D.2000908@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> <543D75B4.8060708@oracle.com> <543D7F9D.2000908@oracle.com> Message-ID: <543D8613.9070507@oracle.com> Eric says it was a fresh check out from the webrev repo, and for the rest, he says, I'm not terribly familiar with ksh, but $ ksh -v gives the following: version sh (AT&T Research) 93v- 2014-06-06 The OS is Linux. Oddly enough, it doesn't seem to negatively affect the output that I can tell. -- Jon On 10/14/2014 12:55 PM, Daniel Fuchs wrote: > On 10/14/14 9:12 PM, Jonathan Gibbons wrote: >> Eric, >> >> Can you provide info on the OS and version of ksh you are using that >> caused the problems you experienced with webrev? > And also the version of webrev please :-) > > -- daniel > >> >> -- Jon >> >> On 10/14/2014 11:47 AM, Bengt Rutisson wrote: >>> On 10/14/14 11:05 AM, Daniel Fuchs wrote: >>>> On 14/10/14 00:20, Jonathan Gibbons wrote: >>>>> Bengt, >>>>> >>>>> There may be problems with the latest version of webrev. >>>>> >>>>> Eric McCorkle is reporting syntax errors from his version of ksh. >>>>> >>>>> patch cdiffs udiffs sdiffs frames old new >>>>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >>>>> ../../tl/make/scripts/webrev.ksh[2241]: >>>>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >>>>> syntax error >>>> >>>> Hi Jon, >>>> >>>> These line numbers do not seem to correspond to the latest version >>>> of webrev.ksh. >>>> >>>> line 2241 is a comment >>>> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial >>>> (an not in build_old_new) >>>> line 1666 is ' fi' in look_for_prog >>>> (an not build_old_new_mercurial) >>>> >>>> Could you maybe check that we're speaking of the same version of >>>> webrev.ksh? >>> >>> Daniel, Thanks for pointing this out. >>> >>> It also does not seem to be the lines that I changed. >>> >>> Jon, I'm running the webrev script with ksh and it seems to work >>> fine. Do you know which version ksh and which platform Eric is using? >>> >>> Thanks, >>> Bengt >>> >>> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> >>>> >>>>> >>>>> -- Jon >>>>> >>>>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>>>>> >>>>>> On 2014-10-02 23:39, John Coomes wrote: >>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>> Hi Daniel, >>>>>>>>>> >>>>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>>>>> Hi Bengt, >>>>>>>>>>> >>>>>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>>>>> fore CODE_TOOLS. >>>>>>>>>> Thanks for looking at this Daniel! >>>>>>>>>> >>>>>>>>>>> Hopefully someone who is will step in :-) >>>>>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>>>>>> for the >>>>>>>>>> patch too. >>>>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>>>>> result of >>>>>>>>> "hg export --git" and I'll push that. >>>>>>>> Thanks for looking at this, John! And thanks for sponsoring the >>>>>>>> change. >>>>>>>> I'll send you the export in a separate email. >>>>>>> Got it; it's been pushed. >>>>>> >>>>>> Thanks for pushing this, John! >>>>>> >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> -John >>>>>>> >>>>>>>>>>> best regards, >>>>>>>>>>> >>>>>>>>>>> -- daniel >>>>>>>>>>> >>>>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>>> >>>>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>> >>>>>>>>>>>>> This is a really cool feature! >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>>>>> pending uncommitted changes. >>>>>>>>>>>>> >>>>>>>>>>>>> This seems to work well. >>>>>>>>>>>>> >>>>>>>>>>>>> I have used: >>>>>>>>>>>>> >>>>>>>>>>>>> webrev -fN from top level repo >>>>>>>>>>>>> webrev -N from jdk repo >>>>>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>>>>>> >>>>>>>>>>>> Great that you tired it out. >>>>>>>>>>>> >>>>>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>>>>> intended or not. >>>>>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>>>>> Or did you intentionally not used it? >>>>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>>>>> lines you >>>>>>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>>>>>> suggestion >>>>>>>>>>>> is good. >>>>>>>>>>>> >>>>>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>>>>> >>>>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>>>>> Thanks, didn't think of that. >>>>>>>>>>>> >>>>>>>>>>>> New webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Diff compared to the first version: >>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Bengt >>>>>>>>>>>> >>>>>>>>>>>>> best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> -- daniel >>>>>>>>>>>>> >>>>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>> >>>>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to >>>>>>>>>>>>>> the JDK >>>>>>>>>>>>>> 9 dev >>>>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev >>>>>>>>>>>>>> list and >>>>>>>>>>>>>> most JDK >>>>>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>>>>>> the webrev >>>>>>>>>>>>>> tool? >>>>>>>>>>>>>> >>>>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate >>>>>>>>>>>>>> between diffs >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Background: >>>>>>>>>>>>>> When browsing review requests that span many files it is >>>>>>>>>>>>>> quite >>>>>>>>>>>>>> time >>>>>>>>>>>>>> consuming to have to go back to the index page to view to >>>>>>>>>>>>>> the >>>>>>>>>>>>>> next or >>>>>>>>>>>>>> previous file. This patch adds links to the next and >>>>>>>>>>>>>> previous >>>>>>>>>>>>>> files in >>>>>>>>>>>>>> the diff views (including frames). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The above webrev is generated with this new version, but >>>>>>>>>>>>>> since >>>>>>>>>>>>>> it only >>>>>>>>>>>>>> contains a single file it is not that interesting. Here >>>>>>>>>>>>>> is an >>>>>>>>>>>>>> example of >>>>>>>>>>>>>> what the new webrev looks like for a larger change (the >>>>>>>>>>>>>> G1 class >>>>>>>>>>>>>> unloading change): >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>> >>>>>> >>>>> >>>> >>> >> > From eric.mccorkle at oracle.com Tue Oct 14 20:57:16 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 14 Oct 2014 16:57:16 -0400 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543D8613.9070507@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> <543D75B4.8060708@oracle.com> <543D7F9D.2000908@oracle.com> <543D8613.9070507@oracle.com> Message-ID: <543D8E2C.50707@oracle.com> (Sorry, I forgot to hit "reply all") Actually, the results may be from a version I had stashed in my home dir (which I'd forgotten about). Here is from a fresh checkout: $ ksh -p ../../webrev/webrev.ksh SCM detected: mercurial No outgoing, perhaps you haven't commited. Workspace: /usr/home/emccorkl/src/enum_convert/langtools Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev Output Files: ../../webrev/webrev.ksh: line 2273: i: arithmetic syntax error Version: WEBREV_UPDATED=25.6-hg+openjdk.java.net Here is from the one in my home dir: webrev SCM detected: mercurial No outgoing, perhaps you haven't commited. Workspace: /usr/home/emccorkl/src/enum_convert/langtools Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev Output Files: make/build.properties /usr/home/emccorkl//bin/webrev[2241]: build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic syntax error Version: WEBREV_UPDATED=25.1-hg+openjdk.java.net So it seems the output from earlier is from the version I had stashed. Sorry about that. On 10/14/14 16:22, Jonathan Gibbons wrote: > Eric says it was a fresh check out from the webrev repo, and for the > rest, he says, > > I'm not terribly familiar with ksh, but $ ksh -v gives the following: > > version sh (AT&T Research) 93v- 2014-06-06 > > > The OS is Linux. > > > Oddly enough, it doesn't seem to negatively affect the output that I can > tell. > > > -- Jon > > > > On 10/14/2014 12:55 PM, Daniel Fuchs wrote: >> On 10/14/14 9:12 PM, Jonathan Gibbons wrote: >>> Eric, >>> >>> Can you provide info on the OS and version of ksh you are using that >>> caused the problems you experienced with webrev? >> And also the version of webrev please :-) >> >> -- daniel >> >>> >>> -- Jon >>> >>> On 10/14/2014 11:47 AM, Bengt Rutisson wrote: >>>> On 10/14/14 11:05 AM, Daniel Fuchs wrote: >>>>> On 14/10/14 00:20, Jonathan Gibbons wrote: >>>>>> Bengt, >>>>>> >>>>>> There may be problems with the latest version of webrev. >>>>>> >>>>>> Eric McCorkle is reporting syntax errors from his version of ksh. >>>>>> >>>>>> patch cdiffs udiffs sdiffs frames old new >>>>>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >>>>>> ../../tl/make/scripts/webrev.ksh[2241]: >>>>>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >>>>>> syntax error >>>>> >>>>> Hi Jon, >>>>> >>>>> These line numbers do not seem to correspond to the latest version >>>>> of webrev.ksh. >>>>> >>>>> line 2241 is a comment >>>>> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial >>>>> (an not in build_old_new) >>>>> line 1666 is ' fi' in look_for_prog >>>>> (an not build_old_new_mercurial) >>>>> >>>>> Could you maybe check that we're speaking of the same version of >>>>> webrev.ksh? >>>> >>>> Daniel, Thanks for pointing this out. >>>> >>>> It also does not seem to be the lines that I changed. >>>> >>>> Jon, I'm running the webrev script with ksh and it seems to work >>>> fine. Do you know which version ksh and which platform Eric is using? >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> On 2014-10-02 23:39, John Coomes wrote: >>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>>> Hi Daniel, >>>>>>>>>>> >>>>>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>> >>>>>>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>>>>>> fore CODE_TOOLS. >>>>>>>>>>> Thanks for looking at this Daniel! >>>>>>>>>>> >>>>>>>>>>>> Hopefully someone who is will step in :-) >>>>>>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>>>>>>> for the >>>>>>>>>>> patch too. >>>>>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>>>>>> result of >>>>>>>>>> "hg export --git" and I'll push that. >>>>>>>>> Thanks for looking at this, John! And thanks for sponsoring the >>>>>>>>> change. >>>>>>>>> I'll send you the export in a separate email. >>>>>>>> Got it; it's been pushed. >>>>>>> >>>>>>> Thanks for pushing this, John! >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>>> >>>>>>>> -John >>>>>>>> >>>>>>>>>>>> best regards, >>>>>>>>>>>> >>>>>>>>>>>> -- daniel >>>>>>>>>>>> >>>>>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>>>> >>>>>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a really cool feature! >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>>>>>> pending uncommitted changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This seems to work well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have used: >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev -fN from top level repo >>>>>>>>>>>>>> webrev -N from jdk repo >>>>>>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>>>>>>> >>>>>>>>>>>>> Great that you tired it out. >>>>>>>>>>>>> >>>>>>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>>>>>> intended or not. >>>>>>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>>>>>> Or did you intentionally not used it? >>>>>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>>>>>> lines you >>>>>>>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>>>>>>> suggestion >>>>>>>>>>>>> is good. >>>>>>>>>>>>> >>>>>>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>>>>>> Thanks, didn't think of that. >>>>>>>>>>>>> >>>>>>>>>>>>> New webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Diff compared to the first version: >>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Bengt >>>>>>>>>>>>> >>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- daniel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to >>>>>>>>>>>>>>> the JDK >>>>>>>>>>>>>>> 9 dev >>>>>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev >>>>>>>>>>>>>>> list and >>>>>>>>>>>>>>> most JDK >>>>>>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>>>>>>> the webrev >>>>>>>>>>>>>>> tool? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate >>>>>>>>>>>>>>> between diffs >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Background: >>>>>>>>>>>>>>> When browsing review requests that span many files it is >>>>>>>>>>>>>>> quite >>>>>>>>>>>>>>> time >>>>>>>>>>>>>>> consuming to have to go back to the index page to view to >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> next or >>>>>>>>>>>>>>> previous file. This patch adds links to the next and >>>>>>>>>>>>>>> previous >>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>> the diff views (including frames). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The above webrev is generated with this new version, but >>>>>>>>>>>>>>> since >>>>>>>>>>>>>>> it only >>>>>>>>>>>>>>> contains a single file it is not that interesting. Here >>>>>>>>>>>>>>> is an >>>>>>>>>>>>>>> example of >>>>>>>>>>>>>>> what the new webrev looks like for a larger change (the >>>>>>>>>>>>>>> G1 class >>>>>>>>>>>>>>> unloading change): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Tue Oct 14 20:58:36 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Oct 2014 22:58:36 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543D8613.9070507@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> <543D75B4.8060708@oracle.com> <543D7F9D.2000908@oracle.com> <543D8613.9070507@oracle.com> Message-ID: <543D8E7C.5020702@oracle.com> On 10/14/14 10:22 PM, Jonathan Gibbons wrote: > Eric says it was a fresh check out from the webrev repo, and for the > rest, he says, Is Eric using the webrev from codetools? because from the line numbers it doesn't look like he is. In addition this path: ../../tl/make/scripts/webrev.ksh makes me think it might not be a webrev from the codetools repo - but some old version of webrev from the time when it was checked in the jdk tl repo... I'd suggest trying: `which webrev.ksh` and verifying that it's indeed ../../tl/make/scripts/webrev.ksh and then looking at the version string in ../../tl/make/scripts/webrev.ksh. best regards, -- daniel > > I'm not terribly familiar with ksh, but $ ksh -v gives the following: > > version sh (AT&T Research) 93v- 2014-06-06 > > > The OS is Linux. > > > Oddly enough, it doesn't seem to negatively affect the output that I can > tell. > > > -- Jon > > > > On 10/14/2014 12:55 PM, Daniel Fuchs wrote: >> On 10/14/14 9:12 PM, Jonathan Gibbons wrote: >>> Eric, >>> >>> Can you provide info on the OS and version of ksh you are using that >>> caused the problems you experienced with webrev? >> And also the version of webrev please :-) >> >> -- daniel >> >>> >>> -- Jon >>> >>> On 10/14/2014 11:47 AM, Bengt Rutisson wrote: >>>> On 10/14/14 11:05 AM, Daniel Fuchs wrote: >>>>> On 14/10/14 00:20, Jonathan Gibbons wrote: >>>>>> Bengt, >>>>>> >>>>>> There may be problems with the latest version of webrev. >>>>>> >>>>>> Eric McCorkle is reporting syntax errors from his version of ksh. >>>>>> >>>>>> patch cdiffs udiffs sdiffs frames old new >>>>>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >>>>>> ../../tl/make/scripts/webrev.ksh[2241]: >>>>>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >>>>>> syntax error >>>>> >>>>> Hi Jon, >>>>> >>>>> These line numbers do not seem to correspond to the latest version >>>>> of webrev.ksh. >>>>> >>>>> line 2241 is a comment >>>>> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial >>>>> (an not in build_old_new) >>>>> line 1666 is ' fi' in look_for_prog >>>>> (an not build_old_new_mercurial) >>>>> >>>>> Could you maybe check that we're speaking of the same version of >>>>> webrev.ksh? >>>> >>>> Daniel, Thanks for pointing this out. >>>> >>>> It also does not seem to be the lines that I changed. >>>> >>>> Jon, I'm running the webrev script with ksh and it seems to work >>>> fine. Do you know which version ksh and which platform Eric is using? >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> On 2014-10-02 23:39, John Coomes wrote: >>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>>> Hi Daniel, >>>>>>>>>>> >>>>>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>> >>>>>>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>>>>>> fore CODE_TOOLS. >>>>>>>>>>> Thanks for looking at this Daniel! >>>>>>>>>>> >>>>>>>>>>>> Hopefully someone who is will step in :-) >>>>>>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>>>>>>> for the >>>>>>>>>>> patch too. >>>>>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>>>>>> result of >>>>>>>>>> "hg export --git" and I'll push that. >>>>>>>>> Thanks for looking at this, John! And thanks for sponsoring >>>>>>>>> the change. >>>>>>>>> I'll send you the export in a separate email. >>>>>>>> Got it; it's been pushed. >>>>>>> >>>>>>> Thanks for pushing this, John! >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>>> >>>>>>>> -John >>>>>>>> >>>>>>>>>>>> best regards, >>>>>>>>>>>> >>>>>>>>>>>> -- daniel >>>>>>>>>>>> >>>>>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>>>> >>>>>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a really cool feature! >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>>>>>> pending uncommitted changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This seems to work well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have used: >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev -fN from top level repo >>>>>>>>>>>>>> webrev -N from jdk repo >>>>>>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>>>>>>> >>>>>>>>>>>>> Great that you tired it out. >>>>>>>>>>>>> >>>>>>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>>>>>> intended or not. >>>>>>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>>>>>> Or did you intentionally not used it? >>>>>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>>>>>> lines you >>>>>>>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>>>>>>> suggestion >>>>>>>>>>>>> is good. >>>>>>>>>>>>> >>>>>>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>>>>>> Thanks, didn't think of that. >>>>>>>>>>>>> >>>>>>>>>>>>> New webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Diff compared to the first version: >>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Bengt >>>>>>>>>>>>> >>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- daniel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to >>>>>>>>>>>>>>> the JDK >>>>>>>>>>>>>>> 9 dev >>>>>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev >>>>>>>>>>>>>>> list and >>>>>>>>>>>>>>> most JDK >>>>>>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>>>>>>> the webrev >>>>>>>>>>>>>>> tool? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate >>>>>>>>>>>>>>> between diffs >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Background: >>>>>>>>>>>>>>> When browsing review requests that span many files it is >>>>>>>>>>>>>>> quite >>>>>>>>>>>>>>> time >>>>>>>>>>>>>>> consuming to have to go back to the index page to view >>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>> next or >>>>>>>>>>>>>>> previous file. This patch adds links to the next and >>>>>>>>>>>>>>> previous >>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>> the diff views (including frames). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The above webrev is generated with this new version, but >>>>>>>>>>>>>>> since >>>>>>>>>>>>>>> it only >>>>>>>>>>>>>>> contains a single file it is not that interesting. Here >>>>>>>>>>>>>>> is an >>>>>>>>>>>>>>> example of >>>>>>>>>>>>>>> what the new webrev looks like for a larger change (the >>>>>>>>>>>>>>> G1 class >>>>>>>>>>>>>>> unloading change): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Tue Oct 14 21:29:06 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Oct 2014 23:29:06 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543D8E2C.50707@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> <543D75B4.8060708@oracle.com> <543D7F9D.2000908@oracle.com> <543D8613.9070507@oracle.com> <543D8E2C.50707@oracle.com> Message-ID: <543D95A2.60201@oracle.com> On 10/14/14 10:57 PM, Eric McCorkle wrote: > (Sorry, I forgot to hit "reply all") > > Actually, the results may be from a version I had stashed in my home dir > (which I'd forgotten about). > > Here is from a fresh checkout: > > $ ksh -p ../../webrev/webrev.ksh > SCM detected: mercurial > > No outgoing, perhaps you haven't commited. > Workspace: /usr/home/emccorkl/src/enum_convert/langtools > Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools > Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev > Output Files: > ../../webrev/webrev.ksh: line 2273: i: arithmetic syntax error Ahah - OK - thanks Eric - now the line numbers make sense :-) I've been bitten by this kind of things before - I believe [[ ]] might need to be replaced with something else. For evaluating arithmetic operations (+ - etc..) it seems better to use 'expr'. if [[i -lt ...]] should probably be replaced with something like if [ $i -lt ... ] It's possible that the same kind of medicine will need to be applied to i=$(($i + 1)) a few lines below - though it's not really possible to tell without testing. Does the following works with your version of ksh: ksh i=1 i=$(($i + 1)) echo $i I see there are several occurrences of [[ ]] - not sure whether all of them should be replaced... Usually string comparison don't require a double [[ ]]. Hope this helps, -- daniel > > > > Version: WEBREV_UPDATED=25.6-hg+openjdk.java.net > > > > > > Here is from the one in my home dir: > > > webrev > SCM detected: mercurial > > No outgoing, perhaps you haven't commited. > Workspace: /usr/home/emccorkl/src/enum_convert/langtools > Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools > Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev > Output Files: > make/build.properties > /usr/home/emccorkl//bin/webrev[2241]: > build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic > syntax error > > > > Version: WEBREV_UPDATED=25.1-hg+openjdk.java.net > > > So it seems the output from earlier is from the version I had stashed. > Sorry about that. > > On 10/14/14 16:22, Jonathan Gibbons wrote: >> Eric says it was a fresh check out from the webrev repo, and for the >> rest, he says, >> >> I'm not terribly familiar with ksh, but $ ksh -v gives the following: >> >> version sh (AT&T Research) 93v- 2014-06-06 >> >> >> The OS is Linux. >> >> >> Oddly enough, it doesn't seem to negatively affect the output that I can >> tell. >> >> >> -- Jon >> >> >> >> On 10/14/2014 12:55 PM, Daniel Fuchs wrote: >>> On 10/14/14 9:12 PM, Jonathan Gibbons wrote: >>>> Eric, >>>> >>>> Can you provide info on the OS and version of ksh you are using that >>>> caused the problems you experienced with webrev? >>> And also the version of webrev please :-) >>> >>> -- daniel >>> >>>> -- Jon >>>> >>>> On 10/14/2014 11:47 AM, Bengt Rutisson wrote: >>>>> On 10/14/14 11:05 AM, Daniel Fuchs wrote: >>>>>> On 14/10/14 00:20, Jonathan Gibbons wrote: >>>>>>> Bengt, >>>>>>> >>>>>>> There may be problems with the latest version of webrev. >>>>>>> >>>>>>> Eric McCorkle is reporting syntax errors from his version of ksh. >>>>>>> >>>>>>> patch cdiffs udiffs sdiffs frames old new >>>>>>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >>>>>>> ../../tl/make/scripts/webrev.ksh[2241]: >>>>>>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >>>>>>> syntax error >>>>>> Hi Jon, >>>>>> >>>>>> These line numbers do not seem to correspond to the latest version >>>>>> of webrev.ksh. >>>>>> >>>>>> line 2241 is a comment >>>>>> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial >>>>>> (an not in build_old_new) >>>>>> line 1666 is ' fi' in look_for_prog >>>>>> (an not build_old_new_mercurial) >>>>>> >>>>>> Could you maybe check that we're speaking of the same version of >>>>>> webrev.ksh? >>>>> Daniel, Thanks for pointing this out. >>>>> >>>>> It also does not seem to be the lines that I changed. >>>>> >>>>> Jon, I'm running the webrev script with ksh and it seems to work >>>>> fine. Do you know which version ksh and which platform Eric is using? >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>>>>>>> On 2014-10-02 23:39, John Coomes wrote: >>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>> >>>>>>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>> >>>>>>>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>>>>>>> fore CODE_TOOLS. >>>>>>>>>>>> Thanks for looking at this Daniel! >>>>>>>>>>>> >>>>>>>>>>>>> Hopefully someone who is will step in :-) >>>>>>>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>>>>>>>> for the >>>>>>>>>>>> patch too. >>>>>>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>>>>>>> result of >>>>>>>>>>> "hg export --git" and I'll push that. >>>>>>>>>> Thanks for looking at this, John! And thanks for sponsoring the >>>>>>>>>> change. >>>>>>>>>> I'll send you the export in a separate email. >>>>>>>>> Got it; it's been pushed. >>>>>>>> Thanks for pushing this, John! >>>>>>>> >>>>>>>> Bengt >>>>>>>> >>>>>>>>> -John >>>>>>>>> >>>>>>>>>>>>> best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> -- daniel >>>>>>>>>>>>> >>>>>>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is a really cool feature! >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>>>>>>> pending uncommitted changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This seems to work well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have used: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> webrev -fN from top level repo >>>>>>>>>>>>>>> webrev -N from jdk repo >>>>>>>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Great that you tired it out. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>>>>>>> intended or not. >>>>>>>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>>>>>>> Or did you intentionally not used it? >>>>>>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>>>>>>> lines you >>>>>>>>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>> is good. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>>>>>>> Thanks, didn't think of that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> New webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Diff compared to the first version: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>> >>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- daniel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to >>>>>>>>>>>>>>>> the JDK >>>>>>>>>>>>>>>> 9 dev >>>>>>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev >>>>>>>>>>>>>>>> list and >>>>>>>>>>>>>>>> most JDK >>>>>>>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>>>>>>>> the webrev >>>>>>>>>>>>>>>> tool? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate >>>>>>>>>>>>>>>> between diffs >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Background: >>>>>>>>>>>>>>>> When browsing review requests that span many files it is >>>>>>>>>>>>>>>> quite >>>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>> consuming to have to go back to the index page to view to >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> next or >>>>>>>>>>>>>>>> previous file. This patch adds links to the next and >>>>>>>>>>>>>>>> previous >>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>> the diff views (including frames). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The above webrev is generated with this new version, but >>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>> it only >>>>>>>>>>>>>>>> contains a single file it is not that interesting. Here >>>>>>>>>>>>>>>> is an >>>>>>>>>>>>>>>> example of >>>>>>>>>>>>>>>> what the new webrev looks like for a larger change (the >>>>>>>>>>>>>>>> G1 class >>>>>>>>>>>>>>>> unloading change): >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>>> From John.Coomes at oracle.com Tue Oct 14 22:23:26 2014 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 14 Oct 2014 15:23:26 -0700 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543D95A2.60201@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> <543D75B4.8060708@oracle.com> <543D7F9D.2000908@oracle.com> <543D8613.9070507@oracle.com> <543D8E2C.50707@oracle.com> <543D95A2.60201@oracle.com> Message-ID: <21565.41566.924358.358433@mykonos.us.oracle.com> Daniel Fuchs (daniel.fuchs at oracle.com) wrote: > On 10/14/14 10:57 PM, Eric McCorkle wrote: > > (Sorry, I forgot to hit "reply all") > > > > Actually, the results may be from a version I had stashed in my home dir > > (which I'd forgotten about). > > > > Here is from a fresh checkout: > > > > $ ksh -p ../../webrev/webrev.ksh > > SCM detected: mercurial > > > > No outgoing, perhaps you haven't commited. > > Workspace: /usr/home/emccorkl/src/enum_convert/langtools > > Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools > > Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev > > Output Files: > > ../../webrev/webrev.ksh: line 2273: i: arithmetic syntax error > > Ahah - OK - thanks Eric - now the line numbers make sense :-) > I've been bitten by this kind of things before - I believe [[ ]] might > need to be replaced with something else. Here's line 2273 (plus some context): 2269 i=1; 2270 while read LINE 2271 do 2272 set - $LINE 2273 if [[ i -lt ${#NEXT_FILES[*]} ]] 2274 then 2275 NEXT_FILE=${NEXT_FILES[$i]} On line 2273, that should be $i (note the $) instead of just i. -John > For evaluating arithmetic operations (+ - etc..) it seems better to > use 'expr'. > if [[i -lt ...]] should probably be replaced with something like > if [ $i -lt ... ] > > It's possible that the same kind of medicine will need to be applied > to i=$(($i + 1)) a few lines below - though it's not really possible > to tell without testing. Does the following works with your version > of ksh: > > ksh > i=1 > i=$(($i + 1)) > echo $i > > I see there are several occurrences of [[ ]] - not sure whether all of > them should be replaced... Usually string comparison don't require > a double [[ ]]. > > Hope this helps, > > -- daniel > > > > > > > > Version: WEBREV_UPDATED=25.6-hg+openjdk.java.net > > > > > > > > > > > > Here is from the one in my home dir: > > > > > > webrev > > SCM detected: mercurial > > > > No outgoing, perhaps you haven't commited. > > Workspace: /usr/home/emccorkl/src/enum_convert/langtools > > Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools > > Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev > > Output Files: > > make/build.properties > > /usr/home/emccorkl//bin/webrev[2241]: > > build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic > > syntax error > > > > > > > > Version: WEBREV_UPDATED=25.1-hg+openjdk.java.net > > > > > > So it seems the output from earlier is from the version I had stashed. > > Sorry about that. > > > > On 10/14/14 16:22, Jonathan Gibbons wrote: > >> Eric says it was a fresh check out from the webrev repo, and for the > >> rest, he says, > >> > >> I'm not terribly familiar with ksh, but $ ksh -v gives the following: > >> > >> version sh (AT&T Research) 93v- 2014-06-06 > >> > >> > >> The OS is Linux. > >> > >> > >> Oddly enough, it doesn't seem to negatively affect the output that I can > >> tell. > >> > >> > >> -- Jon > >> > >> > >> > >> On 10/14/2014 12:55 PM, Daniel Fuchs wrote: > >>> On 10/14/14 9:12 PM, Jonathan Gibbons wrote: > >>>> Eric, > >>>> > >>>> Can you provide info on the OS and version of ksh you are using that > >>>> caused the problems you experienced with webrev? > >>> And also the version of webrev please :-) > >>> > >>> -- daniel > >>> > >>>> -- Jon > >>>> > >>>> On 10/14/2014 11:47 AM, Bengt Rutisson wrote: > >>>>> On 10/14/14 11:05 AM, Daniel Fuchs wrote: > >>>>>> On 14/10/14 00:20, Jonathan Gibbons wrote: > >>>>>>> Bengt, > >>>>>>> > >>>>>>> There may be problems with the latest version of webrev. > >>>>>>> > >>>>>>> Eric McCorkle is reporting syntax errors from his version of ksh. > >>>>>>> > >>>>>>> patch cdiffs udiffs sdiffs frames old new > >>>>>>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java > >>>>>>> ../../tl/make/scripts/webrev.ksh[2241]: > >>>>>>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic > >>>>>>> syntax error > >>>>>> Hi Jon, > >>>>>> > >>>>>> These line numbers do not seem to correspond to the latest version > >>>>>> of webrev.ksh. > >>>>>> > >>>>>> line 2241 is a comment > >>>>>> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial > >>>>>> (an not in build_old_new) > >>>>>> line 1666 is ' fi' in look_for_prog > >>>>>> (an not build_old_new_mercurial) > >>>>>> > >>>>>> Could you maybe check that we're speaking of the same version of > >>>>>> webrev.ksh? > >>>>> Daniel, Thanks for pointing this out. > >>>>> > >>>>> It also does not seem to be the lines that I changed. > >>>>> > >>>>> Jon, I'm running the webrev script with ksh and it seems to work > >>>>> fine. Do you know which version ksh and which platform Eric is using? > >>>>> > >>>>> Thanks, > >>>>> Bengt > >>>>> > >>>>> > >>>>>> best regards, > >>>>>> > >>>>>> -- daniel > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -- Jon > >>>>>>> > >>>>>>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: > >>>>>>>> On 2014-10-02 23:39, John Coomes wrote: > >>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > >>>>>>>>>> On 2014-10-02 01:08, John Coomes wrote: > >>>>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > >>>>>>>>>>>> Hi Daniel, > >>>>>>>>>>>> > >>>>>>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: > >>>>>>>>>>>>> Hi Bengt, > >>>>>>>>>>>>> > >>>>>>>>>>>>> The new version looks good to me, but I am not a reviewer > >>>>>>>>>>>>> fore CODE_TOOLS. > >>>>>>>>>>>> Thanks for looking at this Daniel! > >>>>>>>>>>>> > >>>>>>>>>>>>> Hopefully someone who is will step in :-) > >>>>>>>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor > >>>>>>>>>>>> for the > >>>>>>>>>>>> patch too. > >>>>>>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the > >>>>>>>>>>> result of > >>>>>>>>>>> "hg export --git" and I'll push that. > >>>>>>>>>> Thanks for looking at this, John! And thanks for sponsoring the > >>>>>>>>>> change. > >>>>>>>>>> I'll send you the export in a separate email. > >>>>>>>>> Got it; it's been pushed. > >>>>>>>> Thanks for pushing this, John! > >>>>>>>> > >>>>>>>> Bengt > >>>>>>>> > >>>>>>>>> -John > >>>>>>>>> > >>>>>>>>>>>>> best regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- daniel > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: > >>>>>>>>>>>>>> Hi Daniel, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks for looking at this! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: > >>>>>>>>>>>>>>> Hi Bengt, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This is a really cool feature! > >>>>>>>>>>>>>> Thanks! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I have downloaded your patch and applied it in my > >>>>>>>>>>>>>>> local webrev repo - and played with the new > >>>>>>>>>>>>>>> webrev in a couple of repositories where I have > >>>>>>>>>>>>>>> pending uncommitted changes. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This seems to work well. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I have used: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> webrev -fN from top level repo > >>>>>>>>>>>>>>> webrev -N from jdk repo > >>>>>>>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> Great that you tired it out. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I also had a cursory look at your patch. The only thing > >>>>>>>>>>>>>>> I noticed is that 'typeset' is not consistently used in > >>>>>>>>>>>>>>> the original webrev file. I'm not sure whether that's > >>>>>>>>>>>>>>> intended or not. > >>>>>>>>>>>>>>> I believe that's ok - but I've been bitten by not using > >>>>>>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - > >>>>>>>>>>>>>>> you could use typeset at least in those functions that > >>>>>>>>>>>>>>> already use it for their parameters? For instance > >>>>>>>>>>>>>>> lines 532-534, and possibly line 560 as well? > >>>>>>>>>>>>>>> Or did you intentionally not used it? > >>>>>>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the > >>>>>>>>>>>>>> lines you > >>>>>>>>>>>>>> pointed out. I wasn't sure which way to go. But I think your > >>>>>>>>>>>>>> suggestion > >>>>>>>>>>>>>> is good. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Also you should increment the version of webrev. > >>>>>>>>>>>>>>> IIRC that would be 25.6: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net > >>>>>>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net > >>>>>>>>>>>>>> Thanks, didn't think of that. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New webrev: > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Diff compared to the first version: > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> Bengt > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> best regards, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- daniel > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: > >>>>>>>>>>>>>>>> Hi everyone, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to > >>>>>>>>>>>>>>>> the JDK > >>>>>>>>>>>>>>>> 9 dev > >>>>>>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev > >>>>>>>>>>>>>>>> list and > >>>>>>>>>>>>>>>> most JDK > >>>>>>>>>>>>>>>> developers might have opinions about this change.) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Can I get a couple of reviews for this small enhancement to > >>>>>>>>>>>>>>>> the webrev > >>>>>>>>>>>>>>>> tool? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate > >>>>>>>>>>>>>>>> between diffs > >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Webrev: > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Background: > >>>>>>>>>>>>>>>> When browsing review requests that span many files it is > >>>>>>>>>>>>>>>> quite > >>>>>>>>>>>>>>>> time > >>>>>>>>>>>>>>>> consuming to have to go back to the index page to view to > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> next or > >>>>>>>>>>>>>>>> previous file. This patch adds links to the next and > >>>>>>>>>>>>>>>> previous > >>>>>>>>>>>>>>>> files in > >>>>>>>>>>>>>>>> the diff views (including frames). > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The above webrev is generated with this new version, but > >>>>>>>>>>>>>>>> since > >>>>>>>>>>>>>>>> it only > >>>>>>>>>>>>>>>> contains a single file it is not that interesting. Here > >>>>>>>>>>>>>>>> is an > >>>>>>>>>>>>>>>> example of > >>>>>>>>>>>>>>>> what the new webrev looks like for a larger change (the > >>>>>>>>>>>>>>>> G1 class > >>>>>>>>>>>>>>>> unloading change): > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>> Bengt > >>>>>>>>>>>>>>>> > From maurizio.cimadamore at oracle.com Tue Oct 14 23:34:40 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 15 Oct 2014 00:34:40 +0100 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <543DB310.9000105@oracle.com> Vote: yes! Maurizio On 09/10/14 02:54, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in > messages of Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer > to check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until > annotations are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type > parameters > Summary: When reading type variable's annotations out of the owner's > type annotations, use the type variable's index in owner to exclude > annotations belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always > point at the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first > call to JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, > adding formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, > is reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional > cases related to type annotations, adding specialized error message > for annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an > outer class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, > including a short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when > overriding deprecated method > Summary: When the overrides deprecated method warning is being > reported, need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative > varargs test cases > Summary: Introducing a new error message for vararg parameter not > being the last parameter, improving error message for unexpected > character after a parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception > parameters when not generating debuging info > Summary: The exception parameters with type annotations need to be > added into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong > elements > Summary: Match the required and actual annotations using Element > equivalence rather than TypeMirror equivalence, to avoid trouble with > erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how > broken the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the > lambda parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when > passed a Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent > on the default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an > equivalent of an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write > pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself > does not set the pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use > the direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is > unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting > againts improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the > found type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for > interface static method > Summary: ClassReader must not set Flags.DEFAULT for interface static > methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class > (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for > interface without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - > ensure the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings > are reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small > cleanup related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught > exceptions in lambda expression > Summary: Producing individual errors for uncaught undeclared > exceptions inside lambda expressions, rather than one error for the > whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when > processing import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client > data, or null if none. > Reviewed-by: jjg, mcimadamore > From volker.simonis at gmail.com Wed Oct 15 07:31:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Oct 2014 09:31:14 +0200 Subject: CFV: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: Vote: yes On Thu, Oct 9, 2014 at 3:54 AM, Jonathan Gibbons wrote: > I hereby nominate Jan Lahoda to jdk9 Reviewer. > > Jan has had many years experience working on javac, while working on > NetBeans and since joining the javac team. He has contributed over 90 > changesets and participated in many reviews as well. Some of his more > significant contributions are listed below. > > Votes are due by 22 Oct 2014. > > Only current jdk9 Reviewers [1] are eiligible 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]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2b75f318fea > 8043643: Add an crules analyzer avoiding string concatenation in messages of > Assert checks. > Summary: Generalizing the crules infrastructure, adding a new analyzer to > check String concatenation in Assert calls. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/eb1989ca0494 > 6707032: Division by zero warning not suppressed properly in some cases > Summary: Delay reporting of the division by zero warning until annotations > are resolved, so that @SuppressWarnings works correctly. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d49a41294a > 8046916: Type parameter annotations don't work with multiple type parameters > Summary: When reading type variable's annotations out of the owner's type > annotations, use the type variable's index in owner to exclude annotations > belonging to other type variables. > Reviewed-by: jfranck, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4487f6f98252 > 8043186: javac test langtools/tools/javac/util/StringUtilsTest.java fails > Summary: The result of String.toLowerCase.indexOf does not always point at > the start of the given string in the non-lowercased text. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/dfd281a9c6bf > 8041663: Sensitive dependence on location of nested interface > Summary: Adding a method among ambiguous candidates only if it is more > specific than some of the existing candidates. > Reviewed-by: dlsmith, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/da8d9f8995d1 > 8040822: Duplicated notifications can be sent to TaskListener > Summary: The analyze finished event must only be sent on the first call to > JavaCompiler.flow for a given class. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176a2e871eb9 > 8041695: Update the NetBeans build script and metadata > Summary: Various improvements to the NetBeans project for langtools, adding > formatting/import setting for langtools. > Reviewed-by: ksrini > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/95f5329ecbbb > 8038788: javac behaves incorrectly for annotations after method type > parameters in some cases > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d8d27b8088fd > 8038455: Use single Context for all rounds of annotation processing > Summary: One set of javac services, as well as created ClassSymbols, is > reused for all rounds of processing now. > Reviewed-by: jjg, jfranck, darcy, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d06980994e0 > 8035890: jdk8 javac -source 7 compiles test case it should not > Summary: Ensuring source level checks are performed in two additional cases > related to type annotations, adding specialized error message for > annotations after method type parameters. > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7690787d1a81 > 8034854: outer_class_info_index of synthetic class is not zero > Summary: Auxiliary synthetic anonymous classes should not have an outer > class specified in the InnerClasses attribute. > Reviewed-by: vromero, jjg, abuckley > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/86afe494b60f > 8033961: Formatting of -Xlint: command line help > Summary: Improving formatting of command line help for -Xlint, including a > short description of each lint. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d1897a74e801 > 8033421: @SuppressWarnings("deprecation") does not work when overriding > deprecated method > Summary: When the overrides deprecated method warning is being reported, > need to do that in the lint context of the method. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6c96a2941e60 > 8030091: Request to update error messages from javac for negative varargs > test cases > Summary: Introducing a new error message for vararg parameter not being the > last parameter, improving error message for unexpected character after a > parameter. > Reviewed-by: jjg, sogoel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c71cb4fbb329 > 8028576: Incorrect RuntimeVisibleTypeAnnotations for exception parameters > when not generating debuging info > Summary: The exception parameters with type annotations need to be added > into the varBuffer even if not generating debug info > Reviewed-by: jjg, emc > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7163a6b6d8ea > 8030049: RoundEnvironment.getElementsAnnotatedWith receives wrong elements > Summary: Match the required and actual annotations using Element equivalence > rather than TypeMirror equivalence, to avoid trouble with erroneous types. > Reviewed-by: darcy > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c1c20e618930 > 8029376: Full attribution of unresolvable annotations > 8029161: javac crashing when processing broken annotations > Summary: Attributing values of annotation attributes regardless how broken > the annotation is. > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/378aa10645e1 > 8028235: Better error recovery for parsing 'void' as a type of the lambda > parameter > Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. > Reviewed-by: vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/55e4fd84b317 > 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when passed a > Character. > Summary: JCLiteral for char must contain an Integer, not the provided > Character. > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bc18278c195e > 8029800: Flags.java uses String.toLowerCase without specifying Locale > Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on the > default locale, converting almost all usages of > String.toLowerCase/toUpperCase to use the new methods. > Reviewed-by: jjg, bpatel > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/756ae3791c45 > 8027789: Access method for Outer.super.m() references indirect superclass > Summary: Internally convert the qualified super access to an equivalent of > an unqualified super access inside the access method. > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8acb838c9b79 > 8026374: javac accepts void as a method parameter > Summary: Changing Check.validate to reject void types. > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6e0f31d61e56 > 8027142: Invokedynamic instructions don't get line number table entries > Summary: When emitting invokedynamic instruction, write pendingStatPos, if > set, into the LineNumberTable. Invokedynamic itself does not set the > pendingStatPos. > Reviewed-by: jjg, jrose, ksrini, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/75c8cde12ab6 > 8027281: Incorrect invokespecial generated for JCK lang > EXPR/expr636/expr63602m* tests > Summary: When invoking interface default method via a superclass, use the > direct superclass in the reference. > Reviewed-by: vromero, dlsmith, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8b4e1421a9b7 > 8027310: Annotation Processor crashes with NPE > Summary: JCAnnotation.attribute is null when annotation type is unavailable > Reviewed-by: jjg, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/864dafc5ab7a > 8026861: Wrong LineNumberTable for variable declarations in lambdas > Summary: Setting or correcting positions for many trees produced by > LambdaToMethod. > Reviewed-by: vromero, rfield > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/79649bf21a92 > 8026180: com.sun.source.tree.NewArrayTree refers to > com.sun.tools.javac.util.List > Summary: Correcting import in NewArrayTree, adding test protecting againts > improper types in API signatures > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/87b5bfef7edb > 8014016: javac is too late detecting invalid annotation usage > Summary: Adding new queue to Annotate for validation tasks, performing > annotation validation during enter > Reviewed-by: jjg, emc, jfranck > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/872c4a898b38 > 6278240: Exception from AnnotationValue.getValue() should list the found > type not the required type > Reviewed-by: darcy, jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1b469fd31e35 > 8025087: Annotation processing api returns default modifier for interface > static method > Summary: ClassReader must not set Flags.DEFAULT for interface static methods > Reviewed-by: vromero, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0be3f1820e8b > 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) > Summary: Should not generate non-public $assertionsDisabled field into > interfaces > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c13305cf8528 > 8025118: Annotation processing api returns default modifier for interface > without default methods > Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT > Reviewed-by: darcy, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/b7d8b71e1658 > 8022765: Compiler crashes with exception on wrong usage of an annotation. > Summary: Error recovery for incorrect annotation attribute values - ensure > the values are always attributed appropriately > Reviewed-by: jfranck, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/41599b57d262 > 8023835: TreeMaker.QualIdent() too leafy > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8d1c48de706d > 8022567: Javac Should Generate Warnings For Raw Array Type > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4ce8148ffc4f > 8021112: Spurious unchecked warning reported by javac > 6480588: No way to suppress deprecation warnings when implementing > deprecated interface > Summary: Fixing DeferredLintHandler configuration, so lint warnings are > reported with correct @SuppressWarnings settings > Reviewed-by: jjg, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/77d395862700 > 8019521: Enhanced rethrow disabled in lambdas > Summary: Fixing effectively final detection inside lambdas, small cleanup > related to thrown types detection in lambdas > Reviewed-by: mcimadamore, jjg > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f657d400c736 > 8022508: javac crashes if the generics arity of a base class is wrong > Reviewed-by: mcimadamore, vromero > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ec77c7b46c37 > 8015809: More user friendly compile-time errors for uncaught exceptions in > lambda expression > Summary: Producing individual errors for uncaught undeclared exceptions > inside lambda expressions, rather than one error for the whole lambda > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cd9e8cea1b3c > 8021338: Diamond finder may mark a required type argument as unnecessary > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/8c4b2987edac > 8020689: Missing LineNumberTable entries in compiled class files > Reviewed-by: ksrini, mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/10711bd8bb2d > 8020586: Warning produced for an incorrect file > Summary: Always using DeferredLintHandler.immediateHandler when processing > import classes > Reviewed-by: mcimadamore > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/170e486632d9 > 8004504: ListBuffer could reuse List.nil() as the sentinel element > Summary: ListBuffer.last now points to the last elements with client data, > or null if none. > Reviewed-by: jjg, mcimadamore > From bengt.rutisson at oracle.com Wed Oct 15 08:50:22 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 15 Oct 2014 10:50:22 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <21565.41566.924358.358433@mykonos.us.oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> <543D75B4.8060708@oracle.com> <543D7F9D.2000908@oracle.com> <543D8613.9070507@oracle.com> <543D8E2C.50707@oracle.com> <543D95A2.60201@oracle.com> <21565.41566.924358.358433@mykonos.us.oracle.com> Message-ID: <543E354E.1050308@oracle.com> On 2014-10-15 00:23, John Coomes wrote: > Daniel Fuchs (daniel.fuchs at oracle.com) wrote: >> On 10/14/14 10:57 PM, Eric McCorkle wrote: >>> (Sorry, I forgot to hit "reply all") >>> >>> Actually, the results may be from a version I had stashed in my home dir >>> (which I'd forgotten about). >>> >>> Here is from a fresh checkout: >>> >>> $ ksh -p ../../webrev/webrev.ksh >>> SCM detected: mercurial >>> >>> No outgoing, perhaps you haven't commited. >>> Workspace: /usr/home/emccorkl/src/enum_convert/langtools >>> Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools >>> Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev >>> Output Files: >>> ../../webrev/webrev.ksh: line 2273: i: arithmetic syntax error >> Ahah - OK - thanks Eric - now the line numbers make sense :-) >> I've been bitten by this kind of things before - I believe [[ ]] might >> need to be replaced with something else. > Here's line 2273 (plus some context): > > 2269 i=1; > 2270 while read LINE > 2271 do > 2272 set - $LINE > 2273 if [[ i -lt ${#NEXT_FILES[*]} ]] > 2274 then > 2275 NEXT_FILE=${NEXT_FILES[$i]} > > On line 2273, that should be $i (note the $) instead of just i. Thanks for finding this, John! Bengt > > -John > >> For evaluating arithmetic operations (+ - etc..) it seems better to >> use 'expr'. >> if [[i -lt ...]] should probably be replaced with something like >> if [ $i -lt ... ] >> >> It's possible that the same kind of medicine will need to be applied >> to i=$(($i + 1)) a few lines below - though it's not really possible >> to tell without testing. Does the following works with your version >> of ksh: >> >> ksh >> i=1 >> i=$(($i + 1)) >> echo $i >> >> I see there are several occurrences of [[ ]] - not sure whether all of >> them should be replaced... Usually string comparison don't require >> a double [[ ]]. >> >> Hope this helps, >> >> -- daniel >>> >>> >>> Version: WEBREV_UPDATED=25.6-hg+openjdk.java.net >>> >>> >>> >>> >>> >>> Here is from the one in my home dir: >>> >>> >>> webrev >>> SCM detected: mercurial >>> >>> No outgoing, perhaps you haven't commited. >>> Workspace: /usr/home/emccorkl/src/enum_convert/langtools >>> Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools >>> Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev >>> Output Files: >>> make/build.properties >>> /usr/home/emccorkl//bin/webrev[2241]: >>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >>> syntax error >>> >>> >>> >>> Version: WEBREV_UPDATED=25.1-hg+openjdk.java.net >>> >>> >>> So it seems the output from earlier is from the version I had stashed. >>> Sorry about that. >>> >>> On 10/14/14 16:22, Jonathan Gibbons wrote: >>>> Eric says it was a fresh check out from the webrev repo, and for the >>>> rest, he says, >>>> >>>> I'm not terribly familiar with ksh, but $ ksh -v gives the following: >>>> >>>> version sh (AT&T Research) 93v- 2014-06-06 >>>> >>>> >>>> The OS is Linux. >>>> >>>> >>>> Oddly enough, it doesn't seem to negatively affect the output that I can >>>> tell. >>>> >>>> >>>> -- Jon >>>> >>>> >>>> >>>> On 10/14/2014 12:55 PM, Daniel Fuchs wrote: >>>>> On 10/14/14 9:12 PM, Jonathan Gibbons wrote: >>>>>> Eric, >>>>>> >>>>>> Can you provide info on the OS and version of ksh you are using that >>>>>> caused the problems you experienced with webrev? >>>>> And also the version of webrev please :-) >>>>> >>>>> -- daniel >>>>> >>>>>> -- Jon >>>>>> >>>>>> On 10/14/2014 11:47 AM, Bengt Rutisson wrote: >>>>>>> On 10/14/14 11:05 AM, Daniel Fuchs wrote: >>>>>>>> On 14/10/14 00:20, Jonathan Gibbons wrote: >>>>>>>>> Bengt, >>>>>>>>> >>>>>>>>> There may be problems with the latest version of webrev. >>>>>>>>> >>>>>>>>> Eric McCorkle is reporting syntax errors from his version of ksh. >>>>>>>>> >>>>>>>>> patch cdiffs udiffs sdiffs frames old new >>>>>>>>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >>>>>>>>> ../../tl/make/scripts/webrev.ksh[2241]: >>>>>>>>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >>>>>>>>> syntax error >>>>>>>> Hi Jon, >>>>>>>> >>>>>>>> These line numbers do not seem to correspond to the latest version >>>>>>>> of webrev.ksh. >>>>>>>> >>>>>>>> line 2241 is a comment >>>>>>>> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial >>>>>>>> (an not in build_old_new) >>>>>>>> line 1666 is ' fi' in look_for_prog >>>>>>>> (an not build_old_new_mercurial) >>>>>>>> >>>>>>>> Could you maybe check that we're speaking of the same version of >>>>>>>> webrev.ksh? >>>>>>> Daniel, Thanks for pointing this out. >>>>>>> >>>>>>> It also does not seem to be the lines that I changed. >>>>>>> >>>>>>> Jon, I'm running the webrev script with ksh and it seems to work >>>>>>> fine. Do you know which version ksh and which platform Eric is using? >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>> >>>>>>>> best regards, >>>>>>>> >>>>>>>> -- daniel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -- Jon >>>>>>>>> >>>>>>>>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>>>>>>>>> On 2014-10-02 23:39, John Coomes wrote: >>>>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>>>>>>>>> fore CODE_TOOLS. >>>>>>>>>>>>>> Thanks for looking at this Daniel! >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hopefully someone who is will step in :-) >>>>>>>>>>>>>> Yes, and I am not a committer in code-tools so I need a sponsor >>>>>>>>>>>>>> for the >>>>>>>>>>>>>> patch too. >>>>>>>>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>>>>>>>>> result of >>>>>>>>>>>>> "hg export --git" and I'll push that. >>>>>>>>>>>> Thanks for looking at this, John! And thanks for sponsoring the >>>>>>>>>>>> change. >>>>>>>>>>>> I'll send you the export in a separate email. >>>>>>>>>>> Got it; it's been pushed. >>>>>>>>>> Thanks for pushing this, John! >>>>>>>>>> >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>>> -John >>>>>>>>>>> >>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- daniel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is a really cool feature! >>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>>>>>>>>> pending uncommitted changes. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This seems to work well. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have used: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> webrev -fN from top level repo >>>>>>>>>>>>>>>>> webrev -N from jdk repo >>>>>>>>>>>>>>>>> webrev -fN from jdk repo (with changes in test/closed) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Great that you tired it out. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>>>>>>>>> intended or not. >>>>>>>>>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>>>>>>>>> Or did you intentionally not used it? >>>>>>>>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>>>>>>>>> lines you >>>>>>>>>>>>>>>> pointed out. I wasn't sure which way to go. But I think your >>>>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>>>> is good. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>>>>>>>>> Thanks, didn't think of that. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> New webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Diff compared to the first version: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- daniel >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to >>>>>>>>>>>>>>>>>> the JDK >>>>>>>>>>>>>>>>>> 9 dev >>>>>>>>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev >>>>>>>>>>>>>>>>>> list and >>>>>>>>>>>>>>>>>> most JDK >>>>>>>>>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Can I get a couple of reviews for this small enhancement to >>>>>>>>>>>>>>>>>> the webrev >>>>>>>>>>>>>>>>>> tool? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate >>>>>>>>>>>>>>>>>> between diffs >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Background: >>>>>>>>>>>>>>>>>> When browsing review requests that span many files it is >>>>>>>>>>>>>>>>>> quite >>>>>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>>> consuming to have to go back to the index page to view to >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> next or >>>>>>>>>>>>>>>>>> previous file. This patch adds links to the next and >>>>>>>>>>>>>>>>>> previous >>>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>>> the diff views (including frames). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The above webrev is generated with this new version, but >>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>> it only >>>>>>>>>>>>>>>>>> contains a single file it is not that interesting. Here >>>>>>>>>>>>>>>>>> is an >>>>>>>>>>>>>>>>>> example of >>>>>>>>>>>>>>>>>> what the new webrev looks like for a larger change (the >>>>>>>>>>>>>>>>>> G1 class >>>>>>>>>>>>>>>>>> unloading change): >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>>>>> From bengt.rutisson at oracle.com Wed Oct 15 08:54:26 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 15 Oct 2014 10:54:26 +0200 Subject: RFR: CODETOOLS-7901044: Add next/prev links to navigate between diffs In-Reply-To: <543E352E.5040809@oracle.com> References: <542BC1C9.9000204@oracle.com> <542C0762.5070700@oracle.com> <542C083E.40208@oracle.com> <542C0F44.1000009@oracle.com> <542C6DF1.1060409@oracle.com> <21548.35184.576946.43474@mykonos.us.oracle.com> <542CF2E7.3010202@oracle.com> <21549.50683.903473.289915@mykonos.us.oracle.com> <542E5728.8010709@oracle.com> <543C5031.2020000@oracle.com> <543CE755.6060900@oracle.com> <543D6FC3.7020604@oracle.com> <543D75B4.8060708@oracle.com> <543D7F9D.2000908@oracle.com> <543D8613.9070507@oracle.com> <543D8E2C.50707@oracle.com> <543E352E.5040809@oracle.com> Message-ID: <543E3642.7050800@oracle.com> Hi again Eric, My email below was blocked because the webrev.ksh that I attached was a too big attachement for the open lists. Can you try to apply the diff that inlined in the message and see if it solves your problems. Thanks, Bengt On 2014-10-15 10:49, Bengt Rutisson wrote: > > Hi Eric, > > Thanks for finding this issue! > > John Coomes pointed out that there is a missing $ on the failing line. > Since the current version works well on my Linux machine with my ksh > version (sh (AT&T Research) 93u+ 2012-08-01) I can't verify the issue. > > Could you try out the webrev version I'm attaching to this email? It > just adds the $ that John suggested. > > Here's the diff: > > diff --git a/webrev.ksh b/webrev.ksh > --- a/webrev.ksh > +++ b/webrev.ksh > @@ -2270,7 +2270,7 @@ > while read LINE > do > set - $LINE > - if [[ i -lt ${#NEXT_FILES[*]} ]] > + if [[ $i -lt ${#NEXT_FILES[*]} ]] > then > NEXT_FILE=${NEXT_FILES[$i]} > i=$(($i + 1)) > > > Thanks, > Bengt > > > On 2014-10-14 22:57, Eric McCorkle wrote: >> (Sorry, I forgot to hit "reply all") >> >> Actually, the results may be from a version I had stashed in my home dir >> (which I'd forgotten about). >> >> Here is from a fresh checkout: >> >> $ ksh -p ../../webrev/webrev.ksh >> SCM detected: mercurial >> >> No outgoing, perhaps you haven't commited. >> Workspace: /usr/home/emccorkl/src/enum_convert/langtools >> Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools >> Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev >> Output Files: >> ../../webrev/webrev.ksh: line 2273: i: arithmetic syntax error >> >> >> >> Version: WEBREV_UPDATED=25.6-hg+openjdk.java.net >> >> >> >> >> >> Here is from the one in my home dir: >> >> >> webrev >> SCM detected: mercurial >> >> No outgoing, perhaps you haven't commited. >> Workspace: /usr/home/emccorkl/src/enum_convert/langtools >> Compare against: ssh://hg.openjdk.java.net/jdk9/dev/langtools >> Output to: /usr/home/emccorkl/src/enum_convert/langtools/webrev >> Output Files: >> make/build.properties >> /usr/home/emccorkl//bin/webrev[2241]: >> build_old_new[1714]: build_old_new_mercurial[1666]: [: : arithmetic >> syntax error >> >> >> >> Version: WEBREV_UPDATED=25.1-hg+openjdk.java.net >> >> >> So it seems the output from earlier is from the version I had stashed. >> Sorry about that. >> >> On 10/14/14 16:22, Jonathan Gibbons wrote: >>> Eric says it was a fresh check out from the webrev repo, and for the >>> rest, he says, >>> >>> I'm not terribly familiar with ksh, but $ ksh -v gives the following: >>> >>> version sh (AT&T Research) 93v- 2014-06-06 >>> >>> >>> The OS is Linux. >>> >>> >>> Oddly enough, it doesn't seem to negatively affect the output that I >>> can >>> tell. >>> >>> >>> -- Jon >>> >>> >>> >>> On 10/14/2014 12:55 PM, Daniel Fuchs wrote: >>>> On 10/14/14 9:12 PM, Jonathan Gibbons wrote: >>>>> Eric, >>>>> >>>>> Can you provide info on the OS and version of ksh you are using that >>>>> caused the problems you experienced with webrev? >>>> And also the version of webrev please :-) >>>> >>>> -- daniel >>>> >>>>> -- Jon >>>>> >>>>> On 10/14/2014 11:47 AM, Bengt Rutisson wrote: >>>>>> On 10/14/14 11:05 AM, Daniel Fuchs wrote: >>>>>>> On 14/10/14 00:20, Jonathan Gibbons wrote: >>>>>>>> Bengt, >>>>>>>> >>>>>>>> There may be problems with the latest version of webrev. >>>>>>>> >>>>>>>> Eric McCorkle is reporting syntax errors from his version of ksh. >>>>>>>> >>>>>>>> patch cdiffs udiffs sdiffs frames old new >>>>>>>> src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java >>>>>>>> >>>>>>>> ../../tl/make/scripts/webrev.ksh[2241]: >>>>>>>> build_old_new[1714]: build_old_new_mercurial[1666]: [: : >>>>>>>> arithmetic >>>>>>>> syntax error >>>>>>> Hi Jon, >>>>>>> >>>>>>> These line numbers do not seem to correspond to the latest version >>>>>>> of webrev.ksh. >>>>>>> >>>>>>> line 2241 is a comment >>>>>>> line 1714 is ' if [ -f $F ]; then' in build_old_new_mercurial >>>>>>> (an not in build_old_new) >>>>>>> line 1666 is ' fi' in look_for_prog >>>>>>> (an not build_old_new_mercurial) >>>>>>> >>>>>>> Could you maybe check that we're speaking of the same version of >>>>>>> webrev.ksh? >>>>>> Daniel, Thanks for pointing this out. >>>>>> >>>>>> It also does not seem to be the lines that I changed. >>>>>> >>>>>> Jon, I'm running the webrev script with ksh and it seems to work >>>>>> fine. Do you know which version ksh and which platform Eric is >>>>>> using? >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -- Jon >>>>>>>> >>>>>>>> On 10/03/2014 12:58 AM, Bengt Rutisson wrote: >>>>>>>>> On 2014-10-02 23:39, John Coomes wrote: >>>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>>> On 2014-10-02 01:08, John Coomes wrote: >>>>>>>>>>>> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >>>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/1/14 4:27 PM, Daniel Fuchs wrote: >>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The new version looks good to me, but I am not a reviewer >>>>>>>>>>>>>> fore CODE_TOOLS. >>>>>>>>>>>>> Thanks for looking at this Daniel! >>>>>>>>>>>>> >>>>>>>>>>>>>> Hopefully someone who is will step in :-) >>>>>>>>>>>>> Yes, and I am not a committer in code-tools so I need a >>>>>>>>>>>>> sponsor >>>>>>>>>>>>> for the >>>>>>>>>>>>> patch too. >>>>>>>>>>>> Looks good to me; I'll sponsor it. Send me (privately) the >>>>>>>>>>>> result of >>>>>>>>>>>> "hg export --git" and I'll push that. >>>>>>>>>>> Thanks for looking at this, John! And thanks for sponsoring the >>>>>>>>>>> change. >>>>>>>>>>> I'll send you the export in a separate email. >>>>>>>>>> Got it; it's been pushed. >>>>>>>>> Thanks for pushing this, John! >>>>>>>>> >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>>> -John >>>>>>>>>> >>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- daniel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/10/14 15:57, Bengt Rutisson wrote: >>>>>>>>>>>>>>> Hi Daniel, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2014-10-01 15:53, Daniel Fuchs wrote: >>>>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is a really cool feature! >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have downloaded your patch and applied it in my >>>>>>>>>>>>>>>> local webrev repo - and played with the new >>>>>>>>>>>>>>>> webrev in a couple of repositories where I have >>>>>>>>>>>>>>>> pending uncommitted changes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This seems to work well. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have used: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> webrev -fN from top level repo >>>>>>>>>>>>>>>> webrev -N from jdk repo >>>>>>>>>>>>>>>> webrev -fN from jdk repo (with changes in >>>>>>>>>>>>>>>> test/closed) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Great that you tired it out. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I also had a cursory look at your patch. The only thing >>>>>>>>>>>>>>>> I noticed is that 'typeset' is not consistently used in >>>>>>>>>>>>>>>> the original webrev file. I'm not sure whether that's >>>>>>>>>>>>>>>> intended or not. >>>>>>>>>>>>>>>> I believe that's ok - but I've been bitten by not using >>>>>>>>>>>>>>>> typeset before ;-( - maybe - for the sake of uniformity - >>>>>>>>>>>>>>>> you could use typeset at least in those functions that >>>>>>>>>>>>>>>> already use it for their parameters? For instance >>>>>>>>>>>>>>>> lines 532-534, and possibly line 560 as well? >>>>>>>>>>>>>>>> Or did you intentionally not used it? >>>>>>>>>>>>>>> I also noticed the inconsistent use of typeset. I fixed the >>>>>>>>>>>>>>> lines you >>>>>>>>>>>>>>> pointed out. I wasn't sure which way to go. But I think >>>>>>>>>>>>>>> your >>>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>>> is good. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also you should increment the version of webrev. >>>>>>>>>>>>>>>> IIRC that would be 25.6: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - WEBREV_UPDATED=25.5-hg+openjdk.java.net >>>>>>>>>>>>>>>> + WEBREV_UPDATED=25.6-hg+openjdk.java.net >>>>>>>>>>>>>>> Thanks, didn't think of that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> New webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Diff compared to the first version: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00-01.diff/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- daniel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 01/10/14 10:56, Bengt Rutisson wrote: >>>>>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (This is a patch for webrev, but I am cross posting to >>>>>>>>>>>>>>>>> the JDK >>>>>>>>>>>>>>>>> 9 dev >>>>>>>>>>>>>>>>> list since I'm not sure how many are on the webrev-dev >>>>>>>>>>>>>>>>> list and >>>>>>>>>>>>>>>>> most JDK >>>>>>>>>>>>>>>>> developers might have opinions about this change.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Can I get a couple of reviews for this small >>>>>>>>>>>>>>>>> enhancement to >>>>>>>>>>>>>>>>> the webrev >>>>>>>>>>>>>>>>> tool? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> CODETOOLS-7901044: Add next/prev links to navigate >>>>>>>>>>>>>>>>> between diffs >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901044 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Background: >>>>>>>>>>>>>>>>> When browsing review requests that span many files it is >>>>>>>>>>>>>>>>> quite >>>>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>> consuming to have to go back to the index page to view to >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> next or >>>>>>>>>>>>>>>>> previous file. This patch adds links to the next and >>>>>>>>>>>>>>>>> previous >>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>> the diff views (including frames). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The above webrev is generated with this new version, but >>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>> it only >>>>>>>>>>>>>>>>> contains a single file it is not that interesting. Here >>>>>>>>>>>>>>>>> is an >>>>>>>>>>>>>>>>> example of >>>>>>>>>>>>>>>>> what the new webrev looks like for a larger change (the >>>>>>>>>>>>>>>>> G1 class >>>>>>>>>>>>>>>>> unloading change): >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/CODETOOLS-7901044/webrev.00/example/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>>>> > From lana.steuck at oracle.com Wed Oct 15 16:54:13 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 15 Oct 2014 09:54:13 -0700 (PDT) Subject: jdk9-b35: dev Message-ID: <201410151654.s9FGsDH5010779@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/c173ba994245 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/63b8da4c958c http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/b8e7bbdd8064 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e549291a0227 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/afe0c89e2edb http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/b9370464572f http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/438cb613151c http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/9bc2dbd3dfb8 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8059840 core-libs (bb) Typo in javadoc for ByteBuffer.wrap() JDK-8059570 core-libs Add RowSetFactory and RowSetProvider tests JDK-8059973 core-libs Broken link in Class Pack200 JDK-8059997 core-libs Broken link in javax.sql.rowset Interface WebRowSet JDK-8059882 core-libs Disable RowSetFactory and RowSetProviderTests which are failing due to agentvm mode JDK-8028788 core-libs Logger.enterring uses String concatenation in a loop JDK-8059811 core-libs Make optimistic typing off/false by default JDK-8059236 core-libs Memory leak when executing octane pdfjs with optimistic typing JDK-8059938 core-libs NPE restoring cached script with optimistic types disabled JDK-8059786 core-libs Nightly test failure with tz2014g update JDK-8059231 core-libs Octane Raytrace fails when optimistic typing turned off JDK-8059870 core-libs RowSetFactoryTests and RowSetProviderTests failing JDK-8056909 core-libs test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java fails with OOME JDK-8059105 core-svc Add better failure reporting to com/sun/jdi/RunToExit.java test. JDK-8059868 core-svc JVM crashes on attach on Windows when compiled with /RTC1 JDK-8060042 core-svc closed/sun/management/snmp/bootstrap/SnmpExceptionBootstrapTest.sh should be quarantined JDK-8054194 core-svc jstack crash: assert(handle != NULL) failed: JNI handle should not be null JDK-8058578 hotspot -XX:+TraceDependencies is broken for call_site_target_value dependency type JDK-8058927 hotspot ATG throws ClassNotFoundException JDK-8057660 hotspot Add implementation for JFR requestable event. JDK-8058919 hotspot Add sanity test for minimal VM in test/Makefile JDK-8058818 hotspot Allocation of more then 1G of memory using Unsafe.allocateMemory is still causing a fatal error on 32bit platforms JDK-8059556 hotspot C2: crash while inlining MethodHandle invocation w/ null receiver JDK-8043766 hotspot CMM Testing: 8u40 Decommit auxiliary data structures JDK-8057846 hotspot ClassVerifier::change_sig_to_verificationType temporary symbol creation code is hot JDK-8059474 hotspot Clean up vm/utilities/Bitmap type uses JDK-8058737 hotspot CodeCache::find_blob fails with 'unsafe access to zombie method' JDK-8058963 hotspot CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints JDK-8058968 hotspot Compiler time traces should be improved JDK-8059527 hotspot Disallow ParallelGCThreads=0 for G1 JDK-8058825 hotspot EA: ConnectionGraph::split_unique_types does incorrect scalar replacement JDK-8047976 hotspot Ergonomics for GC thread counts should update the flags JDK-8059468 hotspot Fix PrintCodeCache output changed by JDK-8059137 JDK-8059452 hotspot G1: Change the default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent JDK-8058880 hotspot Introduce identifier TEMP_DEF for effects in adl. JDK-8059037 hotspot JdpTest.sh hangs when trying to kill the test VM JDK-8059137 hotspot MemoryPoolMXBeans for different code heaps should contain 'Code heap' in their names JDK-8049599 hotspot MetaspaceGC::_capacity_until_GC can overflow JDK-8057925 hotspot PrintSymbolTableSizeHistogram prints misleading output JDK-8059651 hotspot Tests specify -XX:+UseG1GC and -XX:ParallelGCThreads=0 JDK-8058828 hotspot Wrong ciConstant type for arrays from ConstantPool::_resolved_reference JDK-8032253 hotspot [Event Request] Add information about loaded libraries to JFR. JDK-8025606 hotspot [TESTBUG] Move ctw-tests to /testlibrary_tests JDK-8038098 hotspot [TESTBUG] remove explicit set build flavor from hotspot/test/compiler/* tests JDK-8059390 hotspot code cache fills up for bigapps/Weblogic+medrec/nowarnings JDK-8058936 hotspot hotspot/test/Makefile should use jtreg script from $JT_HOME/bin/jreg (instead of $JT_HOME/win32/bin/jtreg) JDK-8058536 hotspot java/lang/instrument/NativeMethodPrefixAgent.java fails due to VirtualMachineError: out of space in CodeCache for method handle intrinsic JDK-8058891 hotspot serviceability/dcmd/CodelistTest.java - fails on all platforms JDK-8059658 infrastructure Bootcycle build not actually using built image JDK-8058920 infrastructure JPRT: Add basic sanity testing for embedded builds and for the minimal VM JDK-8059627 security-libs Enable PKCS11 tests on Mac JDK-8060007 security-libs Keytool test can use bundled NSS lib on Mac JDK-8041740 security-libs Test sun/security/tools/keytool/ListKeychainStore.sh fails on Mac JDK-8037550 security-libs Update RFC references in javadoc to RFC 5280 JDK-8056258 tools Analysis of public API does not take super classes into account JDK-8059349 tools Public API scanning should be implemented in the form of a TaskListener JDK-8057652 tools Request to improve error messages for labeled declarations JDK-8056051 tools int[]::clone causes "java.lang.NoClassDefFoundError: Array" JDK-8048609 tools simplify sjavac dependence on javac dependency gathering JDK-8059653(was JDK-8059596): VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set From mark.reinhold at oracle.com Thu Oct 16 00:55:01 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 15 Oct 2014 17:55:01 -0700 (PDT) Subject: JEP 212: Resolve Lint and Doclint Warnings Message-ID: <20141016005501.98E553DE45@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/212 - Mark From mparchet at sunrise.ch Mon Oct 20 20:36:36 2014 From: mparchet at sunrise.ch (Michael Parchet) Date: Mon, 20 Oct 2014 22:36:36 +0200 Subject: Fwd: Downloud Openjdk 7, 8, or 9 for Linux, Mac or windows References: <8A0FF610-E6B8-4F74-86E1-01ABDCD13FF0@sunrise.ch> Message-ID: > Hello, > > Where I could download open jdk (not oracle jdk )7, 8, or 9, for Mac, windows or Linux. > > Tanks by avance for your answer > > Best regards > > mparchet > > From sadhak001 at gmail.com Mon Oct 20 20:49:04 2014 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 20 Oct 2014 21:49:04 +0100 Subject: Downloud Openjdk 7, 8, or 9 for Linux, Mac or windows In-Reply-To: References: <8A0FF610-E6B8-4F74-86E1-01ABDCD13FF0@sunrise.ch> Message-ID: Hi Michael, There's a Adopt OpenJDK CI server building a Linux version of OpenJDK 8 and OpenJDK9. You can find the latest binaries at: https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.8-linux-x86_64/ https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ I hope this helps. Cheers, Mani On Mon, Oct 20, 2014 at 9:36 PM, Michael Parchet wrote: > > > Hello, > > > > Where I could download open jdk (not oracle jdk )7, 8, or 9, for Mac, > windows or Linux. > > > > Tanks by avance for your answer > > > > Best regards > > > > mparchet > > > > > -- @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 martijnverburg at gmail.com Mon Oct 20 21:06:35 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 20 Oct 2014 22:06:35 +0100 Subject: Downloud Openjdk 7, 8, or 9 for Linux, Mac or windows In-Reply-To: References: <8A0FF610-E6B8-4F74-86E1-01ABDCD13FF0@sunrise.ch> Message-ID: Please note these should not be used for production, they're for R&D purposes only. You're highly recommended to go with Oracle's JDK for PRD or a supported OpenJDK binary from a vendor such as Red Hat Cheers, Martijn On 20 October 2014 21:49, Mani Sarkar wrote: > Hi Michael, > > There's a Adopt OpenJDK CI server building a Linux version of OpenJDK 8 and > OpenJDK9. You can find the latest binaries at: > > https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.8-linux-x86_64/ > https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ > > I hope this helps. > > Cheers, > Mani > > > On Mon, Oct 20, 2014 at 9:36 PM, Michael Parchet > wrote: > > > > > > Hello, > > > > > > Where I could download open jdk (not oracle jdk )7, 8, or 9, for Mac, > > windows or Linux. > > > > > > Tanks by avance for your answer > > > > > > Best regards > > > > > > mparchet > > > > > > > > > > > > -- > @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 rednaxelafx at gmail.com Mon Oct 20 21:55:13 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 20 Oct 2014 14:55:13 -0700 Subject: Downloud Openjdk 7, 8, or 9 for Linux, Mac or windows In-Reply-To: References: <8A0FF610-E6B8-4F74-86E1-01ABDCD13FF0@sunrise.ch> Message-ID: ... and Azul's Zulu [1] builds, too :-) Just my two cents, Kris [1]: http://www.azulsystems.com/products/zulu On Mon, Oct 20, 2014 at 2:06 PM, Martijn Verburg wrote: > Please note these should not be used for production, they're for R&D > purposes only. You're highly recommended to go with Oracle's JDK for PRD > or a supported OpenJDK binary from a vendor such as Red Hat > > Cheers, > Martijn > > On 20 October 2014 21:49, Mani Sarkar wrote: > > > Hi Michael, > > > > There's a Adopt OpenJDK CI server building a Linux version of OpenJDK 8 > and > > OpenJDK9. You can find the latest binaries at: > > > > https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.8-linux-x86_64/ > > https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ > > > > I hope this helps. > > > > Cheers, > > Mani > > > > > > On Mon, Oct 20, 2014 at 9:36 PM, Michael Parchet > > wrote: > > > > > > > > > Hello, > > > > > > > > Where I could download open jdk (not oracle jdk )7, 8, or 9, for Mac, > > > windows or Linux. > > > > > > > > Tanks by avance for your answer > > > > > > > > Best regards > > > > > > > > mparchet > > > > > > > > > > > > > > > > > > > -- > > @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 xerxes at zafena.se Tue Oct 21 08:17:35 2014 From: xerxes at zafena.se (=?UTF-8?B?WGVyeGVzIFLDpW5ieQ==?=) Date: Tue, 21 Oct 2014 10:17:35 +0200 Subject: Downloud Openjdk 7, 8, or 9 for Linux, Mac or windows In-Reply-To: References: <8A0FF610-E6B8-4F74-86E1-01ABDCD13FF0@sunrise.ch> Message-ID: <5446169F.5000207@zafena.se> Alex Kasko openjdk-unofficial-builds provide IcedTea patched OpenJDK 6 and 7 builds with installers for Windows, Linux and Mac: https://github.com/alexkasko/openjdk-unofficial-builds/blob/master/README.md Henri Gomez obuildfactory provide OpenJDK 7 and 8 builds for Linux obuildfactory contains support for building OSX packages as well. https://github.com/hgomez/obuildfactory/blob/master/README.md Cheers Xerxes Den 2014-10-20 23:55, Krystal Mok skrev: > ... and Azul's Zulu [1] builds, too :-) > > Just my two cents, > Kris > > [1]: http://www.azulsystems.com/products/zulu > > On Mon, Oct 20, 2014 at 2:06 PM, Martijn Verburg > wrote: > >> Please note these should not be used for production, they're for R&D >> purposes only. You're highly recommended to go with Oracle's JDK for PRD >> or a supported OpenJDK binary from a vendor such as Red Hat >> >> Cheers, >> Martijn >> >> On 20 October 2014 21:49, Mani Sarkar wrote: >> >>> Hi Michael, >>> >>> There's a Adopt OpenJDK CI server building a Linux version of OpenJDK 8 >> and >>> OpenJDK9. You can find the latest binaries at: >>> >>> https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.8-linux-x86_64/ >>> https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ >>> >>> I hope this helps. >>> >>> Cheers, >>> Mani >>> >>> >>> On Mon, Oct 20, 2014 at 9:36 PM, Michael Parchet >>> wrote: >>> >>>>> Hello, >>>>> >>>>> Where I could download open jdk (not oracle jdk )7, 8, or 9, for Mac, >>>> windows or Linux. >>>>> Tanks by avance for your answer >>>>> >>>>> Best regards >>>>> >>>>> mparchet >>>>> >>>>> >>> >>> >>> -- >>> @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 mparchet at sunrise.ch Tue Oct 21 13:35:16 2014 From: mparchet at sunrise.ch (Michael Parchet) Date: Tue, 21 Oct 2014 15:35:16 +0200 Subject: Downloud Openjdk 7, 8, or 9 for Linux, Mac or windows In-Reply-To: References: <8A0FF610-E6B8-4F74-86E1-01ABDCD13FF0@sunrise.ch> Message-ID: <3450653F-DEBF-4F4A-8847-B91C7201A482@sunrise.ch> Hello, I would like to use openjdk for development What's do you think ? Thanks for your answer Best regards mparchet > Le 20 oct. 2014 ? 23:06, Martijn Verburg a ?crit : > > Please note these should not be used for production, they're for R&D purposes only. You're highly recommended to go with Oracle's JDK for PRD or a supported OpenJDK binary from a vendor such as Red Hat > > Cheers, > Martijn > >> On 20 October 2014 21:49, Mani Sarkar wrote: >> Hi Michael, >> >> There's a Adopt OpenJDK CI server building a Linux version of OpenJDK 8 and >> OpenJDK9. You can find the latest binaries at: >> >> https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.8-linux-x86_64/ >> https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ >> >> I hope this helps. >> >> Cheers, >> Mani >> >> >> On Mon, Oct 20, 2014 at 9:36 PM, Michael Parchet >> wrote: >> >> > >> > > Hello, >> > > >> > > Where I could download open jdk (not oracle jdk )7, 8, or 9, for Mac, >> > windows or Linux. >> > > >> > > Tanks by avance for your answer >> > > >> > > Best regards >> > > >> > > mparchet >> > > >> > > >> > >> >> >> >> -- >> @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 neugens.limasoftware at gmail.com Tue Oct 21 14:21:40 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 21 Oct 2014 16:21:40 +0200 Subject: Downloud Openjdk 7, 8, or 9 for Linux, Mac or windows In-Reply-To: <3450653F-DEBF-4F4A-8847-B91C7201A482@sunrise.ch> References: <8A0FF610-E6B8-4F74-86E1-01ABDCD13FF0@sunrise.ch> <3450653F-DEBF-4F4A-8847-B91C7201A482@sunrise.ch> Message-ID: It really depends on your needs. You can build OpenJDK yourself, it's stable and works very well and it may be enough, or you could use a commercially supported version, which builds on top of that, like what was suggested in previous mails for example, or you could use a non paid version like what ships with most other Linux distributions. All those are really just OpenJDK with minor tweaks for the specific system they run on, and some form of community (or paid) support. For Mac and Window I don't know what distribution you can use, except again what was suggested before. If you're putting your program on a server or target production use, it makes sense to use the same OpenJDK as the one you'll use in production. In any case, this is not really a general discussion mailing list, it's more on development of OpenJDK itself, not on using OpenJDK for development (although you can ask some questions if you have troubles, they'll likely to be answered). Cheers, Mario 2014-10-21 15:35 GMT+02:00 Michael Parchet : > Hello, > > I would like to use openjdk for development > > What's do you think ? > > Thanks for your answer > > Best regards > > mparchet > > > > > >> Le 20 oct. 2014 ? 23:06, Martijn Verburg a ?crit : >> >> Please note these should not be used for production, they're for R&D purposes only. You're highly recommended to go with Oracle's JDK for PRD or a supported OpenJDK binary from a vendor such as Red Hat >> >> Cheers, >> Martijn >> >>> On 20 October 2014 21:49, Mani Sarkar wrote: >>> Hi Michael, >>> >>> There's a Adopt OpenJDK CI server building a Linux version of OpenJDK 8 and >>> OpenJDK9. You can find the latest binaries at: >>> >>> https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.8-linux-x86_64/ >>> https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ >>> >>> I hope this helps. >>> >>> Cheers, >>> Mani >>> >>> >>> On Mon, Oct 20, 2014 at 9:36 PM, Michael Parchet >>> wrote: >>> >>> > >>> > > Hello, >>> > > >>> > > Where I could download open jdk (not oracle jdk )7, 8, or 9, for Mac, >>> > windows or Linux. >>> > > >>> > > Tanks by avance for your answer >>> > > >>> > > Best regards >>> > > >>> > > mparchet >>> > > >>> > > >>> > >>> >>> >>> >>> -- >>> @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!* >> -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From tim.bell at oracle.com Tue Oct 21 20:58:06 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 21 Oct 2014 13:58:06 -0700 Subject: Update: JDK 9 Platform/Compiler upgrades at Oracle Message-ID: <5446C8DE.60102@oracle.com> All- For JDK 9 we will upgrade the build platforms and compilers used at Oracle to build the JDK. In this cycle, our target combinations are: - Linux - Oracle Linux 6.4 64-bit / GCC 4.8.2 - Mac OS X - 10.9.2 (Mavericks) 64-bit / XCode 5.1.1 / clang - Solaris X86 - 11.1 SRU19 / Oracle Solaris Studio 12.3 - Solaris SPARC - 11.1 / Oracle Solaris Studio 12.3 - Windows - Windows Server 2012 R2 64-bit / Microsoft Visual Studio 2013 For Linux and Windows, the 64-bit platform will also build 32-bit binaries. The Mac OS X and Solaris builds are already 64-bit only. Status of the project: At this point in the project, both the Solaris and Linux platforms were updated in June with b18 (Reference bug number JDK-8046474) Upgrades are currently planned for Mac OS this week (October 24). A JDK 9 build will be promoted containing only these changes. Windows will follow when the stopper bugs are fixed and we are ready. At this point, we are estimating the end of October. We will send an update to the list when we start the upgrade. It is important to keep as few things as possible moving during the special promotion cycle. We will work with the integrators to ensure no changes apart from those needed for the compiler upgrades are integrated into the master. We will notify you when the upgrade has been completed and will also let you know where to find the build that was done after the compiler upgrades. Feedback is welcome. Please send to jdk9-dev at openjdk.java.net Tim From alejandro.murillo at oracle.com Tue Oct 21 23:04:46 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 21 Oct 2014 17:04:46 -0600 Subject: jdk9-dev: HotSpot Message-ID: <5446E68E.1000805@oracle.com> jdk9-hs-2014-10-17 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/51ae5ede31b1 http://hg.openjdk.java.net/jdk9/dev/corba/rev/ffd90c81d4ef http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5c8dffe3d889 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/a9f2e9c339c9 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/84803c3be7f7 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/526d69b15ff5 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/e284f560acf6 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4dfa462ee93f Component : VM Status : Go for integration Date : 10/21/2014 at 13:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-10-17-150340.amurillo.jdk9-hs-2014-10-17-snapshot Testing: 138 new failures, 2803 known failures, 372798 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 7102541: RFE: os::set_native_thread_name() cleanups 8027428: Different conditions for printing taskqueue statistics for parallel gc, parNew and G1 8046268: compiler/whitebox/ tests fail : must be osr_compiled 8047934: Adding new API for unlocking diagnostic argument. 8049737: Contended Locking reorder and cache line bucket 8057737: Avoid G1 write barriers on newly allocated objects 8057777: Cleanup of old and unused VM interfaces 8058606: [TESTBUG] Detailed Native Memory Tracking (NMT) data is not verified as output at VM exit 8058746: escape analysis special case code for array copy broken by 7173584 8058801: G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object 8059100: SIGSEGV VirtualMemoryTracker::remove_released_region 8059604: Add CompileThresholdScaling flag to control when methods are first compiled (with and withour TieredCompilation) 8059758: Footprint regressions with JDK-8038423 8059847: complement JDK-8055286 and JDK-8056964 changes 8059904: libjvm_db.c warnings in solaris/sparc build with SS 8059924: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java: assert(Universe::verify_in_progress() || !SafepointSynchronize::is_at_safepoint()) failed: invariant 8060116: After JDK-8047976 gc/g1/TestSummarizeRSetStatsThreads fails 8060215: per-method PrintIdealGraphLevel -- Alejandro From lana.steuck at oracle.com Wed Oct 22 19:06:58 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 Oct 2014 12:06:58 -0700 (PDT) Subject: jdk9-b36: dev Message-ID: <201410221906.s9MJ6wJk023913@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/201d4e235d59 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/10fe62bc1884 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/c536541235e5 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cdcf2e599e42 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/84803c3be7f7 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/61b4c9acaa58 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/464ab653fbb1 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/ffd90c81d4ef --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8058473 client-libs "Comparison method violates its general contract" when using Clipboard JDK-8058305 client-libs BadLocationException is not thrown by javax.swing.text.View.getNextVisualPositionFrom() for invalid positions JDK-8041540 client-libs Better use of pages in font processing JDK-8041545 client-libs Better validation of generated rasters JDK-8058930 client-libs GraphicsEnvironment.getHeadlessProperty() does not work for AIX JDK-6329748 client-libs Invalid/old variable name - newModel in setModel method in JTable class JDK-8041734 client-libs JFrame in full screen mode leaves empty workspace after close JDK-8058858 client-libs JRE 8u20 crashes while using Japanese IM on Windows JDK-8042200 client-libs Less angular angles JDK-8042609 client-libs Limit splashiness of splash images JDK-8058870 client-libs Mac: JFXPanel deadlocks in jnlp mode JDK-8039515 client-libs More colorful color management JDK-8017773 client-libs OpenJDK7 returns incorrect TrueType font metrics JDK-8051857 client-libs OperationTimedOut exception inside from XToolkit.syncNativeQueue call JDK-8056914 client-libs Right Click Menu for Paste not showing after upgrading to java 7 JDK-8035162 client-libs Service printing service JDK-8058115 client-libs Some of MidiDeviceProviders do not follow the specification JDK-8058739 client-libs The test case failed as "ERROR in native method: ReleasePrimitiveArrayCritical: failed bounds check" JDK-8049346 client-libs [TESTBUG] fix the @run line of the test: jdk/test/java/awt/Focus/SortingFTP/JDK8048887.java JDK-8059219 client-libs javax.print.PrintServiceLookup allows to register null service JDK-8060485 core-libs (str) contentEquals checks the String contents twice on mismatch JDK-8047031 core-libs Add SocketPermission tests for legacy socket types JDK-8060101 core-libs AssertionError: __noSuchProperty__ placeholder called from NativeJavaImporter JDK-8042797 core-libs Avoid strawberries in LogRecord JDK-8041529 core-libs Better parameterization of parameter lists JDK-8060242 core-libs Compile-time expression evaluator wasn't seeing into ArrayBufferViews JDK-8060011 core-libs Concatenating an array and converting it to Java gives wrong result JDK-8059842 core-libs Creating symbols for declared functions shouldn't be a special case JDK-8048025 core-libs Ensure cache consistency JDK-8058892 core-libs FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl JDK-8060052 core-libs FutureTask; fix underflow when timeout = Long.MIN_VALUE JDK-8060471 core-libs GlobalConstants.findSetMethod calls DynamicLinker.getLinkedCallSiteLocation, which does Throwables JDK-8060241 core-libs Immediately invoked function expressions cause lot of deoptimization JDK-8035781 core-libs Improve equality for annotations JDK-8041564 core-libs Improved management of logger resources JDK-8050977 core-libs Java8 Javascript Nashorn exception: no current Global instance for nashorn JDK-8060688 core-libs Nashorn: Generated script class name fails --verify-code for names with special chars JDK-8061113 core-libs Nightlies secretly failing JDK-8060006 core-libs No Russian time zones mapping for Windows JDK-8044274 core-libs Proper property processing JDK-8058854 core-libs Remove dependency on dt.jar from test/tools/jar/normalize/TestNormal.java JDK-8060238 core-libs Reports for optimistic test run overwrite those for pessimistic run JDK-8012518 core-libs Turn Parser into bottom up JDK-8044627 core-libs Update JNDI to work with modules JDK-8058855 core-libs Update java.util.zip tests to work with modular image JDK-8036936 core-libs Use local locales JDK-8039509 core-libs Wrap sockets more thoroughly JDK-8039915 core-libs Wrong NumberFormat.format() HALF_UP rounding when last digit exactly at rounding position greater than 5 JDK-8058733 core-libs [TESTBUG] java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java and LFMultiThreadCachingTest.java failed on some platforms due to java.lang.VirtualMachineError JDK-8042147 core-libs test sun/util/logging/SourceClassName.java failed: Unexpected source: java.util.Currency info JDK-8058856 core-libs tools/jar/LeadingGarbage.java, introduced in JDK-8058520, fails on Windows JDK-8060120 core-svc Improve diagnostic output of StartManagementAgent test JDK-8030840 core-svc Test closed/javax/management/security/IllegalStandardMBean.java timeout intermittently JDK-8060166 core-svc javax/management/MBeanInfo/NotificationInfoTest.java fails with modular image JDK-8056167 deploy [nightly] 7u80 when set security level to LOW via deployment.properties in JCP shown MEDIUM level JDK-8041798 deploy Add certificate handling exceptions JDK-8047120 deploy Better codebase base bias JDK-8048089 deploy ClientConfig.refreshIfNeeded() doesn't restore properties with "active." prefix. JDK-8031464 deploy Debug trace controlled by SystemUtil flag not enabled when JPI_PLUGIN2_DEBUG is set JDK-8039528 deploy Direct validations more accurately JDK-8046640 deploy Document JavaScript shortcomings JDK-8022730 deploy For a non-jnlp applet when DRS blocks app it is possible to get multiple dialogs. JDK-8047105 deploy Increase integrity of applet launching JDK-8048972 deploy Launcher to achieve LEO JDK-8046651 deploy Less automatic configuration JDK-8046645 deploy More automatic configuration JDK-8046568 deploy More consistent LiveConnect processing JDK-8047135 deploy More prompt progress reporting JDK-8047836 deploy Progressive class selectivity JDK-8047110 deploy Reduce jarring nature of jar files JDK-8059484 deploy Revert JDK-8056167 fix in jdk9 repository JDK-8037417 deploy javaws fails to launch app with empty href in jnlp file if Application-Library-Allowable-Codebase is used JDK-8058697 deploy on linux, mixed code operation is blocked silently without showing mixed code dialog JDK-8044758 deploy plugin didn't use proxy to download files in javadl JDK-8047693 deploy valid cert with sandbox permission with extension shows Install button instead of Run JDK-8055667 hotspot Add new and adapt existing tests for Enable JFR Dynamically at Run Time feature JDK-8044269 hotspot Analysis of archive files JDK-8015256 hotspot Better class accessibility JDK-8046607 hotspot Code cleanup: PerfMemory::backing_store_filename() should be removed JDK-8059889 hotspot CommandLineFlagCombo and SharedBaseAddress AppCDS tests always timed out on some machine JDK-8036805 hotspot Correct linker method lookup JDK-8037326 hotspot Correctly allow access for subclasses JDK-8059466 hotspot Force young GC to initiate marking cycle when stat update is requested JDK-8041717 hotspot Issue with class file parser JDK-8055654 hotspot JFR Dynamic load JDK-8059621 hotspot JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw JDK-8036156 hotspot Limit default method hierarchy JDK-8036533 hotspot Method for correct defaults JDK-8059548 hotspot Missing @Deprecated for JFR JDK-8038903 hotspot More native monitor monitoring JDK-8059331 hotspot Print additional information for the assert in Compile::start() JDK-8059592 hotspot Recent bugfixes in ppc64 port. JDK-8047736 hotspot Remove JVM_GetClassLoader as no longer used JDK-8059559 hotspot SIGSEGV at CodeHeap::allocate(unsigned int, bool) JDK-8058298 hotspot Separate heap region iterator claim values from the data structures iterated over JDK-8055662 hotspot Update mapfile for libjfr JDK-8059595 hotspot Verifier::verify is wasting time before is_eligible_for_verification check JDK-8059299 hotspot assert(adr_type != NULL) failed: expecting TypeKlassPtr JDK-8059735 hotspot make_not_entrant_or_zombie sees zombies JDK-8055191 infrastructure Split GensrcProperties.gmk into separate modules JDK-8052096 install Dev Tasks for Linux Usability Enhancements JDK-8056083 install Illogical Messaging from AU Flow JDK-8037813 install Image on in-progress dialog is not localized JDK-8059802 install JPRT builds failed JDK-8040693 install Restart Browser checkbox Should not show up for 64bit JRE JDK-8059079 install Typo in Installer Removal Tool UE JDK-8059207 install [ 9b30 promotion ] "Go to the Java Help Center" is not correctly displayed JDK-8051701 install [de] Minor truncation in Uninstall out-of-date versions dialog JDK-8059077 install [windows XP] Installer links do not show up properly on Win XP JDK-8039193 install switch to new Version classes JDK-8059083 other-libs Remove jdk.compact3 from modules.xml JDK-8038913 security-libs Bolster XML support JDK-8032573 security-libs CertificateFactory.getInstance("X.509").generateCertificates(InputStream) does not throw CertificateException for invalid input JDK-8037846 security-libs Ensure streaming of input cipher streams JDK-8029659 security-libs Keytool, print key algorithm of certificate or key entry JDK-8038908 security-libs Make Signature more robust JDK-8048052 security-libs Permission tests for "setFactory" JDK-8037066 security-libs Secure transport layer JDK-8044215 security-libs Unable to initiate SpNego using a S4U2Proxy GSSCredential (Krb5ProxyCredential) JDK-8038364 security-libs Use certificate exceptions correctly JDK-8060249 tools Backout fix for JDK-8058243 JDK-8058199 tools Code generation problem with javac skipping a checkcast instruction JDK-8060234 tools Fix push for JDK-8058243 JDK-8058410 tools Group 10b: golden files for tests in tools/javac dir JDK-8040131 tools Implement classfile test for LineNumberTable attribute JDK-8054956 tools Javac reports wrong error offset for unknown identifier of annotation element/value pair JDK-8058243 tools Reduce size of bytecode for large switch statements JDK-8060043 tools Rename Locations.Path to Locations.SearchPath JDK-8058511 tools StackOverflowError at com.sun.tools.javac.code.Types.lub JDK-8039533 xml Higher resolution resolvers JDK-8036951 xml Xerces Update: XMLSchemaValidator.java and XMLSchemaLoader.java From mark.reinhold at oracle.com Thu Oct 23 22:15:55 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 23 Oct 2014 15:15:55 -0700 Subject: JEPs proposed to target JDK 9 Message-ID: <20141023151555.106363@eggemoggin.niobe.net> For your consideration: The following JEPs have been placed into the "Proposed to Target" state by their respective owners after discussion and review. 158: Unified JVM Logging http://openjdk.java.net/jeps/158 211: Elide Deprecation Warnings on Import Statements http://openjdk.java.net/jeps/211 212: Resolve Lint and Doclint Warnings http://openjdk.java.net/jeps/212 213: Milling Project Coin http://openjdk.java.net/jeps/213 214: Remove GC Combinations Deprecated in JDK 8 http://openjdk.java.net/jeps/214 216: Process Import Statements Correctly http://openjdk.java.net/jeps/216 Feedback is more than welcome, as are reasoned objections. If no such objections are raised in one week's time (i.e., by 2014/10/30 23:00 UTC), 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 david.lloyd at redhat.com Fri Oct 24 15:06:38 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 24 Oct 2014 10:06:38 -0500 Subject: JEPs proposed to target JDK 9 In-Reply-To: <20141023151555.106363@eggemoggin.niobe.net> References: <20141023151555.106363@eggemoggin.niobe.net> Message-ID: <544A6AFE.8090702@redhat.com> On 10/23/2014 05:15 PM, mark.reinhold at oracle.com wrote: > For your consideration: The following JEPs have been placed into the > "Proposed to Target" state by their respective owners after discussion > and review. > > 158: Unified JVM Logging http://openjdk.java.net/jeps/158 > 211: Elide Deprecation Warnings on Import Statements http://openjdk.java.net/jeps/211 > 212: Resolve Lint and Doclint Warnings http://openjdk.java.net/jeps/212 > 213: Milling Project Coin http://openjdk.java.net/jeps/213 > 214: Remove GC Combinations Deprecated in JDK 8 http://openjdk.java.net/jeps/214 > 216: Process Import Statements Correctly http://openjdk.java.net/jeps/216 > > Feedback is more than welcome, as are reasoned objections. If no such > objections are raised in one week's time (i.e., by 2014/10/30 23:00 UTC), > 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. I still object to removing _ (one of only two legal single-symbol identifiers in Java) as an identifier. I believe that if a special identifier is desired, a new, previously unused character should be used instead, such as #. This has the advantage of not breaking existing frameworks (including two of my own), as well as being visually distinct. I do not believe that referencing existing non-Java languages is a valid reason for doing this. Yes it might improve initial recognition ever so slightly. But 5 years down the line, if you choose # instead, it will be just as clear (if not more so) as to what it means (since you won't have the baggage of other languages' interpretations of that symbol to confuse matters; as an example, we still see users come into ##java IRC expecting generics<> to work like C++ templates because they look similar). The rest of the changes look great - much needed improvements. -- - DML From neugens.limasoftware at gmail.com Fri Oct 24 15:28:28 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 24 Oct 2014 17:28:28 +0200 Subject: JEPs proposed to target JDK 9 In-Reply-To: <544A6AFE.8090702@redhat.com> References: <20141023151555.106363@eggemoggin.niobe.net> <544A6AFE.8090702@redhat.com> Message-ID: I agree with David, _ should remain. Cheers, Mario 2014-10-24 17:06 GMT+02:00 David M. Lloyd : > On 10/23/2014 05:15 PM, mark.reinhold at oracle.com wrote: >> >> For your consideration: The following JEPs have been placed into the >> "Proposed to Target" state by their respective owners after discussion >> and review. >> >> 158: Unified JVM Logging >> http://openjdk.java.net/jeps/158 >> 211: Elide Deprecation Warnings on Import Statements >> http://openjdk.java.net/jeps/211 >> 212: Resolve Lint and Doclint Warnings >> http://openjdk.java.net/jeps/212 >> 213: Milling Project Coin >> http://openjdk.java.net/jeps/213 >> 214: Remove GC Combinations Deprecated in JDK 8 >> http://openjdk.java.net/jeps/214 >> 216: Process Import Statements Correctly >> http://openjdk.java.net/jeps/216 >> >> Feedback is more than welcome, as are reasoned objections. If no such >> objections are raised in one week's time (i.e., by 2014/10/30 23:00 UTC), >> 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. > > > I still object to removing _ (one of only two legal single-symbol > identifiers in Java) as an identifier. I believe that if a special > identifier is desired, a new, previously unused character should be used > instead, such as #. This has the advantage of not breaking existing > frameworks (including two of my own), as well as being visually distinct. > > I do not believe that referencing existing non-Java languages is a valid > reason for doing this. Yes it might improve initial recognition ever so > slightly. But 5 years down the line, if you choose # instead, it will be > just as clear (if not more so) as to what it means (since you won't have the > baggage of other languages' interpretations of that symbol to confuse > matters; as an example, we still see users come into ##java IRC expecting > generics<> to work like C++ templates because they look similar). > > The rest of the changes look great - much needed improvements. > -- > - DML -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From brian.goetz at oracle.com Fri Oct 24 16:01:44 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 24 Oct 2014 12:01:44 -0400 Subject: JEPs proposed to target JDK 9 In-Reply-To: <544A6AFE.8090702@redhat.com> References: <20141023151555.106363@eggemoggin.niobe.net> <544A6AFE.8090702@redhat.com> Message-ID: <544A77E8.6090608@oracle.com> >> Feedback is more than welcome, as are reasoned objections. If no such >> objections are raised in one week's time (i.e., by 2014/10/30 23:00 UTC), >> 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. > > I still object to removing _ (one of only two legal single-symbol > identifiers in Java) as an identifier. I believe that if a special > identifier is desired, a new, previously unused character should be used > instead, such as #. This has the advantage of not breaking existing > frameworks (including two of my own), as well as being visually distinct. I realize that you don't like this choice; you were even in the room when the decision was made (you were on the JSR-335 EG), and you raised this concern at the time. And it was considered, and discussed. Of course, not everyone will agree with the decision; that's what happens when you have 9 million opinions, especially on something as opinion-prone as syntax. > I do not believe that referencing existing non-Java languages is a valid > reason for doing this. This is a valid opinion, and certainly "but language X does it this way" is not a strong enough reason to do anything. However, the use of _ as an "I don't care" token is nearly universal in languages supporting pattern-matching, and we concluded that its eventual possible use for such features outweighed the very small number of "but my codebase already uses it!" concerns. (Observation: this is one of the very few times we've made the conscious choice to make an incompatible language change for the sake of making things better in the long run. When we do this, people complain; when we don't do this, people complain.) So, I understand your concern, and I'm not saying your concern is totally invalid (every issue has many sides), but you are not now bringing any *new* information to the discussion -- this concern was raised and understood and considered at the time the decision was made, and nothing has really changed since then, so I see no reason to to pull the emergency brake cord on this train-already-in-motion. From jonathan.gibbons at oracle.com Fri Oct 24 18:38:46 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 24 Oct 2014 11:38:46 -0700 Subject: Result: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <5435EAE2.2030605@oracle.com> References: <5435EAE2.2030605@oracle.com> Message-ID: <544A9CB6.2040802@oracle.com> |Voting for Jan Lahoda [1] is now closed. Yes: 19 (not counting one invalid vote) Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Jonathan Gibbons [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001414.html| From serguei.spitsyn at oracle.com Fri Oct 24 20:20:07 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Oct 2014 13:20:07 -0700 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <543C591E.8010602@oracle.com> References: <543C591E.8010602@oracle.com> Message-ID: <544AB477.4000204@oracle.com> Hi Yumin, Below is some analysis to make sure I understand the test scenario correctly. The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. At each iteration it does: - creates and starts a new TestThread - loads TestClass1 with the current class loader: ParallelTransformerLoaderAgent.getClassLoader() - changes the current class loader with new one: ParallelTransformerLoaderAgent.generateNewClassLoader() The TestThread loads the TestClass2 concurrently with the main thread. At the CFLH events, the ParallelTransformerLoaderAgent does the class retransformation. If the thread loading the class is not "main", it loads the class TestClass3 with the current class loader ParallelTransformerLoaderAgent.getClassLoader(). Sometimes, the TestClass2 and TestClass3 are loaded by the same class loader recursively. It happens if the class loader has not been changed between loading TestClass2 and TestClass3 classes. I'm not convinced yet the test is incorrect. And it is not clear why do we get a ClassCircularityError. Please, let me know if the above understanding is wrong. I also see the reply from David and share his concerns. It is not clear if this failure is a regression. Did we observe this issue before? If - NOT then when and why had this failure started to appear? Unfortunately, it is impossible to look at the test run history at the moment. The Aurora is at a maintenance. Thanks, Serguei On 10/13/14 3:58 PM, Yumin Qi wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8038468 > webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ > > the bug marked as confidential so post the webrev internally. > > Problem: The test case tries to load a class from the same jar via > agent in the middle of loading another class from the jar via same > class loader in same thread. The call happens in transform which is a > rare case --- in middle of loading class, loading another class. The > result is a CircularityError. When first class is in loading, in vm we > put JarLoader$2 on place holder table, then we start the defineClass, > which calls transform, begins loading the second class so go along the > same routine for loading JarLoader$2 first, found it already in > placeholder table. A CircularityError is thrown. > Fix: The test case should not call loading class with same class > loader in same thread from same jar in 'transform' method. I modify it > loading with system class loader and we expect see > ClassNotFoundException. Detail see bug comments. > > Thanks > Yumin * From mparchet at sunrise.ch Fri Oct 24 21:12:25 2014 From: mparchet at sunrise.ch (Michael Parchet) Date: Fri, 24 Oct 2014 23:12:25 +0200 Subject: How to test interactive mode ? Message-ID: <39DD7DE7-B852-4179-BC00-DE00ADF9C6A7@sunrise.ch> Hello, In pass I voted yes for an interactive mode implementation like Python I would like test it with polarszs or eclipse ? Is it possible ? Thanks by advanced for your answer. Best regards mparchet From yumin.qi at oracle.com Fri Oct 24 23:08:55 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 24 Oct 2014 16:08:55 -0700 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <544AB477.4000204@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> Message-ID: <544ADC07.6080904@oracle.com> Serguei, Thanks for your comments. This test happens intermittently, but now it can repeat with 8/9. Loading TestClass1 in main thread while loading TestClass2 in TestThread in parallel. They both will call transform since TestClass[1-3] are loaded via agent. When loading TestClass2, it will call loading TestClass3 in TestThread. Note in the main thread, for loop: for (int i = 0; i < kNumIterations; i++) { // load some classes from multiple threads (this thread and one other) Thread testThread = new TestThread(2); testThread.start(); loadClasses(1); // log that it completed and reset for the next iteration testThread.join(); System.out.print("."); ParallelTransformerLoaderAgent.generateNewClassLoader(); } The loader got renewed after testThread.join(). So both threads are using the exact same class loader. After create a new class loader, next loop will use the loader. This is why quite often on the stack trace we can see it resolves JarLoader$2. I am not quite understand the test case either. Loading TestClass3 inside transform using the same classloader will cause call to transform again and form a circle. Nonetheless, if we see TestClass2 already loaded, the loop will end but that still is a risk. Thanks Yumin On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: > Hi Yumin, > > Below is some analysis to make sure I understand the test scenario > correctly. > > The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. > At each iteration it does: > - creates and starts a new TestThread > - loads TestClass1 with the current class loader: > ParallelTransformerLoaderAgent.getClassLoader() > - changes the current class loader with new one: > ParallelTransformerLoaderAgent.generateNewClassLoader() > > The TestThread loads the TestClass2 concurrently with the main thread. > > At the CFLH events, the ParallelTransformerLoaderAgent does the class > retransformation. > If the thread loading the class is not "main", it loads the class > TestClass3 > with the current class loader > ParallelTransformerLoaderAgent.getClassLoader(). > > Sometimes, the TestClass2 and TestClass3 are loaded by the same class > loader recursively. > It happens if the class loader has not been changed between loading > TestClass2 and TestClass3 classes. > > I'm not convinced yet the test is incorrect. > And it is not clear why do we get a ClassCircularityError. > > Please, let me know if the above understanding is wrong. > I also see the reply from David and share his concerns. > > It is not clear if this failure is a regression. > Did we observe this issue before? > If - NOT then when and why had this failure started to appear? > > Unfortunately, it is impossible to look at the test run history at the > moment. > The Aurora is at a maintenance. > > Thanks, > Serguei > > On 10/13/14 3:58 PM, Yumin Qi wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >> >> the bug marked as confidential so post the webrev internally. >> >> Problem: The test case tries to load a class from the same jar via >> agent in the middle of loading another class from the jar via same >> class loader in same thread. The call happens in transform which is a >> rare case --- in middle of loading class, loading another class. The >> result is a CircularityError. When first class is in loading, in vm >> we put JarLoader$2 on place holder table, then we start the >> defineClass, which calls transform, begins loading the second class >> so go along the same routine for loading JarLoader$2 first, found it >> already in placeholder table. A CircularityError is thrown. >> Fix: The test case should not call loading class with same class >> loader in same thread from same jar in 'transform' method. I modify >> it loading with system class loader and we expect see >> ClassNotFoundException. Detail see bug comments. >> >> Thanks >> Yumin * > From serguei.spitsyn at oracle.com Fri Oct 24 23:57:30 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Oct 2014 16:57:30 -0700 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <544ADC07.6080904@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> <544ADC07.6080904@oracle.com> Message-ID: <544AE76A.9030701@oracle.com> Yumin, On 10/24/14 4:08 PM, Yumin Qi wrote: > Serguei, > > Thanks for your comments. > This test happens intermittently, but now it can repeat with 8/9. > Loading TestClass1 in main thread while loading TestClass2 in > TestThread in parallel. They both will call transform since > TestClass[1-3] are loaded via agent. When loading TestClass2, it will > call loading TestClass3 in TestThread. > Note in the main thread, for loop: > > for (int i = 0; i < kNumIterations; i++) > { > // load some classes from multiple threads > (this thread and one other) > Thread testThread = new TestThread(2); > testThread.start(); > loadClasses(1); > > // log that it completed and reset for the > next iteration > testThread.join(); > System.out.print("."); > ParallelTransformerLoaderAgent.generateNewClassLoader(); > } > > The loader got renewed after testThread.join(). So both threads are > using the exact same class loader. You are right, thanks. It means that all three classes (TesClass1, TestClass2 and TestClass3) are loaded by the same class loader in each iteration. However, I see more cases when the TestClass3 gets loaded. It happens in a CFLH event when any other class (not TestClass*) in the system is loaded. The class loading thread can be any, not only "main" or "TestClass" thread. I suspect this test case mostly targets class loading that happens on other threads. It is because of the lines: // In 160_03 and older, transform() is called // with the "system_loader_lock" held and that // prevents the bootstrap class loaded from // running in parallel. If we add a slight sleep // delay here when the transform() call is not // main or TestThread, then the deadlock in // 160_03 and older is much more reproducible. if (!tName.equals("main") && !tName.equals("TestThread")) { System.out.println("Thread '" + tName + "' has called transform()"); try { Thread.sleep(500); } catch (InterruptedException ie) { } } What about the following? In the ParallelTransformerLoaderAgent.java make this change: if (!tName.equals("main")) => if (tName.equals("TestThread")) Does such updated test still failing? > After create a new class loader, next loop will use the loader. This > is why quite often on the stack trace we can see it resolves JarLoader$2. > > I am not quite understand the test case either. Loading TestClass3 > inside transform using the same classloader will cause call to > transform again and form a circle. Nonetheless, if we see TestClass2 > already loaded, the loop will end but that still is a risk. In fact, I don't like that the test loads the class TestClass3 at the TestClass3 CFLH event. However, it is interesting to know why we did not see (is it the case?) this issue before. Also, it is interesting why the test stops failing with you fix (replacing loader with SystemClassLoader). The test case was added by Dan. We may want to ask him to clarify the test case purpose. (added Dan to the to-list) Thanks, Serguei > > Thanks > Yumin > > On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: >> Hi Yumin, >> >> Below is some analysis to make sure I understand the test scenario >> correctly. >> >> The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. >> At each iteration it does: >> - creates and starts a new TestThread >> - loads TestClass1 with the current class loader: >> ParallelTransformerLoaderAgent.getClassLoader() >> - changes the current class loader with new one: >> ParallelTransformerLoaderAgent.generateNewClassLoader() >> >> The TestThread loads the TestClass2 concurrently with the main thread. >> >> At the CFLH events, the ParallelTransformerLoaderAgent does the class >> retransformation. >> If the thread loading the class is not "main", it loads the class >> TestClass3 >> with the current class loader >> ParallelTransformerLoaderAgent.getClassLoader(). >> >> Sometimes, the TestClass2 and TestClass3 are loaded by the same class >> loader recursively. >> It happens if the class loader has not been changed between loading >> TestClass2 and TestClass3 classes. >> >> I'm not convinced yet the test is incorrect. >> And it is not clear why do we get a ClassCircularityError. >> >> Please, let me know if the above understanding is wrong. >> I also see the reply from David and share his concerns. >> >> It is not clear if this failure is a regression. >> Did we observe this issue before? >> If - NOT then when and why had this failure started to appear? >> >> Unfortunately, it is impossible to look at the test run history at >> the moment. >> The Aurora is at a maintenance. >> >> Thanks, >> Serguei >> >> On 10/13/14 3:58 PM, Yumin Qi wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >>> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >>> >>> the bug marked as confidential so post the webrev internally. >>> >>> Problem: The test case tries to load a class from the same jar via >>> agent in the middle of loading another class from the jar via same >>> class loader in same thread. The call happens in transform which is >>> a rare case --- in middle of loading class, loading another class. >>> The result is a CircularityError. When first class is in loading, in >>> vm we put JarLoader$2 on place holder table, then we start the >>> defineClass, which calls transform, begins loading the second class >>> so go along the same routine for loading JarLoader$2 first, found it >>> already in placeholder table. A CircularityError is thrown. >>> Fix: The test case should not call loading class with same class >>> loader in same thread from same jar in 'transform' method. I modify >>> it loading with system class loader and we expect see >>> ClassNotFoundException. Detail see bug comments. >>> >>> Thanks >>> Yumin * >> > From serguei.spitsyn at oracle.com Sat Oct 25 00:39:19 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Oct 2014 17:39:19 -0700 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <544AED82.7070706@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> <544ADC07.6080904@oracle.com> <544AE76A.9030701@oracle.com> <544AED82.7070706@oracle.com> Message-ID: <544AF137.90105@oracle.com> Yumin, Thank you for answering my questions. Thanks, Serguei On 10/24/14 5:23 PM, Yumin Qi wrote: > > On 10/24/2014 4:57 PM, serguei.spitsyn at oracle.com wrote: >> Yumin, >> >> On 10/24/14 4:08 PM, Yumin Qi wrote: >>> Serguei, >>> >>> Thanks for your comments. >>> This test happens intermittently, but now it can repeat with 8/9. >>> Loading TestClass1 in main thread while loading TestClass2 in >>> TestThread in parallel. They both will call transform since >>> TestClass[1-3] are loaded via agent. When loading TestClass2, it >>> will call loading TestClass3 in TestThread. >>> Note in the main thread, for loop: >>> >>> for (int i = 0; i < kNumIterations; i++) >>> { >>> // load some classes from multiple threads >>> (this thread and one other) >>> Thread testThread = new TestThread(2); >>> testThread.start(); >>> loadClasses(1); >>> >>> // log that it completed and reset for the >>> next iteration >>> testThread.join(); >>> System.out.print("."); >>> ParallelTransformerLoaderAgent.generateNewClassLoader(); >>> } >>> >>> The loader got renewed after testThread.join(). So both threads are >>> using the exact same class loader. >> >> You are right, thanks. >> It means that all three classes (TesClass1, TestClass2 and TestClass3) >> are loaded by the same class loader in each iteration. >> >> However, I see more cases when the TestClass3 gets loaded. >> It happens in a CFLH event when any other class (not TestClass*) in >> the system is loaded. >> The class loading thread can be any, not only "main" or "TestClass" >> thread. >> I suspect this test case mostly targets class loading that happens on >> other threads. >> It is because of the lines: >> // In 160_03 and older, transform() is called >> // with the "system_loader_lock" held and that >> // prevents the bootstrap class loaded from >> // running in parallel. If we add a slight sleep >> // delay here when the transform() call is not >> // main or TestThread, then the deadlock in >> // 160_03 and older is much more reproducible. >> if (!tName.equals("main") && >> !tName.equals("TestThread")) { >> System.out.println("Thread '" + tName + >> "' has called transform()"); >> try { >> Thread.sleep(500); >> } catch (InterruptedException ie) { >> } >> } >> >> What about the following? >> >> In the ParallelTransformerLoaderAgent.java make this change: >> if (!tName.equals("main")) >> => if (tName.equals("TestThread")) >> >> Does such updated test still failing? >> > It still fails though it takes longer time to fail. The other > question, from D. H. is that the exception stack trace is from 'main' > thread. That still not known how that happened. > >>> After create a new class loader, next loop will use the loader. This >>> is why quite often on the stack trace we can see it resolves >>> JarLoader$2. >>> >>> I am not quite understand the test case either. Loading TestClass3 >>> inside transform using the same classloader will cause call to >>> transform again and form a circle. Nonetheless, if we see TestClass2 >>> already loaded, the loop will end but that still is a risk. >> >> In fact, I don't like that the test loads the class TestClass3 at the >> TestClass3 CFLH event. >> However, it is interesting to know why we did not see (is it the >> case?) this issue before. >> Also, it is interesting why the test stops failing with you fix >> (replacing loader with SystemClassLoader). >> > Since TestClass[1-3] are designed loaded by custom class loader, the > system class loader will not find it --- ClassNotFoundException thrown. > >> The test case was added by Dan. >> We may want to ask him to clarify the test case purpose. >> (added Dan to the to-list) >> > Looking forward to getting Dan's comments. > >> Thanks, >> Serguei >> >>> >>> Thanks >>> Yumin >>> >>> On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Yumin, >>>> >>>> Below is some analysis to make sure I understand the test scenario >>>> correctly. >>>> >>>> The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. >>>> At each iteration it does: >>>> - creates and starts a new TestThread >>>> - loads TestClass1 with the current class loader: >>>> ParallelTransformerLoaderAgent.getClassLoader() >>>> - changes the current class loader with new one: >>>> ParallelTransformerLoaderAgent.generateNewClassLoader() >>>> >>>> The TestThread loads the TestClass2 concurrently with the main thread. >>>> >>>> At the CFLH events, the ParallelTransformerLoaderAgent does the >>>> class retransformation. >>>> If the thread loading the class is not "main", it loads the class >>>> TestClass3 >>>> with the current class loader >>>> ParallelTransformerLoaderAgent.getClassLoader(). >>>> >>>> Sometimes, the TestClass2 and TestClass3 are loaded by the same >>>> class loader recursively. >>>> It happens if the class loader has not been changed between loading >>>> TestClass2 and TestClass3 classes. >>>> >>>> I'm not convinced yet the test is incorrect. >>>> And it is not clear why do we get a ClassCircularityError. >>>> >>>> Please, let me know if the above understanding is wrong. >>>> I also see the reply from David and share his concerns. >>>> >>>> It is not clear if this failure is a regression. >>>> Did we observe this issue before? >>>> If - NOT then when and why had this failure started to appear? >>>> >>>> Unfortunately, it is impossible to look at the test run history at >>>> the moment. >>>> The Aurora is at a maintenance. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/13/14 3:58 PM, Yumin Qi wrote: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >>>>> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >>>>> >>>>> the bug marked as confidential so post the webrev internally. >>>>> >>>>> Problem: The test case tries to load a class from the same jar via >>>>> agent in the middle of loading another class from the jar via same >>>>> class loader in same thread. The call happens in transform which >>>>> is a rare case --- in middle of loading class, loading another >>>>> class. The result is a CircularityError. When first class is in >>>>> loading, in vm we put JarLoader$2 on place holder table, then we >>>>> start the defineClass, which calls transform, begins loading the >>>>> second class so go along the same routine for loading JarLoader$2 >>>>> first, found it already in placeholder table. A CircularityError >>>>> is thrown. >>>>> Fix: The test case should not call loading class with same class >>>>> loader in same thread from same jar in 'transform' method. I >>>>> modify it loading with system class loader and we expect see >>>>> ClassNotFoundException. Detail see bug comments. >>>>> >>>>> Thanks >>>>> Yumin * >>>> >>> >> > From yumin.qi at oracle.com Sat Oct 25 00:23:30 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 24 Oct 2014 17:23:30 -0700 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <544AE76A.9030701@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> <544ADC07.6080904@oracle.com> <544AE76A.9030701@oracle.com> Message-ID: <544AED82.7070706@oracle.com> On 10/24/2014 4:57 PM, serguei.spitsyn at oracle.com wrote: > Yumin, > > On 10/24/14 4:08 PM, Yumin Qi wrote: >> Serguei, >> >> Thanks for your comments. >> This test happens intermittently, but now it can repeat with 8/9. >> Loading TestClass1 in main thread while loading TestClass2 in >> TestThread in parallel. They both will call transform since >> TestClass[1-3] are loaded via agent. When loading TestClass2, it will >> call loading TestClass3 in TestThread. >> Note in the main thread, for loop: >> >> for (int i = 0; i < kNumIterations; i++) >> { >> // load some classes from multiple threads >> (this thread and one other) >> Thread testThread = new TestThread(2); >> testThread.start(); >> loadClasses(1); >> >> // log that it completed and reset for the >> next iteration >> testThread.join(); >> System.out.print("."); >> ParallelTransformerLoaderAgent.generateNewClassLoader(); >> } >> >> The loader got renewed after testThread.join(). So both threads are >> using the exact same class loader. > > You are right, thanks. > It means that all three classes (TesClass1, TestClass2 and TestClass3) > are loaded by the same class loader in each iteration. > > However, I see more cases when the TestClass3 gets loaded. > It happens in a CFLH event when any other class (not TestClass*) in > the system is loaded. > The class loading thread can be any, not only "main" or "TestClass" > thread. > I suspect this test case mostly targets class loading that happens on > other threads. > It is because of the lines: > // In 160_03 and older, transform() is called > // with the "system_loader_lock" held and that > // prevents the bootstrap class loaded from > // running in parallel. If we add a slight sleep > // delay here when the transform() call is not > // main or TestThread, then the deadlock in > // 160_03 and older is much more reproducible. > if (!tName.equals("main") && > !tName.equals("TestThread")) { > System.out.println("Thread '" + tName + > "' has called transform()"); > try { > Thread.sleep(500); > } catch (InterruptedException ie) { > } > } > > What about the following? > > In the ParallelTransformerLoaderAgent.java make this change: > if (!tName.equals("main")) > => if (tName.equals("TestThread")) > > Does such updated test still failing? > It still fails though it takes longer time to fail. The other question, from D. H. is that the exception stack trace is from 'main' thread. That still not known how that happened. >> After create a new class loader, next loop will use the loader. This >> is why quite often on the stack trace we can see it resolves JarLoader$2. >> >> I am not quite understand the test case either. Loading TestClass3 >> inside transform using the same classloader will cause call to >> transform again and form a circle. Nonetheless, if we see TestClass2 >> already loaded, the loop will end but that still is a risk. > > In fact, I don't like that the test loads the class TestClass3 at the > TestClass3 CFLH event. > However, it is interesting to know why we did not see (is it the > case?) this issue before. > Also, it is interesting why the test stops failing with you fix > (replacing loader with SystemClassLoader). > Since TestClass[1-3] are designed loaded by custom class loader, the system class loader will not find it --- ClassNotFoundException thrown. > The test case was added by Dan. > We may want to ask him to clarify the test case purpose. > (added Dan to the to-list) > Looking forward to getting Dan's comments. > Thanks, > Serguei > >> >> Thanks >> Yumin >> >> On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Yumin, >>> >>> Below is some analysis to make sure I understand the test scenario >>> correctly. >>> >>> The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. >>> At each iteration it does: >>> - creates and starts a new TestThread >>> - loads TestClass1 with the current class loader: >>> ParallelTransformerLoaderAgent.getClassLoader() >>> - changes the current class loader with new one: >>> ParallelTransformerLoaderAgent.generateNewClassLoader() >>> >>> The TestThread loads the TestClass2 concurrently with the main thread. >>> >>> At the CFLH events, the ParallelTransformerLoaderAgent does the >>> class retransformation. >>> If the thread loading the class is not "main", it loads the class >>> TestClass3 >>> with the current class loader >>> ParallelTransformerLoaderAgent.getClassLoader(). >>> >>> Sometimes, the TestClass2 and TestClass3 are loaded by the same >>> class loader recursively. >>> It happens if the class loader has not been changed between loading >>> TestClass2 and TestClass3 classes. >>> >>> I'm not convinced yet the test is incorrect. >>> And it is not clear why do we get a ClassCircularityError. >>> >>> Please, let me know if the above understanding is wrong. >>> I also see the reply from David and share his concerns. >>> >>> It is not clear if this failure is a regression. >>> Did we observe this issue before? >>> If - NOT then when and why had this failure started to appear? >>> >>> Unfortunately, it is impossible to look at the test run history at >>> the moment. >>> The Aurora is at a maintenance. >>> >>> Thanks, >>> Serguei >>> >>> On 10/13/14 3:58 PM, Yumin Qi wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >>>> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >>>> >>>> the bug marked as confidential so post the webrev internally. >>>> >>>> Problem: The test case tries to load a class from the same jar via >>>> agent in the middle of loading another class from the jar via same >>>> class loader in same thread. The call happens in transform which is >>>> a rare case --- in middle of loading class, loading another class. >>>> The result is a CircularityError. When first class is in loading, >>>> in vm we put JarLoader$2 on place holder table, then we start the >>>> defineClass, which calls transform, begins loading the second class >>>> so go along the same routine for loading JarLoader$2 first, found >>>> it already in placeholder table. A CircularityError is thrown. >>>> Fix: The test case should not call loading class with same class >>>> loader in same thread from same jar in 'transform' method. I modify >>>> it loading with system class loader and we expect see >>>> ClassNotFoundException. Detail see bug comments. >>>> >>>> Thanks >>>> Yumin * >>> >> > From david.holmes at oracle.com Sun Oct 26 22:42:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Oct 2014 08:42:12 +1000 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <544AED82.7070706@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> <544ADC07.6080904@oracle.com> <544AE76A.9030701@oracle.com> <544AED82.7070706@oracle.com> Message-ID: <544D78C4.4090703@oracle.com> On 25/10/2014 10:23 AM, Yumin Qi wrote: > > On 10/24/2014 4:57 PM, serguei.spitsyn at oracle.com wrote: >> Yumin, >> >> On 10/24/14 4:08 PM, Yumin Qi wrote: >>> Serguei, >>> >>> Thanks for your comments. >>> This test happens intermittently, but now it can repeat with 8/9. >>> Loading TestClass1 in main thread while loading TestClass2 in >>> TestThread in parallel. They both will call transform since >>> TestClass[1-3] are loaded via agent. When loading TestClass2, it will >>> call loading TestClass3 in TestThread. >>> Note in the main thread, for loop: >>> >>> for (int i = 0; i < kNumIterations; i++) >>> { >>> // load some classes from multiple threads >>> (this thread and one other) >>> Thread testThread = new TestThread(2); >>> testThread.start(); >>> loadClasses(1); >>> >>> // log that it completed and reset for the >>> next iteration >>> testThread.join(); >>> System.out.print("."); >>> ParallelTransformerLoaderAgent.generateNewClassLoader(); >>> } >>> >>> The loader got renewed after testThread.join(). So both threads are >>> using the exact same class loader. >> >> You are right, thanks. >> It means that all three classes (TesClass1, TestClass2 and TestClass3) >> are loaded by the same class loader in each iteration. >> >> However, I see more cases when the TestClass3 gets loaded. >> It happens in a CFLH event when any other class (not TestClass*) in >> the system is loaded. >> The class loading thread can be any, not only "main" or "TestClass" >> thread. >> I suspect this test case mostly targets class loading that happens on >> other threads. >> It is because of the lines: >> // In 160_03 and older, transform() is called >> // with the "system_loader_lock" held and that >> // prevents the bootstrap class loaded from >> // running in parallel. If we add a slight sleep >> // delay here when the transform() call is not >> // main or TestThread, then the deadlock in >> // 160_03 and older is much more reproducible. >> if (!tName.equals("main") && >> !tName.equals("TestThread")) { >> System.out.println("Thread '" + tName + >> "' has called transform()"); >> try { >> Thread.sleep(500); >> } catch (InterruptedException ie) { >> } >> } >> >> What about the following? >> >> In the ParallelTransformerLoaderAgent.java make this change: >> if (!tName.equals("main")) >> => if (tName.equals("TestThread")) >> >> Does such updated test still failing? >> > It still fails though it takes longer time to fail. The other question, > from D. H. is that the exception stack trace is from 'main' thread. That > still not known how that happened. It happens because the exception in thrown in the main thread - and that to me is the big mystery. I've previously expressed this in email to Yumin but have added it to the bug report and can add it here: I've had a look at the test code and the bug report and I'm still quite confused by the analysis. First I think we can disregard the DestroyJavaVM part of this. The main thread encounters the CCE and so main terminates and we see the "Exception in thread "main" ..." on stderr. That thread detaches and re-attaches as the DestroyJavaVM thread. When the TestThread terminates the DestroyJavaVMThread initiates shutdown and that causes loading of the Shutdown class and that triggers execution of transform(). But this is all well after the CCE happens in main. The problem occurs when we are loading the system classes. I can imagine that the main thread is trying to execute loadClasses(1) which will use the agent defined classloader to try and load TestClass1. In invoking Class.forName it seems that some of the URLClassLoader internal classes - ie JarLoader$2 - still need to be loaded and so we start to load those. Concurrently the TestThread wants to load TestClass2 and so it too has to ensure that all the URLClassLoader classes are loaded, but at some point the transform() is encountered and so it then starts to load TestClass3. This in turn still needs all of the URLClassLoader classes to complete loading. I'm unclear at what point in the loading process transform() gets invoked, but I can easily imagine a cycle (or even an infinite loop!) developing here. But the CCE occurs in the main thread and the main thread doesn't load anything via transform() so I am at a loss to understand how it can encounter CCE. --- There are numerous arbitrary changes that can be made to the test to avoid the problem, but that doesn't explain why the problem is occurring in the first place. David ----- > >>> After create a new class loader, next loop will use the loader. This >>> is why quite often on the stack trace we can see it resolves >>> JarLoader$2. >>> >>> I am not quite understand the test case either. Loading TestClass3 >>> inside transform using the same classloader will cause call to >>> transform again and form a circle. Nonetheless, if we see TestClass2 >>> already loaded, the loop will end but that still is a risk. >> >> In fact, I don't like that the test loads the class TestClass3 at the >> TestClass3 CFLH event. >> However, it is interesting to know why we did not see (is it the >> case?) this issue before. >> Also, it is interesting why the test stops failing with you fix >> (replacing loader with SystemClassLoader). >> > Since TestClass[1-3] are designed loaded by custom class loader, the > system class loader will not find it --- ClassNotFoundException thrown. > >> The test case was added by Dan. >> We may want to ask him to clarify the test case purpose. >> (added Dan to the to-list) >> > Looking forward to getting Dan's comments. > >> Thanks, >> Serguei >> >>> >>> Thanks >>> Yumin >>> >>> On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Yumin, >>>> >>>> Below is some analysis to make sure I understand the test scenario >>>> correctly. >>>> >>>> The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. >>>> At each iteration it does: >>>> - creates and starts a new TestThread >>>> - loads TestClass1 with the current class loader: >>>> ParallelTransformerLoaderAgent.getClassLoader() >>>> - changes the current class loader with new one: >>>> ParallelTransformerLoaderAgent.generateNewClassLoader() >>>> >>>> The TestThread loads the TestClass2 concurrently with the main thread. >>>> >>>> At the CFLH events, the ParallelTransformerLoaderAgent does the >>>> class retransformation. >>>> If the thread loading the class is not "main", it loads the class >>>> TestClass3 >>>> with the current class loader >>>> ParallelTransformerLoaderAgent.getClassLoader(). >>>> >>>> Sometimes, the TestClass2 and TestClass3 are loaded by the same >>>> class loader recursively. >>>> It happens if the class loader has not been changed between loading >>>> TestClass2 and TestClass3 classes. >>>> >>>> I'm not convinced yet the test is incorrect. >>>> And it is not clear why do we get a ClassCircularityError. >>>> >>>> Please, let me know if the above understanding is wrong. >>>> I also see the reply from David and share his concerns. >>>> >>>> It is not clear if this failure is a regression. >>>> Did we observe this issue before? >>>> If - NOT then when and why had this failure started to appear? >>>> >>>> Unfortunately, it is impossible to look at the test run history at >>>> the moment. >>>> The Aurora is at a maintenance. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/13/14 3:58 PM, Yumin Qi wrote: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >>>>> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >>>>> >>>>> the bug marked as confidential so post the webrev internally. >>>>> >>>>> Problem: The test case tries to load a class from the same jar via >>>>> agent in the middle of loading another class from the jar via same >>>>> class loader in same thread. The call happens in transform which is >>>>> a rare case --- in middle of loading class, loading another class. >>>>> The result is a CircularityError. When first class is in loading, >>>>> in vm we put JarLoader$2 on place holder table, then we start the >>>>> defineClass, which calls transform, begins loading the second class >>>>> so go along the same routine for loading JarLoader$2 first, found >>>>> it already in placeholder table. A CircularityError is thrown. >>>>> Fix: The test case should not call loading class with same class >>>>> loader in same thread from same jar in 'transform' method. I modify >>>>> it loading with system class loader and we expect see >>>>> ClassNotFoundException. Detail see bug comments. >>>>> >>>>> Thanks >>>>> Yumin * >>>> >>> >> > From daniel.daugherty at oracle.com Mon Oct 27 14:05:23 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 27 Oct 2014 08:05:23 -0600 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <544AE76A.9030701@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> <544ADC07.6080904@oracle.com> <544AE76A.9030701@oracle.com> Message-ID: <544E5123.1060202@oracle.com> > The test case was added by Dan. > We may want to ask him to clarify the test case purpose. > (added Dan to the to-list) Here's the changeset that added the test: $ hg log -v -r bca8bf23ac59 test/java/lang/instrument/ParallelTransformerLoader.sh changeset: 132:bca8bf23ac59 user: dcubed date: Mon Mar 24 15:05:09 2008 -0700 files: test/java/lang/instrument/ParallelTransformerLoader.sh test/java/lang/instrument/ParallelTransformerLoaderAgent.java test/java/lang/instrument/ParallelTransformerLoaderApp.java test/java/lang/instrument/TestClass1.java test/java/lang/instrument/TestClass2.java test/java/lang/instrument/TestClass3.java description: 5088398: 3/2 java.lang.instrument TCK test deadlock (test11) Summary: Add regression test for single-threaded bootstrap classloader. Reviewed-by: sspitsyn Based on my e-mail archive for this bug and from the bug report itself, it looks like we got this test from Wily Labs. The original bug was a deadlock that stopped being reproducible after: Karen fixed the bootstrap class loader to work in parallel via: 4997893 4/5 Investigate allowing bootstrap loader to work in parallel with that fix in place the deadlock no longer reproduces. I'm planning to use this bug as the vehicle for getting the test program into the INSTRUMENT_REGRESSION test suite. *** (#2 of 2): 2008-02-29 18:20:17 GMT+00:00 daniel.daugherty at sun.com A careful reading of JDK-5088398 might reveal the intentions of this test... Dan On 10/24/14 5:57 PM, serguei.spitsyn at oracle.com wrote: > Yumin, > > On 10/24/14 4:08 PM, Yumin Qi wrote: >> Serguei, >> >> Thanks for your comments. >> This test happens intermittently, but now it can repeat with 8/9. >> Loading TestClass1 in main thread while loading TestClass2 in >> TestThread in parallel. They both will call transform since >> TestClass[1-3] are loaded via agent. When loading TestClass2, it will >> call loading TestClass3 in TestThread. >> Note in the main thread, for loop: >> >> for (int i = 0; i < kNumIterations; i++) >> { >> // load some classes from multiple threads >> (this thread and one other) >> Thread testThread = new TestThread(2); >> testThread.start(); >> loadClasses(1); >> >> // log that it completed and reset for the >> next iteration >> testThread.join(); >> System.out.print("."); >> ParallelTransformerLoaderAgent.generateNewClassLoader(); >> } >> >> The loader got renewed after testThread.join(). So both threads are >> using the exact same class loader. > > You are right, thanks. > It means that all three classes (TesClass1, TestClass2 and TestClass3) > are loaded by the same class loader in each iteration. > > However, I see more cases when the TestClass3 gets loaded. > It happens in a CFLH event when any other class (not TestClass*) in > the system is loaded. > The class loading thread can be any, not only "main" or "TestClass" > thread. > I suspect this test case mostly targets class loading that happens on > other threads. > It is because of the lines: > // In 160_03 and older, transform() is called > // with the "system_loader_lock" held and that > // prevents the bootstrap class loaded from > // running in parallel. If we add a slight sleep > // delay here when the transform() call is not > // main or TestThread, then the deadlock in > // 160_03 and older is much more reproducible. > if (!tName.equals("main") && > !tName.equals("TestThread")) { > System.out.println("Thread '" + tName + > "' has called transform()"); > try { > Thread.sleep(500); > } catch (InterruptedException ie) { > } > } > > What about the following? > > In the ParallelTransformerLoaderAgent.java make this change: > if (!tName.equals("main")) > => if (tName.equals("TestThread")) > > Does such updated test still failing? > >> After create a new class loader, next loop will use the loader. This >> is why quite often on the stack trace we can see it resolves JarLoader$2. >> >> I am not quite understand the test case either. Loading TestClass3 >> inside transform using the same classloader will cause call to >> transform again and form a circle. Nonetheless, if we see TestClass2 >> already loaded, the loop will end but that still is a risk. > > In fact, I don't like that the test loads the class TestClass3 at the > TestClass3 CFLH event. > However, it is interesting to know why we did not see (is it the > case?) this issue before. > Also, it is interesting why the test stops failing with you fix > (replacing loader with SystemClassLoader). > > The test case was added by Dan. > We may want to ask him to clarify the test case purpose. > (added Dan to the to-list) > > Thanks, > Serguei > >> >> Thanks >> Yumin >> >> On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Yumin, >>> >>> Below is some analysis to make sure I understand the test scenario >>> correctly. >>> >>> The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. >>> At each iteration it does: >>> - creates and starts a new TestThread >>> - loads TestClass1 with the current class loader: >>> ParallelTransformerLoaderAgent.getClassLoader() >>> - changes the current class loader with new one: >>> ParallelTransformerLoaderAgent.generateNewClassLoader() >>> >>> The TestThread loads the TestClass2 concurrently with the main thread. >>> >>> At the CFLH events, the ParallelTransformerLoaderAgent does the >>> class retransformation. >>> If the thread loading the class is not "main", it loads the class >>> TestClass3 >>> with the current class loader >>> ParallelTransformerLoaderAgent.getClassLoader(). >>> >>> Sometimes, the TestClass2 and TestClass3 are loaded by the same >>> class loader recursively. >>> It happens if the class loader has not been changed between loading >>> TestClass2 and TestClass3 classes. >>> >>> I'm not convinced yet the test is incorrect. >>> And it is not clear why do we get a ClassCircularityError. >>> >>> Please, let me know if the above understanding is wrong. >>> I also see the reply from David and share his concerns. >>> >>> It is not clear if this failure is a regression. >>> Did we observe this issue before? >>> If - NOT then when and why had this failure started to appear? >>> >>> Unfortunately, it is impossible to look at the test run history at >>> the moment. >>> The Aurora is at a maintenance. >>> >>> Thanks, >>> Serguei >>> >>> On 10/13/14 3:58 PM, Yumin Qi wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >>>> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >>>> >>>> the bug marked as confidential so post the webrev internally. >>>> >>>> Problem: The test case tries to load a class from the same jar via >>>> agent in the middle of loading another class from the jar via same >>>> class loader in same thread. The call happens in transform which is >>>> a rare case --- in middle of loading class, loading another class. >>>> The result is a CircularityError. When first class is in loading, >>>> in vm we put JarLoader$2 on place holder table, then we start the >>>> defineClass, which calls transform, begins loading the second class >>>> so go along the same routine for loading JarLoader$2 first, found >>>> it already in placeholder table. A CircularityError is thrown. >>>> Fix: The test case should not call loading class with same class >>>> loader in same thread from same jar in 'transform' method. I modify >>>> it loading with system class loader and we expect see >>>> ClassNotFoundException. Detail see bug comments. >>>> >>>> Thanks >>>> Yumin * >>> >> > From david.lloyd at redhat.com Mon Oct 27 14:23:53 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 27 Oct 2014 09:23:53 -0500 Subject: JEPs proposed to target JDK 9 In-Reply-To: <544A77E8.6090608@oracle.com> References: <20141023151555.106363@eggemoggin.niobe.net> <544A6AFE.8090702@redhat.com> <544A77E8.6090608@oracle.com> Message-ID: <544E5579.7080201@redhat.com> On 10/24/2014 11:01 AM, Brian Goetz wrote: >>> Feedback is more than welcome, as are reasoned objections. If no such >>> objections are raised in one week's time (i.e., by 2014/10/30 23:00 >>> UTC), >>> 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. >> >> I still object to removing _ (one of only two legal single-symbol >> identifiers in Java) as an identifier. I believe that if a special >> identifier is desired, a new, previously unused character should be used >> instead, such as #. This has the advantage of not breaking existing >> frameworks (including two of my own), as well as being visually distinct. > > I realize that you don't like this choice; you were even in the room > when the decision was made (you were on the JSR-335 EG), and you raised > this concern at the time. And it was considered, and discussed. Of > course, not everyone will agree with the decision; that's what happens > when you have 9 million opinions, especially on something as > opinion-prone as syntax. To clarify for outsiders, on this particular issue there were only two opinions that I am aware of: mine and Brian's. I recall that most of the input to this seemed indifferent and Brian simply made a ruling, which was his right as specification lead, but I don't recall that there was really a lot of due reasonable consideration of alternatives. >> I do not believe that referencing existing non-Java languages is a valid >> reason for doing this. > > This is a valid opinion, and certainly "but language X does it this way" > is not a strong enough reason to do anything. However, the use of _ as > an "I don't care" token is nearly universal in languages supporting > pattern-matching, and we concluded that its eventual possible use for > such features outweighed the very small number of "but my codebase > already uses it!" concerns. Again, I think this was largely you speaking with the group's voice. In fact the only non-neutral feedback I've ever gotten from anyone external (granted with a small informal sample group) has been that using a new, previously unused symbol (specifically #) is better than breaking compatibility. > (Observation: this is one of the very few times we've made the conscious > choice to make an incompatible language change for the sake of making > things better in the long run. When we do this, people complain; when > we don't do this, people complain.) It should be emphasized here that making an incompatible language change is not in any way *necessary* to make this particular improvement; in this case, language compatibility would be broken purely for a subjective style choice. I don't oppose the improvement itself (not on these grounds anyway), but it should never be implied that removing _ from the identifier space is necessary to make this change. > So, I understand your concern, and I'm not saying your concern is > totally invalid (every issue has many sides), but you are not now > bringing any *new* information to the discussion -- this concern was > raised and understood and considered at the time the decision was made, > and nothing has really changed since then, so I see no reason to to pull > the emergency brake cord on this train-already-in-motion. Again, as far as I know this issue has only two sides. -- - DML From serguei.spitsyn at oracle.com Mon Oct 27 18:00:36 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Oct 2014 11:00:36 -0700 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <544E5123.1060202@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> <544ADC07.6080904@oracle.com> <544AE76A.9030701@oracle.com> <544E5123.1060202@oracle.com> Message-ID: <544E8844.1070907@oracle.com> Ok. Thanks, Dan! Serguei On 10/27/14 7:05 AM, Daniel D. Daugherty wrote: > > The test case was added by Dan. > > We may want to ask him to clarify the test case purpose. > > (added Dan to the to-list) > > Here's the changeset that added the test: > > $ hg log -v -r bca8bf23ac59 > test/java/lang/instrument/ParallelTransformerLoader.sh > changeset: 132:bca8bf23ac59 > user: dcubed > date: Mon Mar 24 15:05:09 2008 -0700 > files: test/java/lang/instrument/ParallelTransformerLoader.sh > test/java/lang/instrument/ParallelTransformerLoaderAgent.java > test/java/lang/instrument/ParallelTransformerLoaderApp.java > test/java/lang/instrument/TestClass1.java > test/java/lang/instrument/TestClass2.java > test/java/lang/instrument/TestClass3.java > description: > 5088398: 3/2 java.lang.instrument TCK test deadlock (test11) > Summary: Add regression test for single-threaded bootstrap classloader. > Reviewed-by: sspitsyn > > > Based on my e-mail archive for this bug and from the bug report itself, > it looks like we got this test from Wily Labs. The original bug was a > deadlock that stopped being reproducible after: > > Karen fixed the bootstrap class loader to work in parallel via: > > 4997893 4/5 Investigate allowing bootstrap loader to work in parallel > > with that fix in place the deadlock no longer reproduces. > I'm planning to use this bug as the vehicle for getting > the test program into the INSTRUMENT_REGRESSION test suite. > > *** (#2 of 2): 2008-02-29 18:20:17 GMT+00:00 daniel.daugherty at sun.com > > > A careful reading of JDK-5088398 might reveal the intentions of this > test... > > Dan > > > On 10/24/14 5:57 PM, serguei.spitsyn at oracle.com wrote: >> Yumin, >> >> On 10/24/14 4:08 PM, Yumin Qi wrote: >>> Serguei, >>> >>> Thanks for your comments. >>> This test happens intermittently, but now it can repeat with 8/9. >>> Loading TestClass1 in main thread while loading TestClass2 in >>> TestThread in parallel. They both will call transform since >>> TestClass[1-3] are loaded via agent. When loading TestClass2, it >>> will call loading TestClass3 in TestThread. >>> Note in the main thread, for loop: >>> >>> for (int i = 0; i < kNumIterations; i++) >>> { >>> // load some classes from multiple threads >>> (this thread and one other) >>> Thread testThread = new TestThread(2); >>> testThread.start(); >>> loadClasses(1); >>> >>> // log that it completed and reset for the >>> next iteration >>> testThread.join(); >>> System.out.print("."); >>> ParallelTransformerLoaderAgent.generateNewClassLoader(); >>> } >>> >>> The loader got renewed after testThread.join(). So both threads are >>> using the exact same class loader. >> >> You are right, thanks. >> It means that all three classes (TesClass1, TestClass2 and TestClass3) >> are loaded by the same class loader in each iteration. >> >> However, I see more cases when the TestClass3 gets loaded. >> It happens in a CFLH event when any other class (not TestClass*) in >> the system is loaded. >> The class loading thread can be any, not only "main" or "TestClass" >> thread. >> I suspect this test case mostly targets class loading that happens on >> other threads. >> It is because of the lines: >> // In 160_03 and older, transform() is called >> // with the "system_loader_lock" held and that >> // prevents the bootstrap class loaded from >> // running in parallel. If we add a slight sleep >> // delay here when the transform() call is not >> // main or TestThread, then the deadlock in >> // 160_03 and older is much more reproducible. >> if (!tName.equals("main") && >> !tName.equals("TestThread")) { >> System.out.println("Thread '" + tName + >> "' has called transform()"); >> try { >> Thread.sleep(500); >> } catch (InterruptedException ie) { >> } >> } >> >> What about the following? >> >> In the ParallelTransformerLoaderAgent.java make this change: >> if (!tName.equals("main")) >> => if (tName.equals("TestThread")) >> >> Does such updated test still failing? >> >>> After create a new class loader, next loop will use the loader. This >>> is why quite often on the stack trace we can see it resolves >>> JarLoader$2. >>> >>> I am not quite understand the test case either. Loading TestClass3 >>> inside transform using the same classloader will cause call to >>> transform again and form a circle. Nonetheless, if we see TestClass2 >>> already loaded, the loop will end but that still is a risk. >> >> In fact, I don't like that the test loads the class TestClass3 at the >> TestClass3 CFLH event. >> However, it is interesting to know why we did not see (is it the >> case?) this issue before. >> Also, it is interesting why the test stops failing with you fix >> (replacing loader with SystemClassLoader). >> >> The test case was added by Dan. >> We may want to ask him to clarify the test case purpose. >> (added Dan to the to-list) >> >> Thanks, >> Serguei >> >>> >>> Thanks >>> Yumin >>> >>> On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Yumin, >>>> >>>> Below is some analysis to make sure I understand the test scenario >>>> correctly. >>>> >>>> The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. >>>> At each iteration it does: >>>> - creates and starts a new TestThread >>>> - loads TestClass1 with the current class loader: >>>> ParallelTransformerLoaderAgent.getClassLoader() >>>> - changes the current class loader with new one: >>>> ParallelTransformerLoaderAgent.generateNewClassLoader() >>>> >>>> The TestThread loads the TestClass2 concurrently with the main thread. >>>> >>>> At the CFLH events, the ParallelTransformerLoaderAgent does the >>>> class retransformation. >>>> If the thread loading the class is not "main", it loads the class >>>> TestClass3 >>>> with the current class loader >>>> ParallelTransformerLoaderAgent.getClassLoader(). >>>> >>>> Sometimes, the TestClass2 and TestClass3 are loaded by the same >>>> class loader recursively. >>>> It happens if the class loader has not been changed between loading >>>> TestClass2 and TestClass3 classes. >>>> >>>> I'm not convinced yet the test is incorrect. >>>> And it is not clear why do we get a ClassCircularityError. >>>> >>>> Please, let me know if the above understanding is wrong. >>>> I also see the reply from David and share his concerns. >>>> >>>> It is not clear if this failure is a regression. >>>> Did we observe this issue before? >>>> If - NOT then when and why had this failure started to appear? >>>> >>>> Unfortunately, it is impossible to look at the test run history at >>>> the moment. >>>> The Aurora is at a maintenance. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/13/14 3:58 PM, Yumin Qi wrote: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >>>>> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >>>>> >>>>> the bug marked as confidential so post the webrev internally. >>>>> >>>>> Problem: The test case tries to load a class from the same jar via >>>>> agent in the middle of loading another class from the jar via same >>>>> class loader in same thread. The call happens in transform which >>>>> is a rare case --- in middle of loading class, loading another >>>>> class. The result is a CircularityError. When first class is in >>>>> loading, in vm we put JarLoader$2 on place holder table, then we >>>>> start the defineClass, which calls transform, begins loading the >>>>> second class so go along the same routine for loading JarLoader$2 >>>>> first, found it already in placeholder table. A CircularityError >>>>> is thrown. >>>>> Fix: The test case should not call loading class with same class >>>>> loader in same thread from same jar in 'transform' method. I >>>>> modify it loading with system class loader and we expect see >>>>> ClassNotFoundException. Detail see bug comments. >>>>> >>>>> Thanks >>>>> Yumin * >>>> >>> >> > From vicente.romero at oracle.com Mon Oct 27 23:04:23 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Mon, 27 Oct 2014 16:04:23 -0700 Subject: Result: New jdk9 Reviewer: Jan Lahoda In-Reply-To: <544A9CB6.2040802@oracle.com> References: <5435EAE2.2030605@oracle.com> <544A9CB6.2040802@oracle.com> Message-ID: <544ECF77.4000309@oracle.com> woohoo!, congrats! On 10/24/2014 11:38 AM, Jonathan Gibbons wrote: > |Voting for Jan Lahoda [1] is now closed. > > Yes: 19 (not counting one invalid vote) > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is > sufficient to approve the nomination. > > Jonathan Gibbons > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001414.html| > From alejandro.murillo at oracle.com Tue Oct 28 20:54:33 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 28 Oct 2014 14:54:33 -0600 Subject: jdk9-dev: HotSpot Message-ID: <54500289.1020307@oracle.com> jdk9-hs-2014-10-27 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/12d3dc35f0e8 http://hg.openjdk.java.net/jdk9/dev/corba/rev/7e9add74ad50 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/2891b59e2899 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/48e4ec70cc1c http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/90de6ecbff46 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6e6f26621fa2 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7b80aafb5b76 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/71ddc6499be5 Component : VM Status : Go for integration Date : 10/28/2014 at 19:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-10-27-145521.amurillo.jdk9-hs-2014-10-27-snapshot Testing: 120 new failures, 2841 known failures, 390721 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6979279: remove special-case code for ParallelGCThreads==0 8055702: Remove the generations array 8056240: Investigate increased GC remark time after class unloading changes in CRM Fuse 8058568: GC cleanup phase can cause G1 skipping a System.gc() 8060256: The loop in Arguments::parse() can be enhanced. 8061805: BACKOUT - Remove the generations array -- Alejandro From lana.steuck at oracle.com Wed Oct 29 20:08:46 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Oct 2014 13:08:46 -0700 (PDT) Subject: jdk9-b37: dev Message-ID: <201410292008.s9TK8kEb018565@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/723a67b0c442 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/dd7bbdf81a53 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/478972d90f7b http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/27c3345d6dce http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/90de6ecbff46 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/48e4ec70cc1c http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b1c2dd843f24 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/7e9add74ad50 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8042622 core-libs Check for CRL results in IllegalArgumentException "white space not allowed" JDK-8059767 core-libs FileHandler should allow 'long' limits and handle overflow of MeteredStream.written. JDK-8059844 core-libs Implement optimistic splitter JDK-8062024 core-libs Issue with date.setFullYear when time other than midnight JDK-8059843 core-libs Make AST serializable JDK-8060483 core-libs NPE with explicitCastArguments unboxing null JDK-8058610 core-libs Pessimistic LMUL used where optimistic should be JDK-8059411 core-libs RowSetWarning does not correctly chain warnings JDK-8061391 core-libs String.concat needs to have optimistic builtin versions JDK-8060170 core-libs Support SIO_LOOPBACK_FAST_PATH option on Windows JDK-8059813 core-libs Type Info Cache flag must must be documented JDK-8060724 core-libs ant test262parallel in Nashorn spends a significant amount of time after almost all the tests are run JDK-8061955 core-libs asm.js idioms result in unnecessarily code emission JDK-8060086 core-libs closed/java/lang/Character/CheckBlocks.java failed JDK-8060089 core-libs closed/java/util/Calendar/CalendarTestScripts/Japanese*Tests.sh failed in tr locale JDK-8061257 core-libs nashorn ant build script should have a sanity target JDK-8060432 core-libs tools/pack200/TestNormal.java fails on Windows with java.io.FileNotFoundException after JDK-8058854 JDK-8044473 core-svc Allow for extended set of platform MXBeans JDK-8060692 core-svc Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK JDK-8061312 core-svc Even more debug output needed JDK-8046190 core-svc Move com/sun/jmx/snmp and sun/management/snmp to the closed jdk repo JDK-8056143 core-svc interrupted java/lang/management/MemoryMXBean/LowMemoryTest.java leaves running process JDK-8029465 core-svc warnings from b118 for jdk.src.share.native.sun.management: JNI exception pending JDK-8049373 embedded All compact profiles builds fail following JDK-8044473 JDK-8059353 embedded [TESTBUG] closed/runtime/AppCDS tests failed on minimal VM JDK-8059604 hotspot Add CompileThresholdScaling flag to control when methods are first compiled (with +/-TieredCompilation) JDK-8047934 hotspot Adding new API for unlocking diagnostic argument for SharedArchiveFile JDK-8060116 hotspot After JDK-8047976 gc/g1/TestSummarizeRSetStatsThreads fails JDK-8057737 hotspot Avoid G1 write barriers on newly allocated objects JDK-8057777 hotspot Cleanup of old and unused VM interfaces JDK-8049737 hotspot Contended Locking reorder and cache line bucket JDK-8027428 hotspot Different conditions for printing taskqueue statistics for parallel gc, parNew and G1 JDK-8059758 hotspot Footprint regressions with JDK-8038423 JDK-8058801 hotspot G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object JDK-8055005 hotspot GC should react to memory pressure JDK-8060439 hotspot JFR initialization attempt failed on windows x86_64 JDK-7102541 hotspot RFE: os::set_native_thread_name() cleanups JDK-8059100 hotspot SIGSEGV VirtualMemoryTracker::remove_released_region JDK-8058606 hotspot [TESTBUG] Detailed Native Memory Tracking (NMT) data is not verified as output at VM exit JDK-8057135 hotspot [TESTBUG] Need a test to cover JDK-8050167 JDK-8060034 hotspot [TESTBUG] Test closed/runtime/superInTryBlock/TestCtorThrow.java can pass when it should fail JDK-8060493 hotspot [TESTBUG] hotspot/test/closed/runtime/AppCDS/ParallelLoad2.java - ParallelLoad.class : no such file or directory JDK-8061932 hotspot closed/com/oracle/jfr/dynamicstart/TestDynamicStart.java fails due to changes from JDK-8056143 JDK-8059924 hotspot com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java: assert(Universe::verify_in_progress() || !SafepointSynchronize::is_at_safepoint()) failed: invariant JDK-8046268 hotspot compiler/whitebox/ tests fail : must be osr_compiled JDK-8059847 hotspot complement JDK-8055286 and JDK-8056964 changes JDK-8058746 hotspot escape analysis special case code for array copy broken by 7173584 JDK-8059904 hotspot libjvm_db.c warnings in solaris/sparc build with SS JDK-8060215 hotspot per-method PrintIdealGraphLevel JDK-8059389 hotspot process_object_instance_fmt is incorrect for non-english versions of Windows JDK-8061610 infrastructure "make test" broken for hotspot test targets JDK-8060102 infrastructure Add build scripts for SE Embedded and JDK-on-ARM JDK-8061301 infrastructure Fix typo when translating characters in $USER JDK-8060766 infrastructure build of jdk9-b33 seems broken due to how security zip files are interfaced JDK-8061924 infrastructure demos target fails if users CDPATH is incorrectly set JDK-8061830 other-libs [asm] refresh internal ASM version v5.0.3 JDK-8031532 performance CMM: Add a Resource Pressure MBean JDK-8049682 performance CMM: Move SystemResourcePressureImpl from jdk.internal.cmm to jdk.management.cmm.internal JDK-8061574 security-libs 9-dev solaris-amd64 and solaris-sparcv9 build fail on 2014-10-20 JDK-8061464 security-libs A typo in CipherTestUtils test JDK-8058547 security-libs Memory leak in ProtectionDomain cache JDK-8046002 security-libs Move Ucrypto to the open jdk repo JDK-8054448 tools (ann) Cannot reference field of inner class in an anonymous class JDK-8061723 tools 8060056 breaks tests on Windows JDK-8061323 tools JavadocTokenizer repeatedly compiles pattern to check for deprecation JDK-8057800 tools Method reference with generic type creates NPE when compiling JDK-8054457 tools Refactor Symbol kinds from small ints to an enum JDK-8042888 tools Remove extcheck tool JDK-8059423 tools Replace references for rt.jar by temp.jar JDK-8060715 tools There is a small race condition in IdleResetSjavac JDK-8061778 tools Wrong LineNumberTable for default constructors JDK-8059710 tools javac, the same approach used in fix for JDK-8058708 should be applied to Code.closeAliveRanges JDK-8060056 tools replace java.io.File with java.nio.file.Path JDK-8051540 xml Convert JAXP functional tests to jtreg(TestNG): SAX and Transform JDK-8051561 xml Convert JAXP functional tests to jtreg(TestNG): javax.xml.xpath.* JDK-8061686 xml Size limits in BufferAllocator should have been final From mark.reinhold at oracle.com Wed Oct 29 22:12:39 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 29 Oct 2014 15:12:39 -0700 Subject: JEPs proposed to target JDK 9 In-Reply-To: <544E5579.7080201@redhat.com> References: <20141023151555.106363@eggemoggin.niobe.net>, <544A6AFE.8090702@redhat.com>, <544A77E8.6090608@oracle.com>, <544E5579.7080201@redhat.com> Message-ID: <20141029151239.591463@eggemoggin.niobe.net> The change to disallow the use of "_" as an identifier was approved by the Lambda EG (JSR 335), approved by the JCP EC, and also approved as part of the Java SE 8 Platform Specification (JSR 337). At this point the bar for revisiting that decision -- never mind reversing it -- is incredibly high. The javac compiler has issued warning messages for the use of "_" as an identifier ever since build 75 of JDK 8 [1], well over a year before JDK 8 GA. The message clearly states that "_" may be disallowed in a future release. If that warning had sent thousands of developers into a justified panic then that would, I think, constitute an argument for revisiting the decision and, for now, delaying this change. So far as I know, however, few people have even noticed this warning, and none has complained. I understand that you disagreed with the Lambda EG's decision on this issue at the time. You haven't brought any new information to bear on this topic now, however, so I see no reason why JEP 213 should not proceed in its current form. - Mark [1] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/2d2b2be57c78 From joel.franck at oracle.com Thu Oct 30 12:48:51 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 30 Oct 2014 13:48:51 +0100 Subject: Result: New JDK 9 Committer: Claes Redestad Message-ID: Voting for Claes Redestad [1] is now closed. Yes: 28 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Joel Borggr?n-Franck [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001431.html From mark.reinhold at oracle.com Thu Oct 30 17:30:20 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Oct 2014 10:30:20 -0700 Subject: FYI: Next Jigsaw JEP posted Message-ID: <20141030103020.482306@eggemoggin.niobe.net> http://openjdk.java.net/jeps/220 -- Modular Run-Time Images This JEP will soon be proposed for JDK 9. Please direct questions and comments to the jigsaw-dev list. - Mark From mark.reinhold at oracle.com Thu Oct 30 23:02:38 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Oct 2014 16:02:38 -0700 Subject: JEPs proposed to target JDK 9 In-Reply-To: <20141023151555.106363@eggemoggin.niobe.net> References: <20141023151555.106363@eggemoggin.niobe.net> Message-ID: <20141030160238.70963@eggemoggin.niobe.net> 2014/10/23 3:15 -0700, mark.reinhold at oracle.com: > For your consideration: The following JEPs have been placed into the > "Proposed to Target" state by their respective owners after discussion > and review. > > 158: Unified JVM Logging http://openjdk.java.net/jeps/158 > 211: Elide Deprecation Warnings on Import Statements http://openjdk.java.net/jeps/211 > 212: Resolve Lint and Doclint Warnings http://openjdk.java.net/jeps/212 > 213: Milling Project Coin http://openjdk.java.net/jeps/213 > 214: Remove GC Combinations Deprecated in JDK 8 http://openjdk.java.net/jeps/214 > 216: Process Import Statements Correctly http://openjdk.java.net/jeps/216 > > Feedback is more than welcome, as are reasoned objections. If no such > objections are raised in one week's time (i.e., by 2014/10/30 23:00 UTC), > 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. Thanks to all who commented on this round. One objection was raised, and satisfactorily answered. Hearing no further objections, I've targeted all these JEPs to JDK 9. - Mark From neugens.limasoftware at gmail.com Fri Oct 31 15:43:40 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 31 Oct 2014 16:43:40 +0100 Subject: JEPs proposed to target JDK 9 In-Reply-To: <20141030160238.70963@eggemoggin.niobe.net> References: <20141023151555.106363@eggemoggin.niobe.net> <20141030160238.70963@eggemoggin.niobe.net> Message-ID: 2014-10-31 0:02 GMT+01:00 : > 2014/10/23 3:15 -0700, mark.reinhold at oracle.com: >> For your consideration: The following JEPs have been placed into the >> "Proposed to Target" state by their respective owners after discussion >> and review. >> >> 158: Unified JVM Logging http://openjdk.java.net/jeps/158 >> 211: Elide Deprecation Warnings on Import Statements http://openjdk.java.net/jeps/211 >> 212: Resolve Lint and Doclint Warnings http://openjdk.java.net/jeps/212 >> 213: Milling Project Coin http://openjdk.java.net/jeps/213 >> 214: Remove GC Combinations Deprecated in JDK 8 http://openjdk.java.net/jeps/214 >> 216: Process Import Statements Correctly http://openjdk.java.net/jeps/216 >> >> Feedback is more than welcome, as are reasoned objections. If no such >> objections are raised in one week's time (i.e., by 2014/10/30 23:00 UTC), >> 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. > > Thanks to all who commented on this round. One objection was raised, > and satisfactorily answered. More like just answered :) but this ship has sailed I don't think there's much we can do about it anymore. I understand that the JCP *is* the ultimate authority and the place where those discussion should take place. I understand it, appreciate it and fully endorse it of course. I would have expected though that changes that may be relevant to everybody like breaking backward compatibility (like the change we questioned) should have wider exposure than just a summary mail at the end of the cycle, where there's no discussion that can be done anymore. The main problem is that even if there are objection, they just won't count, decision had been made, the train is gone, the consensus in the group has been reached, so anything we may say it's just not "adding any new information". Of course, as said the JCP is the place to go, if we want our voice heard this is where it should be. But maybe we should have some digest of what's going on in the JCP that affect what's going on here, so that people don't loose track, the way it works now is totally confusing to be honest. > Hearing no further objections, I've targeted all these JEPs to JDK 9. Sure, don't misunderstand me and my criticism please, there's lot of good stuff going on here, so cheers! Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From gnu.andrew at redhat.com Fri Oct 31 15:50:50 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 31 Oct 2014 11:50:50 -0400 (EDT) Subject: JEPs proposed to target JDK 9 In-Reply-To: <544E5579.7080201@redhat.com> References: <20141023151555.106363@eggemoggin.niobe.net> <544A6AFE.8090702@redhat.com> <544A77E8.6090608@oracle.com> <544E5579.7080201@redhat.com> Message-ID: <1977997141.3458745.1414770650173.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 10/24/2014 11:01 AM, Brian Goetz wrote: > >>> Feedback is more than welcome, as are reasoned objections. If no such > >>> objections are raised in one week's time (i.e., by 2014/10/30 23:00 > >>> UTC), > >>> 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. > >> > >> I still object to removing _ (one of only two legal single-symbol > >> identifiers in Java) as an identifier. I believe that if a special > >> identifier is desired, a new, previously unused character should be used > >> instead, such as #. This has the advantage of not breaking existing > >> frameworks (including two of my own), as well as being visually distinct. > > > > I realize that you don't like this choice; you were even in the room > > when the decision was made (you were on the JSR-335 EG), and you raised > > this concern at the time. And it was considered, and discussed. Of > > course, not everyone will agree with the decision; that's what happens > > when you have 9 million opinions, especially on something as > > opinion-prone as syntax. > > To clarify for outsiders, on this particular issue there were only two > opinions that I am aware of: mine and Brian's. I recall that most of > the input to this seemed indifferent and Brian simply made a ruling, > which was his right as specification lead, but I don't recall that there > was really a lot of due reasonable consideration of alternatives. As one of these outsiders, it's not clear to me where the "9 million opinions" concept comes from. I can, however, foresee nine million objections when users find their code (or worse, someone else's) is broken for the sake of a feature they don't yet use. Not only that, but it also results in concomitant changes in external tooling to support the new syntax. Theoretically, you could have the whole of Unicode to choose from for an alternative character, so it seems strange to insist on _. > > >> I do not believe that referencing existing non-Java languages is a valid > >> reason for doing this. > > > > This is a valid opinion, and certainly "but language X does it this way" > > is not a strong enough reason to do anything. However, the use of _ as > > an "I don't care" token is nearly universal in languages supporting > > pattern-matching, and we concluded that its eventual possible use for > > such features outweighed the very small number of "but my codebase > > already uses it!" concerns. > > Again, I think this was largely you speaking with the group's voice. In > fact the only non-neutral feedback I've ever gotten from anyone external > (granted with a small informal sample group) has been that using a new, > previously unused symbol (specifically #) is better than breaking > compatibility. > On what do you base this notion of a very small number of concerns? Java has been around for nearly twenty years. That's a lot of potential for code using _ as an identifier. > > (Observation: this is one of the very few times we've made the conscious > > choice to make an incompatible language change for the sake of making > > things better in the long run. When we do this, people complain; when > > we don't do this, people complain.) > > It should be emphasized here that making an incompatible language change > is not in any way *necessary* to make this particular improvement; in > this case, language compatibility would be broken purely for a > subjective style choice. I don't oppose the improvement itself (not on > these grounds anyway), but it should never be implied that removing _ > from the identifier space is necessary to make this change. > > > So, I understand your concern, and I'm not saying your concern is > > totally invalid (every issue has many sides), but you are not now > > bringing any *new* information to the discussion -- this concern was > > raised and understood and considered at the time the decision was made, > > and nothing has really changed since then, so I see no reason to to pull > > the emergency brake cord on this train-already-in-motion. > > Again, as far as I know this issue has only two sides. > > -- > - DML > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From daniil.x.titov at oracle.com Fri Oct 31 20:47:17 2014 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 31 Oct 2014 13:47:17 -0700 Subject: Request for review 8021423 : Update java.applet.Applet javadoc for getCodeBase and getDocumentBase Message-ID: <5453F555.90902@oracle.com> Hi, Please review the changes in Javadoc for*getCodeBase() *and*getDocumentBase()* methods in *java.applet.Applet* and*java.applet.AppletStub* classes indicating that for locally running applets these methods return null. Bug: https://bugs.openjdk.java.net/browse/JDK-8021423 JDK 9 webrev: http://cr.openjdk.java.net/~dtitov/8021423/webrev.01/ Thanks, Daniil From neugens.limasoftware at gmail.com Fri Oct 31 21:35:13 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 31 Oct 2014 22:35:13 +0100 Subject: JEPs proposed to target JDK 9 In-Reply-To: References: <20141023151555.106363@eggemoggin.niobe.net> <20141030160238.70963@eggemoggin.niobe.net> Message-ID: I just felt I should clarify my view here of that what I see as a point of failure in the process. You may (and probably will) disagree with me, but I hope there's some feedback here that will improve things for the future. The issue for me is that one JSR that targets a specific area introduces an incompatible change that affect everybody. This change is proposed as a Jep for inclusion in the next JDK, which doesn't yet have a JSR, but we still have to accept this just under the explanation that "it's too late and there's too much in motion to pull the emergency brake". In my naive world a Jep needs to be discussed, and is not law until it's accepted or promoted to a JSR in its own right. The EG may decide for lamdas to be the way they are out of simple personal preference, but it can't decide for an incompatible language change since this belong to the JDK 9 JSR which doesn't even exist yet! So yes, the ship has sailed and our opinion has been kindly noted but won't change anything, but in fact the ship sailed without waiting for the right review process to begin with. This is why I think there should be an open communication channel in the future, especially regarding changes in behaviour and compatibility. After all, this channel has more or less been open with Jigsaw, not sure why lamdas are special here. Cheers, Mario Il 31/ott/2014 16:43 "Mario Torre" ha scritto: > 2014-10-31 0:02 GMT+01:00 : > > 2014/10/23 3:15 -0700, mark.reinhold at oracle.com: > >> For your consideration: The following JEPs have been placed into the > >> "Proposed to Target" state by their respective owners after discussion > >> and review. > >> > >> 158: Unified JVM Logging > http://openjdk.java.net/jeps/158 > >> 211: Elide Deprecation Warnings on Import Statements > http://openjdk.java.net/jeps/211 > >> 212: Resolve Lint and Doclint Warnings > http://openjdk.java.net/jeps/212 > >> 213: Milling Project Coin > http://openjdk.java.net/jeps/213 > >> 214: Remove GC Combinations Deprecated in JDK 8 > http://openjdk.java.net/jeps/214 > >> 216: Process Import Statements Correctly > http://openjdk.java.net/jeps/216 > >> > >> Feedback is more than welcome, as are reasoned objections. If no such > >> objections are raised in one week's time (i.e., by 2014/10/30 23:00 > UTC), > >> 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. > > > > Thanks to all who commented on this round. One objection was raised, > > and satisfactorily answered. > > More like just answered :) but this ship has sailed I don't think > there's much we can do about it anymore. > > I understand that the JCP *is* the ultimate authority and the place > where those discussion should take place. I understand it, appreciate > it and fully endorse it of course. I would have expected though that > changes that may be relevant to everybody like breaking backward > compatibility (like the change we questioned) should have wider > exposure than just a summary mail at the end of the cycle, where > there's no discussion that can be done anymore. > > The main problem is that even if there are objection, they just won't > count, decision had been made, the train is gone, the consensus in the > group has been reached, so anything we may say it's just not "adding > any new information". > > Of course, as said the JCP is the place to go, if we want our voice > heard this is where it should be. But maybe we should have some digest > of what's going on in the JCP that affect what's going on here, so > that people don't loose track, the way it works now is totally > confusing to be honest. > > > Hearing no further objections, I've targeted all these JEPs to JDK 9. > > Sure, don't misunderstand me and my criticism please, there's lot of > good stuff going on here, so cheers! > > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > From karen.kinnear at oracle.com Fri Oct 31 22:29:01 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 31 Oct 2014 18:29:01 -0400 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <544E8844.1070907@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> <544ADC07.6080904@oracle.com> <544AE76A.9030701@oracle.com> <544E5123.1060202@oracle.com> <544E8844.1070907@oracle.com> Message-ID: <0FB37288-5995-4E0B-B005-E00A4FB3B22A@oracle.com> Yumin, From your earlier exception stack trace (many thanks) you reported: Exception in thread "main" java.lang.ClassCircularityError: (no - I don't know why this is in thread "main") sun/misc/URLClassPath$JarLoader$2 at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:771) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:843) at sun.misc.URLClassPath.getResource(URLClassPath.java:199) at java.net.URLClassLoader$1.run(URLClassLoader.java:364) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:426) at java.lang.ClassLoader.loadClass(ClassLoader.java:359) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:340) at ParallelTransformerLoaderApp.loadClasses(ParallelTransformerLoaderApp.java:83) at ParallelTransformerLoaderApp.main(ParallelTransformerLoaderApp.java:45) So I ran with -XX:AbortVMOnException=java.lang.ClassCircularityError -XX:+ShowMessageBoxOnError to get a log file and stack trace. See my instructions below on how to do that. I did this, attached a debugger, which didn't help enough since I needed to see the java stack frames, and got an hs_err_log also, so the stack traces came from the error log. The stack trace was on Thread 2, which in the hs_err_log was TestThread (which makes sense for what the test logic says). See later in email for stack traces from Thread 2. Summary of stack trace: TestThread: loadClasses(#) -> forName(TestClass#, URLClassLoader) vm calls out to URLClassLoader.loadClass(String) which is inherited from java.lang.ClassLoader.loadClass(String) ... calls java.net.URLClassLoader.findClass(...) which calls DoPrivileged java.net.URLClassLoader$1.run which calls sun.misc.URLClassPath.getResource(name, false) which calls sun.misc.URLClassPath$JarLoader.getResource which calls sun.misc.URLClassPath$JarLoader.checkResource which tries to call sun.misc.URLClassPath$JarLoader$2 - and then the transformer jumps in with loadClasses(# (which we know is 3) and walks the same logic which tries to load sun.misc.URLClassPath$JarLoader$2 again Note that in the placeholder table information that Yumin printed, the circularity error is on sun.misc.URLClassPath$JarLoader$2 with the null == boot loader, which makes sense -- that is the appropriate defining loader, and therefore the one the CFLH would intercept during the defineClass phase. In the sun.misc.URLClassPath.java file, in the class JarLoader, in the method checkResource ... return new Resource() { ... } -- I do not know why that generates sun.misc.URLClassPath$JarLoader$1, $2 and $3 at build time or when that was added. I would guess that is when the bug started happening. When I have a successful run, sun.misc.URLClassPath$JarLoader$2 loads before any TestClass1 loads. My belief is that the point of the test is to test parallel class loading for URL class loaders. I don't think the point is to test the bootstrap class loader, nor to test bootstrapping - i.e. running the agent before we have loaded sufficient classes to allow loading URLClassLoader classes. What I suggested to Yumin that he try would be to change the test to NOT intercept boot loader loads, so that sun.misc.URLClassPath$JarLoader$# can load which will in turn allow classes loaded by a URLClassLoader subclass to load. So that change to the test would be: in TestTransformer: if (loader != null) { if (tName.equals("TestThread")) { { loadClasses(3); } } return null; } // I also suspect with that change, we can remove the sleep loop Note: there was a printed message which said that the Thread "Signal Dispatcher" has called transform(), which I ignored, however it is good that we don't call loadClass on that thread - which is part of what the sleep loop does - but that would be handled by the boot loader screening above Alternatively we can preload the URLClassPath classes, but I don't think we want to do that, or we can have the agent explicitly screen on a variety of jdk bootstrapping classes. But I think the cleaner solution is to screen on the boot loader. Does that make any sense to others? thanks, Karen p.s. How to run with hotspot flags (jtreg has a -show:rerun option, but with a shell script in the test, this is more complex, so the following should be easier): So what I did was run the test once for it to pass (not your script, but just once with jtreg) so that it generated the $DST/work directory. I then created a rerun.csh script - attached - you can modify for your own $DST directory. I used it to be able to quickly rerun the test without the jtreg framework and compile time etc. but mostly to be able to actually add hotspot command-line flags. -------------- next part -------------- p.p.s. details from the error log (let me know if you want me to attach the error log to the bug report) note: error log shows last 10 events including: Event: 0.928 loading class sun/misc/URLClassPath$JarLoader$2 Event: 0.928 loading class TestClass3 Event: 0.929 loading class TestClass3 done Event: 0.929 loading class java/lang/ClassCircularityError Event: 0.929 loading class java/lang/ClassCircularityError done TestThread java frames: j sun.misc.URLClassPath$JarLoader.checkResource(Ljava/lang/String;ZLjava/util/jar/JarEntry;)Lsun/misc/Resource;+42 j sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+54 j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53 j java.net.URLClassLoader$1.run()Ljava/lang/Class;+26 j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 v ~StubRoutines::call_stub j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70 j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 v ~StubRoutines::call_stub j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0 j java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49 j ParallelTransformerLoaderAgent$TestTransformer.loadClasses(I)V+25 j ParallelTransformerLoaderAgent$TestTransformer.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[B)[B+81 j sun.instrument.TransformerManager.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[B)[B+50 j sun.instrument.InstrumentationImpl.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[BZ)[B+34 v ~StubRoutines::call_stub j sun.misc.URLClassPath$JarLoader.checkResource(Ljava/lang/String;ZLjava/util/jar/JarEntry;)Lsun/misc/Resource;+42 j sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+54 j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53 j java.net.URLClassLoader$1.run()Ljava/lang/Class;+26 j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 v ~StubRoutines::call_stub j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70 j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 v ~StubRoutines::call_stub j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0 j java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49 j ParallelTransformerLoaderApp.loadClasses(I)V+25 j ParallelTransformerLoaderApp$TestThread.run()V+4 v ~StubRoutines::call_stub detailed frames: V [libjvm.so+0x760f5a] Exceptions::_throw_msg(Thread*, char const*, int, Symbol*, char const*)+0x7c V [libjvm.so+0xce005c] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x7d8 V [libjvm.so+0xcde9e5] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x26d V [libjvm.so+0xcde435] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x39 V [libjvm.so+0x690fbc] ConstantPool::klass_at_impl(constantPoolHandle, int, Thread*)+0x3cc V [libjvm.so+0x5398cb] ConstantPool::klass_at(int, Thread*)+0x55 V [libjvm.so+0x8b1f3c] InterpreterRuntime::_new(JavaThread*, ConstantPool*, int)+0x14a j sun.misc.URLClassPath$JarLoader.checkResource(Ljava/lang/String;ZLjava/util/jar/JarEntry;)Lsun/misc/Resource;+42 j sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+54 j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53 j java.net.URLClassLoader$1.run()Ljava/lang/Class;+26 j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 v ~StubRoutines::call_stub V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d V [libjvm.so+0x972a80] JVM_DoPrivileged+0x63d j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70 j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 v ~StubRoutines::call_stub V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d V [libjvm.so+0x8c1ec7] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x1cb V [libjvm.so+0x8c2086] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0xb0 V [libjvm.so+0xce2096] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x4ea V [libjvm.so+0xce00a8] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x824 V [libjvm.so+0xcde9e5] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x26d V [libjvm.so+0xcde435] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x39 V [libjvm.so+0x98c89e] find_class_from_class_loader(JNIEnv_*, Symbol*, unsigned char, Handle, Handle, unsigned char, Thread*)+0x49 V [libjvm.so+0x96f681] JVM_FindClassFromCaller+0x39d C [libjava.so+0xdfd0] Java_java_lang_Class_forName0+0x130 j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0 j java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49 j ParallelTransformerLoaderAgent$TestTransformer.loadClasses(I)V+25 j ParallelTransformerLoaderAgent$TestTransformer.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[B)[B+81 j sun.instrument.TransformerManager.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[B)[B+50 j sun.instrument.InstrumentationImpl.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[BZ)[B+34 v ~StubRoutines::call_stub V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d V [libjvm.so+0x911bfb] jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x3cd V [libjvm.so+0x916918] jni_CallObjectMethod+0x388 C [libinstrument.so+0x4eb5] transformClassFile+0x1e5 C [libinstrument.so+0x1e06] eventHandlerClassFileLoadHook+0x96 V [libjvm.so+0xa04afa] JvmtiClassFileLoadHookPoster::post_to_env(JvmtiEnv*, bool)+0x1a8 V [libjvm.so+0xa0485e] JvmtiClassFileLoadHookPoster::post_all_envs()+0x8a V [libjvm.so+0xa047c6] JvmtiClassFileLoadHookPoster::post()+0x18 V [libjvm.so+0x9fb6e1] JvmtiExport::post_class_file_load_hook(Symbol*, Handle, Handle, unsigned char**, unsigned char**, JvmtiCachedClassFileData**)+0x85 V [libjvm.so+0x5cd17d] ClassFileParser::parseClassFile(Symbol*, ClassLoaderData*, Handle, KlassHandle, GrowableArray*, TempNewSymbol&, bool, Thread*)+0x2af V [libjvm.so+0x5dd441] ClassFileParser::parseClassFile(Symbol*, ClassLoaderData*, Handle, TempNewSymbol&, bool, Thread*)+0x95 V [libjvm.so+0x5daf03] ClassLoader::load_classfile(Symbol*, Thread*)+0x2ed V [libjvm.so+0xce1cc4] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x118 V [libjvm.so+0xce00a8] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x824 V [libjvm.so+0xcde9e5] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x26d V [libjvm.so+0xcde435] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x39 V [libjvm.so+0x690fbc] ConstantPool::klass_at_impl(constantPoolHandle, int, Thread*)+0x3cc V [libjvm.so+0x5398cb] ConstantPool::klass_at(int, Thread*)+0x55 V [libjvm.so+0x8b1f3c] InterpreterRuntime::_new(JavaThread*, ConstantPool*, int)+0x14a j sun.misc.URLClassPath$JarLoader.checkResource(Ljava/lang/String;ZLjava/util/jar/JarEntry;)Lsun/misc/Resource;+42 j sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+54 j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53 j java.net.URLClassLoader$1.run()Ljava/lang/Class;+26 j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 v ~StubRoutines::call_stub V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d V [libjvm.so+0x972a80] JVM_DoPrivileged+0x63d j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70 j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class; v ~StubRoutines::call_stub V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d V [libjvm.so+0x8c1ec7] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x1cb V [libjvm.so+0x8c2086] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0xb0 V [libjvm.so+0xce2096] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x4ea V [libjvm.so+0xce00a8] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x824 V [libjvm.so+0xcde9e5] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x26d V [libjvm.so+0xcde435] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x39 V [libjvm.so+0x98c89e] find_class_from_class_loader(JNIEnv_*, Symbol*, unsigned char, Handle, Handle, unsigned char, Thread*)+0x49 V [libjvm.so+0x96f681] JVM_FindClassFromCaller+0x39d C [libjava.so+0xdfd0] Java_java_lang_Class_forName0+0x130 j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0 j java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49 j ParallelTransformerLoaderApp.loadClasses(I)V+25 ...... On Oct 27, 2014, at 2:00 PM, serguei.spitsyn at oracle.com wrote: > Ok. > > Thanks, Dan! > Serguei > > > On 10/27/14 7:05 AM, Daniel D. Daugherty wrote: >> > The test case was added by Dan. >> > We may want to ask him to clarify the test case purpose. >> > (added Dan to the to-list) >> >> Here's the changeset that added the test: >> >> $ hg log -v -r bca8bf23ac59 test/java/lang/instrument/ParallelTransformerLoader.sh >> changeset: 132:bca8bf23ac59 >> user: dcubed >> date: Mon Mar 24 15:05:09 2008 -0700 >> files: test/java/lang/instrument/ParallelTransformerLoader.sh test/java/lang/instrument/ParallelTransformerLoaderAgent.java test/java/lang/instrument/ParallelTransformerLoaderApp.java test/java/lang/instrument/TestClass1.java test/java/lang/instrument/TestClass2.java test/java/lang/instrument/TestClass3.java >> description: >> 5088398: 3/2 java.lang.instrument TCK test deadlock (test11) >> Summary: Add regression test for single-threaded bootstrap classloader. >> Reviewed-by: sspitsyn >> >> >> Based on my e-mail archive for this bug and from the bug report itself, >> it looks like we got this test from Wily Labs. The original bug was a >> deadlock that stopped being reproducible after: >> >> Karen fixed the bootstrap class loader to work in parallel via: >> >> 4997893 4/5 Investigate allowing bootstrap loader to work in parallel >> >> with that fix in place the deadlock no longer reproduces. >> I'm planning to use this bug as the vehicle for getting >> the test program into the INSTRUMENT_REGRESSION test suite. >> >> *** (#2 of 2): 2008-02-29 18:20:17 GMT+00:00 daniel.daugherty at sun.com >> >> >> A careful reading of JDK-5088398 might reveal the intentions of this test... >> >> Dan >> >> >> On 10/24/14 5:57 PM, serguei.spitsyn at oracle.com wrote: >>> Yumin, >>> >>> On 10/24/14 4:08 PM, Yumin Qi wrote: >>>> Serguei, >>>> >>>> Thanks for your comments. >>>> This test happens intermittently, but now it can repeat with 8/9. >>>> Loading TestClass1 in main thread while loading TestClass2 in TestThread in parallel. They both will call transform since TestClass[1-3] are loaded via agent. When loading TestClass2, it will call loading TestClass3 in TestThread. >>>> Note in the main thread, for loop: >>>> >>>> for (int i = 0; i < kNumIterations; i++) >>>> { >>>> // load some classes from multiple threads (this thread and one other) >>>> Thread testThread = new TestThread(2); >>>> testThread.start(); >>>> loadClasses(1); >>>> >>>> // log that it completed and reset for the next iteration >>>> testThread.join(); >>>> System.out.print("."); >>>> ParallelTransformerLoaderAgent.generateNewClassLoader(); >>>> } >>>> >>>> The loader got renewed after testThread.join(). So both threads are using the exact same class loader. >>> >>> You are right, thanks. >>> It means that all three classes (TesClass1, TestClass2 and TestClass3) >>> are loaded by the same class loader in each iteration. >>> >>> However, I see more cases when the TestClass3 gets loaded. >>> It happens in a CFLH event when any other class (not TestClass*) in the system is loaded. >>> The class loading thread can be any, not only "main" or "TestClass" thread. >>> I suspect this test case mostly targets class loading that happens on other threads. >>> It is because of the lines: >>> // In 160_03 and older, transform() is called >>> // with the "system_loader_lock" held and that >>> // prevents the bootstrap class loaded from >>> // running in parallel. If we add a slight sleep >>> // delay here when the transform() call is not >>> // main or TestThread, then the deadlock in >>> // 160_03 and older is much more reproducible. >>> if (!tName.equals("main") && !tName.equals("TestThread")) { >>> System.out.println("Thread '" + tName + >>> "' has called transform()"); >>> try { >>> Thread.sleep(500); >>> } catch (InterruptedException ie) { >>> } >>> } >>> >>> What about the following? >>> >>> In the ParallelTransformerLoaderAgent.java make this change: >>> if (!tName.equals("main")) >>> => if (tName.equals("TestThread")) >>> >>> Does such updated test still failing? >>> >>>> After create a new class loader, next loop will use the loader. This is why quite often on the stack trace we can see it resolves JarLoader$2. >>>> >>>> I am not quite understand the test case either. Loading TestClass3 inside transform using the same classloader will cause call to transform again and form a circle. Nonetheless, if we see TestClass2 already loaded, the loop will end but that still is a risk. >>> >>> In fact, I don't like that the test loads the class TestClass3 at the TestClass3 CFLH event. >>> However, it is interesting to know why we did not see (is it the case?) this issue before. >>> Also, it is interesting why the test stops failing with you fix (replacing loader with SystemClassLoader). >>> >>> The test case was added by Dan. >>> We may want to ask him to clarify the test case purpose. >>> (added Dan to the to-list) >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yumin, >>>>> >>>>> Below is some analysis to make sure I understand the test scenario correctly. >>>>> >>>>> The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. >>>>> At each iteration it does: >>>>> - creates and starts a new TestThread >>>>> - loads TestClass1 with the current class loader: ParallelTransformerLoaderAgent.getClassLoader() >>>>> - changes the current class loader with new one: ParallelTransformerLoaderAgent.generateNewClassLoader() >>>>> >>>>> The TestThread loads the TestClass2 concurrently with the main thread. >>>>> >>>>> At the CFLH events, the ParallelTransformerLoaderAgent does the class retransformation. >>>>> If the thread loading the class is not "main", it loads the class TestClass3 >>>>> with the current class loader ParallelTransformerLoaderAgent.getClassLoader(). >>>>> >>>>> Sometimes, the TestClass2 and TestClass3 are loaded by the same class loader recursively. >>>>> It happens if the class loader has not been changed between loading TestClass2 and TestClass3 classes. >>>>> >>>>> I'm not convinced yet the test is incorrect. >>>>> And it is not clear why do we get a ClassCircularityError. >>>>> >>>>> Please, let me know if the above understanding is wrong. >>>>> I also see the reply from David and share his concerns. >>>>> >>>>> It is not clear if this failure is a regression. >>>>> Did we observe this issue before? >>>>> If - NOT then when and why had this failure started to appear? >>>>> >>>>> Unfortunately, it is impossible to look at the test run history at the moment. >>>>> The Aurora is at a maintenance. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 10/13/14 3:58 PM, Yumin Qi wrote: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >>>>>> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >>>>>> >>>>>> the bug marked as confidential so post the webrev internally. >>>>>> >>>>>> Problem: The test case tries to load a class from the same jar via agent in the middle of loading another class from the jar via same class loader in same thread. The call happens in transform which is a rare case --- in middle of loading class, loading another class. The result is a CircularityError. When first class is in loading, in vm we put JarLoader$2 on place holder table, then we start the defineClass, which calls transform, begins loading the second class so go along the same routine for loading JarLoader$2 first, found it already in placeholder table. A CircularityError is thrown. >>>>>> Fix: The test case should not call loading class with same class loader in same thread from same jar in 'transform' method. I modify it loading with system class loader and we expect see ClassNotFoundException. Detail see bug comments. >>>>>> >>>>>> Thanks >>>>>> Yumin * >>>>> >>>> >>> >> > From yumin.qi at oracle.com Fri Oct 31 23:55:57 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 31 Oct 2014 16:55:57 -0700 Subject: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError In-Reply-To: <0FB37288-5995-4E0B-B005-E00A4FB3B22A@oracle.com> References: <543C591E.8010602@oracle.com> <544AB477.4000204@oracle.com> <544ADC07.6080904@oracle.com> <544AE76A.9030701@oracle.com> <544E5123.1060202@oracle.com> <544E8844.1070907@oracle.com> <0FB37288-5995-4E0B-B005-E00A4FB3B22A@oracle.com> Message-ID: <5454218D.40009@oracle.com> Karen, Thanks for your detail message for debugging. Yes, from my debugging, the exception did happen in TestThread other than main thread. I have no idea why in the end the exception was reported in main thread. You mention So that change to the test would be: in TestTransformer: if (loader != null) { if (tName.equals("TestThread")) { { loadClasses(3); } } return null; } The loader is the one defined in the test case, right? The system class loader is never null. I will try this change, let's see if it can work it out. Thanks Yumin On 10/31/2014 3:29 PM, Karen Kinnear wrote: > Yumin, > > From your earlier exception stack trace (many thanks) you reported: > > Exception in thread "main" java.lang.ClassCircularityError: (no - I don't know why this is in thread "main") > sun/misc/URLClassPath$JarLoader$2 > at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:771) > at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:843) > at sun.misc.URLClassPath.getResource(URLClassPath.java:199) > at java.net.URLClassLoader$1.run(URLClassLoader.java:364) > at java.net.URLClassLoader$1.run(URLClassLoader.java:361) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:360) > at java.lang.ClassLoader.loadClass(ClassLoader.java:426) > at java.lang.ClassLoader.loadClass(ClassLoader.java:359) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:340) > at ParallelTransformerLoaderApp.loadClasses(ParallelTransformerLoaderApp.java:83) > at ParallelTransformerLoaderApp.main(ParallelTransformerLoaderApp.java:45) > > > So I ran with -XX:AbortVMOnException=java.lang.ClassCircularityError -XX:+ShowMessageBoxOnError to get > a log file and stack trace. See my instructions below on how to do that. > > I did this, attached a debugger, which didn't help enough since I needed to see the java stack frames, > and got an hs_err_log also, so the stack traces came from the error log. > > The stack trace was on Thread 2, which in the hs_err_log was TestThread (which makes sense for what the test logic says). > See later in email for stack traces from Thread 2. > > Summary of stack trace: > > TestThread: > loadClasses(#) -> forName(TestClass#, URLClassLoader) > vm calls out to URLClassLoader.loadClass(String) which is inherited from java.lang.ClassLoader.loadClass(String) > ... calls java.net.URLClassLoader.findClass(...) which calls > DoPrivileged java.net.URLClassLoader$1.run which calls > sun.misc.URLClassPath.getResource(name, false) which calls > sun.misc.URLClassPath$JarLoader.getResource which calls > sun.misc.URLClassPath$JarLoader.checkResource which tries to call sun.misc.URLClassPath$JarLoader$2 > - and then the transformer jumps in with loadClasses(# (which we know is 3) and walks the same logic which tries to load sun.misc.URLClassPath$JarLoader$2 again > > Note that in the placeholder table information that Yumin printed, the circularity error is on sun.misc.URLClassPath$JarLoader$2 with the null == boot loader, which > makes sense -- that is the appropriate defining loader, and therefore the one the CFLH would intercept during the defineClass phase. > > In the sun.misc.URLClassPath.java file, in the class JarLoader, in the method checkResource > ... return new Resource() { ... } > -- I do not know why that generates sun.misc.URLClassPath$JarLoader$1, $2 and $3 at build time or when that was added. > I would guess that is when the bug started happening. > > When I have a successful run, sun.misc.URLClassPath$JarLoader$2 loads before any TestClass1 loads. > > My belief is that the point of the test is to test parallel class loading for URL class loaders. > I don't think the point is to test the bootstrap class loader, nor to test bootstrapping - i.e. running the agent before > we have loaded sufficient classes to allow loading URLClassLoader classes. > > What I suggested to Yumin that he try would be to change the test to NOT intercept boot loader loads, so that sun.misc.URLClassPath$JarLoader$# > can load which will in turn allow classes loaded by a URLClassLoader subclass to load. > > So that change to the test would be: > in TestTransformer: > if (loader != null) { > if (tName.equals("TestThread")) { > { > loadClasses(3); > } > } > return null; > } > // I also suspect with that change, we can remove the sleep loop > Note: there was a printed message which said that the Thread "Signal Dispatcher" has called transform(), which I > ignored, however it is good that we don't call loadClass on that thread - which is part of what the sleep loop does - > but that would be handled by the boot loader screening above > > Alternatively we can preload the URLClassPath classes, but I don't think we want to do that, or > we can have the agent explicitly screen on a variety of jdk bootstrapping classes. But I think the cleaner > solution is to screen on the boot loader. > > Does that make any sense to others? > > thanks, > Karen > > p.s. How to run with hotspot flags (jtreg has a -show:rerun option, but with a shell script in the test, this is more complex, so > the following should be easier): > > So what I did was run the test once for it to pass (not your script, but just once with jtreg) so that it generated > the $DST/work directory. > I then created a rerun.csh script - attached - you can modify for your own $DST directory. > I used it to be able to quickly rerun the test without the jtreg framework and compile time etc. but mostly > to be able to actually add hotspot command-line flags. > > > > > p.p.s. details from the error log (let me know if you want me to attach the error log to the bug report) > > note: error log shows last 10 events including: > Event: 0.928 loading class sun/misc/URLClassPath$JarLoader$2 > Event: 0.928 loading class TestClass3 > Event: 0.929 loading class TestClass3 done > Event: 0.929 loading class java/lang/ClassCircularityError > Event: 0.929 loading class java/lang/ClassCircularityError done > > TestThread > > java frames: > > j sun.misc.URLClassPath$JarLoader.checkResource(Ljava/lang/String;ZLjava/util/jar/JarEntry;)Lsun/misc/Resource;+42 > j sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+54 > j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53 > j java.net.URLClassLoader$1.run()Ljava/lang/Class;+26 > j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 > v ~StubRoutines::call_stub > j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 > j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 > v ~StubRoutines::call_stub > j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0 > j java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49 > j ParallelTransformerLoaderAgent$TestTransformer.loadClasses(I)V+25 > j ParallelTransformerLoaderAgent$TestTransformer.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[B)[B+81 > j sun.instrument.TransformerManager.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[B)[B+50 > j sun.instrument.InstrumentationImpl.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[BZ)[B+34 > v ~StubRoutines::call_stub > j sun.misc.URLClassPath$JarLoader.checkResource(Ljava/lang/String;ZLjava/util/jar/JarEntry;)Lsun/misc/Resource;+42 > j sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+54 > j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53 > j java.net.URLClassLoader$1.run()Ljava/lang/Class;+26 > j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 > v ~StubRoutines::call_stub > j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 > j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 > v ~StubRoutines::call_stub > j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0 > j java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49 > j ParallelTransformerLoaderApp.loadClasses(I)V+25 > j ParallelTransformerLoaderApp$TestThread.run()V+4 > v ~StubRoutines::call_stub > > > > > detailed frames: > > V [libjvm.so+0x760f5a] Exceptions::_throw_msg(Thread*, char const*, int, Symbol*, char const*)+0x7c > V [libjvm.so+0xce005c] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x7d8 > V [libjvm.so+0xcde9e5] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x26d > V [libjvm.so+0xcde435] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x39 > V [libjvm.so+0x690fbc] ConstantPool::klass_at_impl(constantPoolHandle, int, Thread*)+0x3cc > V [libjvm.so+0x5398cb] ConstantPool::klass_at(int, Thread*)+0x55 > V [libjvm.so+0x8b1f3c] InterpreterRuntime::_new(JavaThread*, ConstantPool*, int)+0x14a > j sun.misc.URLClassPath$JarLoader.checkResource(Ljava/lang/String;ZLjava/util/jar/JarEntry;)Lsun/misc/Resource;+42 > j sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+54 > j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53 > j java.net.URLClassLoader$1.run()Ljava/lang/Class;+26 > j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 > v ~StubRoutines::call_stub > V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 > V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a > V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d > V [libjvm.so+0x972a80] JVM_DoPrivileged+0x63d > j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 > j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 > v ~StubRoutines::call_stub > V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 > V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a > V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d > V [libjvm.so+0x8c1ec7] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x1cb > V [libjvm.so+0x8c2086] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0xb0 > V [libjvm.so+0xce2096] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x4ea > V [libjvm.so+0xce00a8] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x824 > V [libjvm.so+0xcde9e5] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x26d > V [libjvm.so+0xcde435] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x39 > V [libjvm.so+0x98c89e] find_class_from_class_loader(JNIEnv_*, Symbol*, unsigned char, Handle, Handle, unsigned char, Thread*)+0x49 > V [libjvm.so+0x96f681] JVM_FindClassFromCaller+0x39d > C [libjava.so+0xdfd0] Java_java_lang_Class_forName0+0x130 > j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0 > j java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49 > j ParallelTransformerLoaderAgent$TestTransformer.loadClasses(I)V+25 > j ParallelTransformerLoaderAgent$TestTransformer.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[B)[B+81 > j sun.instrument.TransformerManager.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[B)[B+50 > j sun.instrument.InstrumentationImpl.transform(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[BZ)[B+34 > v ~StubRoutines::call_stub > V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 > V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a > V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d > V [libjvm.so+0x911bfb] jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x3cd > V [libjvm.so+0x916918] jni_CallObjectMethod+0x388 > C [libinstrument.so+0x4eb5] transformClassFile+0x1e5 > C [libinstrument.so+0x1e06] eventHandlerClassFileLoadHook+0x96 > V [libjvm.so+0xa04afa] JvmtiClassFileLoadHookPoster::post_to_env(JvmtiEnv*, bool)+0x1a8 > V [libjvm.so+0xa0485e] JvmtiClassFileLoadHookPoster::post_all_envs()+0x8a > V [libjvm.so+0xa047c6] JvmtiClassFileLoadHookPoster::post()+0x18 > V [libjvm.so+0x9fb6e1] JvmtiExport::post_class_file_load_hook(Symbol*, Handle, Handle, unsigned char**, unsigned char**, JvmtiCachedClassFileData**)+0x85 > V [libjvm.so+0x5cd17d] ClassFileParser::parseClassFile(Symbol*, ClassLoaderData*, Handle, KlassHandle, GrowableArray*, TempNewSymbol&, bool, Thread*)+0x2af > V [libjvm.so+0x5dd441] ClassFileParser::parseClassFile(Symbol*, ClassLoaderData*, Handle, TempNewSymbol&, bool, Thread*)+0x95 > V [libjvm.so+0x5daf03] ClassLoader::load_classfile(Symbol*, Thread*)+0x2ed > V [libjvm.so+0xce1cc4] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x118 > V [libjvm.so+0xce00a8] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x824 > V [libjvm.so+0xcde9e5] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x26d > V [libjvm.so+0xcde435] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x39 > V [libjvm.so+0x690fbc] ConstantPool::klass_at_impl(constantPoolHandle, int, Thread*)+0x3cc > V [libjvm.so+0x5398cb] ConstantPool::klass_at(int, Thread*)+0x55 > V [libjvm.so+0x8b1f3c] InterpreterRuntime::_new(JavaThread*, ConstantPool*, int)+0x14a > j sun.misc.URLClassPath$JarLoader.checkResource(Ljava/lang/String;ZLjava/util/jar/JarEntry;)Lsun/misc/Resource;+42 > j sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+54 > j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53 > j java.net.URLClassLoader$1.run()Ljava/lang/Class;+26 > j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 > v ~StubRoutines::call_stub > V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 > V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a > V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d > V [libjvm.so+0x972a80] JVM_DoPrivileged+0x63d > j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 > j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class; > v ~StubRoutines::call_stub > V [libjvm.so+0x8c3060] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b2 > V [libjvm.so+0xba06bc] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a > V [libjvm.so+0x8c29a7] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d > V [libjvm.so+0x8c1ec7] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x1cb > V [libjvm.so+0x8c2086] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0xb0 > V [libjvm.so+0xce2096] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x4ea > V [libjvm.so+0xce00a8] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x824 > V [libjvm.so+0xcde9e5] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x26d > V [libjvm.so+0xcde435] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x39 > V [libjvm.so+0x98c89e] find_class_from_class_loader(JNIEnv_*, Symbol*, unsigned char, Handle, Handle, unsigned char, Thread*)+0x49 > V [libjvm.so+0x96f681] JVM_FindClassFromCaller+0x39d > C [libjava.so+0xdfd0] Java_java_lang_Class_forName0+0x130 > j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0 > j java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49 > j ParallelTransformerLoaderApp.loadClasses(I)V+25 > ...... > > > > > > > > > > > > > > > On Oct 27, 2014, at 2:00 PM, serguei.spitsyn at oracle.com wrote: > >> Ok. >> >> Thanks, Dan! >> Serguei >> >> >> On 10/27/14 7:05 AM, Daniel D. Daugherty wrote: >>>> The test case was added by Dan. >>>> We may want to ask him to clarify the test case purpose. >>>> (added Dan to the to-list) >>> Here's the changeset that added the test: >>> >>> $ hg log -v -r bca8bf23ac59 test/java/lang/instrument/ParallelTransformerLoader.sh >>> changeset: 132:bca8bf23ac59 >>> user: dcubed >>> date: Mon Mar 24 15:05:09 2008 -0700 >>> files: test/java/lang/instrument/ParallelTransformerLoader.sh test/java/lang/instrument/ParallelTransformerLoaderAgent.java test/java/lang/instrument/ParallelTransformerLoaderApp.java test/java/lang/instrument/TestClass1.java test/java/lang/instrument/TestClass2.java test/java/lang/instrument/TestClass3.java >>> description: >>> 5088398: 3/2 java.lang.instrument TCK test deadlock (test11) >>> Summary: Add regression test for single-threaded bootstrap classloader. >>> Reviewed-by: sspitsyn >>> >>> >>> Based on my e-mail archive for this bug and from the bug report itself, >>> it looks like we got this test from Wily Labs. The original bug was a >>> deadlock that stopped being reproducible after: >>> >>> Karen fixed the bootstrap class loader to work in parallel via: >>> >>> 4997893 4/5 Investigate allowing bootstrap loader to work in parallel >>> >>> with that fix in place the deadlock no longer reproduces. >>> I'm planning to use this bug as the vehicle for getting >>> the test program into the INSTRUMENT_REGRESSION test suite. >>> >>> *** (#2 of 2): 2008-02-29 18:20:17 GMT+00:00 daniel.daugherty at sun.com >>> >>> >>> A careful reading of JDK-5088398 might reveal the intentions of this test... >>> >>> Dan >>> >>> >>> On 10/24/14 5:57 PM, serguei.spitsyn at oracle.com wrote: >>>> Yumin, >>>> >>>> On 10/24/14 4:08 PM, Yumin Qi wrote: >>>>> Serguei, >>>>> >>>>> Thanks for your comments. >>>>> This test happens intermittently, but now it can repeat with 8/9. >>>>> Loading TestClass1 in main thread while loading TestClass2 in TestThread in parallel. They both will call transform since TestClass[1-3] are loaded via agent. When loading TestClass2, it will call loading TestClass3 in TestThread. >>>>> Note in the main thread, for loop: >>>>> >>>>> for (int i = 0; i < kNumIterations; i++) >>>>> { >>>>> // load some classes from multiple threads (this thread and one other) >>>>> Thread testThread = new TestThread(2); >>>>> testThread.start(); >>>>> loadClasses(1); >>>>> >>>>> // log that it completed and reset for the next iteration >>>>> testThread.join(); >>>>> System.out.print("."); >>>>> ParallelTransformerLoaderAgent.generateNewClassLoader(); >>>>> } >>>>> >>>>> The loader got renewed after testThread.join(). So both threads are using the exact same class loader. >>>> You are right, thanks. >>>> It means that all three classes (TesClass1, TestClass2 and TestClass3) >>>> are loaded by the same class loader in each iteration. >>>> >>>> However, I see more cases when the TestClass3 gets loaded. >>>> It happens in a CFLH event when any other class (not TestClass*) in the system is loaded. >>>> The class loading thread can be any, not only "main" or "TestClass" thread. >>>> I suspect this test case mostly targets class loading that happens on other threads. >>>> It is because of the lines: >>>> // In 160_03 and older, transform() is called >>>> // with the "system_loader_lock" held and that >>>> // prevents the bootstrap class loaded from >>>> // running in parallel. If we add a slight sleep >>>> // delay here when the transform() call is not >>>> // main or TestThread, then the deadlock in >>>> // 160_03 and older is much more reproducible. >>>> if (!tName.equals("main") && !tName.equals("TestThread")) { >>>> System.out.println("Thread '" + tName + >>>> "' has called transform()"); >>>> try { >>>> Thread.sleep(500); >>>> } catch (InterruptedException ie) { >>>> } >>>> } >>>> >>>> What about the following? >>>> >>>> In the ParallelTransformerLoaderAgent.java make this change: >>>> if (!tName.equals("main")) >>>> => if (tName.equals("TestThread")) >>>> >>>> Does such updated test still failing? >>>> >>>>> After create a new class loader, next loop will use the loader. This is why quite often on the stack trace we can see it resolves JarLoader$2. >>>>> >>>>> I am not quite understand the test case either. Loading TestClass3 inside transform using the same classloader will cause call to transform again and form a circle. Nonetheless, if we see TestClass2 already loaded, the loop will end but that still is a risk. >>>> In fact, I don't like that the test loads the class TestClass3 at the TestClass3 CFLH event. >>>> However, it is interesting to know why we did not see (is it the case?) this issue before. >>>> Also, it is interesting why the test stops failing with you fix (replacing loader with SystemClassLoader). >>>> >>>> The test case was added by Dan. >>>> We may want to ask him to clarify the test case purpose. >>>> (added Dan to the to-list) >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 10/24/2014 1:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> Below is some analysis to make sure I understand the test scenario correctly. >>>>>> >>>>>> The ParallelTransformerLoaderApp.main() executes a 1000 iteration loop. >>>>>> At each iteration it does: >>>>>> - creates and starts a new TestThread >>>>>> - loads TestClass1 with the current class loader: ParallelTransformerLoaderAgent.getClassLoader() >>>>>> - changes the current class loader with new one: ParallelTransformerLoaderAgent.generateNewClassLoader() >>>>>> >>>>>> The TestThread loads the TestClass2 concurrently with the main thread. >>>>>> >>>>>> At the CFLH events, the ParallelTransformerLoaderAgent does the class retransformation. >>>>>> If the thread loading the class is not "main", it loads the class TestClass3 >>>>>> with the current class loader ParallelTransformerLoaderAgent.getClassLoader(). >>>>>> >>>>>> Sometimes, the TestClass2 and TestClass3 are loaded by the same class loader recursively. >>>>>> It happens if the class loader has not been changed between loading TestClass2 and TestClass3 classes. >>>>>> >>>>>> I'm not convinced yet the test is incorrect. >>>>>> And it is not clear why do we get a ClassCircularityError. >>>>>> >>>>>> Please, let me know if the above understanding is wrong. >>>>>> I also see the reply from David and share his concerns. >>>>>> >>>>>> It is not clear if this failure is a regression. >>>>>> Did we observe this issue before? >>>>>> If - NOT then when and why had this failure started to appear? >>>>>> >>>>>> Unfortunately, it is impossible to look at the test run history at the moment. >>>>>> The Aurora is at a maintenance. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 10/13/14 3:58 PM, Yumin Qi wrote: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038468 >>>>>>> webrev:*http://cr.openjdk.java.net/~minqi/8038468/webrev00/ >>>>>>> >>>>>>> the bug marked as confidential so post the webrev internally. >>>>>>> >>>>>>> Problem: The test case tries to load a class from the same jar via agent in the middle of loading another class from the jar via same class loader in same thread. The call happens in transform which is a rare case --- in middle of loading class, loading another class. The result is a CircularityError. When first class is in loading, in vm we put JarLoader$2 on place holder table, then we start the defineClass, which calls transform, begins loading the second class so go along the same routine for loading JarLoader$2 first, found it already in placeholder table. A CircularityError is thrown. >>>>>>> Fix: The test case should not call loading class with same class loader in same thread from same jar in 'transform' method. I modify it loading with system class loader and we expect see ClassNotFoundException. Detail see bug comments. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin *