From erik.joelsson at oracle.com Thu Jan 2 07:57:07 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 2 Jan 2020 08:57:07 +0100 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com> Message-ID: <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com> Build files look good. /Erik On 2019-12-24 19:22, Sergey Bylokhov wrote: > Hello. > > Here is an updated version: > ? Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 > ? Patch (2 Mb): > http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch > ? Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/ > > ?- "jdk.internal.vm.compiler" is removed from the patch. > ?- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018" > > On 12/22/19 11:24 pm, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 15. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 >> Patch (2 Mb): >> http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch >> Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 >> >> I have updated the source code copyrights by the >> "update_copyright_year.sh" >> script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 >> because of: "JDK-8187443: Forest Consolidation: Move files to unified >> layout" >> which touched all files. >> >> > > From Sergey.Bylokhov at oracle.com Thu Jan 2 12:02:14 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Jan 2020 15:02:14 +0300 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com> <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com> Message-ID: <0caab700-28e3-16e7-db00-b698557443f0@oracle.com> I guess it is too late to fix it, will need to update the files at the end of 2020. On 1/2/20 10:57 am, Erik Joelsson wrote: > Build files look good. > > /Erik > > On 2019-12-24 19:22, Sergey Bylokhov wrote: >> Hello. >> >> Here is an updated version: >> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 >> ? Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch >> ? Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/ >> >> ?- "jdk.internal.vm.compiler" is removed from the patch. >> ?- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018" >> >> On 12/22/19 11:24 pm, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for JDK 15. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 >>> Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch >>> Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 >>> >>> I have updated the source code copyrights by the "update_copyright_year.sh" >>> script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 >>> because of: "JDK-8187443: Forest Consolidation: Move files to unified layout" >>> which touched all files. >>> >>> >> >> -- Best regards, Sergey. From vicente.romero at oracle.com Thu Jan 2 18:41:34 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 2 Jan 2020 13:41:34 -0500 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier Message-ID: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> Hi, Please review a simple fix to a bug in the records code. Basically the spec allows record components to redundantly declare the `final` modifier. The current implementation is not allowing this. This patch is fixing this issue. Thanks, Vicente http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8236598 From vicente.romero at oracle.com Thu Jan 2 19:42:27 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 2 Jan 2020 14:42:27 -0500 Subject: RFR: JDK-8236544: Confusing javac message: return type of accessor method abc() is not compatible with type of record component number Message-ID: Hi, Please review this very simple change to an error message related to records. The patch makes the error message more specific as the spec doesn't allow an accessor method to declare a return type other than the same declared by the corresponding record component. The current error message is referring to compatibility between types instead of exact match which is what the spec allows, Thanks, Vicente http://cr.openjdk.java.net/~vromero/8236544/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8236544 From paul.sandoz at oracle.com Thu Jan 2 19:46:31 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Jan 2020 11:46:31 -0800 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> Message-ID: If you allow redundant declaration of ?final? would the same reasoning apply to ?private?? I notice the spec does not specify an optionally private modifier but does declare that the associated implicit field is private. It feels inconsistent. Did you consider the opposite direction and change the spec? Paul. > On Jan 2, 2020, at 10:41 AM, Vicente Romero wrote: > > Hi, > > Please review a simple fix to a bug in the records code. Basically the spec allows record components to redundantly declare the `final` modifier. The current implementation is not allowing this. This patch is fixing this issue. > > Thanks, > Vicente > > http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8236598 From forax at univ-mlv.fr Thu Jan 2 20:17:46 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 2 Jan 2020 21:17:46 +0100 (CET) Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> Message-ID: <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "Vicente Romero" > Cc: "compiler-dev" > Envoy?: Jeudi 2 Janvier 2020 20:46:31 > Objet: Re: RFR: JDK-8236598: javac rejects record component with 'final' modifier > If you allow redundant declaration of ?final? would the same reasoning apply to > ?private?? > > I notice the spec does not specify an optionally private modifier but does > declare that the associated implicit field is private. > > It feels inconsistent. Did you consider the opposite direction and change the > spec? > > Paul. Hi Paul, the keywords apply on the record components, not on the generated fields. Given a record component is always accessible if the class itself is accessible, "private" makes no sense in that case. And about allowing final or not ? I don't know. R?mi > >> On Jan 2, 2020, at 10:41 AM, Vicente Romero wrote: >> >> Hi, >> >> Please review a simple fix to a bug in the records code. Basically the spec >> allows record components to redundantly declare the `final` modifier. The >> current implementation is not allowing this. This patch is fixing this issue. >> >> Thanks, >> Vicente >> >> http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8236598 From paul.sandoz at oracle.com Thu Jan 2 20:30:40 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Jan 2020 12:30:40 -0800 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> Message-ID: > On Jan 2, 2020, at 12:17 PM, Remi Forax wrote: > > ----- Mail original ----- >> De: "Paul Sandoz" >> ?: "Vicente Romero" >> Cc: "compiler-dev" >> Envoy?: Jeudi 2 Janvier 2020 20:46:31 >> Objet: Re: RFR: JDK-8236598: javac rejects record component with 'final' modifier > >> If you allow redundant declaration of ?final? would the same reasoning apply to >> ?private?? >> >> I notice the spec does not specify an optionally private modifier but does >> declare that the associated implicit field is private. >> >> It feels inconsistent. Did you consider the opposite direction and change the >> spec? >> >> Paul. > > Hi Paul, > the keywords apply on the record components, not on the generated fields. > Given a record component is always accessible if the class itself is accessible, "private" makes no sense in that case. > Ah, I see, thanks, it?s easy to fall into the trap of field rather than component. Paul. > And about allowing final or not ? > I don't know. > > R?mi > >> >>> On Jan 2, 2020, at 10:41 AM, Vicente Romero wrote: >>> >>> Hi, >>> >>> Please review a simple fix to a bug in the records code. Basically the spec >>> allows record components to redundantly declare the `final` modifier. The >>> current implementation is not allowing this. This patch is fixing this issue. >>> >>> Thanks, >>> Vicente >>> >>> http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8236598 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jan 3 01:18:06 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 3 Jan 2020 01:18:06 +0000 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> Message-ID: <67086b28-1b8e-7b6b-ead5-0e9ab30a4015@oracle.com> Looks good Maurizio On 02/01/2020 18:41, Vicente Romero wrote: > Hi, > > Please review a simple fix to a bug in the records code. Basically the > spec allows record components to redundantly declare the `final` > modifier. The current implementation is not allowing this. This patch > is fixing this issue. > > Thanks, > Vicente > > http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8236598 From maurizio.cimadamore at oracle.com Fri Jan 3 01:26:59 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 3 Jan 2020 01:26:59 +0000 Subject: RFR: JDK-8236544: Confusing javac message: return type of accessor method abc() is not compatible with type of record component number In-Reply-To: References: Message-ID: Looks good - consider flipping from negative to positive, and replacing "identical" with "match", as in: "return type of accessor method {0} must match the type of record component {1}" If you go down this path, I see this other key that uses related wording (and you might update that to, to use 'match'): 3501 compiler.misc.type.must.be.identical.to.corresponding.record.component.type=\ 3502 type must be identical to corresponding record component type\ e.g. "type must match that of the corresponding record component" (bringing this up because the "identical" word appears nowhere else in the javac error messages) Maurizio On 02/01/2020 19:42, Vicente Romero wrote: > Hi, > > Please review this very simple change to an error message related to > records. The patch makes the error message more specific as the spec > doesn't allow an accessor method to declare a return type other than > the same declared by the corresponding record component. The current > error message is referring to compatibility between types instead of > exact match which is what the spec allows, > > Thanks, > Vicente > > http://cr.openjdk.java.net/~vromero/8236544/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8236544 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jan 3 15:56:21 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 3 Jan 2020 10:56:21 -0500 Subject: RFR: JDK-8236544: Confusing javac message: return type of accessor method abc() is not compatible with type of record component number In-Reply-To: References: Message-ID: Hi Maurizio, Thanks for the review, I will update the patch accordingly before pushing, Vicente On 1/2/20 8:26 PM, Maurizio Cimadamore wrote: > > Looks good - consider flipping from negative to positive, and > replacing "identical" with "match", as in: > > "return type of accessor method {0} must match the type of record > component {1}" > > If you go down this path, I see this other key that uses related > wording (and you might update that to, to use 'match'): > > 3501 compiler.misc.type.must.be.identical.to.corresponding.record.component.type=\ > 3502 type must be identical to corresponding record component type\ > > e.g. > > "type must match that of the corresponding record component" > > (bringing this up because the "identical" word appears nowhere else in > the javac error messages) > > Maurizio > > On 02/01/2020 19:42, Vicente Romero wrote: >> Hi, >> >> Please review this very simple change to an error message related to >> records. The patch makes the error message more specific as the spec >> doesn't allow an accessor method to declare a return type other than >> the same declared by the corresponding record component. The current >> error message is referring to compatibility between types instead of >> exact match which is what the spec allows, >> >> Thanks, >> Vicente >> >> http://cr.openjdk.java.net/~vromero/8236544/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8236544 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 6 20:25:07 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 6 Jan 2020 15:25:07 -0500 Subject: RFR: JDK_14 8234445: spurious error message for record constructors with receiver parameters Message-ID: <3112e80a-5737-b775-8637-6b5529bbe612@oracle.com> Please review the patch to fix [1] in JDK 14. I mistakingly pushed the code initially to 15 when it should have been pushed to 14. The patch applies cleanly. The fix in JDK 15 can be is at [3] and the review thread can be accessed at [4], Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8234445 [2] http://cr.openjdk.java.net/~vromero/8234445_jdk14/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8236276 [4] http://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014111.html From vicente.romero at oracle.com Mon Jan 6 20:44:01 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 6 Jan 2020 15:44:01 -0500 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> Message-ID: On 1/2/20 3:17 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Paul Sandoz" >> ?: "Vicente Romero" >> Cc: "compiler-dev" >> Envoy?: Jeudi 2 Janvier 2020 20:46:31 >> Objet: Re: RFR: JDK-8236598: javac rejects record component with 'final' modifier >> If you allow redundant declaration of ?final? would the same reasoning apply to >> ?private?? >> >> I notice the spec does not specify an optionally private modifier but does >> declare that the associated implicit field is private. >> >> It feels inconsistent. Did you consider the opposite direction and change the >> spec? >> >> Paul. > Hi Paul, > the keywords apply on the record components, not on the generated fields. > Given a record component is always accessible if the class itself is accessible, "private" makes no sense in that case. > > And about allowing final or not ? I guess we should discuss tomorrow about this, allowing final or not, given that it is a redundant declaration that could bring some confusion it could make sense to do not allow it > I don't know. > > R?mi Vicente > >>> On Jan 2, 2020, at 10:41 AM, Vicente Romero wrote: >>> >>> Hi, >>> >>> Please review a simple fix to a bug in the records code. Basically the spec >>> allows record components to redundantly declare the `final` modifier. The >>> current implementation is not allowing this. This patch is fixing this issue. >>> >>> Thanks, >>> Vicente >>> >>> http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8236598 From vicente.romero at oracle.com Mon Jan 6 22:25:22 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 6 Jan 2020 17:25:22 -0500 Subject: RFR JDK-14: 8236266: change error message for the case when a class extends j.l.Record Message-ID: Please review the patch to fix [1] in JDK 14.? I pushed the code initially to 15 when it should have been pushed to 14.? The patch applies cleanly.? The fix in JDK 15 can be is at [3] and the review thread can be accessed at [4], Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236266 [2] http://cr.openjdk.java.net/~vromero/8236266-jdk14/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8236279 [4]http://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014120.html From vicente.romero at oracle.com Mon Jan 6 22:47:04 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 6 Jan 2020 17:47:04 -0500 Subject: RFR: JDK-14: 8236544: confusing error message: return type of accessor method is not compatible with type of record component Message-ID: <9a69ed14-e48e-a168-03c1-f67f7751c7d2@oracle.com> Please review the patch to fix [1] in JDK 14.? I pushed the code initially to 15 when it should have been pushed to 14.? The patch applies cleanly.? The fix in JDK 15 can be is at [3] and the review thread can be accessed at [4], Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236544 [2] http://cr.openjdk.java.net/~vromero/8236544_jdk_14/webrev.00/ [3] https://hg.openjdk.java.net/jdk/jdk/rev/b9293de7bdff [4] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-January/014155.html From maurizio.cimadamore at oracle.com Mon Jan 6 23:09:05 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 6 Jan 2020 23:09:05 +0000 Subject: RFR JDK-14: 8236266: change error message for the case when a class extends j.l.Record In-Reply-To: References: Message-ID: Looks good Maurizio On 06/01/2020 22:25, Vicente Romero wrote: > Please review the patch to fix [1] in JDK 14.? I pushed the code > initially to 15 when it should have been pushed to 14.? The patch > applies cleanly.? The fix in JDK 15 can be is at [3] and the review > thread can be accessed at [4], > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236266 > [2] http://cr.openjdk.java.net/~vromero/8236266-jdk14/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8236279 > [4]http://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014120.html > From maurizio.cimadamore at oracle.com Mon Jan 6 23:10:57 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 6 Jan 2020 23:10:57 +0000 Subject: RFR: JDK-14: 8236544: confusing error message: return type of accessor method is not compatible with type of record component In-Reply-To: <9a69ed14-e48e-a168-03c1-f67f7751c7d2@oracle.com> References: <9a69ed14-e48e-a168-03c1-f67f7751c7d2@oracle.com> Message-ID: <60da2d46-32c9-34d5-8bd4-43be85f8039d@oracle.com> Looks good - I'm not sure about the change in the copyright header - I wonder if it could mess with the auto-merge with 15. Maybe leave that part out? Maurizio On 06/01/2020 22:47, Vicente Romero wrote: > Please review the patch to fix [1] in JDK 14.? I pushed the code > initially to 15 when it should have been pushed to 14.? The patch > applies cleanly.? The fix in JDK 15 can be is at [3] and the review > thread can be accessed at [4], > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236544 > [2] http://cr.openjdk.java.net/~vromero/8236544_jdk_14/webrev.00/ > [3] https://hg.openjdk.java.net/jdk/jdk/rev/b9293de7bdff > [4] > http://mail.openjdk.java.net/pipermail/compiler-dev/2020-January/014155.html From maurizio.cimadamore at oracle.com Mon Jan 6 23:11:37 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 6 Jan 2020 23:11:37 +0000 Subject: RFR: JDK_14 8234445: spurious error message for record constructors with receiver parameters In-Reply-To: <3112e80a-5737-b775-8637-6b5529bbe612@oracle.com> References: <3112e80a-5737-b775-8637-6b5529bbe612@oracle.com> Message-ID: Looks good Maurizio On 06/01/2020 20:25, Vicente Romero wrote: > Please review the patch to fix [1] in JDK 14. I mistakingly pushed the > code initially to 15 when it should have been pushed to 14. The patch > applies cleanly. The fix in JDK 15 can be is at [3] and the review > thread can be accessed at [4], > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8234445 > [2] http://cr.openjdk.java.net/~vromero/8234445_jdk14/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8236276 > [4] > http://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014111.html From vicente.romero at oracle.com Tue Jan 7 00:42:25 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 6 Jan 2020 19:42:25 -0500 Subject: RFR: JDK-14: 8236544: confusing error message: return type of accessor method is not compatible with type of record component In-Reply-To: <60da2d46-32c9-34d5-8bd4-43be85f8039d@oracle.com> References: <9a69ed14-e48e-a168-03c1-f67f7751c7d2@oracle.com> <60da2d46-32c9-34d5-8bd4-43be85f8039d@oracle.com> Message-ID: <7dd5b170-4821-ece6-2501-0a85fc32f732@oracle.com> sure I will, Vicente On 1/6/20 6:10 PM, Maurizio Cimadamore wrote: > Looks good - I'm not sure about the change in the copyright header - I > wonder if it could mess with the auto-merge with 15. Maybe leave that > part out? > > Maurizio > > On 06/01/2020 22:47, Vicente Romero wrote: >> Please review the patch to fix [1] in JDK 14.? I pushed the code >> initially to 15 when it should have been pushed to 14.? The patch >> applies cleanly.? The fix in JDK 15 can be is at [3] and the review >> thread can be accessed at [4], >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8236544 >> [2] http://cr.openjdk.java.net/~vromero/8236544_jdk_14/webrev.00/ >> [3] https://hg.openjdk.java.net/jdk/jdk/rev/b9293de7bdff >> [4] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2020-January/014155.html From brian.goetz at oracle.com Tue Jan 7 02:06:01 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 6 Jan 2020 21:06:01 -0500 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> Message-ID: <849F0AC4-D808-427A-BD96-000F44FF32B2@oracle.com> My preference is to allow no modifiers on components at this time. Since there are none that are actually useful, none seems like the right number. Sent from my iPad > On Jan 6, 2020, at 3:44 PM, Vicente Romero wrote: > > > >> On 1/2/20 3:17 PM, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Paul Sandoz" >>> ?: "Vicente Romero" >>> Cc: "compiler-dev" >>> Envoy?: Jeudi 2 Janvier 2020 20:46:31 >>> Objet: Re: RFR: JDK-8236598: javac rejects record component with 'final' modifier >>> If you allow redundant declaration of ?final? would the same reasoning apply to >>> ?private?? >>> >>> I notice the spec does not specify an optionally private modifier but does >>> declare that the associated implicit field is private. >>> >>> It feels inconsistent. Did you consider the opposite direction and change the >>> spec? >>> >>> Paul. >> Hi Paul, >> the keywords apply on the record components, not on the generated fields. >> Given a record component is always accessible if the class itself is accessible, "private" makes no sense in that case. >> >> And about allowing final or not ? > > I guess we should discuss tomorrow about this, allowing final or not, given that it is a redundant declaration that could bring some confusion it could make sense to do not allow it > >> I don't know. >> >> R?mi > > Vicente > >> >>>> On Jan 2, 2020, at 10:41 AM, Vicente Romero wrote: >>>> >>>> Hi, >>>> >>>> Please review a simple fix to a bug in the records code. Basically the spec >>>> allows record components to redundantly declare the `final` modifier. The >>>> current implementation is not allowing this. This patch is fixing this issue. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8236598 > From amaembo at gmail.com Tue Jan 7 02:51:48 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 7 Jan 2020 09:51:48 +0700 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: <849F0AC4-D808-427A-BD96-000F44FF32B2@oracle.com> References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> <849F0AC4-D808-427A-BD96-000F44FF32B2@oracle.com> Message-ID: Btw how about finality of compact constructor parameters? I assume that if I declare the records component final and declare a compact constructor, its formal parameters become final as well. Or not? If we disable 'final' on records components, this means that compact constructor formal parameters are never final? Also, current spec draft says: It can be seen that the production for *RecordComponent* is identical in content to the production for *FormalParameter* (8.4.1 ). The following productions from 8.4.1 , 8.3 and 4.3 are shown here for convenience: If you disable 'final', this part is no longer true. With best regards, Tagir Valeev. ??, 7 ???. 2020 ?., 9:08 Brian Goetz : > My preference is to allow no modifiers on components at this time. Since > there are none that are actually useful, none seems like the right number. > > Sent from my iPad > > > On Jan 6, 2020, at 3:44 PM, Vicente Romero > wrote: > > > > > > > >> On 1/2/20 3:17 PM, Remi Forax wrote: > >> ----- Mail original ----- > >>> De: "Paul Sandoz" > >>> ?: "Vicente Romero" > >>> Cc: "compiler-dev" > >>> Envoy?: Jeudi 2 Janvier 2020 20:46:31 > >>> Objet: Re: RFR: JDK-8236598: javac rejects record component with > 'final' modifier > >>> If you allow redundant declaration of ?final? would the same reasoning > apply to > >>> ?private?? > >>> > >>> I notice the spec does not specify an optionally private modifier but > does > >>> declare that the associated implicit field is private. > >>> > >>> It feels inconsistent. Did you consider the opposite direction and > change the > >>> spec? > >>> > >>> Paul. > >> Hi Paul, > >> the keywords apply on the record components, not on the generated > fields. > >> Given a record component is always accessible if the class itself is > accessible, "private" makes no sense in that case. > >> > >> And about allowing final or not ? > > > > I guess we should discuss tomorrow about this, allowing final or not, > given that it is a redundant declaration that could bring some confusion it > could make sense to do not allow it > > > >> I don't know. > >> > >> R?mi > > > > Vicente > > > >> > >>>> On Jan 2, 2020, at 10:41 AM, Vicente Romero < > vicente.romero at oracle.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Please review a simple fix to a bug in the records code. Basically > the spec > >>>> allows record components to redundantly declare the `final` modifier. > The > >>>> current implementation is not allowing this. This patch is fixing > this issue. > >>>> > >>>> Thanks, > >>>> Vicente > >>>> > >>>> http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ > >>>> https://bugs.openjdk.java.net/browse/JDK-8236598 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue Jan 7 03:50:37 2020 From: john.r.rose at oracle.com (John Rose) Date: Mon, 6 Jan 2020 19:50:37 -0800 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> <849F0AC4-D808-427A-BD96-000F44FF32B2@oracle.com> Message-ID: On Jan 6, 2020, at 6:51 PM, Tagir Valeev wrote: > > Btw how about finality of compact constructor parameters? I assume that if I declare the records component final and declare a compact constructor, its formal parameters become final as well. Or not? If we disable 'final' on records components, this means that compact constructor formal parameters are never final? This would be an adjustment tending to make compact constructor parameters final, which is an anti-pattern. Constructor parameters are often non-final to allow the class author to perform argument projections, such as clipping or defensive copying. So final compact constructor arguments needlessly narrow the sweet spot for records. They require more ceremony to do a simple job, like array cloning. Gavin?s draft recognizes these cases when it mentions ?normalizations?, and shows the example of NonNullString. Let?s not give artificial roadblocks to such use cases by propagating an unnecessary ?final". Put another way: If for some very obscure reason you *need* constructor parameters that are final, then write out the whole constructor with full ceremony. For lambda capture, implicit finality does the job better than an explicit final modifier. (I?m glad of that feature.) ? John (and that?s final) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Tue Jan 7 15:40:50 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 7 Jan 2020 10:40:50 -0500 Subject: RFR: JDK-8236598: javac rejects record component with 'final' modifier In-Reply-To: References: <241db65d-ca24-e7a0-84a2-c6895f01fb73@oracle.com> <1859269183.235298.1577996266848.JavaMail.zimbra@u-pem.fr> <849F0AC4-D808-427A-BD96-000F44FF32B2@oracle.com> Message-ID: <20fb4c31-88f9-0390-f9a8-d6331ecc824b@oracle.com> This not only goes against how constructor parameters work in every other class, but also against the intended use for normalization: ??? record Sign(int signum) { ??????? Sign { ??????????? if (signum < -1) ??????????????? signum = -1; ??????????? else if (signum > 1) ??????????????? signum = 1; ??????? } ??? } Normalization could is most natural when it mutates the arguments, and then lets them be committed as a batch.? If these were final, then you'd have to do more (and different) gymnastics to normalize state. On 1/6/2020 9:51 PM, Tagir Valeev wrote: > Btw how about finality of compact constructor parameters? I assume > that if I declare the records component final and declare a compact > constructor, its formal parameters become final as well. Or not? If we > disable 'final' on records components, this means that compact > constructor formal parameters are never final? > > Also, current spec draft says: > > It can be seen that the production for /RecordComponent/?is identical > in content to the production for /FormalParameter/?(8.4.1 > ). > > The following productions from 8.4.1 > , > 8.3 > ?and > 4.3 > ?are > shown here for convenience: > > > If you disable 'final', this part is no longer true. > > With best regards, > Tagir Valeev. > > ??, 7 ???. 2020 ?., 9:08 Brian Goetz >: > > My preference is to allow no modifiers on components at this > time.? Since there are none that are actually useful, none seems > like the right number. > > Sent from my iPad > > > On Jan 6, 2020, at 3:44 PM, Vicente Romero > > wrote: > > > > > > > >> On 1/2/20 3:17 PM, Remi Forax wrote: > >> ----- Mail original ----- > >>> De: "Paul Sandoz" > > >>> ?: "Vicente Romero" > > >>> Cc: "compiler-dev" > > >>> Envoy?: Jeudi 2 Janvier 2020 20:46:31 > >>> Objet: Re: RFR: JDK-8236598: javac rejects record component > with 'final' modifier > >>> If you allow redundant declaration of ?final? would the same > reasoning apply to > >>> ?private?? > >>> > >>> I notice the spec does not specify an optionally private > modifier but does > >>> declare that the associated implicit field is private. > >>> > >>> It feels inconsistent. Did you consider the opposite direction > and change the > >>> spec? > >>> > >>> Paul. > >> Hi Paul, > >> the keywords apply on the record components, not on the > generated fields. > >> Given a record component is always accessible if the class > itself is accessible, "private" makes no sense in that case. > >> > >> And about allowing final or not ? > > > > I guess we should discuss tomorrow about this, allowing final or > not, given that it is a redundant declaration that could bring > some confusion it could make sense to do not allow it > > > >> I don't know. > >> > >> R?mi > > > > Vicente > > > >> > >>>> On Jan 2, 2020, at 10:41 AM, Vicente Romero > > wrote: > >>>> > >>>> Hi, > >>>> > >>>> Please review a simple fix to a bug in the records code. > Basically the spec > >>>> allows record components to redundantly declare the `final` > modifier. The > >>>> current implementation is not allowing this. This patch is > fixing this issue. > >>>> > >>>> Thanks, > >>>> Vicente > >>>> > >>>> http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ > >>>> https://bugs.openjdk.java.net/browse/JDK-8236598 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jan 7 20:18:39 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Jan 2020 15:18:39 -0500 Subject: RFR: JDK-8236692: static final fields without initializer are accepted by javac Message-ID: <7835fa07-5e87-7280-dd75-ca12f443337a@oracle.com> Please review the fix for [1] at [2], javac was failing to issue an error for code like: record R() { ??? public static final int X; } even though `X` was not initialized as the automatic code to generate initializer expressions only apply to the fields generated from the record component. The patch updates the code in Flow that analyzes compact constructors to don't bail out if the variable being analyzed is static. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236692 [2] http://cr.openjdk.java.net/~vromero/8236692/webrev.00/ From vicente.romero at oracle.com Tue Jan 7 21:50:34 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Jan 2020 16:50:34 -0500 Subject: RFR JDK-8236598: make sure that the compiler issues an error for any modifier applied to record components Message-ID: <856d0435-06f7-760f-217e-c471993625fc@oracle.com> As discussed offline the spec will be changed to remove the mention that the `final` modifier can redundantly be applied to record components. We already had a test in place to check that some modifiers couldn't be applied to record components but the list of modifiers being tested was not complete. I have increased the test to include all known modifiers. Please review the fix to make the test checking for modifiers complete. Thanks, Vicente http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8236598 From maurizio.cimadamore at oracle.com Tue Jan 7 22:31:25 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 7 Jan 2020 22:31:25 +0000 Subject: RFR JDK-8236598: make sure that the compiler issues an error for any modifier applied to record components In-Reply-To: <856d0435-06f7-760f-217e-c471993625fc@oracle.com> References: <856d0435-06f7-760f-217e-c471993625fc@oracle.com> Message-ID: <4ff28de7-bc63-d485-8d44-da1ebb2f10da@oracle.com> Looks good - I assume this should be pushed in jdk14? Maurizio On 07/01/2020 21:50, Vicente Romero wrote: > As discussed offline the spec will be changed to remove the mention > that the `final` modifier can redundantly be applied to record > components. We already had a test in place to check that some > modifiers couldn't be applied to record components but the list of > modifiers being tested was not complete. I have increased the test to > include all known modifiers. Please review the fix to make the test > checking for modifiers complete. > > Thanks, > Vicente > > http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8236598 From vicente.romero at oracle.com Tue Jan 7 23:32:16 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Jan 2020 18:32:16 -0500 Subject: RFR JDK-8236598: make sure that the compiler issues an error for any modifier applied to record components In-Reply-To: <4ff28de7-bc63-d485-8d44-da1ebb2f10da@oracle.com> References: <856d0435-06f7-760f-217e-c471993625fc@oracle.com> <4ff28de7-bc63-d485-8d44-da1ebb2f10da@oracle.com> Message-ID: yes, there is a related spec issue [1], to update the spec to remove the reference to `final` modifier as soon as it is resolved I will push this fix, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236734 On 1/7/20 5:31 PM, Maurizio Cimadamore wrote: > Looks good - I assume this should be pushed in jdk14? > > Maurizio > > On 07/01/2020 21:50, Vicente Romero wrote: >> As discussed offline the spec will be changed to remove the >> mention that the `final` modifier can redundantly be applied >> to record components. We already had a test in place to check >> that some modifiers couldn't be applied to record components >> but the list of modifiers being tested was not complete. I >> have increased the test to include all known modifiers. >> Please review the fix to make the test checking for modifiers >> complete. >> >> Thanks, >> Vicente >> >> http://cr.openjdk.java.net/~vromero/8236598/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8236598 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jan 8 03:39:05 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Jan 2020 22:39:05 -0500 Subject: RFR: JDK-8236692: static final fields without initializer are accepted by javac In-Reply-To: <7835fa07-5e87-7280-dd75-ca12f443337a@oracle.com> References: <7835fa07-5e87-7280-dd75-ca12f443337a@oracle.com> Message-ID: <2116375e-4a3b-5b88-5560-c1d9d31c18e3@oracle.com> Hi, I have updated the patch after an offline review with Maurizio, basically I have rewritten how Flow deals with the compact constructor to isolate it as a special case. The new iteration is at [1]. I have basically restored the original code for method checkInit and added a special case for the compact constructor. Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8236692/webrev.01/ On 1/7/20 3:18 PM, Vicente Romero wrote: > Please review the fix for [1] at [2], javac was failing to issue an > error for code like: > > record R() { > ??? public static final int X; > } > > even though `X` was not initialized as the automatic code to generate > initializer expressions only apply to the fields generated from the > record component. The patch updates the code in Flow that analyzes > compact constructors to don't bail out if the variable being analyzed > is static. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236692 > [2] http://cr.openjdk.java.net/~vromero/8236692/webrev.00/ From maurizio.cimadamore at oracle.com Wed Jan 8 11:38:37 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 8 Jan 2020 11:38:37 +0000 Subject: RFR: JDK-8236692: static final fields without initializer are accepted by javac In-Reply-To: <2116375e-4a3b-5b88-5560-c1d9d31c18e3@oracle.com> References: <7835fa07-5e87-7280-dd75-ca12f443337a@oracle.com> <2116375e-4a3b-5b88-5560-c1d9d31c18e3@oracle.com> Message-ID: <6a18c3cd-eb9a-c163-5dec-df47458b367b@oracle.com> The Flow patch looks great and it brings back some sanity into the code - after all adding the special case for compact constructor is not so bad, and is now called out in its own special case, which makes the code more readable. On the test - I'm not sure, why is the test source defined in two strings - as in "record R() { # }", "static final String x;" Doesn't this mean the second string will be replaced for the "#" ? But since there's only one string, why having the replacement at all? I noted this idiom in most of the negative tests. Maurizio On 08/01/2020 03:39, Vicente Romero wrote: > Hi, > > I have updated the patch after an offline review with Maurizio, > basically I have rewritten how Flow deals with the compact constructor > to isolate it as a special case. The new iteration is at [1]. I have > basically restored the original code for method checkInit and added a > special case for the compact constructor. > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8236692/webrev.01/ > > On 1/7/20 3:18 PM, Vicente Romero wrote: >> Please review the fix for [1] at [2], javac was failing to issue an >> error for code like: >> >> record R() { >> ??? public static final int X; >> } >> >> even though `X` was not initialized as the automatic code to generate >> initializer expressions only apply to the fields generated from the >> record component. The patch updates the code in Flow that analyzes >> compact constructors to don't bail out if the variable being analyzed >> is static. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8236692 >> [2] http://cr.openjdk.java.net/~vromero/8236692/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jan 8 12:30:11 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 8 Jan 2020 13:30:11 +0100 Subject: RFR (14): JDK-8236546: Yield with boolean expression and Object target type crashes javac. Message-ID: <6af9370e-de81-a8f6-e92f-fc921de45aaa@oracle.com> Code like this crashes javac in Flow: Object o = switch (s) { default -> s != null && s == s; }; The reason is that "s != null && s == s" will use split "when true" and "when false" (un/)initialized variables masks. But as the target type is not boolean, the merged (un/)initialized masks are needed. The real mistake is in using "scan" instead of "scanExpr" (which e.g. visitReturn does), so the proposal is to use "scanExpr" instead of "scan". Proposed patch: http://cr.openjdk.java.net/~jlahoda/8236546/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8236546 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Wed Jan 8 12:34:36 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 8 Jan 2020 12:34:36 +0000 Subject: RFR (14): JDK-8236546: Yield with boolean expression and Object target type crashes javac. In-Reply-To: <6af9370e-de81-a8f6-e92f-fc921de45aaa@oracle.com> References: <6af9370e-de81-a8f6-e92f-fc921de45aaa@oracle.com> Message-ID: <4109daca-ff48-4856-e09c-5f82470341ba@oracle.com> Looks good Maurizio On 08/01/2020 12:30, Jan Lahoda wrote: > Code like this crashes javac in Flow: > > Object o = switch (s) { default -> s != null && s == s; }; > > The reason is that "s != null && s == s" will use split "when true" > and "when false" (un/)initialized variables masks. But as the target > type is not boolean, the merged (un/)initialized masks are needed. The > real mistake is in using "scan" instead of "scanExpr" (which e.g. > visitReturn does), so the proposal is to use "scanExpr" instead of > "scan". > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8236546/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8236546 > > How does this look? > > Thanks, > ???? Jan From vicente.romero at oracle.com Wed Jan 8 13:40:14 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 Jan 2020 08:40:14 -0500 Subject: RFR: JDK-8236692: static final fields without initializer are accepted by javac In-Reply-To: <6a18c3cd-eb9a-c163-5dec-df47458b367b@oracle.com> References: <7835fa07-5e87-7280-dd75-ca12f443337a@oracle.com> <2116375e-4a3b-5b88-5560-c1d9d31c18e3@oracle.com> <6a18c3cd-eb9a-c163-5dec-df47458b367b@oracle.com> Message-ID: <538b8993-a0b6-f4af-c78e-e06fc84e4494@oracle.com> On 1/8/20 6:38 AM, Maurizio Cimadamore wrote: > > The Flow patch looks great and it brings back some sanity into the > code - after all adding the special case for compact constructor is > not so bad, and is now called out in its own special case, which makes > the code more readable. > > On the test - I'm not sure, why is the test source defined in two > strings - as in > > "record R() { # }", "static final String x;" > Doesn't this mean the second string will be replaced for the "#" ? yes > But since there's only one string, why having the replacement at all? > I noted this idiom in most of the negative tests. yes we can do either, although there are already other cases of one liners using this idiom > Maurizio Vicente > > On 08/01/2020 03:39, Vicente Romero wrote: >> Hi, >> >> I have updated the patch after an offline review with Maurizio, >> basically I have rewritten how Flow deals with the compact >> constructor to isolate it as a special case. The new iteration is at >> [1]. I have basically restored the original code for method checkInit >> and added a special case for the compact constructor. >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8236692/webrev.01/ >> >> On 1/7/20 3:18 PM, Vicente Romero wrote: >>> Please review the fix for [1] at [2], javac was failing to issue an >>> error for code like: >>> >>> record R() { >>> ??? public static final int X; >>> } >>> >>> even though `X` was not initialized as the automatic code to >>> generate initializer expressions only apply to the fields generated >>> from the record component. The patch updates the code in Flow that >>> analyzes compact constructors to don't bail out if the variable >>> being analyzed is static. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8236692 >>> [2] http://cr.openjdk.java.net/~vromero/8236692/webrev.00/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jan 8 15:15:38 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 8 Jan 2020 15:15:38 +0000 Subject: RFR: JDK-8236692: static final fields without initializer are accepted by javac In-Reply-To: <538b8993-a0b6-f4af-c78e-e06fc84e4494@oracle.com> References: <7835fa07-5e87-7280-dd75-ca12f443337a@oracle.com> <2116375e-4a3b-5b88-5560-c1d9d31c18e3@oracle.com> <6a18c3cd-eb9a-c163-5dec-df47458b367b@oracle.com> <538b8993-a0b6-f4af-c78e-e06fc84e4494@oracle.com> Message-ID: On 08/01/2020 13:40, Vicente Romero wrote: > > > On 1/8/20 6:38 AM, Maurizio Cimadamore wrote: >> >> The Flow patch looks great and it brings back some sanity into the >> code - after all adding the special case for compact constructor is >> not so bad, and is now called out in its own special case, which >> makes the code more readable. >> >> On the test - I'm not sure, why is the test source defined in two >> strings - as in >> >> "record R() { # }", "static final String x;" >> Doesn't this mean the second string will be replaced for the "#" ? > > yes > >> But since there's only one string, why having the replacement at all? >> I noted this idiom in most of the negative tests. > > yes we can do either, although there are already other cases of one > liners using this idiom To be clear, I'm fine for this changeset, I guess I'm more curious as to why the framework is being used in this way - to avoid multiline string? Maurizio > > >> Maurizio > > Vicente > >> >> On 08/01/2020 03:39, Vicente Romero wrote: >>> Hi, >>> >>> I have updated the patch after an offline review with Maurizio, >>> basically I have rewritten how Flow deals with the compact >>> constructor to isolate it as a special case. The new iteration is at >>> [1]. I have basically restored the original code for method >>> checkInit and added a special case for the compact constructor. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8236692/webrev.01/ >>> >>> On 1/7/20 3:18 PM, Vicente Romero wrote: >>>> Please review the fix for [1] at [2], javac was failing to issue an >>>> error for code like: >>>> >>>> record R() { >>>> ??? public static final int X; >>>> } >>>> >>>> even though `X` was not initialized as the automatic code to >>>> generate initializer expressions only apply to the fields generated >>>> from the record component. The patch updates the code in Flow that >>>> analyzes compact constructors to don't bail out if the variable >>>> being analyzed is static. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236692 >>>> [2] http://cr.openjdk.java.net/~vromero/8236692/webrev.00/ >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jan 8 16:11:45 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 Jan 2020 11:11:45 -0500 Subject: RFR: JDK-8236692: static final fields without initializer are accepted by javac In-Reply-To: References: <7835fa07-5e87-7280-dd75-ca12f443337a@oracle.com> <2116375e-4a3b-5b88-5560-c1d9d31c18e3@oracle.com> <6a18c3cd-eb9a-c163-5dec-df47458b367b@oracle.com> <538b8993-a0b6-f4af-c78e-e06fc84e4494@oracle.com> Message-ID: On 1/8/20 10:15 AM, Maurizio Cimadamore wrote: > > > On 08/01/2020 13:40, Vicente Romero wrote: >> >> >> On 1/8/20 6:38 AM, Maurizio Cimadamore wrote: >>> >>> The Flow patch looks great and it brings back some sanity into the >>> code - after all adding the special case for compact constructor is >>> not so bad, and is now called out in its own special case, which >>> makes the code more readable. >>> >>> On the test - I'm not sure, why is the test source defined in two >>> strings - as in >>> >>> "record R() { # }", "static final String x;" >>> Doesn't this mean the second string will be replaced for the "#" ? >> >> yes >> >>> But since there's only one string, why having the replacement at >>> all? I noted this idiom in most of the negative tests. >> >> yes we can do either, although there are already other cases of one >> liners using this idiom > > To be clear, I'm fine for this changeset, I guess I'm more curious as > to why the framework is being used in this way - to avoid multiline > string? > it was created around the time we started to use multiline strings. We can in a separate effort rewrite the tests to use multiline strings as much as possible > Maurizio > Vicente > >> >> >>> Maurizio >> >> Vicente >> >>> >>> On 08/01/2020 03:39, Vicente Romero wrote: >>>> Hi, >>>> >>>> I have updated the patch after an offline review with Maurizio, >>>> basically I have rewritten how Flow deals with the compact >>>> constructor to isolate it as a special case. The new iteration is >>>> at [1]. I have basically restored the original code for method >>>> checkInit and added a special case for the compact constructor. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8236692/webrev.01/ >>>> >>>> On 1/7/20 3:18 PM, Vicente Romero wrote: >>>>> Please review the fix for [1] at [2], javac was failing to issue >>>>> an error for code like: >>>>> >>>>> record R() { >>>>> ??? public static final int X; >>>>> } >>>>> >>>>> even though `X` was not initialized as the automatic code to >>>>> generate initializer expressions only apply to the fields >>>>> generated from the record component. The patch updates the code in >>>>> Flow that analyzes compact constructors to don't bail out if the >>>>> variable being analyzed is static. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236692 >>>>> [2] http://cr.openjdk.java.net/~vromero/8236692/webrev.00/ >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jan 8 21:11:15 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 Jan 2020 16:11:15 -0500 Subject: RFR: JDK-8235352: java.lang.runtime.package-info should be annotated with @PreviewFeature Message-ID: <0dcfd4f1-c307-d8fb-066c-9b862577f2c4@oracle.com> Please review this simple fix which is adding the @PreviewFeature and related doc to, new for records, file java/lang/runtime/package-info.java. Webrev is at [1] and JIRA issue at [2] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8235352/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8235352 From jonathan.gibbons at oracle.com Wed Jan 8 21:17:44 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 8 Jan 2020 13:17:44 -0800 Subject: RFR: JDK-8235352: java.lang.runtime.package-info should be annotated with @PreviewFeature In-Reply-To: <0dcfd4f1-c307-d8fb-066c-9b862577f2c4@oracle.com> References: <0dcfd4f1-c307-d8fb-066c-9b862577f2c4@oracle.com> Message-ID: <40187ae7-9c41-d0cb-6d17-d36258ec2371@oracle.com> Vicente, Given that you have put the {@preview} at the beginning, how well does this interact with javadoc and javadoc's handling of the first sentence in summary contexts? Could you generate docs and post the API bundle along with the webrev. -- Jon On 01/08/2020 01:11 PM, Vicente Romero wrote: > Please review this simple fix which is adding the @PreviewFeature and > related doc to, new for records, file > java/lang/runtime/package-info.java. Webrev is at [1] and JIRA issue > at [2] > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8235352/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8235352 From vicente.romero at oracle.com Wed Jan 8 22:13:37 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 Jan 2020 17:13:37 -0500 Subject: RFR: JDK-8235352: java.lang.runtime.package-info should be annotated with @PreviewFeature In-Reply-To: <40187ae7-9c41-d0cb-6d17-d36258ec2371@oracle.com> References: <0dcfd4f1-c307-d8fb-066c-9b862577f2c4@oracle.com> <40187ae7-9c41-d0cb-6d17-d36258ec2371@oracle.com> Message-ID: sure, please find it at [1] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8235352/specdiff.runtime/ On 1/8/20 4:17 PM, Jonathan Gibbons wrote: > Vicente, > > Given that you have put the {@preview} at the beginning, how well does > this interact with javadoc and javadoc's handling of the first > sentence in summary contexts? Could you generate docs and post the API > bundle along with the webrev. > > -- Jon > > > On 01/08/2020 01:11 PM, Vicente Romero wrote: >> Please review this simple fix which is adding the @PreviewFeature and >> related doc to, new for records, file >> java/lang/runtime/package-info.java. Webrev is at [1] and JIRA issue >> at [2] >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8235352/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8235352 > From jonathan.gibbons at oracle.com Wed Jan 8 22:16:34 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 8 Jan 2020 14:16:34 -0800 Subject: RFR: JDK-8235352: java.lang.runtime.package-info should be annotated with @PreviewFeature In-Reply-To: References: <0dcfd4f1-c307-d8fb-066c-9b862577f2c4@oracle.com> <40187ae7-9c41-d0cb-6d17-d36258ec2371@oracle.com> Message-ID: <98170cd0-ec1d-e9df-5022-ce3af2e5c2a3@oracle.com> Yeah, that's the specdiff, not the underlying API, but I can see the info I was looking for. Thanks. -- Jon On 1/8/20 2:13 PM, Vicente Romero wrote: > sure, please find it at [1] > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8235352/specdiff.runtime/ > > On 1/8/20 4:17 PM, Jonathan Gibbons wrote: >> Vicente, >> >> Given that you have put the {@preview} at the beginning, how well >> does this interact with javadoc and javadoc's handling of the first >> sentence in summary contexts? Could you generate docs and post the >> API bundle along with the webrev. >> >> -- Jon >> >> >> On 01/08/2020 01:11 PM, Vicente Romero wrote: >>> Please review this simple fix which is adding the @PreviewFeature >>> and related doc to, new for records, file >>> java/lang/runtime/package-info.java. Webrev is at [1] and JIRA issue >>> at [2] >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8235352/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8235352 >> > From vicente.romero at oracle.com Wed Jan 8 22:58:41 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 Jan 2020 17:58:41 -0500 Subject: RFR: JDK-8235352: java.lang.runtime.package-info should be annotated with @PreviewFeature In-Reply-To: <98170cd0-ec1d-e9df-5022-ce3af2e5c2a3@oracle.com> References: <0dcfd4f1-c307-d8fb-066c-9b862577f2c4@oracle.com> <40187ae7-9c41-d0cb-6d17-d36258ec2371@oracle.com> <98170cd0-ec1d-e9df-5022-ce3af2e5c2a3@oracle.com> Message-ID: ok good, are you OK with the change? Vicente On 1/8/20 5:16 PM, Jonathan Gibbons wrote: > Yeah, that's the specdiff, not the underlying API, but I can see the > info I was looking for. Thanks. > > -- Jon > > On 1/8/20 2:13 PM, Vicente Romero wrote: >> sure, please find it at [1] >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8235352/specdiff.runtime/ >> >> On 1/8/20 4:17 PM, Jonathan Gibbons wrote: >>> Vicente, >>> >>> Given that you have put the {@preview} at the beginning, how well >>> does this interact with javadoc and javadoc's handling of the first >>> sentence in summary contexts? Could you generate docs and post the >>> API bundle along with the webrev. >>> >>> -- Jon >>> >>> >>> On 01/08/2020 01:11 PM, Vicente Romero wrote: >>>> Please review this simple fix which is adding the @PreviewFeature >>>> and related doc to, new for records, file >>>> java/lang/runtime/package-info.java. Webrev is at [1] and JIRA >>>> issue at [2] >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8235352/webrev.00/ >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8235352 >>> >> From jonathan.gibbons at oracle.com Wed Jan 8 23:13:54 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 8 Jan 2020 15:13:54 -0800 Subject: RFR: JDK-8235352: java.lang.runtime.package-info should be annotated with @PreviewFeature In-Reply-To: References: <0dcfd4f1-c307-d8fb-066c-9b862577f2c4@oracle.com> <40187ae7-9c41-d0cb-6d17-d36258ec2371@oracle.com> <98170cd0-ec1d-e9df-5022-ce3af2e5c2a3@oracle.com> Message-ID: <397cacf1-c3bd-da7b-07af-d037709502b0@oracle.com> Vicente, A qualified-OK. I find it curious to declare the package as a preview feature, as compared to the class in it. I agree that ObjectMethods should be so marked, so there is no issue there. So my OK is conditional on there being some decision recorded somewhere that we want to do this;? if there is such a decision, then I agree you have implemented the decision in an acceptable way. -- Jon On 1/8/20 2:58 PM, Vicente Romero wrote: > ok good, are you OK with the change? > > Vicente > > On 1/8/20 5:16 PM, Jonathan Gibbons wrote: >> Yeah, that's the specdiff, not the underlying API, but I can see the >> info I was looking for. Thanks. >> >> -- Jon >> >> On 1/8/20 2:13 PM, Vicente Romero wrote: >>> sure, please find it at [1] >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8235352/specdiff.runtime/ >>> >>> On 1/8/20 4:17 PM, Jonathan Gibbons wrote: >>>> Vicente, >>>> >>>> Given that you have put the {@preview} at the beginning, how well >>>> does this interact with javadoc and javadoc's handling of the first >>>> sentence in summary contexts? Could you generate docs and post the >>>> API bundle along with the webrev. >>>> >>>> -- Jon >>>> >>>> >>>> On 01/08/2020 01:11 PM, Vicente Romero wrote: >>>>> Please review this simple fix which is adding the @PreviewFeature >>>>> and related doc to, new for records, file >>>>> java/lang/runtime/package-info.java. Webrev is at [1] and JIRA >>>>> issue at [2] >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] http://cr.openjdk.java.net/~vromero/8235352/webrev.00/ >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8235352 >>>> >>> > From alex.buckley at oracle.com Thu Jan 9 00:16:38 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 8 Jan 2020 16:16:38 -0800 Subject: RFR: JDK-8235352: java.lang.runtime.package-info should be annotated with @PreviewFeature In-Reply-To: <397cacf1-c3bd-da7b-07af-d037709502b0@oracle.com> References: <0dcfd4f1-c307-d8fb-066c-9b862577f2c4@oracle.com> <40187ae7-9c41-d0cb-6d17-d36258ec2371@oracle.com> <98170cd0-ec1d-e9df-5022-ce3af2e5c2a3@oracle.com> <397cacf1-c3bd-da7b-07af-d037709502b0@oracle.com> Message-ID: The excitingly-named java.lang.runtime package has been a long time coming. In its absence, LambdaMetaFactory and StringConcatFactory had to go in java.lang.invoke, which confused the purpose of *that* package. Still, with only record-related functionality in java.lang.runtime (nothing is being moved from j.l.i to j.l.r), it's right to be very clear that j.l.r isn't final and permanent in 14. Making it stand out in the module summary of java.base achieves that. Separately, both j.l.i and j.l.r have a description whose style is wrong and whose content is vague. I recommend: - java.lang.invoke: "Provides classes for controlling dynamic linkage in the Java Virtual Machine." [This is a user-level API, albeit for very advanced users. Such APIs in java.base are usually described as providing classes for XYZ.] - java.lang.runtime: "Supports the implementation of Java programs on the Java Virtual Machine." [This is a tool-level API, not a user-level API, so it doesn't "provide classes" for XYZ but rather "supports" XYZ.] And for the record: - java.lang.annotation: "Provides annotations used to describe fundamental properties of annotation types." [e.g. where is an annotation type applicable? is it repeatable? and so on. I'm ignoring java.lang.annotation.Native because it isn't part of the "science" of annotation types; it's just an "application" of the metadata facility, like @Deprecated, with meaning only to a particular tool, so it should be in java.lang.] Alex On 1/8/2020 3:13 PM, Jonathan Gibbons wrote: > Vicente, > > A qualified-OK. > > I find it curious to declare the package as a preview feature, as > compared to the class in it. I agree that ObjectMethods should be so > marked, so there is no issue there. > > So my OK is conditional on there being some decision recorded somewhere > that we want to do this;? if there is such a decision, then I agree you > have implemented the decision in an acceptable way. > > -- Jon > > On 1/8/20 2:58 PM, Vicente Romero wrote: >> ok good, are you OK with the change? >> >> Vicente >> >> On 1/8/20 5:16 PM, Jonathan Gibbons wrote: >>> Yeah, that's the specdiff, not the underlying API, but I can see the >>> info I was looking for. Thanks. >>> >>> -- Jon >>> >>> On 1/8/20 2:13 PM, Vicente Romero wrote: >>>> sure, please find it at [1] >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8235352/specdiff.runtime/ >>>> >>>> On 1/8/20 4:17 PM, Jonathan Gibbons wrote: >>>>> Vicente, >>>>> >>>>> Given that you have put the {@preview} at the beginning, how well >>>>> does this interact with javadoc and javadoc's handling of the first >>>>> sentence in summary contexts? Could you generate docs and post the >>>>> API bundle along with the webrev. >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> On 01/08/2020 01:11 PM, Vicente Romero wrote: >>>>>> Please review this simple fix which is adding the @PreviewFeature >>>>>> and related doc to, new for records, file >>>>>> java/lang/runtime/package-info.java. Webrev is at [1] and JIRA >>>>>> issue at [2] >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~vromero/8235352/webrev.00/ >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8235352 >>>>> >>>> >> From vicente.romero at oracle.com Fri Jan 10 00:34:02 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Jan 2020 19:34:02 -0500 Subject: RFR JDK14-8236597: issues inferring type annotations on records Message-ID: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> Hi, Please review this patch [1] to fix a couple of issues regarding inference of type annotations on records [2]. There where two cases where type annotations were reported as missing. For compact records whose arguments are not inheriting the type annotations from the corresponding record component and for accessors for which the annotation was present but just as a declaration annotation applied to the accessor. Not as a type annotation applied to the return type which was the expected outcome. In the case of the compact constructor, the solution was just to copy the annotations to the parameters which were missing. In the case of the accessor the solution was a bit more complicated. Accessors are created but not added to the list definitions belonging to the record tree. This is done to make them invisible to type attribution as they are not fully fledge methods, but as a side effect they are also invisible to the type annotations machinery. For this reason type annotations were not recognized as such. The solution here has been to make the type annotations machinery to visit accessors for records and set the type annotations correctly. In order to do that the accessor method created at TypeEnter is stored at the record component and visited at the same time type annotations are being classified for the rest of the code. Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8236597/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8236597 From vicente.romero at oracle.com Fri Jan 10 03:33:21 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Jan 2020 22:33:21 -0500 Subject: RFR: JDK14-8236841: compact constructor parameters are always final Message-ID: <59f8268c-dd80-b499-e53e-ac9ad55cbbe8@oracle.com> Hi, Please review this simple fix for bug [1] at [2]. Javac was setting the FINAL flag to all the parameters of the compact constructor. This patch fixes that, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236841 [2] http://cr.openjdk.java.net/~vromero/8236841/webrev.00/ From vicente.romero at oracle.com Fri Jan 10 03:54:26 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Jan 2020 22:54:26 -0500 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type Message-ID: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> Hi, Please review the fix for [1] at [2]. This fix is for the compiler to emit an error if a local record accesses non-static state from the enclosing environment Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236005 [2] http://cr.openjdk.java.net/~vromero/8236005/webrev.00/ From maurizio.cimadamore at oracle.com Fri Jan 10 19:02:25 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 10 Jan 2020 19:02:25 +0000 Subject: RFR: JDK14-8236841: compact constructor parameters are always final In-Reply-To: <59f8268c-dd80-b499-e53e-ac9ad55cbbe8@oracle.com> References: <59f8268c-dd80-b499-e53e-ac9ad55cbbe8@oracle.com> Message-ID: Looks good Maurizio On 10/01/2020 03:33, Vicente Romero wrote: > Hi, > > Please review this simple fix for bug [1] at [2]. Javac was setting > the FINAL flag to all the parameters of the compact constructor. This > patch fixes that, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236841 > [2] http://cr.openjdk.java.net/~vromero/8236841/webrev.00/ > From maurizio.cimadamore at oracle.com Fri Jan 10 19:06:30 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 10 Jan 2020 19:06:30 +0000 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> Message-ID: <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> Not 100% sure - shouldn't the "staticOnly" variable be set to true when we are inside a local record, so that the existing check will issue an error? I see that "staticOnly" is set in this routine: ??? /** An environment is "static" if its static level is greater than ???? *? the one of its outer environment ???? */ ??? protected static boolean isStatic(Env env) { ??????? return env.outer != null && env.info.staticLevel > env.outer.info.staticLevel; ??? } Which makes me think that, maybe the staticLevel of the local record has not increased its value as expected? Maurizio On 10/01/2020 03:54, Vicente Romero wrote: > Hi, > > Please review the fix for [1] at [2]. This fix is for the compiler to > emit an error if a local record accesses non-static state from the > enclosing environment > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236005 > [2] http://cr.openjdk.java.net/~vromero/8236005/webrev.00/ > From maurizio.cimadamore at oracle.com Fri Jan 10 19:23:53 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 10 Jan 2020 19:23:53 +0000 Subject: RFR JDK14-8236597: issues inferring type annotations on records In-Reply-To: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> References: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> Message-ID: <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> Looks good - but I have a question - I assume the changes in TypeEnter are to 'copy' the tree for the return type 'as is' from the record component declaration to the accessor return type. That is, is one is a qualified name, the other should be too, and viceversa. Ok, my question then is: shouldn't something like this be said somewhere in the spec too? After all, since @Nullable foo.bar.Baz is invalid but @Nullable Baz is not (or should use generate code for foo.bar. at Nullable Baz ?) And... what about parameter types? Shouldn't they need same treatment too? Maurizio On 10/01/2020 00:34, Vicente Romero wrote: > Hi, > > Please review this patch [1] to fix a couple of issues regarding > inference of type annotations on records [2]. There where two cases > where type annotations were reported as missing. For compact records > whose arguments are not inheriting the type annotations from the > corresponding record component and for accessors for which the > annotation was present but just as a declaration annotation applied to > the accessor. Not as a type annotation applied to the return type > which was the expected outcome. > > In the case of the compact constructor, the solution was just to copy > the annotations to the parameters which were missing. In the case of > the accessor the solution was a bit more complicated. Accessors are > created but not added to the list definitions belonging to the record > tree. This is done to make them invisible to type attribution as they > are not fully fledge methods, but as a side effect they are also > invisible to the type annotations machinery. For this reason type > annotations were not recognized as such. The solution here has been to > make the type annotations machinery to visit accessors for records and > set the type annotations correctly. In order to do that the accessor > method created at TypeEnter is stored at the record component and > visited at the same time type annotations are being classified for the > rest of the code. > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8236597/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8236597 From vicente.romero at oracle.com Fri Jan 10 19:34:49 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 10 Jan 2020 14:34:49 -0500 Subject: RFR JDK14-8236597: issues inferring type annotations on records In-Reply-To: <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> References: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> Message-ID: <4d82f1db-f6b5-62f7-6c83-489ce5680423@oracle.com> On 1/10/20 2:23 PM, Maurizio Cimadamore wrote: > Looks good - but I have a question - I assume the changes in TypeEnter > are to 'copy' the tree for the return type 'as is' from the record > component declaration to the accessor return type. That is, is one is > a qualified name, the other should be too, and viceversa. > > Ok, my question then is: shouldn't something like this be said > somewhere in the spec too? After all, since @Nullable foo.bar.Baz is > invalid but @Nullable Baz is not (or should use generate code for > foo.bar. at Nullable Baz ?) I'm not sure that we should mention this in the spec as this patch is just generating verbatim the same type typed by the user and thus it would be the expected outcome by the user, unless I'm missing something. > > And... what about parameter types? Shouldn't they need same treatment > too? they should but I wasn't sure if I should tackle that in this same patch, but I can do a: now that I was in the neighborhood... > > Maurizio Vicente > > On 10/01/2020 00:34, Vicente Romero wrote: >> Hi, >> >> Please review this patch [1] to fix a couple of issues regarding >> inference of type annotations on records [2]. There where two cases >> where type annotations were reported as missing. For compact records >> whose arguments are not inheriting the type annotations from the >> corresponding record component and for accessors for which the >> annotation was present but just as a declaration annotation applied >> to the accessor. Not as a type annotation applied to the return type >> which was the expected outcome. >> >> In the case of the compact constructor, the solution was just to copy >> the annotations to the parameters which were missing. In the case of >> the accessor the solution was a bit more complicated. Accessors are >> created but not added to the list definitions belonging to the record >> tree. This is done to make them invisible to type attribution as they >> are not fully fledge methods, but as a side effect they are also >> invisible to the type annotations machinery. For this reason type >> annotations were not recognized as such. The solution here has been >> to make the type annotations machinery to visit accessors for records >> and set the type annotations correctly. In order to do that the >> accessor method created at TypeEnter is stored at the record >> component and visited at the same time type annotations are being >> classified for the rest of the code. >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8236597/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8236597 From maurizio.cimadamore at oracle.com Fri Jan 10 20:51:08 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 10 Jan 2020 20:51:08 +0000 Subject: RFR JDK14-8236597: issues inferring type annotations on records In-Reply-To: <4d82f1db-f6b5-62f7-6c83-489ce5680423@oracle.com> References: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> <4d82f1db-f6b5-62f7-6c83-489ce5680423@oracle.com> Message-ID: On 10/01/2020 19:34, Vicente Romero wrote: > > > On 1/10/20 2:23 PM, Maurizio Cimadamore wrote: >> Looks good - but I have a question - I assume the changes in >> TypeEnter are to 'copy' the tree for the return type 'as is' from the >> record component declaration to the accessor return type. That is, is >> one is a qualified name, the other should be too, and viceversa. >> >> Ok, my question then is: shouldn't something like this be said >> somewhere in the spec too? After all, since @Nullable foo.bar.Baz is >> invalid but @Nullable Baz is not (or should use generate code for >> foo.bar. at Nullable Baz ?) > > I'm not sure that we should mention this in the spec as this patch is > just generating verbatim the same type typed by the user and thus it > would be the expected outcome by the user, unless I'm missing something. I guess my point here is that it's not sufficient to say that a record class has an accessor with this and that type - for type annotations it is also relevant which syntactic form is used to express the type (ident vs. qualified name). If the syntactic form should be preserved, then I think we should say something, otherwise it's not clear exactly which type annotations will be applicable to e.g. the accessor and which not. > >> >> And... what about parameter types? Shouldn't they need same treatment >> too? > > they should but I wasn't sure if I should tackle that in this same > patch, but I can do a: now that I was in the neighborhood... > Ok Maurizio >> >> Maurizio > > Vicente > >> >> On 10/01/2020 00:34, Vicente Romero wrote: >>> Hi, >>> >>> Please review this patch [1] to fix a couple of issues regarding >>> inference of type annotations on records [2]. There where two cases >>> where type annotations were reported as missing. For compact records >>> whose arguments are not inheriting the type annotations from the >>> corresponding record component and for accessors for which the >>> annotation was present but just as a declaration annotation applied >>> to the accessor. Not as a type annotation applied to the return type >>> which was the expected outcome. >>> >>> In the case of the compact constructor, the solution was just to >>> copy the annotations to the parameters which were missing. In the >>> case of the accessor the solution was a bit more complicated. >>> Accessors are created but not added to the list definitions >>> belonging to the record tree. This is done to make them invisible to >>> type attribution as they are not fully fledge methods, but as a side >>> effect they are also invisible to the type annotations machinery. >>> For this reason type annotations were not recognized as such. The >>> solution here has been to make the type annotations machinery to >>> visit accessors for records and set the type annotations correctly. >>> In order to do that the accessor method created at TypeEnter is >>> stored at the record component and visited at the same time type >>> annotations are being classified for the rest of the code. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8236597/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8236597 > From vicente.romero at oracle.com Fri Jan 10 21:04:59 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 10 Jan 2020 16:04:59 -0500 Subject: RFR JDK14-8236597: issues inferring type annotations on records In-Reply-To: References: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> <4d82f1db-f6b5-62f7-6c83-489ce5680423@oracle.com> Message-ID: <2a0a2eb7-bb34-8779-9872-8c5258cc49c4@oracle.com> On 1/10/20 3:51 PM, Maurizio Cimadamore wrote: > > On 10/01/2020 19:34, Vicente Romero wrote: >> >> >> On 1/10/20 2:23 PM, Maurizio Cimadamore wrote: >>> Looks good - but I have a question - I assume the changes in >>> TypeEnter are to 'copy' the tree for the return type 'as is' from >>> the record component declaration to the accessor return type. That >>> is, is one is a qualified name, the other should be too, and viceversa. >>> >>> Ok, my question then is: shouldn't something like this be said >>> somewhere in the spec too? After all, since @Nullable foo.bar.Baz is >>> invalid but @Nullable Baz is not (or should use generate code for >>> foo.bar. at Nullable Baz ?) >> >> I'm not sure that we should mention this in the spec as this patch is >> just generating verbatim the same type typed by the user and thus it >> would be the expected outcome by the user, unless I'm missing something. > I guess my point here is that it's not sufficient to say that a record > class has an accessor with this and that type - for type annotations > it is also relevant which syntactic form is used to express the type > (ident vs. qualified name). If the syntactic form should be preserved, > then I think we should say something, otherwise it's not clear exactly > which type annotations will be applicable to e.g. the accessor and > which not. right now if the user writes @TypeAnno java.lang.String, that's a compiler error at any location of the type, this is wo records being involved. So there is only one representation of the type that can work. Also if the user writes: record R(@TypeAnno java.lang.String s) {} that's a compiler error too >> >>> >>> And... what about parameter types? Shouldn't they need same >>> treatment too? >> >> they should but I wasn't sure if I should tackle that in this same >> patch, but I can do a: now that I was in the neighborhood... >> > Ok > > Maurizio > >>> >>> Maurizio >> >> Vicente >> >>> >>> On 10/01/2020 00:34, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review this patch [1] to fix a couple of issues regarding >>>> inference of type annotations on records [2]. There where two cases >>>> where type annotations were reported as missing. For compact >>>> records whose arguments are not inheriting the type annotations >>>> from the corresponding record component and for accessors for which >>>> the annotation was present but just as a declaration annotation >>>> applied to the accessor. Not as a type annotation applied to the >>>> return type which was the expected outcome. >>>> >>>> In the case of the compact constructor, the solution was just to >>>> copy the annotations to the parameters which were missing. In the >>>> case of the accessor the solution was a bit more complicated. >>>> Accessors are created but not added to the list definitions >>>> belonging to the record tree. This is done to make them invisible >>>> to type attribution as they are not fully fledge methods, but as a >>>> side effect they are also invisible to the type annotations >>>> machinery. For this reason type annotations were not recognized as >>>> such. The solution here has been to make the type annotations >>>> machinery to visit accessors for records and set the type >>>> annotations correctly. In order to do that the accessor method >>>> created at TypeEnter is stored at the record component and visited >>>> at the same time type annotations are being classified for the rest >>>> of the code. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8236597/webrev.00/ >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8236597 >> From vicente.romero at oracle.com Fri Jan 10 22:53:47 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 10 Jan 2020 17:53:47 -0500 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> Message-ID: <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> On 1/10/20 2:06 PM, Maurizio Cimadamore wrote: > Not 100% sure - shouldn't the "staticOnly" variable be set to true > when we are inside a local record, so that the existing check will > issue an error? > > I see that "staticOnly" is set in this routine: > > ??? /** An environment is "static" if its static level is greater than > ???? *? the one of its outer environment > ???? */ > ??? protected static boolean isStatic(Env env) { > ??????? return env.outer != null && env.info.staticLevel > > env.outer.info.staticLevel; > ??? } staticOnly is true, it is because of the rest of the conditions that the static error is not generated. So with the current conditions this code fails correctly: class R { ??? int z = 0; ??? void m() { ??????? record RR(int x) { public int x() { return z; }}; ??? } } here we have: if (staticOnly && // true sym.kind ==VAR && sym.owner.kind ==TYP && // true it is a field (sym.flags() &STATIC) ==0) // true is is not static, then error return new StaticError(sym); but this code is accepted: class R { ??? void m() { int z = 0; ??????? record RR(int x) { public int x() { return z; }}; ??? } } if (staticOnly && // true sym.kind ==VAR && sym.owner.kind ==TYP && // false it is a local variable (sym.flags() &STATIC) ==0) // true is is not static but it won't be evaluated anyway, then NO error return new StaticError(sym); that's why I added the additional conditions > > Which makes me think that, maybe the staticLevel of the local record > has not increased its value as expected? > > Maurizio Vicente > > On 10/01/2020 03:54, Vicente Romero wrote: >> Hi, >> >> Please review the fix for [1] at [2]. This fix is for the compiler to >> emit an error if a local record accesses non-static state from the >> enclosing environment >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8236005 >> [2] http://cr.openjdk.java.net/~vromero/8236005/webrev.00/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jan 10 23:55:24 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 10 Jan 2020 18:55:24 -0500 Subject: RFR JDK14-8236597: issues inferring type annotations on records In-Reply-To: <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> References: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> Message-ID: <863e4a8f-4714-bff8-54aa-a3faa0619451@oracle.com> while we wait on the decision regarding the change in the spec I realized that for the constructor I was already setting the type as defined in the record component, see method: RecordConstructorHelper::finalAdjustment, public JCMethodDecl finalAdjustment(JCMethodDecl md) { List tmpRecordFieldDecls =recordFieldDecls; for (JCVariableDecl arg : md.params) { /* at this point we are passing all the annotations in the field to the corresponding * parameter in the constructor. */ arg.mods.annotations = tmpRecordFieldDecls.head.mods.annotations; arg.vartype = tmpRecordFieldDecls.head.vartype; <------------------------- here tmpRecordFieldDecls = tmpRecordFieldDecls.tail; } return md; } Thanks, Vicente On 1/10/20 2:23 PM, Maurizio Cimadamore wrote: > Looks good - but I have a question - I assume the changes in TypeEnter > are to 'copy' the tree for the return type 'as is' from the record > component declaration to the accessor return type. That is, is one is > a qualified name, the other should be too, and viceversa. > > Ok, my question then is: shouldn't something like this be said > somewhere in the spec too? After all, since @Nullable foo.bar.Baz is > invalid but @Nullable Baz is not (or should use generate code for > foo.bar. at Nullable Baz ?) > > And... what about parameter types? Shouldn't they need same treatment > too? > > Maurizio > > On 10/01/2020 00:34, Vicente Romero wrote: >> Hi, >> >> Please review this patch [1] to fix a couple of issues regarding >> inference of type annotations on records [2]. There where two cases >> where type annotations were reported as missing. For compact records >> whose arguments are not inheriting the type annotations from the >> corresponding record component and for accessors for which the >> annotation was present but just as a declaration annotation applied >> to the accessor. Not as a type annotation applied to the return type >> which was the expected outcome. >> >> In the case of the compact constructor, the solution was just to copy >> the annotations to the parameters which were missing. In the case of >> the accessor the solution was a bit more complicated. Accessors are >> created but not added to the list definitions belonging to the record >> tree. This is done to make them invisible to type attribution as they >> are not fully fledge methods, but as a side effect they are also >> invisible to the type annotations machinery. For this reason type >> annotations were not recognized as such. The solution here has been >> to make the type annotations machinery to visit accessors for records >> and set the type annotations correctly. In order to do that the >> accessor method created at TypeEnter is stored at the record >> component and visited at the same time type annotations are being >> classified for the rest of the code. >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8236597/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8236597 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Sat Jan 11 00:58:51 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 11 Jan 2020 00:58:51 +0000 Subject: RFR JDK14-8236597: issues inferring type annotations on records In-Reply-To: <863e4a8f-4714-bff8-54aa-a3faa0619451@oracle.com> References: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> <863e4a8f-4714-bff8-54aa-a3faa0619451@oracle.com> Message-ID: <89027832-5aec-3e5b-1c44-94d83b567900@oracle.com> Uhm I see - you copy the tree as is from one place to another? This might be a bit suboptimal (e.g. tree position and all that), and can misfire if the two trees are ever added into a map of some kind. But I take that this code has nothing to do with the patch under review. Maurizio On 10/01/2020 23:55, Vicente Romero wrote: > while we wait on the decision regarding the change in the spec I > realized that for the constructor I was already setting the type as > defined in the record component, see method: > RecordConstructorHelper::finalAdjustment, > > public JCMethodDecl finalAdjustment(JCMethodDecl md) { > List tmpRecordFieldDecls =recordFieldDecls; > for (JCVariableDecl arg : md.params) { > /* at this point we are passing all the annotations in the field to > the corresponding * parameter in the constructor. */ arg.mods.annotations = tmpRecordFieldDecls.head.mods.annotations; > arg.vartype = tmpRecordFieldDecls.head.vartype; <------------------------- here > tmpRecordFieldDecls = tmpRecordFieldDecls.tail; > } > return md; > } > > Thanks, > Vicente > > On 1/10/20 2:23 PM, Maurizio Cimadamore wrote: >> Looks good - but I have a question - I assume the changes in >> TypeEnter are to 'copy' the tree for the return type 'as is' from the >> record component declaration to the accessor return type. That is, is >> one is a qualified name, the other should be too, and viceversa. >> >> Ok, my question then is: shouldn't something like this be said >> somewhere in the spec too? After all, since @Nullable foo.bar.Baz is >> invalid but @Nullable Baz is not (or should use generate code for >> foo.bar. at Nullable Baz ?) >> >> And... what about parameter types? Shouldn't they need same treatment >> too? >> >> Maurizio >> >> On 10/01/2020 00:34, Vicente Romero wrote: >>> Hi, >>> >>> Please review this patch [1] to fix a couple of issues regarding >>> inference of type annotations on records [2]. There where two cases >>> where type annotations were reported as missing. For compact records >>> whose arguments are not inheriting the type annotations from the >>> corresponding record component and for accessors for which the >>> annotation was present but just as a declaration annotation applied >>> to the accessor. Not as a type annotation applied to the return type >>> which was the expected outcome. >>> >>> In the case of the compact constructor, the solution was just to >>> copy the annotations to the parameters which were missing. In the >>> case of the accessor the solution was a bit more complicated. >>> Accessors are created but not added to the list definitions >>> belonging to the record tree. This is done to make them invisible to >>> type attribution as they are not fully fledge methods, but as a side >>> effect they are also invisible to the type annotations machinery. >>> For this reason type annotations were not recognized as such. The >>> solution here has been to make the type annotations machinery to >>> visit accessors for records and set the type annotations correctly. >>> In order to do that the accessor method created at TypeEnter is >>> stored at the record component and visited at the same time type >>> annotations are being classified for the rest of the code. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8236597/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8236597 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Sat Jan 11 01:02:24 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 11 Jan 2020 01:02:24 +0000 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> Message-ID: <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> On 10/01/2020 22:53, Vicente Romero wrote: > but this code is accepted: > > class R { > ??? void m() { > int z = 0; > ??????? record RR(int x) { public int x() { return z; }}; > ??? } > } Why is this accepted? Isn't capture of locals also disabled, as demonstrated in the test: // Cant capture locals + assertFail("compiler.err.non-static.cant.be.ref", + "class R { \n" + " void m(int y) { \n" + " record RR(int x) { public int x() { return y; }};\n" + " }\n" + "}"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Sat Jan 11 11:35:04 2020 From: gunnar at hibernate.org (Gunnar Morling) Date: Sat, 11 Jan 2020 12:35:04 +0100 Subject: JEP 182: Policy for Retiring javac -source and -target Options Message-ID: Hi, In JEP 182 (currently in draft state, [1]) it says: "In JDK 9 and going forward, javac will use a "one + three back" policy of supported source and target options." Are there any plans to update this one in the light of the increased release cadence? In particular, what's the next planned upgrade of the minimum supported version (javac 14 still supports source/target level 7 at this point)? Thanks, --Gunnar [1] https://openjdk.java.net/jeps/182 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Sat Jan 11 18:07:42 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 11 Jan 2020 10:07:42 -0800 Subject: JEP 182: Policy for Retiring javac -source and -target Options In-Reply-To: References: Message-ID: <56a23f34-145e-4a0d-7c65-9a7ecdca6c5a@oracle.com> Hello, In the corresponding JBS issue, ??? https://bugs.openjdk.java.net/browse/JDK-8046172 a comment states > Note that with the six month release cadence > (http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html) > being used starting with JDK 10, the chronogical range covered by "one > plus three back" would be much shortened. In due course, this policy > will be updated accordingly, possibly taking into account LTS (long > term support) releases and possibly offering a sparse set of values. > For example, one possible policy would be to support the last two LTS > release and each release after the most recent LTS, but not the > releases between those two LTS releases. https://bugs.openjdk.java.net/browse/JDK-8046172?focusedCommentId=14145783&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14145783 There are no plans to remove support for --release 7 in JDK 15. HTH, -Joe On 1/11/2020 3:35 AM, Gunnar Morling wrote: > Hi, > > In JEP 182 (currently in draft state, [1]) it says: "In JDK 9 and > going forward, javac will use a "one + three back" policy of supported > source and target options." > > Are there any plans to update this one in the light of the increased > release cadence? In particular, what's the next planned upgrade of the > minimum supported version (javac 14 still supports source/target level > 7 at this point)? > > Thanks, > > --Gunnar > > [1] https://openjdk.java.net/jeps/182 > From forax at univ-mlv.fr Sat Jan 11 18:46:17 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 11 Jan 2020 19:46:17 +0100 (CET) Subject: JEP 182: Policy for Retiring javac -source and -target Options In-Reply-To: <56a23f34-145e-4a0d-7c65-9a7ecdca6c5a@oracle.com> References: <56a23f34-145e-4a0d-7c65-9a7ecdca6c5a@oracle.com> Message-ID: <423160841.1162962.1578768377543.JavaMail.zimbra@u-pem.fr> I think the set of supported source/target should not change until after a LTS. Because we should minimize the change in the tooling to upgrade from a release to another one, otherwise, we are defeating the purpose of a 6 month release cadence. So i propose that for each release just after a LTS, we may decide to revisit the supported versions of --source/--target/--release. cheers, R?mi ----- Mail original ----- > De: "joe darcy" > ?: "Gunnar Morling" , "compiler-dev" > Envoy?: Samedi 11 Janvier 2020 19:07:42 > Objet: Re: JEP 182: Policy for Retiring javac -source and -target Options > Hello, > > In the corresponding JBS issue, > > ??? https://bugs.openjdk.java.net/browse/JDK-8046172 > > a comment states > >> Note that with the six month release cadence >> (http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html) >> being used starting with JDK 10, the chronogical range covered by "one >> plus three back" would be much shortened. In due course, this policy >> will be updated accordingly, possibly taking into account LTS (long >> term support) releases and possibly offering a sparse set of values. >> For example, one possible policy would be to support the last two LTS >> release and each release after the most recent LTS, but not the >> releases between those two LTS releases. > > https://bugs.openjdk.java.net/browse/JDK-8046172?focusedCommentId=14145783&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14145783 > > There are no plans to remove support for --release 7 in JDK 15. > > HTH, > > -Joe > > On 1/11/2020 3:35 AM, Gunnar Morling wrote: >> Hi, >> >> In JEP 182 (currently in draft state, [1]) it says: "In JDK 9 and >> going forward, javac will use a "one + three back" policy of supported >> source and target options." >> >> Are there any plans to update this one in the light of the increased >> release cadence? In particular, what's the next planned upgrade of the >> minimum supported version (javac 14 still supports source/target level >> 7 at this point)? >> >> Thanks, >> >> --Gunnar >> >> [1] https://openjdk.java.net/jeps/182 From gunnar at hibernate.org Sat Jan 11 21:38:35 2020 From: gunnar at hibernate.org (Gunnar Morling) Date: Sat, 11 Jan 2020 22:38:35 +0100 Subject: JEP 182: Policy for Retiring javac -source and -target Options In-Reply-To: <423160841.1162962.1578768377543.JavaMail.zimbra@u-pem.fr> References: <56a23f34-145e-4a0d-7c65-9a7ecdca6c5a@oracle.com> <423160841.1162962.1578768377543.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks for your replies, Joe and Remi! > possibly taking into account LTS... > should not change until after a LTS... I think something like that would help. Here's the situation which made me bring this up: I'm considering to use text blocks (preview feature in 13) in *tests*. Whereas my main code needs to remain at Java 8 compatibility, so to not exclude any of my users (sorry for those still on older versions ;). So I considered building with JDK 13, using release 8 for main code and 13 for test code. Now as I'd be on non-LTS with 13, I'd have to go to 14, 15, etc. as soon as they are out, in order to get bug fixes, security fixes etc. This means I'd have a problem if any of those were to drop support for Java 8 compatibility, as I'd either have to stay on an unmaintained JDK or would be forced to increase the release level of my main code. For a user in my situation, the earliest safe option to drop Java 8 compatibility would be in 18, because then I could stay on 17 LTS for the foreseeable future. That said, it's my understanding that LTS is *not* a notion of OpenJDK, but rather one of build providers such as Oracle, Adopt and many others. While it seems there's consensus on 11, 17, ... being LTS, vendors could decide to offer long-term support for other releases, too. So which LTS would then be the basis for that decision in OpenJDK? Perhaps it'd be a good idea to formalize in OpenJDK itself the nature of specific releases being recommended for LTS by build providers? --Gunnar Am Sa., 11. Jan. 2020 um 19:46 Uhr schrieb Remi Forax : > I think the set of supported source/target should not change until after a > LTS. > Because we should minimize the change in the tooling to upgrade from a > release to another one, otherwise, we are defeating the purpose of a 6 > month release cadence. > > So i propose that for each release just after a LTS, we may decide to > revisit the supported versions of --source/--target/--release. > > cheers, > R?mi > > ----- Mail original ----- > > De: "joe darcy" > > ?: "Gunnar Morling" , "compiler-dev" < > compiler-dev at openjdk.java.net> > > Envoy?: Samedi 11 Janvier 2020 19:07:42 > > Objet: Re: JEP 182: Policy for Retiring javac -source and -target Options > > > Hello, > > > > In the corresponding JBS issue, > > > > https://bugs.openjdk.java.net/browse/JDK-8046172 > > > > a comment states > > > >> Note that with the six month release cadence > >> ( > http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html) > >> being used starting with JDK 10, the chronogical range covered by "one > >> plus three back" would be much shortened. In due course, this policy > >> will be updated accordingly, possibly taking into account LTS (long > >> term support) releases and possibly offering a sparse set of values. > >> For example, one possible policy would be to support the last two LTS > >> release and each release after the most recent LTS, but not the > >> releases between those two LTS releases. > > > > > https://bugs.openjdk.java.net/browse/JDK-8046172?focusedCommentId=14145783&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14145783 > > > > There are no plans to remove support for --release 7 in JDK 15. > > > > HTH, > > > > -Joe > > > > On 1/11/2020 3:35 AM, Gunnar Morling wrote: > >> Hi, > >> > >> In JEP 182 (currently in draft state, [1]) it says: "In JDK 9 and > >> going forward, javac will use a "one + three back" policy of supported > >> source and target options." > >> > >> Are there any plans to update this one in the light of the increased > >> release cadence? In particular, what's the next planned upgrade of the > >> minimum supported version (javac 14 still supports source/target level > >> 7 at this point)? > >> > >> Thanks, > >> > >> --Gunnar > >> > >> [1] https://openjdk.java.net/jeps/182 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Sun Jan 12 10:50:33 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 12 Jan 2020 11:50:33 +0100 Subject: Setting the dev option Message-ID: <87a76tx81y.fsf@mid.deneb.enyo.de> javac has this code: } catch (Throwable ex) { // Nasty. If we've already reported an error, compensate // for buggy compiler error recovery by swallowing thrown // exceptions. if (comp == null || comp.errorCount() == 0 || options.isSet("dev")) bugMessage(ex); printArgsToFile = true; return Result.ABNORMAL; Is there some way to set the "dev" option without patching the sources, so that I can see the exception even if it follows an earlier error? From jonathan.gibbons at oracle.com Sun Jan 12 16:47:53 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 12 Jan 2020 08:47:53 -0800 Subject: Setting the dev option In-Reply-To: <87a76tx81y.fsf@mid.deneb.enyo.de> References: <87a76tx81y.fsf@mid.deneb.enyo.de> Message-ID: -XDdev -- Jon On 1/12/20 2:50 AM, Florian Weimer wrote: > javac has this code: > > } catch (Throwable ex) { > // Nasty. If we've already reported an error, compensate > // for buggy compiler error recovery by swallowing thrown > // exceptions. > if (comp == null || comp.errorCount() == 0 || options.isSet("dev")) > bugMessage(ex); > printArgsToFile = true; > return Result.ABNORMAL; > > Is there some way to set the "dev" option without patching the > sources, so that I can see the exception even if it follows an earlier > error? From jan.lahoda at oracle.com Mon Jan 13 12:42:18 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 13 Jan 2020 13:42:18 +0100 Subject: RFR (14): JDK-8236670: Conflicting bindings accepted in some cases Message-ID: <01693138-3b6c-79f9-9178-af5f60bcf0be@oracle.com> Hi, Tagir reported a problem where javac accepts a program with conflicting bindings, like (simplified): static void test(Object o1, Object o2) { boolean b = o1 instanceof String s && !(o2 instanceof String s)); } There are two problem here: -in the right-hand side of the conditional and, "s" is already in scope, but no error reported. This is because in Check, while checking clashes, clashes between binding variables are ignored, and expected to be reported in MatchBindingsComputer - but here, MatchBindingsComputer does not see the conflict when computing the binding variables for the expression. The proposed fix is to let the error be reported in Check, with some checks to avoid duplicate errors from MatchBindingsComputer. As a side effect, this should provide better error positions in some (although not all) cases, consider: static void test(Object o1, Object o2) { if (o1 instanceof String s && (o2 instanceof String s)); } before: /tmp/T.java:3: error: illegal attempt to redefine an existing match binding if (o1 instanceof String s && (o2 instanceof String s)); ^ with the patch: /tmp/T.java:3: error: illegal attempt to redefine an existing match binding if (o1 instanceof String s && (o2 instanceof String s)); ^ -the second problem is more intricate - some bindings consistency constraints are curently only checked when match bindings are evaluated for a whole expression, like e.g.: if (!(o1 instanceof String s) && !(o2 instanceof String s)) {} this is illegal per JLS 6.3.1.1 ("It is a compile-time error if a pattern variable is both introduced by a when false, and by b when false.") The constraint is checked when the expression is e.g. a condition for an if statement, but not when the expression is e.g. an initializer to a variable: boolean b = !(o1 instanceof String s) && !(o2 instanceof String s); - this yields no error, as the expression is never checked by the MatchBindingComputer as a whole. We could either run the MatchBindingComputer on every non-conditional expression, but seems a nicer way is to build the current match bindings while attributing the expressions (i.e. keeping the match bindings in Attr and enhance/check them as it goes up the AST). The current proposed patch is here: http://cr.openjdk.java.net/~jlahoda/8236670/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8236670 What do you think? Thanks, Jan From vicente.romero at oracle.com Mon Jan 13 13:35:50 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 13 Jan 2020 08:35:50 -0500 Subject: RFR JDK14-8236597: issues inferring type annotations on records In-Reply-To: <89027832-5aec-3e5b-1c44-94d83b567900@oracle.com> References: <1d4fc9f6-b665-b0cf-85bc-eddcfaf5c90b@oracle.com> <5965e4cb-9443-3a1d-144b-42aded43a581@oracle.com> <863e4a8f-4714-bff8-54aa-a3faa0619451@oracle.com> <89027832-5aec-3e5b-1c44-94d83b567900@oracle.com> Message-ID: <4995cc04-94db-6a37-4b76-de5120ef1090@oracle.com> On 1/10/20 7:58 PM, Maurizio Cimadamore wrote: > > Uhm I see - you copy the tree as is from one place to another? This > might be a bit suboptimal (e.g. tree position and all that), and can > misfire if the two trees are ever added into a map of some kind. > true I can fix that, > But I take that this code has nothing to do with the patch under review. > > Maurizio > Vicente > On 10/01/2020 23:55, Vicente Romero wrote: >> while we wait on the decision regarding the change in the spec I >> realized that for the constructor I was already setting the type as >> defined in the record component, see method: >> RecordConstructorHelper::finalAdjustment, >> >> public JCMethodDecl finalAdjustment(JCMethodDecl md) { >> List tmpRecordFieldDecls =recordFieldDecls; >> for (JCVariableDecl arg : md.params) { >> /* at this point we are passing all the annotations in the field to >> the corresponding * parameter in the constructor. */ arg.mods.annotations = tmpRecordFieldDecls.head.mods.annotations; >> arg.vartype = tmpRecordFieldDecls.head.vartype; <------------------------- here >> tmpRecordFieldDecls = tmpRecordFieldDecls.tail; >> } >> return md; >> } >> >> Thanks, >> Vicente >> >> On 1/10/20 2:23 PM, Maurizio Cimadamore wrote: >>> Looks good - but I have a question - I assume the changes in >>> TypeEnter are to 'copy' the tree for the return type 'as is' from >>> the record component declaration to the accessor return type. That >>> is, is one is a qualified name, the other should be too, and viceversa. >>> >>> Ok, my question then is: shouldn't something like this be said >>> somewhere in the spec too? After all, since @Nullable foo.bar.Baz is >>> invalid but @Nullable Baz is not (or should use generate code for >>> foo.bar. at Nullable Baz ?) >>> >>> And... what about parameter types? Shouldn't they need same >>> treatment too? >>> >>> Maurizio >>> >>> On 10/01/2020 00:34, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review this patch [1] to fix a couple of issues regarding >>>> inference of type annotations on records [2]. There where two cases >>>> where type annotations were reported as missing. For compact >>>> records whose arguments are not inheriting the type annotations >>>> from the corresponding record component and for accessors for which >>>> the annotation was present but just as a declaration annotation >>>> applied to the accessor. Not as a type annotation applied to the >>>> return type which was the expected outcome. >>>> >>>> In the case of the compact constructor, the solution was just to >>>> copy the annotations to the parameters which were missing. In the >>>> case of the accessor the solution was a bit more complicated. >>>> Accessors are created but not added to the list definitions >>>> belonging to the record tree. This is done to make them invisible >>>> to type attribution as they are not fully fledge methods, but as a >>>> side effect they are also invisible to the type annotations >>>> machinery. For this reason type annotations were not recognized as >>>> such. The solution here has been to make the type annotations >>>> machinery to visit accessors for records and set the type >>>> annotations correctly. In order to do that the accessor method >>>> created at TypeEnter is stored at the record component and visited >>>> at the same time type annotations are being classified for the rest >>>> of the code. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8236597/webrev.00/ >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8236597 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 13 13:39:31 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 13 Jan 2020 08:39:31 -0500 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> Message-ID: <1bf9b149-df64-3a7d-ca1c-2fcf1237eb6d@oracle.com> On 1/10/20 8:02 PM, Maurizio Cimadamore wrote: > > > On 10/01/2020 22:53, Vicente Romero wrote: >> but this code is accepted: >> >> class R { >> ??? void m() { >> int z = 0; >> ??????? record RR(int x) { public int x() { return z; }}; >> ??? } >> } > > Why is this accepted? Isn't capture of locals also disabled, as > demonstrated in the test: > > // Cant capture locals > + assertFail("compiler.err.non-static.cant.be.ref", > + "class R { \n" + > " void m(int y) { \n" + > " record RR(int x) { public int x() { return y; }};\n" + > " }\n" + > "}"); sorry I should have been more specific. When I said: "with the current conditions" in my previous mail I should had said: "with current state without the patch this code is accepted" that's what I meant. Without the patch access to non-static fields from records are banned but access to local variables is not. This patch is closing that last gap Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jan 13 14:22:45 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 Jan 2020 14:22:45 +0000 Subject: RFR (14): JDK-8236670: Conflicting bindings accepted in some cases In-Reply-To: <01693138-3b6c-79f9-9178-af5f60bcf0be@oracle.com> References: <01693138-3b6c-79f9-9178-af5f60bcf0be@oracle.com> Message-ID: <51c3b363-9af3-e08a-6f17-fd5057d33957@oracle.com> Looks good - I like the way in which you have folded binding computation inside Attr. As for the changes in TransPatterns, they are a bit hard to digest, but I think ultimately correct. I suggest replacing bindingDeclared(Symbol) with declareBinding(Symbol), so that it's clearer that it's an operation that should take place before any access (e.g. call to "getBindingFor"). Maurizio On 13/01/2020 12:42, Jan Lahoda wrote: > Hi, > > Tagir reported a problem where javac accepts a program with > conflicting bindings, like (simplified): > > static void test(Object o1, Object o2) { > ????? boolean b = o1 instanceof String s && !(o2 instanceof String s)); > } > > There are two problem here: > -in the right-hand side of the conditional and, "s" is already in > scope, but no error reported. This is because in Check, while checking > clashes, clashes between binding variables are ignored, and expected > to be reported in MatchBindingsComputer - but here, > MatchBindingsComputer does not see the conflict when computing the > binding variables for the expression. The proposed fix is to let the > error be reported in Check, with some checks to avoid duplicate errors > from MatchBindingsComputer. As a side effect, this should provide > better error positions in some (although not all) cases, consider: > static void test(Object o1, Object o2) { > ????? if (o1 instanceof String s && (o2 instanceof String s)); > } > before: > /tmp/T.java:3: error: illegal attempt to redefine an existing match > binding > ????? if (o1 instanceof String s && (o2 instanceof String s)); > ???????????????????????????????? ^ > with the patch: > /tmp/T.java:3: error: illegal attempt to redefine an existing match > binding > ????? if (o1 instanceof String s && (o2 instanceof String s)); > ????????????????????????????????????????????????????????? ^ > > > -the second problem is more intricate - some bindings consistency > constraints are curently only checked when match bindings are > evaluated for a whole expression, like e.g.: > if (!(o1 instanceof String s) && !(o2 instanceof String s)) {} > > this is illegal per JLS 6.3.1.1 ("It is a compile-time error if a > pattern variable is both introduced by a when false, and by b when > false.") The constraint is checked when the expression is e.g. a > condition for an if statement, but not when the expression is e.g. an > initializer to a variable: > boolean b = !(o1 instanceof String s) && !(o2 instanceof String s); > > - this yields no error, as the expression is never checked by the > MatchBindingComputer as a whole. We could either run the > MatchBindingComputer on every non-conditional expression, but seems a > nicer way is to build the current match bindings while attributing the > expressions (i.e. keeping the match bindings in Attr and enhance/check > them as it goes up the AST). > > The current proposed patch is here: > http://cr.openjdk.java.net/~jlahoda/8236670/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8236670 > > What do you think? > > Thanks, > ???? Jan From maurizio.cimadamore at oracle.com Mon Jan 13 14:46:31 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 Jan 2020 14:46:31 +0000 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: <1bf9b149-df64-3a7d-ca1c-2fcf1237eb6d@oracle.com> References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> <1bf9b149-df64-3a7d-ca1c-2fcf1237eb6d@oracle.com> Message-ID: <66a327aa-bc0a-4039-e328-d1ca97423bd0@oracle.com> Thanks for the explanation. I've convinced myself that the code is correct. Basically, if we're trying to access a local variable defined in a method whose class is != than the current class && the current class is also static (which can only happen with records, as that's the only local construct which can also be static), an error should be issued. Maurizio On 13/01/2020 13:39, Vicente Romero wrote: > > > On 1/10/20 8:02 PM, Maurizio Cimadamore wrote: >> >> >> On 10/01/2020 22:53, Vicente Romero wrote: >>> but this code is accepted: >>> >>> class R { >>> ??? void m() { >>> int z = 0; >>> ??????? record RR(int x) { public int x() { return z; }}; >>> ??? } >>> } >> >> Why is this accepted? Isn't capture of locals also disabled, as >> demonstrated in the test: >> >> // Cant capture locals >> + assertFail("compiler.err.non-static.cant.be.ref", >> + "class R { \n" + >> " void m(int y) { \n" + >> " record RR(int x) { public int x() { return y; }};\n" + >> " }\n" + >> "}"); > sorry I should have been more specific. When I said: "with the current > conditions" in my previous mail I should had said: "with current state > without the patch this code is accepted" that's what I meant. Without > the patch access to non-static fields from records are banned but > access to local variables is not. This patch is closing that last gap > > Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 13 17:46:08 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 13 Jan 2020 12:46:08 -0500 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: <66a327aa-bc0a-4039-e328-d1ca97423bd0@oracle.com> References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> <1bf9b149-df64-3a7d-ca1c-2fcf1237eb6d@oracle.com> <66a327aa-bc0a-4039-e328-d1ca97423bd0@oracle.com> Message-ID: <28d36ee0-af69-9a11-63f4-dab199a0257b@oracle.com> On 1/13/20 9:46 AM, Maurizio Cimadamore wrote: > > Thanks for the explanation. I've convinced myself that the code is > correct. Basically, if we're trying to access a local variable defined > in a method whose class is != than the current class && the current > class is also static (which can only happen with records, as that's > the only local construct which can also be static), an error should be > issued. > cool thanks, > Maurizio > Vicente > On 13/01/2020 13:39, Vicente Romero wrote: >> >> >> On 1/10/20 8:02 PM, Maurizio Cimadamore wrote: >>> >>> >>> On 10/01/2020 22:53, Vicente Romero wrote: >>>> but this code is accepted: >>>> >>>> class R { >>>> ??? void m() { >>>> int z = 0; >>>> ??????? record RR(int x) { public int x() { return z; }}; >>>> ??? } >>>> } >>> >>> Why is this accepted? Isn't capture of locals also disabled, as >>> demonstrated in the test: >>> >>> // Cant capture locals >>> + assertFail("compiler.err.non-static.cant.be.ref", >>> + "class R { \n" + >>> " void m(int y) { \n" + >>> " record RR(int x) { public int x() { return y; }};\n" + >>> " }\n" + >>> "}"); >> sorry I should have been more specific. When I said: "with the >> current conditions" in my previous mail I should had said: "with >> current state without the patch this code is accepted" that's what I >> meant. Without the patch access to non-static fields from records are >> banned but access to local variables is not. This patch is closing >> that last gap >> >> Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 13 20:02:46 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 13 Jan 2020 15:02:46 -0500 Subject: RFR: CSR: JDK-8236189: local records shouldn't capture any non-static state from any enclosing type Message-ID: Hi, I need a reviewer for CSR [1]: "local records shouldn't capture any non-static state from any enclosing type". I contains the spec update enforcing that local records can't capture any non-static state from enclosing types, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236189 From maurizio.cimadamore at oracle.com Mon Jan 13 21:05:45 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 Jan 2020 21:05:45 +0000 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: <28d36ee0-af69-9a11-63f4-dab199a0257b@oracle.com> References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> <1bf9b149-df64-3a7d-ca1c-2fcf1237eb6d@oracle.com> <66a327aa-bc0a-4039-e328-d1ca97423bd0@oracle.com> <28d36ee0-af69-9a11-63f4-dab199a0257b@oracle.com> Message-ID: Maybe too late but we might want to add a test for type-variables - e.g. accessing enclosing type-variables should equally be banned. Maurizio On 13/01/2020 17:46, Vicente Romero wrote: > > > On 1/13/20 9:46 AM, Maurizio Cimadamore wrote: >> >> Thanks for the explanation. I've convinced myself that the code is >> correct. Basically, if we're trying to access a local variable >> defined in a method whose class is != than the current class && the >> current class is also static (which can only happen with records, as >> that's the only local construct which can also be static), an error >> should be issued. >> > > cool thanks, > >> Maurizio >> > > Vicente > >> On 13/01/2020 13:39, Vicente Romero wrote: >>> >>> >>> On 1/10/20 8:02 PM, Maurizio Cimadamore wrote: >>>> >>>> >>>> On 10/01/2020 22:53, Vicente Romero wrote: >>>>> but this code is accepted: >>>>> >>>>> class R { >>>>> ??? void m() { >>>>> int z = 0; >>>>> ??????? record RR(int x) { public int x() { return z; }}; >>>>> ??? } >>>>> } >>>> >>>> Why is this accepted? Isn't capture of locals also disabled, as >>>> demonstrated in the test: >>>> >>>> // Cant capture locals >>>> + assertFail("compiler.err.non-static.cant.be.ref", >>>> + "class R { \n" + >>>> " void m(int y) { \n" + >>>> " record RR(int x) { public int x() { return y; }};\n" + >>>> " }\n" + >>>> "}"); >>> sorry I should have been more specific. When I said: "with the >>> current conditions" in my previous mail I should had said: "with >>> current state without the patch this code is accepted" that's what I >>> meant. Without the patch access to non-static fields from records >>> are banned but access to local variables is not. This patch is >>> closing that last gap >>> >>> Vicente > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jan 13 21:06:51 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 Jan 2020 21:06:51 +0000 Subject: RFR: CSR: JDK-8236189: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: References: Message-ID: <62b12d25-fbf5-57f3-cf96-c7bbf06c4795@oracle.com> Reviewed Maurizio On 13/01/2020 20:02, Vicente Romero wrote: > Hi, > > I need a reviewer for CSR [1]: "local records shouldn't capture any > non-static state from any enclosing type". I contains the spec update > enforcing that local records can't capture any non-static state from > enclosing types, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236189 From vicente.romero at oracle.com Tue Jan 14 03:37:31 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 13 Jan 2020 22:37:31 -0500 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> <1bf9b149-df64-3a7d-ca1c-2fcf1237eb6d@oracle.com> <66a327aa-bc0a-4039-e328-d1ca97423bd0@oracle.com> <28d36ee0-af69-9a11-63f4-dab199a0257b@oracle.com> Message-ID: I will add a test in the lines of: class Outer { ??? void m() { ??????? record R(T t) {} ??? } } to the patch Thanks, Vicente On 1/13/20 4:05 PM, Maurizio Cimadamore wrote: > > Maybe too late but we might want to add a test for type-variables - > e.g. accessing enclosing type-variables should equally be banned. > > Maurizio > > On 13/01/2020 17:46, Vicente Romero wrote: >> >> >> On 1/13/20 9:46 AM, Maurizio Cimadamore wrote: >>> >>> Thanks for the explanation. I've convinced myself that the code is >>> correct. Basically, if we're trying to access a local variable >>> defined in a method whose class is != than the current class && the >>> current class is also static (which can only happen with records, as >>> that's the only local construct which can also be static), an error >>> should be issued. >>> >> >> cool thanks, >> >>> Maurizio >>> >> >> Vicente >> >>> On 13/01/2020 13:39, Vicente Romero wrote: >>>> >>>> >>>> On 1/10/20 8:02 PM, Maurizio Cimadamore wrote: >>>>> >>>>> >>>>> On 10/01/2020 22:53, Vicente Romero wrote: >>>>>> but this code is accepted: >>>>>> >>>>>> class R { >>>>>> ??? void m() { >>>>>> int z = 0; >>>>>> ??????? record RR(int x) { public int x() { return z; }}; >>>>>> ??? } >>>>>> } >>>>> >>>>> Why is this accepted? Isn't capture of locals also disabled, as >>>>> demonstrated in the test: >>>>> >>>>> // Cant capture locals >>>>> + assertFail("compiler.err.non-static.cant.be.ref", >>>>> + "class R { \n" + >>>>> " void m(int y) { \n" + >>>>> " record RR(int x) { public int x() { return y; }};\n" + >>>>> " }\n" + >>>>> "}"); >>>> sorry I should have been more specific. When I said: "with the >>>> current conditions" in my previous mail I should had said: "with >>>> current state without the patch this code is accepted" that's what >>>> I meant. Without the patch access to non-static fields from records >>>> are banned but access to local variables is not. This patch is >>>> closing that last gap >>>> >>>> Vicente >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jan 14 07:00:44 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 13 Jan 2020 23:00:44 -0800 Subject: JDK 14 RFR of 8237062: Refine JSR 269 API ahead of Java SE 14 MR Message-ID: Hello, From a pass over the JSR 269 API ahead of its MR for Java SE 14, I noticed some small areas for improvement: ??? http://cr.openjdk.java.net/~darcy/8237062.0/ The Filer is updated to refer to the Generated annotation that was added to the containing package back in Java SE 9. The largest update is for AnnotatedConstruct to make some reference to how annotations are record components are propagated down to other members. Patch below; thanks, -Joe --- old/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 2020-01-13 22:55:36.206212693 -0800 +++ new/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 2020-01-13 22:55:36.026302687 -0800 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -113,7 +113,7 @@ ? * to overwrite existing files that were not generated. ? * ? *

Processors can indicate a source or class file is generated by - * including a {@code javax.annotation.Generated} annotation if the + * including a {@link javax.annotation.processing.Generated} annotation if the ? * environment is configured so that that type is accessible. ? * ? * @apiNote Some of the effect of overwriting a file can be --- old/src/java.compiler/share/classes/javax/annotation/processing/Processor.java 2020-01-13 22:55:36.578026707 -0800 +++ new/src/java.compiler/share/classes/javax/annotation/processing/Processor.java 2020-01-13 22:55:36.406112701 -0800 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -130,7 +130,7 @@ ? * annotations on elements, are ignored when computing whether or not ? * an annotation type is present. ? * - *

An annotation is present if it meets the definition of being + *

An annotation is present if it meets the definition of being ? * present given in {@link AnnotatedConstruct}. In brief, an ? * annotation is considered present for the purposes of discovery if ? * it is directly present or present via inheritance. An annotation is --- old/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java 2020-01-13 22:55:37.289670733 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java 2020-01-13 22:55:37.113758726 -0800 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -60,10 +60,17 @@ ? * the source code of representation of C, then A is ? * explicitly declared as applying to C. ? * + * An annotation of type AT on a {@linkplain + * RecordComponentElement record component} can be implicitly propagated + * down to affiliated mandated members. Type annotations modifying the + * type of a record component can be also propagated to mandated + * members. Propagation of the annotations to mandated members is + * governed by rules given in the The Java™ Language + * Specification. + * ? * If there are multiple annotations of type AT present on ? * C, then if AT is repeatable annotation type, an ? * annotation of type ATC is {@linkplain javax.lang.model.util.Elements#getOrigin(AnnotatedConstruct, AnnotationMirror) implicitly declared} on C. - * ? *

  • A representation of A appears in the executable output ? * for C, such as the {@code RuntimeVisibleAnnotations} or ? * {@code RuntimeVisibleParameterAnnotations} attributes of a class From maurizio.cimadamore at oracle.com Tue Jan 14 10:49:48 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 14 Jan 2020 10:49:48 +0000 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> <1bf9b149-df64-3a7d-ca1c-2fcf1237eb6d@oracle.com> <66a327aa-bc0a-4039-e328-d1ca97423bd0@oracle.com> <28d36ee0-af69-9a11-63f4-dab199a0257b@oracle.com> Message-ID: Thanks! Maurizio On 14/01/2020 03:37, Vicente Romero wrote: > I will add a test in the lines of: > > class Outer { > ??? void m() { > ??????? record R(T t) {} > ??? } > } > > to the patch > > Thanks, > Vicente > > On 1/13/20 4:05 PM, Maurizio Cimadamore wrote: >> >> Maybe too late but we might want to add a test for type-variables - >> e.g. accessing enclosing type-variables should equally be banned. >> >> Maurizio >> >> On 13/01/2020 17:46, Vicente Romero wrote: >>> >>> >>> On 1/13/20 9:46 AM, Maurizio Cimadamore wrote: >>>> >>>> Thanks for the explanation. I've convinced myself that the code is >>>> correct. Basically, if we're trying to access a local variable >>>> defined in a method whose class is != than the current class && the >>>> current class is also static (which can only happen with records, >>>> as that's the only local construct which can also be static), an >>>> error should be issued. >>>> >>> >>> cool thanks, >>> >>>> Maurizio >>>> >>> >>> Vicente >>> >>>> On 13/01/2020 13:39, Vicente Romero wrote: >>>>> >>>>> >>>>> On 1/10/20 8:02 PM, Maurizio Cimadamore wrote: >>>>>> >>>>>> >>>>>> On 10/01/2020 22:53, Vicente Romero wrote: >>>>>>> but this code is accepted: >>>>>>> >>>>>>> class R { >>>>>>> ??? void m() { >>>>>>> int z = 0; >>>>>>> ??????? record RR(int x) { public int x() { return z; }}; >>>>>>> ??? } >>>>>>> } >>>>>> >>>>>> Why is this accepted? Isn't capture of locals also disabled, as >>>>>> demonstrated in the test: >>>>>> >>>>>> // Cant capture locals >>>>>> + assertFail("compiler.err.non-static.cant.be.ref", >>>>>> + "class R { \n" + >>>>>> " void m(int y) { \n" + >>>>>> " record RR(int x) { public int x() { return y; }};\n" + >>>>>> " }\n" + >>>>>> "}"); >>>>> sorry I should have been more specific. When I said: "with the >>>>> current conditions" in my previous mail I should had said: "with >>>>> current state without the patch this code is accepted" that's what >>>>> I meant. Without the patch access to non-static fields from >>>>> records are banned but access to local variables is not. This >>>>> patch is closing that last gap >>>>> >>>>> Vicente >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Tue Jan 14 11:48:37 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 14 Jan 2020 12:48:37 +0100 Subject: JDK 14 RFR of 8237062: Refine JSR 269 API ahead of Java SE 14 MR In-Reply-To: References: Message-ID: <90a691a5-24b2-f464-533c-1aab6e44c2a5@oracle.com> Looks good to me. Jan On 14. 01. 20 8:00, Joe Darcy wrote: > Hello, > > From a pass over the JSR 269 API ahead of its MR for Java SE 14, I > noticed some small areas for improvement: > > ??? http://cr.openjdk.java.net/~darcy/8237062.0/ > > The Filer is updated to refer to the Generated annotation that was added > to the containing package back in Java SE 9. The largest update is for > AnnotatedConstruct to make some reference to how annotations are record > components are propagated down to other members. > > Patch below; thanks, > > -Joe > > --- > old/src/java.compiler/share/classes/javax/annotation/processing/Filer.java > 2020-01-13 22:55:36.206212693 -0800 > +++ > new/src/java.compiler/share/classes/javax/annotation/processing/Filer.java > 2020-01-13 22:55:36.026302687 -0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -113,7 +113,7 @@ > ? * to overwrite existing files that were not generated. > ? * > ? *

    Processors can indicate a source or class file is generated by > - * including a {@code javax.annotation.Generated} annotation if the > + * including a {@link javax.annotation.processing.Generated} annotation > if the > ? * environment is configured so that that type is accessible. > ? * > ? * @apiNote Some of the effect of overwriting a file can be > --- > old/src/java.compiler/share/classes/javax/annotation/processing/Processor.java > 2020-01-13 22:55:36.578026707 -0800 > +++ > new/src/java.compiler/share/classes/javax/annotation/processing/Processor.java > 2020-01-13 22:55:36.406112701 -0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -130,7 +130,7 @@ > ? * annotations on elements, are ignored when computing whether or not > ? * an annotation type is present. > ? * > - *

    An annotation is present if it meets the definition of being > + *

    An annotation is present if it meets the definition of > being > ? * present given in {@link AnnotatedConstruct}. In brief, an > ? * annotation is considered present for the purposes of discovery if > ? * it is directly present or present via inheritance. An annotation is > --- > old/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java > 2020-01-13 22:55:37.289670733 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java > 2020-01-13 22:55:37.113758726 -0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -60,10 +60,17 @@ > ? * the source code of representation of C, then A is > ? * explicitly declared as applying to C. > ? * > + * An annotation of type AT on a {@linkplain > + * RecordComponentElement record component} can be implicitly propagated > + * down to affiliated mandated members. Type annotations modifying the > + * type of a record component can be also propagated to mandated > + * members. Propagation of the annotations to mandated members is > + * governed by rules given in the The Java™ Language > + * Specification. > + * > ? * If there are multiple annotations of type AT present on > ? * C, then if AT is repeatable annotation type, an > ? * annotation of type ATC is {@linkplain > javax.lang.model.util.Elements#getOrigin(AnnotatedConstruct, > AnnotationMirror) implicitly declared} on C. > - * > ? *

  • A representation of A appears in the executable output > ? * for C, such as the {@code RuntimeVisibleAnnotations} or > ? * {@code RuntimeVisibleParameterAnnotations} attributes of a class > From vicente.romero at oracle.com Tue Jan 14 12:05:18 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 14 Jan 2020 07:05:18 -0500 Subject: RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type In-Reply-To: References: <99f604fd-f89f-224b-d016-0a62d4f54adb@oracle.com> <5d8b40bb-0bf1-49b1-ba15-19e57b549c43@oracle.com> <60883e1a-6b56-e605-a6c1-f8d4071223b9@oracle.com> <538d2c1a-7218-9f19-6652-b536718b2dcc@oracle.com> <1bf9b149-df64-3a7d-ca1c-2fcf1237eb6d@oracle.com> <66a327aa-bc0a-4039-e328-d1ca97423bd0@oracle.com> <28d36ee0-af69-9a11-63f4-dab199a0257b@oracle.com> Message-ID: ;) sure, good catch Vicente On 1/14/20 5:49 AM, Maurizio Cimadamore wrote: > > Thanks! > > Maurizio > > On 14/01/2020 03:37, Vicente Romero wrote: >> I will add a test in the lines of: >> >> class Outer { >> ??? void m() { >> ??????? record R(T t) {} >> ??? } >> } >> >> to the patch >> >> Thanks, >> Vicente >> >> On 1/13/20 4:05 PM, Maurizio Cimadamore wrote: >>> >>> Maybe too late but we might want to add a test for type-variables - >>> e.g. accessing enclosing type-variables should equally be banned. >>> >>> Maurizio >>> >>> On 13/01/2020 17:46, Vicente Romero wrote: >>>> >>>> >>>> On 1/13/20 9:46 AM, Maurizio Cimadamore wrote: >>>>> >>>>> Thanks for the explanation. I've convinced myself that the code is >>>>> correct. Basically, if we're trying to access a local variable >>>>> defined in a method whose class is != than the current class && >>>>> the current class is also static (which can only happen with >>>>> records, as that's the only local construct which can also be >>>>> static), an error should be issued. >>>>> >>>> >>>> cool thanks, >>>> >>>>> Maurizio >>>>> >>>> >>>> Vicente >>>> >>>>> On 13/01/2020 13:39, Vicente Romero wrote: >>>>>> >>>>>> >>>>>> On 1/10/20 8:02 PM, Maurizio Cimadamore wrote: >>>>>>> >>>>>>> >>>>>>> On 10/01/2020 22:53, Vicente Romero wrote: >>>>>>>> but this code is accepted: >>>>>>>> >>>>>>>> class R { >>>>>>>> ??? void m() { >>>>>>>> int z = 0; >>>>>>>> ??????? record RR(int x) { public int x() { return z; }}; >>>>>>>> ??? } >>>>>>>> } >>>>>>> >>>>>>> Why is this accepted? Isn't capture of locals also disabled, as >>>>>>> demonstrated in the test: >>>>>>> >>>>>>> // Cant capture locals >>>>>>> + assertFail("compiler.err.non-static.cant.be.ref", >>>>>>> + "class R { \n" + >>>>>>> " void m(int y) { \n" + >>>>>>> " record RR(int x) { public int x() { return y; }};\n" + >>>>>>> " }\n" + >>>>>>> "}"); >>>>>> sorry I should have been more specific. When I said: "with the >>>>>> current conditions" in my previous mail I should had said: "with >>>>>> current state without the patch this code is accepted" that's >>>>>> what I meant. Without the patch access to non-static fields from >>>>>> records are banned but access to local variables is not. This >>>>>> patch is closing that last gap >>>>>> >>>>>> Vicente >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Tue Jan 14 13:48:45 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 14 Jan 2020 14:48:45 +0100 Subject: RFR (14): JDK-8233655: NPE at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply Message-ID: Hi, Under bug JDK-8177068, the speculative attribution was improved to better handle missing classes. Before that, errors reported outside of the speculative tree were propagated outside of the speculative attribution. This was removed, as it seemed unnecessary due to the new handling of missing classes. But it turns out it is still needed, as shown in this bug. A simple testcase is: --- public class JDK8233655 { public void t() { Class c= test(test(JDK8233655Helper.class)); } private T test(Class c) { return null; } } --- public class JDK8233655Helper extends Unknown {} --- $ javac JDK8233655.java ... the exception from Flow ... The proposed fix is to restore the error handling similarly to what existed before JDK-8177068. Webrev: http://cr.openjdk.java.net/~jlahoda/8233655/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8233655 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Tue Jan 14 16:06:17 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 14 Jan 2020 16:06:17 +0000 Subject: RFR (14): JDK-8233655: NPE at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply In-Reply-To: References: Message-ID: <8b1d0409-b52d-efa9-26d7-72012b2476d6@oracle.com> Looks good Maurizio On 14/01/2020 13:48, Jan Lahoda wrote: > Hi, > > Under bug JDK-8177068, the speculative attribution was improved to > better handle missing classes. Before that, errors reported outside of > the speculative tree were propagated outside of the speculative > attribution. This was removed, as it seemed unnecessary due to the new > handling of missing classes. But it turns out it is still needed, as > shown in this bug. A simple testcase is: > --- > public class JDK8233655 { > ??? public void t() { > ??????? Class c= test(test(JDK8233655Helper.class)); > ??? } > ??? private T test(Class c) { > ??????? return null; > ??? } > } > --- > public class JDK8233655Helper extends Unknown {} > --- > > $ javac JDK8233655.java > ... the exception from Flow ... > > The proposed fix is to restore the error handling similarly to what > existed before JDK-8177068. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8233655/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8233655 > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Tue Jan 14 23:25:09 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 14 Jan 2020 18:25:09 -0500 Subject: RFR JDK-15: 8236682: Javac generates a redundant FieldRef constant for record fields Message-ID: Please review the fix for [1] at [2]. Javac is generating a redundant FieldRef for each instance field in a record. The bug was that when generating the body for the accessor, basically the return statement as in: record R(int i) {}, javac generates accessor: public int i() { ??? return i;? <-------------? this statement } so for the return statement javac was using the record component's symbol instead of using the field's symbol. As a result there were two FieldRef entries in the constant pool per field. This patch fixes this issue, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236682 [2] http://cr.openjdk.java.net/~vromero/8236682/webrev.00/ From maurizio.cimadamore at oracle.com Tue Jan 14 23:34:50 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 14 Jan 2020 23:34:50 +0000 Subject: RFR JDK-15: 8236682: Javac generates a redundant FieldRef constant for record fields In-Reply-To: References: Message-ID: <23d35cb3-1a34-5458-8aa4-c5e1d0240ecd@oracle.com> Looks good - should (maybe in the future) the implementation class for record component symbol point to the synthetic field derived from it? Maurizio On 14/01/2020 23:25, Vicente Romero wrote: > Please review the fix for [1] at [2]. Javac is generating a redundant > FieldRef for each instance field in a record. The bug was that when > generating the body for the accessor, basically the return statement > as in: > > record R(int i) {}, javac generates accessor: > > public int i() { > ??? return i;? <-------------? this statement > } > > so for the return statement javac was using the record component's > symbol instead of using the field's symbol. As a result there were two > FieldRef entries in the constant pool per field. This patch fixes this > issue, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236682 > [2] http://cr.openjdk.java.net/~vromero/8236682/webrev.00/ > From vicente.romero at oracle.com Wed Jan 15 00:48:35 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 14 Jan 2020 19:48:35 -0500 Subject: RFR JDK-15: 8236682: Javac generates a redundant FieldRef constant for record fields In-Reply-To: <23d35cb3-1a34-5458-8aa4-c5e1d0240ecd@oracle.com> References: <23d35cb3-1a34-5458-8aa4-c5e1d0240ecd@oracle.com> Message-ID: Hi, Thanks for the review. On 1/14/20 6:34 PM, Maurizio Cimadamore wrote: > Looks good - should (maybe in the future) the implementation class for > record component symbol point to the synthetic field derived from it? yep we could do that > > Maurizio Vicente > > On 14/01/2020 23:25, Vicente Romero wrote: >> Please review the fix for [1] at [2]. Javac is generating a redundant >> FieldRef for each instance field in a record. The bug was that when >> generating the body for the accessor, basically the return statement >> as in: >> >> record R(int i) {}, javac generates accessor: >> >> public int i() { >> ??? return i;? <-------------? this statement >> } >> >> so for the return statement javac was using the record component's >> symbol instead of using the field's symbol. As a result there were >> two FieldRef entries in the constant pool per field. This patch fixes >> this issue, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8236682 >> [2] http://cr.openjdk.java.net/~vromero/8236682/webrev.00/ >> From vicente.romero at oracle.com Wed Jan 15 19:10:10 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 15 Jan 2020 14:10:10 -0500 Subject: RFR: JDK-8237214: fix for JDK-8236597 reintroduced wrong subexpression Message-ID: <199a42b1-24e1-b37b-ee03-d51c60abc3b0@oracle.com> Hi, Please review this patch that fixes [1] at [2]. The fix for JDK-8237214 that I pushed this morning reintroduced a subexpression at JavacParser that has been removed by another patch. Both patches were based on the same code and both were modifying the same line, then I resurrected a condition that was removed by a previous patch. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8237214 [2] http://cr.openjdk.java.net/~vromero/8237214/webrev.00/ From maurizio.cimadamore at oracle.com Wed Jan 15 19:14:41 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 15 Jan 2020 19:14:41 +0000 Subject: RFR: JDK-8237214: fix for JDK-8236597 reintroduced wrong subexpression In-Reply-To: <199a42b1-24e1-b37b-ee03-d51c60abc3b0@oracle.com> References: <199a42b1-24e1-b37b-ee03-d51c60abc3b0@oracle.com> Message-ID: <87930306-f2e5-273b-9d9e-dcc9640fef1e@oracle.com> Looks good Maurizio On 15/01/2020 19:10, Vicente Romero wrote: > Hi, > > Please review this patch that fixes [1] at [2]. The fix for > JDK-8237214 that I pushed this morning reintroduced a subexpression at > JavacParser that has been removed by another patch. Both patches were > based on the same code and both were modifying the same line, then I > resurrected a condition that was removed by a previous patch. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8237214 > [2] http://cr.openjdk.java.net/~vromero/8237214/webrev.00/ From jonathan.gibbons at oracle.com Wed Jan 15 22:20:26 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 15 Jan 2020 14:20:26 -0800 Subject: [PATCH] JDK-8233680: JavacFileManager.close() doesn't clear some cache instance variables In-Reply-To: References: Message-ID: Daniel, I've pushed your proposed fix for JavacFileManager.java, but without the test, which still has enough issues that fixing them outweighs the benefit. For this case, I have labeled the bug 'noreg-trivial' and 'noreg-perf' on the grounds that the fix is trivial and (at least in part) is just a memory usage issue. I see the test had a binary blob in it. As a general rule, we don't put binary blobs in our source repos, and certainly not for a jar file. Also, tests for javac functionality do not belong in the javadoc directory. Your comment about not being able to reuse the filemanager needs more investigation, but that could be done separately. -- Jon On 12/20/2019 01:01 AM, Daniel Le Duc Khoi Nguyen wrote: > Hi Jon, > > I've converted the test to Java and moved it under the javadoc package to avoid > any confusion of it being a compiler test. I've also simplified and add comments > to it. Please refer to JDK-8233680-1.patch. > > In order to trigger the bug, one must reuse the JavacFileManager object that is > created automatically by the compiler tools (when no fileManager argument is > passed to getTask) after it's been automatically closed. > > This is only possible with JavaDoc and not javac. JavacTaskImpl.cleanup and > JavacTaskImpl.prepareCompiler together make reusing the JavacFileManager object > impossible. > > If you'd like to remove JavaDoc from the test dependency, please refer to > JDK-8233680-javac-test-not-working-wip.patch and see if you could take it > further. Thank you. From vicente.romero at oracle.com Thu Jan 16 21:24:15 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 16 Jan 2020 16:24:15 -0500 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components Message-ID: Please review the fix for [1] at [2]. Some background: Annotations applied to record components are propagated to the corresponding record member so if an annotation has target: FIELD, it is propagated to the corresponding FIELD, if it has target METHOD, it is propagated to the accessor and so on. But at the moment when method members are generated there is no enough information to propagate only the right annotations. So all the annotations are propagated to all the possible locations. So there is a point when we need to remove all the annotations that are not in place before going on with the annotation party. On top of the above there is the issue that there is no AST representing record components, just symbols so the corresponding field has been holding all the annotations and it's metadata has been modified as if it was both a field and a record component. So there are two places where we need to trim annotations from: the metadata of the symbol and / or the modifiers in the AST. Whatever is in the metadata will be written to the class file, whatever is in the modifiers could be see by annotation processors. The metadata contains both type annotations and declaration annotations. Type annotations are all in the right place as they are applicable to all the types of the corresponding record members generated by the compiler. But we could need to remove declaration annotations. So for declaration annotations if they are not applicable to the given record member it will be needed to remove them. For the AST modifiers if the annotation is not applicable either as type annotation and or declaration annotation, only in the last case it will be removed. So it could be that an annotation is removed as a declaration annotation but it is kept in the AST modifier for further inspection by annotation processors. For example: ??? import java.lang.annotation.*; ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) ??? @Retention(RetentionPolicy.RUNTIME) ??? @interface Anno { } ??? record R(@Anno String s) {} just before Enter ends we will have for the case of the generated field: ? - @Anno in the modifier ? - @Anno as a type annotation ? - @Anno as a declaration annotation the last one should be removed because the annotation has not FIELD as target but it was applied as a declaration annotation because the field was being treated both as a field and as a record component. Once we reach the point when the corresponding annotations have been copied to the record component, the field doesn't need to hold annotations that are not intended for it anymore. Still @Anno has to be kept in the AST's modifiers as it is applicable as a type annotation to the type of the field. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236210 [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ From jeremy.kuhn.java at gmail.com Thu Jan 16 23:48:05 2020 From: jeremy.kuhn.java at gmail.com (Jeremy Kuhn) Date: Fri, 17 Jan 2020 00:48:05 +0100 Subject: JDK13 annotation processors not run when a supported annotation type specifies a module Message-ID: Hi, I've just ran into this issue while testing annotation processors with JDK13. It happens when you specify a @SupportedAnnotationTypes annotation with annotation names prefixed with composite module names like the following: @SupportedAnnotationTypes({"com.example.moda/com.example.moda.annotation.SomeAnnotation"}) public class ModuleAnnotationProcessor extends AbstractProcessor { ... } This is perfectly valid according to the documentation and was working just fine until JDK13 "the name of the annotation type can be optionally preceded by a module name followed by a "/" character. For example, if a processor supports "a.B", this can include multiple annotation types named a.B which reside in different modules. To only support a.B in the Foo module, instead use "Foo/a.B". If a module name is included, only an annotation in that module is matched. In particular, if a module name is given in an environment where modules are not supported, such as an annotation processing environment configured for a source version without modules, then the annotation types with a module name do *not* match." -- https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/Processor.html#getSupportedAnnotationTypes() I've track down the issue in JavacProcessingEnvironment.java to the following commit: https://hg.openjdk.java.net/jdk/jdk/diff/d84176dd57b0/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Some checks have been added to make sure supported annotation strings are valid and proper warning reported, unfortunately there's an error in the module's name check: private static Pattern importStringToPattern(boolean allowModules, String s, Processor p, Log log, boolean lint) { .... else { String moduleName = s.substring(0, slash); if (!SourceVersion.isIdentifier(moduleName)) { return warnAndNoMatches(s, p, log, lint); } .... } A module name is not a simple identifier like "moda", "com.example.moda" is also a valid module name as stated in the Java Language Specification (7.7). This results in always returning a no match pattern when such module name is used and the processor basically ignored. If we do not prefix the annotation with a module name, so there is a workaround but that doesn't match the API doc. Please let me know if I can help! Rgs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jan 16 23:55:10 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 16 Jan 2020 15:55:10 -0800 Subject: JDK13 annotation processors not run when a supported annotation type specifies a module In-Reply-To: References: Message-ID: <361c320b-344a-3563-763e-da069b0d2026@oracle.com> Jeremy, Thanks for the detailed analysis. Filed as https://bugs.openjdk.java.net/browse/JDK-8237450 On 01/16/2020 03:48 PM, Jeremy Kuhn wrote: > Hi, > > I've just ran into this issue while testing annotation processors with > JDK13. It happens when you specify a @SupportedAnnotationTypes > annotation with annotation names prefixed with composite module names > like the following: > > @SupportedAnnotationTypes({"com.example.moda/com.example.moda.annotation.SomeAnnotation"}) > public class ModuleAnnotationProcessor extends AbstractProcessor { > ?? ... > } > > This is perfectly valid according to the documentation and was working > just fine until JDK13 > > "the name of the annotation type can be optionally preceded by a > module name followed by a |"/"| character. For example, if a processor > supports |"a.B"|, this can include multiple annotation types named > |a.B| which reside in different modules. To only support |a.B| in the > |Foo| module, instead use |"Foo/a.B"|. If a module name is included, > only an annotation in that module is matched. In particular, if a > module name is given in an environment where modules are not > supported, such as an annotation processing environment configured for > a source version > > without modules, then the annotation types with a module name do /not/ > match." -- > https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/Processor.html#getSupportedAnnotationTypes() > > > I've track down the issue in JavacProcessingEnvironment.java to the > following commit: > https://hg.openjdk.java.net/jdk/jdk/diff/d84176dd57b0/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > > Some checks have been added to make sure supported annotation strings > are valid and proper warning reported, unfortunately there's an error > in the module's name check: > > private static Pattern importStringToPattern(boolean allowModules, > String s, Processor p, Log log, boolean lint) { > ??? .... > ??? else { > ? ? ? ? ? ? String moduleName = s.substring(0, slash); > ? ? ? ? ? ? if (!SourceVersion.isIdentifier(moduleName)) { > ? ? ? ? ? ? ? ? return warnAndNoMatches(s, p, log, lint); > ? ? ? ? ? ? } > ??? .... > } > > A module name is not a simple identifier like "moda", > "com.example.moda" is also a valid module name as stated in the Java > Language Specification (7.7). This results in always returning a no > match pattern when such module name is used and the processor > basically ignored. > > If we do not prefix the annotation with a module name, so there is a > workaround but that doesn't match the API doc. > > Please let me know if I can help! > > Rgs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jan 16 23:57:08 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 16 Jan 2020 15:57:08 -0800 Subject: JDK13 annotation processors not run when a supported annotation type specifies a module In-Reply-To: References: Message-ID: <27d58a7a-79e7-34db-8152-fcba4d76fa81@oracle.com> Suggestion inline: -- Jon On 01/16/2020 03:48 PM, Jeremy Kuhn wrote: > Hi, > > I've just ran into this issue while testing annotation processors with > JDK13. It happens when you specify a @SupportedAnnotationTypes > annotation with annotation names prefixed with composite module names > like the following: > > @SupportedAnnotationTypes({"com.example.moda/com.example.moda.annotation.SomeAnnotation"}) > public class ModuleAnnotationProcessor extends AbstractProcessor { > ?? ... > } > > This is perfectly valid according to the documentation and was working > just fine until JDK13 > > "the name of the annotation type can be optionally preceded by a > module name followed by a |"/"| character. For example, if a processor > supports |"a.B"|, this can include multiple annotation types named > |a.B| which reside in different modules. To only support |a.B| in the > |Foo| module, instead use |"Foo/a.B"|. If a module name is included, > only an annotation in that module is matched. In particular, if a > module name is given in an environment where modules are not > supported, such as an annotation processing environment configured for > a source version > > without modules, then the annotation types with a module name do /not/ > match." -- > https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/Processor.html#getSupportedAnnotationTypes() > > > I've track down the issue in JavacProcessingEnvironment.java to the > following commit: > https://hg.openjdk.java.net/jdk/jdk/diff/d84176dd57b0/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > > Some checks have been added to make sure supported annotation strings > are valid and proper warning reported, unfortunately there's an error > in the module's name check: > > private static Pattern importStringToPattern(boolean allowModules, > String s, Processor p, Log log, boolean lint) { > ??? .... > ??? else { > ? ? ? ? ? ? String moduleName = s.substring(0, slash); > ? ? ? ? ? ? if (!SourceVersion.isIdentifier(moduleName)) { It looks like this should use isName instead of isIdentifier. > ? ? ? ? ? ? ? ? return warnAndNoMatches(s, p, log, lint); > ? ? ? ? ? ? } > ??? .... > } > > A module name is not a simple identifier like "moda", > "com.example.moda" is also a valid module name as stated in the Java > Language Specification (7.7). This results in always returning a no > match pattern when such module name is used and the processor > basically ignored. > > If we do not prefix the annotation with a module name, so there is a > workaround but that doesn't match the API doc. > > Please let me know if I can help! > > Rgs -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jan 17 11:27:38 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 17 Jan 2020 11:27:38 +0000 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: References: Message-ID: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> Tricky indeed. Few suggestions: * It seems like SymbolMetadata::remove has morphed more into a removeDeclarationMetadata (since you no longer remove type annos from there) * Another way to simplify the code and avoid the 'ignoreTypeUse' trick, would be for "annotationApplicable" to give you the list of all the applicable targets, rather than just a boolean. Then, from there, I think you can implement the rest of your logic w/o the need of rechecking for applicability multiple times. * The test seems good, but it only checks for one side of the story: classfile generation; should we also test that the annotations are indeed available to processors? Cheers Maurizio On 16/01/2020 21:24, Vicente Romero wrote: > Please review the fix for [1] at [2]. Some background: > > Annotations applied to record components are propagated to the > corresponding record member so if an annotation has target: FIELD, it > is propagated to the corresponding FIELD, if it has target METHOD, it > is propagated to the accessor and so on. But at the moment when method > members are generated there is no enough information to propagate only > the right annotations. So all the annotations are propagated to all > the possible locations. > > So there is a point when we need to remove all the annotations that > are not in place before going on with the annotation party. On top of > the above there is the issue that there is no AST representing record > components, just symbols so the corresponding field has been holding > all the annotations and it's metadata has been modified as if it was > both a field and a record component. > > So there are two places where we need to trim annotations from: the > metadata of the symbol and / or the modifiers in the AST. Whatever is > in the metadata will be written to the class file, whatever is in the > modifiers could be see by annotation processors. > > The metadata contains both type annotations and declaration > annotations. Type annotations are all in the right place as they are > applicable to all the types of the corresponding record members > generated by the compiler. But we could need to remove declaration > annotations. So for declaration annotations if they are not applicable > to the given record member it will be needed to remove them. For the > AST modifiers if the annotation is not applicable either as type > annotation and or declaration annotation, only in the last case it > will be removed. > > So it could be that an annotation is removed as a declaration > annotation but it is kept in the AST modifier for further inspection > by annotation processors. > > For example: > > ??? import java.lang.annotation.*; > > ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) > ??? @Retention(RetentionPolicy.RUNTIME) > ??? @interface Anno { } > > ??? record R(@Anno String s) {} > > just before Enter ends we will have for the case of the generated field: > ? - @Anno in the modifier > ? - @Anno as a type annotation > ? - @Anno as a declaration annotation > > the last one should be removed because the annotation has not FIELD as > target but it was applied as a declaration annotation because the > field was being treated both as a field and as a record component. > Once we reach the point when the corresponding annotations have been > copied to the record component, the field doesn't need to hold > annotations that are not intended for it anymore. Still @Anno has to > be kept in the AST's modifiers as it is applicable as a type > annotation to the type of the field. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236210 > [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ > From vicente.romero at oracle.com Fri Jan 17 12:53:18 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 17 Jan 2020 07:53:18 -0500 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> Message-ID: Hi Maurizio, Thanks for the review, some comments below On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: > Tricky indeed. Few suggestions: > > * It seems like SymbolMetadata::remove has morphed more into a > removeDeclarationMetadata (since you no longer remove type annos from > there) true > > * Another way to simplify the code and avoid the 'ignoreTypeUse' > trick, would be for "annotationApplicable" to give you the list of all > the applicable targets, rather than just a boolean. Then, from there, > I think you can implement the rest of your logic w/o the need of > rechecking for applicability multiple times. right that could work, will give it a try > > * The test seems good, but it only checks for one side of the story: > classfile generation; should we also test that the annotations are > indeed available to processors? we have already tests for that but they live in another neighborhood, see: test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java we can eventually move them to RecordCompilationTests in a separate effort > > Cheers > Maurizio Vicente > > On 16/01/2020 21:24, Vicente Romero wrote: >> Please review the fix for [1] at [2]. Some background: >> >> Annotations applied to record components are propagated to the >> corresponding record member so if an annotation has target: FIELD, it >> is propagated to the corresponding FIELD, if it has target METHOD, it >> is propagated to the accessor and so on. But at the moment when >> method members are generated there is no enough information to >> propagate only the right annotations. So all the annotations are >> propagated to all the possible locations. >> >> So there is a point when we need to remove all the annotations that >> are not in place before going on with the annotation party. On top of >> the above there is the issue that there is no AST representing record >> components, just symbols so the corresponding field has been holding >> all the annotations and it's metadata has been modified as if it was >> both a field and a record component. >> >> So there are two places where we need to trim annotations from: the >> metadata of the symbol and / or the modifiers in the AST. Whatever is >> in the metadata will be written to the class file, whatever is in the >> modifiers could be see by annotation processors. >> >> The metadata contains both type annotations and declaration >> annotations. Type annotations are all in the right place as they are >> applicable to all the types of the corresponding record members >> generated by the compiler. But we could need to remove declaration >> annotations. So for declaration annotations if they are not >> applicable to the given record member it will be needed to remove >> them. For the AST modifiers if the annotation is not applicable >> either as type annotation and or declaration annotation, only in the >> last case it will be removed. >> >> So it could be that an annotation is removed as a declaration >> annotation but it is kept in the AST modifier for further inspection >> by annotation processors. >> >> For example: >> >> ??? import java.lang.annotation.*; >> >> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >> ??? @Retention(RetentionPolicy.RUNTIME) >> ??? @interface Anno { } >> >> ??? record R(@Anno String s) {} >> >> just before Enter ends we will have for the case of the generated field: >> ? - @Anno in the modifier >> ? - @Anno as a type annotation >> ? - @Anno as a declaration annotation >> >> the last one should be removed because the annotation has not FIELD >> as target but it was applied as a declaration annotation because the >> field was being treated both as a field and as a record component. >> Once we reach the point when the corresponding annotations have been >> copied to the record component, the field doesn't need to hold >> annotations that are not intended for it anymore. Still @Anno has to >> be kept in the AST's modifiers as it is applicable as a type >> annotation to the type of the field. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >> From maurizio.cimadamore at oracle.com Fri Jan 17 12:54:37 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 17 Jan 2020 12:54:37 +0000 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> Message-ID: <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> On 17/01/2020 12:53, Vicente Romero wrote: > Hi Maurizio, > > Thanks for the review, some comments below > > On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >> Tricky indeed. Few suggestions: >> >> * It seems like SymbolMetadata::remove has morphed more into a >> removeDeclarationMetadata (since you no longer remove type annos from >> there) > > true > >> >> * Another way to simplify the code and avoid the 'ignoreTypeUse' >> trick, would be for "annotationApplicable" to give you the list of >> all the applicable targets, rather than just a boolean. Then, from >> there, I think you can implement the rest of your logic w/o the need >> of rechecking for applicability multiple times. > > right that could work, will give it a try > >> >> * The test seems good, but it only checks for one side of the story: >> classfile generation; should we also test that the annotations are >> indeed available to processors? > > we have already tests for that but they live in another neighborhood, > see: > > test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java > > test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java > > > we can eventually move them to RecordCompilationTests in a separate > effort Ok - but do they check all the combinations that you gave recently added to the other test? Do they need to be made more powerful? Maurizio > >> >> Cheers >> Maurizio > > Vicente >> >> On 16/01/2020 21:24, Vicente Romero wrote: >>> Please review the fix for [1] at [2]. Some background: >>> >>> Annotations applied to record components are propagated to the >>> corresponding record member so if an annotation has target: FIELD, >>> it is propagated to the corresponding FIELD, if it has target >>> METHOD, it is propagated to the accessor and so on. But at the >>> moment when method members are generated there is no enough >>> information to propagate only the right annotations. So all the >>> annotations are propagated to all the possible locations. >>> >>> So there is a point when we need to remove all the annotations that >>> are not in place before going on with the annotation party. On top >>> of the above there is the issue that there is no AST representing >>> record components, just symbols so the corresponding field has been >>> holding all the annotations and it's metadata has been modified as >>> if it was both a field and a record component. >>> >>> So there are two places where we need to trim annotations from: the >>> metadata of the symbol and / or the modifiers in the AST. Whatever >>> is in the metadata will be written to the class file, whatever is in >>> the modifiers could be see by annotation processors. >>> >>> The metadata contains both type annotations and declaration >>> annotations. Type annotations are all in the right place as they are >>> applicable to all the types of the corresponding record members >>> generated by the compiler. But we could need to remove declaration >>> annotations. So for declaration annotations if they are not >>> applicable to the given record member it will be needed to remove >>> them. For the AST modifiers if the annotation is not applicable >>> either as type annotation and or declaration annotation, only in the >>> last case it will be removed. >>> >>> So it could be that an annotation is removed as a declaration >>> annotation but it is kept in the AST modifier for further inspection >>> by annotation processors. >>> >>> For example: >>> >>> ??? import java.lang.annotation.*; >>> >>> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >>> ??? @Retention(RetentionPolicy.RUNTIME) >>> ??? @interface Anno { } >>> >>> ??? record R(@Anno String s) {} >>> >>> just before Enter ends we will have for the case of the generated >>> field: >>> ? - @Anno in the modifier >>> ? - @Anno as a type annotation >>> ? - @Anno as a declaration annotation >>> >>> the last one should be removed because the annotation has not FIELD >>> as target but it was applied as a declaration annotation because the >>> field was being treated both as a field and as a record component. >>> Once we reach the point when the corresponding annotations have been >>> copied to the record component, the field doesn't need to hold >>> annotations that are not intended for it anymore. Still @Anno has to >>> be kept in the AST's modifiers as it is applicable as a type >>> annotation to the type of the field. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>> > From vicente.romero at oracle.com Fri Jan 17 13:00:41 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 17 Jan 2020 08:00:41 -0500 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> Message-ID: <6140c9fd-5cf6-d3d2-b961-7dcd05339115@oracle.com> On 1/17/20 7:54 AM, Maurizio Cimadamore wrote: > > On 17/01/2020 12:53, Vicente Romero wrote: >> Hi Maurizio, >> >> Thanks for the review, some comments below >> >> On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >>> Tricky indeed. Few suggestions: >>> >>> * It seems like SymbolMetadata::remove has morphed more into a >>> removeDeclarationMetadata (since you no longer remove type annos >>> from there) >> >> true >> >>> >>> * Another way to simplify the code and avoid the 'ignoreTypeUse' >>> trick, would be for "annotationApplicable" to give you the list of >>> all the applicable targets, rather than just a boolean. Then, from >>> there, I think you can implement the rest of your logic w/o the need >>> of rechecking for applicability multiple times. >> >> right that could work, will give it a try >> >>> >>> * The test seems good, but it only checks for one side of the story: >>> classfile generation; should we also test that the annotations are >>> indeed available to processors? >> >> we have already tests for that but they live in another neighborhood, >> see: >> >> test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java >> >> test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java >> >> >> we can eventually move them to RecordCompilationTests in a separate >> effort > > Ok - but do they check all the combinations that you gave recently > added to the other test? Do they need to be made more powerful? I will double check > > Maurizio Vicente > >> >>> >>> Cheers >>> Maurizio >> >> Vicente >>> >>> On 16/01/2020 21:24, Vicente Romero wrote: >>>> Please review the fix for [1] at [2]. Some background: >>>> >>>> Annotations applied to record components are propagated to the >>>> corresponding record member so if an annotation has target: FIELD, >>>> it is propagated to the corresponding FIELD, if it has target >>>> METHOD, it is propagated to the accessor and so on. But at the >>>> moment when method members are generated there is no enough >>>> information to propagate only the right annotations. So all the >>>> annotations are propagated to all the possible locations. >>>> >>>> So there is a point when we need to remove all the annotations that >>>> are not in place before going on with the annotation party. On top >>>> of the above there is the issue that there is no AST representing >>>> record components, just symbols so the corresponding field has been >>>> holding all the annotations and it's metadata has been modified as >>>> if it was both a field and a record component. >>>> >>>> So there are two places where we need to trim annotations from: the >>>> metadata of the symbol and / or the modifiers in the AST. Whatever >>>> is in the metadata will be written to the class file, whatever is >>>> in the modifiers could be see by annotation processors. >>>> >>>> The metadata contains both type annotations and declaration >>>> annotations. Type annotations are all in the right place as they >>>> are applicable to all the types of the corresponding record members >>>> generated by the compiler. But we could need to remove declaration >>>> annotations. So for declaration annotations if they are not >>>> applicable to the given record member it will be needed to remove >>>> them. For the AST modifiers if the annotation is not applicable >>>> either as type annotation and or declaration annotation, only in >>>> the last case it will be removed. >>>> >>>> So it could be that an annotation is removed as a declaration >>>> annotation but it is kept in the AST modifier for further >>>> inspection by annotation processors. >>>> >>>> For example: >>>> >>>> ??? import java.lang.annotation.*; >>>> >>>> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >>>> ??? @Retention(RetentionPolicy.RUNTIME) >>>> ??? @interface Anno { } >>>> >>>> ??? record R(@Anno String s) {} >>>> >>>> just before Enter ends we will have for the case of the generated >>>> field: >>>> ? - @Anno in the modifier >>>> ? - @Anno as a type annotation >>>> ? - @Anno as a declaration annotation >>>> >>>> the last one should be removed because the annotation has not FIELD >>>> as target but it was applied as a declaration annotation because >>>> the field was being treated both as a field and as a record >>>> component. Once we reach the point when the corresponding >>>> annotations have been copied to the record component, the field >>>> doesn't need to hold annotations that are not intended for it >>>> anymore. Still @Anno has to be kept in the AST's modifiers as it is >>>> applicable as a type annotation to the type of the field. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>>> >> From mikael.vidstedt at oracle.com Tue Jan 21 23:58:15 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 21 Jan 2020 15:58:15 -0800 Subject: RFR(XS): 8237601: test/langtools/tools/javac/warnings/MaxDiagsRecompile.java fails after JDK-8237589 Message-ID: <0204BC2F-AAEB-4EEC-B174-92F7970FB331@oracle.com> Please review this small change which fixes the ?golden? files used by the MaxDiagsRecompile test. JDK-8237589 updated the file header, shifting all the line numbers by 4. JBS: https://bugs.openjdk.java.net/browse/JDK-8237601 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.00/open/webrev/ Cheers, Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Wed Jan 22 00:47:21 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 21 Jan 2020 16:47:21 -0800 Subject: RFR(XS): 8237601: test/langtools/tools/javac/warnings/MaxDiagsRecompile.java fails after JDK-8237589 In-Reply-To: <0204BC2F-AAEB-4EEC-B174-92F7970FB331@oracle.com> References: <0204BC2F-AAEB-4EEC-B174-92F7970FB331@oracle.com> Message-ID: tools/javac/warnings/MaxWarnsRecompile.java needs the same kind of fix. New webrev: full: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.01/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.01.incr/open/webrev/ Cheers, Mikael > On Jan 21, 2020, at 3:58 PM, Mikael Vidstedt wrote: > > > Please review this small change which fixes the ?golden? files used by the MaxDiagsRecompile test. JDK-8237589 updated the file header, shifting all the line numbers by 4. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8237601 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.00/open/webrev/ > > Cheers, > Mikael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jan 22 01:34:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2020 11:34:24 +1000 Subject: RFR(XS): 8237601: test/langtools/tools/javac/warnings/MaxDiagsRecompile.java fails after JDK-8237589 In-Reply-To: References: Message-ID: Looks good to me - and trivial. Thanks, David >> On Jan 21, 2020, at 3:58 PM, Mikael Vidstedt wrote: > tools/javac/warnings/MaxWarnsRecompile.java needs the same kind of fix. New webrev: > > full: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.01/open/webrev/ > incremental: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.01.incr/open/webrev/ > > Cheers, > Mikael > >> On Jan 21, 2020, at 3:58 PM, Mikael Vidstedt wrote: >> >> >> Please review this small change which fixes the ?golden? files used by the MaxDiagsRecompile test. JDK-8237589 updated the file header, shifting all the line numbers by 4. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8237601 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.00/open/webrev/ >> >> Cheers, >> Mikael >> From mikael.vidstedt at oracle.com Wed Jan 22 01:41:46 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 21 Jan 2020 17:41:46 -0800 Subject: RFR(XS): 8237601: test/langtools/tools/javac/warnings/MaxDiagsRecompile.java fails after JDK-8237589 In-Reply-To: References: Message-ID: Thanks David. Change pushed. Cheers, Mikael > On Jan 21, 2020, at 5:34 PM, David Holmes wrote: > > Looks good to me - and trivial. > > Thanks, > David > > >> On Jan 21, 2020, at 3:58 PM, Mikael Vidstedt wrote: >> tools/javac/warnings/MaxWarnsRecompile.java needs the same kind of fix. New webrev: >> full: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.01/open/webrev/ >> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.01.incr/open/webrev/ >> Cheers, >> Mikael >>> On Jan 21, 2020, at 3:58 PM, Mikael Vidstedt wrote: >>> Please review this small change which fixes the ?golden? files used by the MaxDiagsRecompile test. JDK-8237589 updated the file header, shifting all the line numbers by 4. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237601 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8237601/webrev.00/open/webrev/ >>> Cheers, >>> Mikael From adam.sotona at oracle.com Wed Jan 22 09:54:10 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 22 Jan 2020 10:54:10 +0100 Subject: RFR: JDK-8042742 possible error in Tokens.Token.checkKind() for javac Message-ID: <73E343F1-E24C-41CA-97E8-3D26D2DE0E4C@oracle.com> Hi, I would like to fix small typo in Tokens (see the patch below). JBS: https://bugs.openjdk.java.net/browse/JDK-8042742 > diff -r 9c53fdf6ba63 src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Wed Jan 15 08:44:53 2020 +0100 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Wed Jan 15 15:26:25 2020 +0100 > @@ -357,7 +357,7 @@ > > protected void checkKind() { > if (kind.tag != Tag.DEFAULT) { > - throw new AssertionError("Bad token kind - expected " + Tag.STRING); > + throw new AssertionError("Bad token kind - expected " + Tag.DEFAULT); > } > } > Please let me know if this is OK. Thank you, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jan 22 16:25:08 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 22 Jan 2020 08:25:08 -0800 Subject: FYI, JSR 269 maintenance review for changes in Java SE 14 Message-ID: <377a9e3f-18cd-3144-3859-9d22d9dc705a@oracle.com> See https://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index8.html for details. -Joe From jan.lahoda at oracle.com Thu Jan 23 12:23:59 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 23 Jan 2020 13:23:59 +0100 Subject: RFR: JDK-8042742 possible error in Tokens.Token.checkKind() for javac In-Reply-To: <73E343F1-E24C-41CA-97E8-3D26D2DE0E4C@oracle.com> References: <73E343F1-E24C-41CA-97E8-3D26D2DE0E4C@oracle.com> Message-ID: Looks sensible to me. I can sponsor this patch. Thanks, Jan On 22. 01. 20 10:54, Adam Sotona wrote: > Hi, > I would like to fix small typo in Tokens (see the patch below). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8042742 > >> diff -r 9c53fdf6ba63 src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Wed Jan 15 08:44:53 2020 +0100 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Wed Jan 15 15:26:25 2020 +0100 >> @@ -357,7 +357,7 @@ >> >> protected void checkKind() { >> if (kind.tag != Tag.DEFAULT) { >> - throw new AssertionError("Bad token kind - expected " + Tag.STRING); >> + throw new AssertionError("Bad token kind - expected " + Tag.DEFAULT); >> } >> } >> > > Please let me know if this is OK. > > Thank you, > Adam From neshkeev at yandex.ru Thu Jan 23 13:59:23 2020 From: neshkeev at yandex.ru (Nikita Eshkeev) Date: Thu, 23 Jan 2020 16:59:23 +0300 Subject: False positive compilation of a method reference with type parameters In-Reply-To: <8151711579367797@iva8-5e86d95f65ab.qloud-c.yandex.net> Message-ID: <5489101579787963@vla1-3991b5027d7d.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From neshkeev at yandex.ru Thu Jan 23 14:00:25 2020 From: neshkeev at yandex.ru (Nikita Eshkeev) Date: Thu, 23 Jan 2020 17:00:25 +0300 Subject: [PATCH] Re: False positive compilation of a method reference with type parameters In-Reply-To: <7866091579367891@iva2-d0266d205f48.qloud-c.yandex.net> Message-ID: <5800981579788025@myt2-508c8f44300a.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Thu Jan 23 16:13:12 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Thu, 23 Jan 2020 17:13:12 +0100 Subject: RFR: JDK-8236997 tools/javac tests fail with --illegal-access=deny Message-ID: <7EE0A011-0A75-40F5-A1D5-6A3DD174E699@oracle.com> Hi, I would like to ask for review of tools/javac tests patch (attached) so the tests work correctly with --illegal-access=deny switch. JBS: https://bugs.openjdk.java.net/browse/JDK-8236997 Please let me know if this is OK or if there are any issues with the proposed patch. Thank you, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8236997.patch Type: application/octet-stream Size: 22824 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jan 23 17:10:36 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 23 Jan 2020 18:10:36 +0100 Subject: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof Message-ID: <3c16b477-1c54-82f3-448b-3067a1481c45@oracle.com> Hi, When javac compiles: o instanceof String s it desugars this to: (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String && (s = (String)s$temp) == (String)s$temp) The "(s = (String)s$temp) == (String)s$temp)" is there to set the variable "s" to the correct, and still return/have a boolean value. But this produces several unnecessary instructions for the comparison - second cast and unnecessary test/jump. This can be changed to: (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String && (let s = (String)s$temp; in true)) I.e. the (s = (String)s$temp) == (String)s$temp) is replaced with (let s = (String)s$temp; in true) This is a let expression that will execute the assignment as a statement and then return true without any tests. This eliminates the unnecessary cast and test/jump, producing a smaller code (see bytecode before and after below). Proposed patch: http://cr.openjdk.java.net/~jlahoda/8237528/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8237528 How does this look? Jan The bytecode for: if (o instanceof String s) { nop(s); } current state: 0: aload_0 1: astore_2 2: aload_2 3: instanceof #7 // class java/lang/String 6: ifeq 26 9: aload_2 10: checkcast #7 // class java/lang/String 13: dup 14: astore_1 15: aload_2 16: checkcast #7 // class java/lang/String 19: if_acmpne 26 22: aload_1 23: invokestatic #9 // Method nop:(Ljava/lang/String;)V 26: return after the proposed patch: 0: aload_0 1: astore_2 2: aload_2 3: instanceof #7 // class java/lang/String 6: ifeq 18 9: aload_2 10: checkcast #7 // class java/lang/String 13: astore_1 14: aload_1 15: invokestatic #9 // Method nop:(Ljava/lang/String;)V 18: return I.e. the instructions at original bytecode indexes 13, 15, 16 and 19 disappear. From forax at univ-mlv.fr Thu Jan 23 17:24:05 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 23 Jan 2020 18:24:05 +0100 (CET) Subject: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof In-Reply-To: <3c16b477-1c54-82f3-448b-3067a1481c45@oracle.com> References: <3c16b477-1c54-82f3-448b-3067a1481c45@oracle.com> Message-ID: <1967341931.477168.1579800245335.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "jan lahoda" > ?: "compiler-dev" > Envoy?: Jeudi 23 Janvier 2020 18:10:36 > Objet: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof > Hi, > > When javac compiles: > o instanceof String s > > it desugars this to: > > (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String > && (s = (String)s$temp) == (String)s$temp) > > The "(s = (String)s$temp) == (String)s$temp)" is there to set the > variable "s" to the correct, and still return/have a boolean value. But > this produces several unnecessary instructions for the comparison - > second cast and unnecessary test/jump. This can be changed to: > > (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String > && (let s = (String)s$temp; in true)) > > I.e. the (s = (String)s$temp) == (String)s$temp) is replaced with > > (let s = (String)s$temp; in true) > > This is a let expression that will execute the assignment as a statement > and then return true without any tests. This eliminates the unnecessary > cast and test/jump, producing a smaller code (see bytecode before and > after below). > Nice ! You can shave two more bytes (the first two instructions) by detecting that the left part of instanceof is already a local variable, so you don't need the first let. > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8237528/webrev.00/index.html > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8237528 > > How does this look? > R?mi > Jan From vicente.romero at oracle.com Thu Jan 23 17:57:09 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 23 Jan 2020 12:57:09 -0500 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> Message-ID: <10aeea45-4cd6-2973-043d-66983495c747@oracle.com> Hi Maurizio, after a deep research and having changed some of the basics of record's implementation, here is another iteration [1]. I have added a map to preserve the original annotations attached to record components in case we need to go back to the originals. This is necessary when there are APs in the middle as the new test made clear. Thanks for your comments and to Jan for offline suggestions, Vicente [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.01/ On 1/17/20 7:54 AM, Maurizio Cimadamore wrote: > > On 17/01/2020 12:53, Vicente Romero wrote: >> Hi Maurizio, >> >> Thanks for the review, some comments below >> >> On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >>> Tricky indeed. Few suggestions: >>> >>> * It seems like SymbolMetadata::remove has morphed more into a >>> removeDeclarationMetadata (since you no longer remove type annos >>> from there) >> >> true >> >>> >>> * Another way to simplify the code and avoid the 'ignoreTypeUse' >>> trick, would be for "annotationApplicable" to give you the list of >>> all the applicable targets, rather than just a boolean. Then, from >>> there, I think you can implement the rest of your logic w/o the need >>> of rechecking for applicability multiple times. >> >> right that could work, will give it a try >> >>> >>> * The test seems good, but it only checks for one side of the story: >>> classfile generation; should we also test that the annotations are >>> indeed available to processors? >> >> we have already tests for that but they live in another neighborhood, >> see: >> >> test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java >> >> test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java >> >> >> we can eventually move them to RecordCompilationTests in a separate >> effort > > Ok - but do they check all the combinations that you gave recently > added to the other test? Do they need to be made more powerful? > > Maurizio > >> >>> >>> Cheers >>> Maurizio >> >> Vicente >>> >>> On 16/01/2020 21:24, Vicente Romero wrote: >>>> Please review the fix for [1] at [2]. Some background: >>>> >>>> Annotations applied to record components are propagated to the >>>> corresponding record member so if an annotation has target: FIELD, >>>> it is propagated to the corresponding FIELD, if it has target >>>> METHOD, it is propagated to the accessor and so on. But at the >>>> moment when method members are generated there is no enough >>>> information to propagate only the right annotations. So all the >>>> annotations are propagated to all the possible locations. >>>> >>>> So there is a point when we need to remove all the annotations that >>>> are not in place before going on with the annotation party. On top >>>> of the above there is the issue that there is no AST representing >>>> record components, just symbols so the corresponding field has been >>>> holding all the annotations and it's metadata has been modified as >>>> if it was both a field and a record component. >>>> >>>> So there are two places where we need to trim annotations from: the >>>> metadata of the symbol and / or the modifiers in the AST. Whatever >>>> is in the metadata will be written to the class file, whatever is >>>> in the modifiers could be see by annotation processors. >>>> >>>> The metadata contains both type annotations and declaration >>>> annotations. Type annotations are all in the right place as they >>>> are applicable to all the types of the corresponding record members >>>> generated by the compiler. But we could need to remove declaration >>>> annotations. So for declaration annotations if they are not >>>> applicable to the given record member it will be needed to remove >>>> them. For the AST modifiers if the annotation is not applicable >>>> either as type annotation and or declaration annotation, only in >>>> the last case it will be removed. >>>> >>>> So it could be that an annotation is removed as a declaration >>>> annotation but it is kept in the AST modifier for further >>>> inspection by annotation processors. >>>> >>>> For example: >>>> >>>> ??? import java.lang.annotation.*; >>>> >>>> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >>>> ??? @Retention(RetentionPolicy.RUNTIME) >>>> ??? @interface Anno { } >>>> >>>> ??? record R(@Anno String s) {} >>>> >>>> just before Enter ends we will have for the case of the generated >>>> field: >>>> ? - @Anno in the modifier >>>> ? - @Anno as a type annotation >>>> ? - @Anno as a declaration annotation >>>> >>>> the last one should be removed because the annotation has not FIELD >>>> as target but it was applied as a declaration annotation because >>>> the field was being treated both as a field and as a record >>>> component. Once we reach the point when the corresponding >>>> annotations have been copied to the record component, the field >>>> doesn't need to hold annotations that are not intended for it >>>> anymore. Still @Anno has to be kept in the AST's modifiers as it is >>>> applicable as a type annotation to the type of the field. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>>> >> From maurizio.cimadamore at oracle.com Thu Jan 23 18:20:38 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Jan 2020 18:20:38 +0000 Subject: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof In-Reply-To: <3c16b477-1c54-82f3-448b-3067a1481c45@oracle.com> References: <3c16b477-1c54-82f3-448b-3067a1481c45@oracle.com> Message-ID: <24111a12-b537-bb49-f6ef-a9e3ff483596@oracle.com> Looks good to me Maurizio On 23/01/2020 17:10, Jan Lahoda wrote: > Hi, > > When javac compiles: > o instanceof String s > > it desugars this to: > > (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String > && (s = (String)s$temp) == (String)s$temp) > > The "(s = (String)s$temp) == (String)s$temp)" is there to set the > variable "s" to the correct, and still return/have a boolean value. > But this produces several unnecessary instructions for the comparison > - second cast and unnecessary test/jump. This can be changed to: > > (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String > && (let s = (String)s$temp; in true)) > > I.e. the (s = (String)s$temp) == (String)s$temp) is replaced with > > (let s = (String)s$temp; in true) > > This is a let expression that will execute the assignment as a > statement and then return true without any tests. This eliminates the > unnecessary cast and test/jump, producing a smaller code (see bytecode > before and after below). > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8237528/webrev.00/index.html > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8237528 > > How does this look? > > Jan > > The bytecode for: > ??????? if (o instanceof String s) { > ??????????? nop(s); > ??????? } > > current state: > ???????? 0: aload_0 > ???????? 1: astore_2 > ???????? 2: aload_2 > ???????? 3: instanceof??? #7????????????????? // class java/lang/String > ???????? 6: ifeq????????? 26 > ???????? 9: aload_2 > ??????? 10: checkcast???? #7????????????????? // class java/lang/String > ??????? 13: dup > ??????? 14: astore_1 > ??????? 15: aload_2 > ??????? 16: checkcast???? #7????????????????? // class java/lang/String > ??????? 19: if_acmpne???? 26 > ??????? 22: aload_1 > ??????? 23: invokestatic? #9????????????????? // Method > nop:(Ljava/lang/String;)V > ??????? 26: return > > > after the proposed patch: > ???????? 0: aload_0 > ???????? 1: astore_2 > ???????? 2: aload_2 > ???????? 3: instanceof??? #7????????????????? // class java/lang/String > ???????? 6: ifeq????????? 18 > ???????? 9: aload_2 > ??????? 10: checkcast???? #7????????????????? // class java/lang/String > ??????? 13: astore_1 > ??????? 14: aload_1 > ??????? 15: invokestatic? #9????????????????? // Method > nop:(Ljava/lang/String;)V > ??????? 18: return > > I.e. the instructions at original bytecode indexes 13, 15, 16 and 19 > disappear. From maurizio.cimadamore at oracle.com Thu Jan 23 18:30:57 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Jan 2020 18:30:57 +0000 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: <10aeea45-4cd6-2973-043d-66983495c747@oracle.com> References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> <10aeea45-4cd6-2973-043d-66983495c747@oracle.com> Message-ID: Some comments: * we can't create a new HashMap per symbol - at the very least the map should be lazy or we will most surely add a lot of footprint * names such as getRCOriginalAnnos seems odd * also... if the goal of the map is to keep track of the original annotations applied to a component... why not storing the original annotations directly in RecordComponent (and get rid of the map) ? * Check - I suggest retaining "annotationApplicable" as a predicate which calls "getApplicableTargets" and test if result isEmpty() - this way you won't need to tweak other clients * I don't like the recovery target much - better to have getApplicableTargets return an Optional> - so that the code has to decide how to handle recovery Maurizio On 23/01/2020 17:57, Vicente Romero wrote: > Hi Maurizio, > > after a deep research and having changed some of the basics of > record's implementation, here is another iteration [1]. I have added a > map to preserve the original annotations attached to record components > in case we need to go back to the originals. This is necessary when > there are APs in the middle as the new test made clear. > > Thanks for your comments and to Jan for offline suggestions, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.01/ > > On 1/17/20 7:54 AM, Maurizio Cimadamore wrote: >> >> On 17/01/2020 12:53, Vicente Romero wrote: >>> Hi Maurizio, >>> >>> Thanks for the review, some comments below >>> >>> On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >>>> Tricky indeed. Few suggestions: >>>> >>>> * It seems like SymbolMetadata::remove has morphed more into a >>>> removeDeclarationMetadata (since you no longer remove type annos >>>> from there) >>> >>> true >>> >>>> >>>> * Another way to simplify the code and avoid the 'ignoreTypeUse' >>>> trick, would be for "annotationApplicable" to give you the list of >>>> all the applicable targets, rather than just a boolean. Then, from >>>> there, I think you can implement the rest of your logic w/o the >>>> need of rechecking for applicability multiple times. >>> >>> right that could work, will give it a try >>> >>>> >>>> * The test seems good, but it only checks for one side of the >>>> story: classfile generation; should we also test that the >>>> annotations are indeed available to processors? >>> >>> we have already tests for that but they live in another >>> neighborhood, see: >>> >>> test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java >>> >>> test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java >>> >>> >>> we can eventually move them to RecordCompilationTests in a separate >>> effort >> >> Ok - but do they check all the combinations that you gave recently >> added to the other test? Do they need to be made more powerful? >> >> Maurizio >> >>> >>>> >>>> Cheers >>>> Maurizio >>> >>> Vicente >>>> >>>> On 16/01/2020 21:24, Vicente Romero wrote: >>>>> Please review the fix for [1] at [2]. Some background: >>>>> >>>>> Annotations applied to record components are propagated to the >>>>> corresponding record member so if an annotation has target: FIELD, >>>>> it is propagated to the corresponding FIELD, if it has target >>>>> METHOD, it is propagated to the accessor and so on. But at the >>>>> moment when method members are generated there is no enough >>>>> information to propagate only the right annotations. So all the >>>>> annotations are propagated to all the possible locations. >>>>> >>>>> So there is a point when we need to remove all the annotations >>>>> that are not in place before going on with the annotation party. >>>>> On top of the above there is the issue that there is no AST >>>>> representing record components, just symbols so the corresponding >>>>> field has been holding all the annotations and it's metadata has >>>>> been modified as if it was both a field and a record component. >>>>> >>>>> So there are two places where we need to trim annotations from: >>>>> the metadata of the symbol and / or the modifiers in the AST. >>>>> Whatever is in the metadata will be written to the class file, >>>>> whatever is in the modifiers could be see by annotation processors. >>>>> >>>>> The metadata contains both type annotations and declaration >>>>> annotations. Type annotations are all in the right place as they >>>>> are applicable to all the types of the corresponding record >>>>> members generated by the compiler. But we could need to remove >>>>> declaration annotations. So for declaration annotations if they >>>>> are not applicable to the given record member it will be needed to >>>>> remove them. For the AST modifiers if the annotation is not >>>>> applicable either as type annotation and or declaration >>>>> annotation, only in the last case it will be removed. >>>>> >>>>> So it could be that an annotation is removed as a declaration >>>>> annotation but it is kept in the AST modifier for further >>>>> inspection by annotation processors. >>>>> >>>>> For example: >>>>> >>>>> ??? import java.lang.annotation.*; >>>>> >>>>> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >>>>> ??? @Retention(RetentionPolicy.RUNTIME) >>>>> ??? @interface Anno { } >>>>> >>>>> ??? record R(@Anno String s) {} >>>>> >>>>> just before Enter ends we will have for the case of the generated >>>>> field: >>>>> ? - @Anno in the modifier >>>>> ? - @Anno as a type annotation >>>>> ? - @Anno as a declaration annotation >>>>> >>>>> the last one should be removed because the annotation has not >>>>> FIELD as target but it was applied as a declaration annotation >>>>> because the field was being treated both as a field and as a >>>>> record component. Once we reach the point when the corresponding >>>>> annotations have been copied to the record component, the field >>>>> doesn't need to hold annotations that are not intended for it >>>>> anymore. Still @Anno has to be kept in the AST's modifiers as it >>>>> is applicable as a type annotation to the type of the field. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>>>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>>>> >>> > From vicente.romero at oracle.com Thu Jan 23 20:58:25 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 23 Jan 2020 15:58:25 -0500 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> <10aeea45-4cd6-2973-043d-66983495c747@oracle.com> Message-ID: Hi Maurizio, Thanks for your comments, I have uploaded another iteration at [1] Vicente [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.02/ On 1/23/20 1:30 PM, Maurizio Cimadamore wrote: > Some comments: > > * we can't create a new HashMap per symbol - at the very least the map > should be lazy or we will most surely add a lot of footprint > > * names such as getRCOriginalAnnos seems odd > > * also... if the goal of the map is to keep track of the original > annotations applied to a component... why not storing the original > annotations directly in RecordComponent (and get rid of the map) ? > > * Check - I suggest retaining "annotationApplicable" as a predicate > which calls "getApplicableTargets" and test if result isEmpty() - this > way you won't need to tweak other clients > > * I don't like the recovery target much - better to have > getApplicableTargets return an Optional> - so that the code > has to decide how to handle recovery > > Maurizio > > > On 23/01/2020 17:57, Vicente Romero wrote: >> Hi Maurizio, >> >> after a deep research and having changed some of the basics of >> record's implementation, here is another iteration [1]. I have added >> a map to preserve the original annotations attached to record >> components in case we need to go back to the originals. This is >> necessary when there are APs in the middle as the new test made clear. >> >> Thanks for your comments and to Jan for offline suggestions, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.01/ >> >> On 1/17/20 7:54 AM, Maurizio Cimadamore wrote: >>> >>> On 17/01/2020 12:53, Vicente Romero wrote: >>>> Hi Maurizio, >>>> >>>> Thanks for the review, some comments below >>>> >>>> On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >>>>> Tricky indeed. Few suggestions: >>>>> >>>>> * It seems like SymbolMetadata::remove has morphed more into a >>>>> removeDeclarationMetadata (since you no longer remove type annos >>>>> from there) >>>> >>>> true >>>> >>>>> >>>>> * Another way to simplify the code and avoid the 'ignoreTypeUse' >>>>> trick, would be for "annotationApplicable" to give you the list of >>>>> all the applicable targets, rather than just a boolean. Then, from >>>>> there, I think you can implement the rest of your logic w/o the >>>>> need of rechecking for applicability multiple times. >>>> >>>> right that could work, will give it a try >>>> >>>>> >>>>> * The test seems good, but it only checks for one side of the >>>>> story: classfile generation; should we also test that the >>>>> annotations are indeed available to processors? >>>> >>>> we have already tests for that but they live in another >>>> neighborhood, see: >>>> >>>> test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java >>>> >>>> test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java >>>> >>>> >>>> we can eventually move them to RecordCompilationTests in a separate >>>> effort >>> >>> Ok - but do they check all the combinations that you gave recently >>> added to the other test? Do they need to be made more powerful? >>> >>> Maurizio >>> >>>> >>>>> >>>>> Cheers >>>>> Maurizio >>>> >>>> Vicente >>>>> >>>>> On 16/01/2020 21:24, Vicente Romero wrote: >>>>>> Please review the fix for [1] at [2]. Some background: >>>>>> >>>>>> Annotations applied to record components are propagated to the >>>>>> corresponding record member so if an annotation has target: >>>>>> FIELD, it is propagated to the corresponding FIELD, if it has >>>>>> target METHOD, it is propagated to the accessor and so on. But at >>>>>> the moment when method members are generated there is no enough >>>>>> information to propagate only the right annotations. So all the >>>>>> annotations are propagated to all the possible locations. >>>>>> >>>>>> So there is a point when we need to remove all the annotations >>>>>> that are not in place before going on with the annotation party. >>>>>> On top of the above there is the issue that there is no AST >>>>>> representing record components, just symbols so the corresponding >>>>>> field has been holding all the annotations and it's metadata has >>>>>> been modified as if it was both a field and a record component. >>>>>> >>>>>> So there are two places where we need to trim annotations from: >>>>>> the metadata of the symbol and / or the modifiers in the AST. >>>>>> Whatever is in the metadata will be written to the class file, >>>>>> whatever is in the modifiers could be see by annotation processors. >>>>>> >>>>>> The metadata contains both type annotations and declaration >>>>>> annotations. Type annotations are all in the right place as they >>>>>> are applicable to all the types of the corresponding record >>>>>> members generated by the compiler. But we could need to remove >>>>>> declaration annotations. So for declaration annotations if they >>>>>> are not applicable to the given record member it will be needed >>>>>> to remove them. For the AST modifiers if the annotation is not >>>>>> applicable either as type annotation and or declaration >>>>>> annotation, only in the last case it will be removed. >>>>>> >>>>>> So it could be that an annotation is removed as a declaration >>>>>> annotation but it is kept in the AST modifier for further >>>>>> inspection by annotation processors. >>>>>> >>>>>> For example: >>>>>> >>>>>> ??? import java.lang.annotation.*; >>>>>> >>>>>> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >>>>>> ??? @Retention(RetentionPolicy.RUNTIME) >>>>>> ??? @interface Anno { } >>>>>> >>>>>> ??? record R(@Anno String s) {} >>>>>> >>>>>> just before Enter ends we will have for the case of the generated >>>>>> field: >>>>>> ? - @Anno in the modifier >>>>>> ? - @Anno as a type annotation >>>>>> ? - @Anno as a declaration annotation >>>>>> >>>>>> the last one should be removed because the annotation has not >>>>>> FIELD as target but it was applied as a declaration annotation >>>>>> because the field was being treated both as a field and as a >>>>>> record component. Once we reach the point when the corresponding >>>>>> annotations have been copied to the record component, the field >>>>>> doesn't need to hold annotations that are not intended for it >>>>>> anymore. Still @Anno has to be kept in the AST's modifiers as it >>>>>> is applicable as a type annotation to the type of the field. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>>>>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>>>>> >>>> >> From maurizio.cimadamore at oracle.com Thu Jan 23 21:29:07 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Jan 2020 21:29:07 +0000 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> <10aeea45-4cd6-2973-043d-66983495c747@oracle.com> Message-ID: <517beb37-8c86-06f1-4426-bb2a9fef556e@oracle.com> Looks good. Minor tweak - seems like if RecordComponent constructor took a VarSymbol you should be able to set all fields (including original annotations) in a single shot and make the original annotation field immutable? Maurizio On 23/01/2020 20:58, Vicente Romero wrote: > Hi Maurizio, > > Thanks for your comments, I have uploaded another iteration at [1] > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.02/ > > On 1/23/20 1:30 PM, Maurizio Cimadamore wrote: >> Some comments: >> >> * we can't create a new HashMap per symbol - at the very least the >> map should be lazy or we will most surely add a lot of footprint >> >> * names such as getRCOriginalAnnos seems odd >> >> * also... if the goal of the map is to keep track of the original >> annotations applied to a component... why not storing the original >> annotations directly in RecordComponent (and get rid of the map) ? >> >> * Check - I suggest retaining "annotationApplicable" as a predicate >> which calls "getApplicableTargets" and test if result isEmpty() - >> this way you won't need to tweak other clients >> >> * I don't like the recovery target much - better to have >> getApplicableTargets return an Optional> - so that the code >> has to decide how to handle recovery >> >> Maurizio >> >> >> On 23/01/2020 17:57, Vicente Romero wrote: >>> Hi Maurizio, >>> >>> after a deep research and having changed some of the basics of >>> record's implementation, here is another iteration [1]. I have added >>> a map to preserve the original annotations attached to record >>> components in case we need to go back to the originals. This is >>> necessary when there are APs in the middle as the new test made clear. >>> >>> Thanks for your comments and to Jan for offline suggestions, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.01/ >>> >>> On 1/17/20 7:54 AM, Maurizio Cimadamore wrote: >>>> >>>> On 17/01/2020 12:53, Vicente Romero wrote: >>>>> Hi Maurizio, >>>>> >>>>> Thanks for the review, some comments below >>>>> >>>>> On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >>>>>> Tricky indeed. Few suggestions: >>>>>> >>>>>> * It seems like SymbolMetadata::remove has morphed more into a >>>>>> removeDeclarationMetadata (since you no longer remove type annos >>>>>> from there) >>>>> >>>>> true >>>>> >>>>>> >>>>>> * Another way to simplify the code and avoid the 'ignoreTypeUse' >>>>>> trick, would be for "annotationApplicable" to give you the list >>>>>> of all the applicable targets, rather than just a boolean. Then, >>>>>> from there, I think you can implement the rest of your logic w/o >>>>>> the need of rechecking for applicability multiple times. >>>>> >>>>> right that could work, will give it a try >>>>> >>>>>> >>>>>> * The test seems good, but it only checks for one side of the >>>>>> story: classfile generation; should we also test that the >>>>>> annotations are indeed available to processors? >>>>> >>>>> we have already tests for that but they live in another >>>>> neighborhood, see: >>>>> >>>>> test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java >>>>> >>>>> test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java >>>>> >>>>> >>>>> we can eventually move them to RecordCompilationTests in a >>>>> separate effort >>>> >>>> Ok - but do they check all the combinations that you gave recently >>>> added to the other test? Do they need to be made more powerful? >>>> >>>> Maurizio >>>> >>>>> >>>>>> >>>>>> Cheers >>>>>> Maurizio >>>>> >>>>> Vicente >>>>>> >>>>>> On 16/01/2020 21:24, Vicente Romero wrote: >>>>>>> Please review the fix for [1] at [2]. Some background: >>>>>>> >>>>>>> Annotations applied to record components are propagated to the >>>>>>> corresponding record member so if an annotation has target: >>>>>>> FIELD, it is propagated to the corresponding FIELD, if it has >>>>>>> target METHOD, it is propagated to the accessor and so on. But >>>>>>> at the moment when method members are generated there is no >>>>>>> enough information to propagate only the right annotations. So >>>>>>> all the annotations are propagated to all the possible locations. >>>>>>> >>>>>>> So there is a point when we need to remove all the annotations >>>>>>> that are not in place before going on with the annotation party. >>>>>>> On top of the above there is the issue that there is no AST >>>>>>> representing record components, just symbols so the >>>>>>> corresponding field has been holding all the annotations and >>>>>>> it's metadata has been modified as if it was both a field and a >>>>>>> record component. >>>>>>> >>>>>>> So there are two places where we need to trim annotations from: >>>>>>> the metadata of the symbol and / or the modifiers in the AST. >>>>>>> Whatever is in the metadata will be written to the class file, >>>>>>> whatever is in the modifiers could be see by annotation processors. >>>>>>> >>>>>>> The metadata contains both type annotations and declaration >>>>>>> annotations. Type annotations are all in the right place as they >>>>>>> are applicable to all the types of the corresponding record >>>>>>> members generated by the compiler. But we could need to remove >>>>>>> declaration annotations. So for declaration annotations if they >>>>>>> are not applicable to the given record member it will be needed >>>>>>> to remove them. For the AST modifiers if the annotation is not >>>>>>> applicable either as type annotation and or declaration >>>>>>> annotation, only in the last case it will be removed. >>>>>>> >>>>>>> So it could be that an annotation is removed as a declaration >>>>>>> annotation but it is kept in the AST modifier for further >>>>>>> inspection by annotation processors. >>>>>>> >>>>>>> For example: >>>>>>> >>>>>>> ??? import java.lang.annotation.*; >>>>>>> >>>>>>> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >>>>>>> ??? @Retention(RetentionPolicy.RUNTIME) >>>>>>> ??? @interface Anno { } >>>>>>> >>>>>>> ??? record R(@Anno String s) {} >>>>>>> >>>>>>> just before Enter ends we will have for the case of the >>>>>>> generated field: >>>>>>> ? - @Anno in the modifier >>>>>>> ? - @Anno as a type annotation >>>>>>> ? - @Anno as a declaration annotation >>>>>>> >>>>>>> the last one should be removed because the annotation has not >>>>>>> FIELD as target but it was applied as a declaration annotation >>>>>>> because the field was being treated both as a field and as a >>>>>>> record component. Once we reach the point when the corresponding >>>>>>> annotations have been copied to the record component, the field >>>>>>> doesn't need to hold annotations that are not intended for it >>>>>>> anymore. Still @Anno has to be kept in the AST's modifiers as it >>>>>>> is applicable as a type annotation to the type of the field. >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>>>>>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>>>>>> >>>>> >>> > From vicente.romero at oracle.com Thu Jan 23 21:39:55 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 23 Jan 2020 16:39:55 -0500 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: <517beb37-8c86-06f1-4426-bb2a9fef556e@oracle.com> References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> <10aeea45-4cd6-2973-043d-66983495c747@oracle.com> <517beb37-8c86-06f1-4426-bb2a9fef556e@oracle.com> Message-ID: <7977a1e1-a8cd-d7b9-24b6-fd4dc7133fa4@oracle.com> On 1/23/20 4:29 PM, Maurizio Cimadamore wrote: > Looks good. > > Minor tweak - seems like if RecordComponent constructor took a > VarSymbol you should be able to set all fields (including original > annotations) in a single shot and make the original annotation field > immutable? right I can do that before pushing, only that it won't be only a VarSymbol as it doesn't have a link to the annotations which are in the AST > > Maurizio Vicente > > On 23/01/2020 20:58, Vicente Romero wrote: >> Hi Maurizio, >> >> Thanks for your comments, I have uploaded another iteration at [1] >> >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.02/ >> >> On 1/23/20 1:30 PM, Maurizio Cimadamore wrote: >>> Some comments: >>> >>> * we can't create a new HashMap per symbol - at the very least the >>> map should be lazy or we will most surely add a lot of footprint >>> >>> * names such as getRCOriginalAnnos seems odd >>> >>> * also... if the goal of the map is to keep track of the original >>> annotations applied to a component... why not storing the original >>> annotations directly in RecordComponent (and get rid of the map) ? >>> >>> * Check - I suggest retaining "annotationApplicable" as a predicate >>> which calls "getApplicableTargets" and test if result isEmpty() - >>> this way you won't need to tweak other clients >>> >>> * I don't like the recovery target much - better to have >>> getApplicableTargets return an Optional> - so that the >>> code has to decide how to handle recovery >>> >>> Maurizio >>> >>> >>> On 23/01/2020 17:57, Vicente Romero wrote: >>>> Hi Maurizio, >>>> >>>> after a deep research and having changed some of the basics of >>>> record's implementation, here is another iteration [1]. I have >>>> added a map to preserve the original annotations attached to record >>>> components in case we need to go back to the originals. This is >>>> necessary when there are APs in the middle as the new test made clear. >>>> >>>> Thanks for your comments and to Jan for offline suggestions, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.01/ >>>> >>>> On 1/17/20 7:54 AM, Maurizio Cimadamore wrote: >>>>> >>>>> On 17/01/2020 12:53, Vicente Romero wrote: >>>>>> Hi Maurizio, >>>>>> >>>>>> Thanks for the review, some comments below >>>>>> >>>>>> On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >>>>>>> Tricky indeed. Few suggestions: >>>>>>> >>>>>>> * It seems like SymbolMetadata::remove has morphed more into a >>>>>>> removeDeclarationMetadata (since you no longer remove type annos >>>>>>> from there) >>>>>> >>>>>> true >>>>>> >>>>>>> >>>>>>> * Another way to simplify the code and avoid the 'ignoreTypeUse' >>>>>>> trick, would be for "annotationApplicable" to give you the list >>>>>>> of all the applicable targets, rather than just a boolean. Then, >>>>>>> from there, I think you can implement the rest of your logic w/o >>>>>>> the need of rechecking for applicability multiple times. >>>>>> >>>>>> right that could work, will give it a try >>>>>> >>>>>>> >>>>>>> * The test seems good, but it only checks for one side of the >>>>>>> story: classfile generation; should we also test that the >>>>>>> annotations are indeed available to processors? >>>>>> >>>>>> we have already tests for that but they live in another >>>>>> neighborhood, see: >>>>>> >>>>>> test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java >>>>>> >>>>>> test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java >>>>>> >>>>>> >>>>>> we can eventually move them to RecordCompilationTests in a >>>>>> separate effort >>>>> >>>>> Ok - but do they check all the combinations that you gave recently >>>>> added to the other test? Do they need to be made more powerful? >>>>> >>>>> Maurizio >>>>> >>>>>> >>>>>>> >>>>>>> Cheers >>>>>>> Maurizio >>>>>> >>>>>> Vicente >>>>>>> >>>>>>> On 16/01/2020 21:24, Vicente Romero wrote: >>>>>>>> Please review the fix for [1] at [2]. Some background: >>>>>>>> >>>>>>>> Annotations applied to record components are propagated to the >>>>>>>> corresponding record member so if an annotation has target: >>>>>>>> FIELD, it is propagated to the corresponding FIELD, if it has >>>>>>>> target METHOD, it is propagated to the accessor and so on. But >>>>>>>> at the moment when method members are generated there is no >>>>>>>> enough information to propagate only the right annotations. So >>>>>>>> all the annotations are propagated to all the possible locations. >>>>>>>> >>>>>>>> So there is a point when we need to remove all the annotations >>>>>>>> that are not in place before going on with the annotation >>>>>>>> party. On top of the above there is the issue that there is no >>>>>>>> AST representing record components, just symbols so the >>>>>>>> corresponding field has been holding all the annotations and >>>>>>>> it's metadata has been modified as if it was both a field and a >>>>>>>> record component. >>>>>>>> >>>>>>>> So there are two places where we need to trim annotations from: >>>>>>>> the metadata of the symbol and / or the modifiers in the AST. >>>>>>>> Whatever is in the metadata will be written to the class file, >>>>>>>> whatever is in the modifiers could be see by annotation >>>>>>>> processors. >>>>>>>> >>>>>>>> The metadata contains both type annotations and declaration >>>>>>>> annotations. Type annotations are all in the right place as >>>>>>>> they are applicable to all the types of the corresponding >>>>>>>> record members generated by the compiler. But we could need to >>>>>>>> remove declaration annotations. So for declaration annotations >>>>>>>> if they are not applicable to the given record member it will >>>>>>>> be needed to remove them. For the AST modifiers if the >>>>>>>> annotation is not applicable either as type annotation and or >>>>>>>> declaration annotation, only in the last case it will be removed. >>>>>>>> >>>>>>>> So it could be that an annotation is removed as a declaration >>>>>>>> annotation but it is kept in the AST modifier for further >>>>>>>> inspection by annotation processors. >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> ??? import java.lang.annotation.*; >>>>>>>> >>>>>>>> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >>>>>>>> ??? @Retention(RetentionPolicy.RUNTIME) >>>>>>>> ??? @interface Anno { } >>>>>>>> >>>>>>>> ??? record R(@Anno String s) {} >>>>>>>> >>>>>>>> just before Enter ends we will have for the case of the >>>>>>>> generated field: >>>>>>>> ? - @Anno in the modifier >>>>>>>> ? - @Anno as a type annotation >>>>>>>> ? - @Anno as a declaration annotation >>>>>>>> >>>>>>>> the last one should be removed because the annotation has not >>>>>>>> FIELD as target but it was applied as a declaration annotation >>>>>>>> because the field was being treated both as a field and as a >>>>>>>> record component. Once we reach the point when the >>>>>>>> corresponding annotations have been copied to the record >>>>>>>> component, the field doesn't need to hold annotations that are >>>>>>>> not intended for it anymore. Still @Anno has to be kept in the >>>>>>>> AST's modifiers as it is applicable as a type annotation to the >>>>>>>> type of the field. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vicente >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>>>>>>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>>>>>>> >>>>>> >>>> >> From maurizio.cimadamore at oracle.com Thu Jan 23 23:23:38 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Jan 2020 23:23:38 +0000 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: <7977a1e1-a8cd-d7b9-24b6-fd4dc7133fa4@oracle.com> References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> <10aeea45-4cd6-2973-043d-66983495c747@oracle.com> <517beb37-8c86-06f1-4426-bb2a9fef556e@oracle.com> <7977a1e1-a8cd-d7b9-24b6-fd4dc7133fa4@oracle.com> Message-ID: On 23/01/2020 21:39, Vicente Romero wrote: > > > On 1/23/20 4:29 PM, Maurizio Cimadamore wrote: >> Looks good. >> >> Minor tweak - seems like if RecordComponent constructor took a >> VarSymbol you should be able to set all fields (including original >> annotations) in a single shot and make the original annotation field >> immutable? > right I can do that before pushing, only that it won't be only a > VarSymbol as it doesn't have a link to the annotations which are in > the AST Sorry - I saw 'var' and I thought symbol - but you are right - it's the JCVariableDecl tree that you need to initialize those guys Maurizio >> >> Maurizio > > Vicente >> >> On 23/01/2020 20:58, Vicente Romero wrote: >>> Hi Maurizio, >>> >>> Thanks for your comments, I have uploaded another iteration at [1] >>> >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.02/ >>> >>> On 1/23/20 1:30 PM, Maurizio Cimadamore wrote: >>>> Some comments: >>>> >>>> * we can't create a new HashMap per symbol - at the very least the >>>> map should be lazy or we will most surely add a lot of footprint >>>> >>>> * names such as getRCOriginalAnnos seems odd >>>> >>>> * also... if the goal of the map is to keep track of the original >>>> annotations applied to a component... why not storing the original >>>> annotations directly in RecordComponent (and get rid of the map) ? >>>> >>>> * Check - I suggest retaining "annotationApplicable" as a predicate >>>> which calls "getApplicableTargets" and test if result isEmpty() - >>>> this way you won't need to tweak other clients >>>> >>>> * I don't like the recovery target much - better to have >>>> getApplicableTargets return an Optional> - so that the >>>> code has to decide how to handle recovery >>>> >>>> Maurizio >>>> >>>> >>>> On 23/01/2020 17:57, Vicente Romero wrote: >>>>> Hi Maurizio, >>>>> >>>>> after a deep research and having changed some of the basics of >>>>> record's implementation, here is another iteration [1]. I have >>>>> added a map to preserve the original annotations attached to >>>>> record components in case we need to go back to the originals. >>>>> This is necessary when there are APs in the middle as the new test >>>>> made clear. >>>>> >>>>> Thanks for your comments and to Jan for offline suggestions, >>>>> Vicente >>>>> >>>>> [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.01/ >>>>> >>>>> On 1/17/20 7:54 AM, Maurizio Cimadamore wrote: >>>>>> >>>>>> On 17/01/2020 12:53, Vicente Romero wrote: >>>>>>> Hi Maurizio, >>>>>>> >>>>>>> Thanks for the review, some comments below >>>>>>> >>>>>>> On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >>>>>>>> Tricky indeed. Few suggestions: >>>>>>>> >>>>>>>> * It seems like SymbolMetadata::remove has morphed more into a >>>>>>>> removeDeclarationMetadata (since you no longer remove type >>>>>>>> annos from there) >>>>>>> >>>>>>> true >>>>>>> >>>>>>>> >>>>>>>> * Another way to simplify the code and avoid the >>>>>>>> 'ignoreTypeUse' trick, would be for "annotationApplicable" to >>>>>>>> give you the list of all the applicable targets, rather than >>>>>>>> just a boolean. Then, from there, I think you can implement the >>>>>>>> rest of your logic w/o the need of rechecking for applicability >>>>>>>> multiple times. >>>>>>> >>>>>>> right that could work, will give it a try >>>>>>> >>>>>>>> >>>>>>>> * The test seems good, but it only checks for one side of the >>>>>>>> story: classfile generation; should we also test that the >>>>>>>> annotations are indeed available to processors? >>>>>>> >>>>>>> we have already tests for that but they live in another >>>>>>> neighborhood, see: >>>>>>> >>>>>>> test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java >>>>>>> >>>>>>> test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java >>>>>>> >>>>>>> >>>>>>> we can eventually move them to RecordCompilationTests in a >>>>>>> separate effort >>>>>> >>>>>> Ok - but do they check all the combinations that you gave >>>>>> recently added to the other test? Do they need to be made more >>>>>> powerful? >>>>>> >>>>>> Maurizio >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Cheers >>>>>>>> Maurizio >>>>>>> >>>>>>> Vicente >>>>>>>> >>>>>>>> On 16/01/2020 21:24, Vicente Romero wrote: >>>>>>>>> Please review the fix for [1] at [2]. Some background: >>>>>>>>> >>>>>>>>> Annotations applied to record components are propagated to the >>>>>>>>> corresponding record member so if an annotation has target: >>>>>>>>> FIELD, it is propagated to the corresponding FIELD, if it has >>>>>>>>> target METHOD, it is propagated to the accessor and so on. But >>>>>>>>> at the moment when method members are generated there is no >>>>>>>>> enough information to propagate only the right annotations. So >>>>>>>>> all the annotations are propagated to all the possible locations. >>>>>>>>> >>>>>>>>> So there is a point when we need to remove all the annotations >>>>>>>>> that are not in place before going on with the annotation >>>>>>>>> party. On top of the above there is the issue that there is no >>>>>>>>> AST representing record components, just symbols so the >>>>>>>>> corresponding field has been holding all the annotations and >>>>>>>>> it's metadata has been modified as if it was both a field and >>>>>>>>> a record component. >>>>>>>>> >>>>>>>>> So there are two places where we need to trim annotations >>>>>>>>> from: the metadata of the symbol and / or the modifiers in the >>>>>>>>> AST. Whatever is in the metadata will be written to the class >>>>>>>>> file, whatever is in the modifiers could be see by annotation >>>>>>>>> processors. >>>>>>>>> >>>>>>>>> The metadata contains both type annotations and declaration >>>>>>>>> annotations. Type annotations are all in the right place as >>>>>>>>> they are applicable to all the types of the corresponding >>>>>>>>> record members generated by the compiler. But we could need to >>>>>>>>> remove declaration annotations. So for declaration annotations >>>>>>>>> if they are not applicable to the given record member it will >>>>>>>>> be needed to remove them. For the AST modifiers if the >>>>>>>>> annotation is not applicable either as type annotation and or >>>>>>>>> declaration annotation, only in the last case it will be removed. >>>>>>>>> >>>>>>>>> So it could be that an annotation is removed as a declaration >>>>>>>>> annotation but it is kept in the AST modifier for further >>>>>>>>> inspection by annotation processors. >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> ??? import java.lang.annotation.*; >>>>>>>>> >>>>>>>>> ??? @Target({ElementType.TYPE_USE, ElementType.RECORD_COMPONENT}) >>>>>>>>> ??? @Retention(RetentionPolicy.RUNTIME) >>>>>>>>> ??? @interface Anno { } >>>>>>>>> >>>>>>>>> ??? record R(@Anno String s) {} >>>>>>>>> >>>>>>>>> just before Enter ends we will have for the case of the >>>>>>>>> generated field: >>>>>>>>> ? - @Anno in the modifier >>>>>>>>> ? - @Anno as a type annotation >>>>>>>>> ? - @Anno as a declaration annotation >>>>>>>>> >>>>>>>>> the last one should be removed because the annotation has not >>>>>>>>> FIELD as target but it was applied as a declaration annotation >>>>>>>>> because the field was being treated both as a field and as a >>>>>>>>> record component. Once we reach the point when the >>>>>>>>> corresponding annotations have been copied to the record >>>>>>>>> component, the field doesn't need to hold annotations that are >>>>>>>>> not intended for it anymore. Still @Anno has to be kept in the >>>>>>>>> AST's modifiers as it is applicable as a type annotation to >>>>>>>>> the type of the field. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vicente >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>>>>>>>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>>>>>>>> >>>>>>> >>>>> >>> > From vicente.romero at oracle.com Thu Jan 23 23:31:28 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 23 Jan 2020 18:31:28 -0500 Subject: RFR: JDK15-8236210: javac generates wrong annotation for fields generated from record components In-Reply-To: References: <1a1bb12a-5632-c177-95b8-ee9a65e57697@oracle.com> <13ed3e15-33b2-f444-952e-1cbdcdae0ee3@oracle.com> <10aeea45-4cd6-2973-043d-66983495c747@oracle.com> <517beb37-8c86-06f1-4426-bb2a9fef556e@oracle.com> <7977a1e1-a8cd-d7b9-24b6-fd4dc7133fa4@oracle.com> Message-ID: <5a0ce85a-f348-6fd8-bfcd-bba65e82c14e@oracle.com> On 1/23/20 6:23 PM, Maurizio Cimadamore wrote: > > On 23/01/2020 21:39, Vicente Romero wrote: >> >> >> On 1/23/20 4:29 PM, Maurizio Cimadamore wrote: >>> Looks good. >>> >>> Minor tweak - seems like if RecordComponent constructor took a >>> VarSymbol you should be able to set all fields (including original >>> annotations) in a single shot and make the original annotation field >>> immutable? >> right I can do that before pushing, only that it won't be only a >> VarSymbol as it doesn't have a link to the annotations which are in >> the AST > > Sorry - I saw 'var' and I thought symbol - but you are right - it's > the JCVariableDecl tree that you need to initialize those guys right > > Maurizio Vicente > >>> >>> Maurizio >> >> Vicente >>> >>> On 23/01/2020 20:58, Vicente Romero wrote: >>>> Hi Maurizio, >>>> >>>> Thanks for your comments, I have uploaded another iteration at [1] >>>> >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.02/ >>>> >>>> On 1/23/20 1:30 PM, Maurizio Cimadamore wrote: >>>>> Some comments: >>>>> >>>>> * we can't create a new HashMap per symbol - at the very least the >>>>> map should be lazy or we will most surely add a lot of footprint >>>>> >>>>> * names such as getRCOriginalAnnos seems odd >>>>> >>>>> * also... if the goal of the map is to keep track of the original >>>>> annotations applied to a component... why not storing the original >>>>> annotations directly in RecordComponent (and get rid of the map) ? >>>>> >>>>> * Check - I suggest retaining "annotationApplicable" as a >>>>> predicate which calls "getApplicableTargets" and test if result >>>>> isEmpty() - this way you won't need to tweak other clients >>>>> >>>>> * I don't like the recovery target much - better to have >>>>> getApplicableTargets return an Optional> - so that the >>>>> code has to decide how to handle recovery >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> On 23/01/2020 17:57, Vicente Romero wrote: >>>>>> Hi Maurizio, >>>>>> >>>>>> after a deep research and having changed some of the basics of >>>>>> record's implementation, here is another iteration [1]. I have >>>>>> added a map to preserve the original annotations attached to >>>>>> record components in case we need to go back to the originals. >>>>>> This is necessary when there are APs in the middle as the new >>>>>> test made clear. >>>>>> >>>>>> Thanks for your comments and to Jan for offline suggestions, >>>>>> Vicente >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~vromero/8236210/webrev.01/ >>>>>> >>>>>> On 1/17/20 7:54 AM, Maurizio Cimadamore wrote: >>>>>>> >>>>>>> On 17/01/2020 12:53, Vicente Romero wrote: >>>>>>>> Hi Maurizio, >>>>>>>> >>>>>>>> Thanks for the review, some comments below >>>>>>>> >>>>>>>> On 1/17/20 6:27 AM, Maurizio Cimadamore wrote: >>>>>>>>> Tricky indeed. Few suggestions: >>>>>>>>> >>>>>>>>> * It seems like SymbolMetadata::remove has morphed more into a >>>>>>>>> removeDeclarationMetadata (since you no longer remove type >>>>>>>>> annos from there) >>>>>>>> >>>>>>>> true >>>>>>>> >>>>>>>>> >>>>>>>>> * Another way to simplify the code and avoid the >>>>>>>>> 'ignoreTypeUse' trick, would be for "annotationApplicable" to >>>>>>>>> give you the list of all the applicable targets, rather than >>>>>>>>> just a boolean. Then, from there, I think you can implement >>>>>>>>> the rest of your logic w/o the need of rechecking for >>>>>>>>> applicability multiple times. >>>>>>>> >>>>>>>> right that could work, will give it a try >>>>>>>> >>>>>>>>> >>>>>>>>> * The test seems good, but it only checks for one side of the >>>>>>>>> story: classfile generation; should we also test that the >>>>>>>>> annotations are indeed available to processors? >>>>>>>> >>>>>>>> we have already tests for that but they live in another >>>>>>>> neighborhood, see: >>>>>>>> >>>>>>>> test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java >>>>>>>> >>>>>>>> test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java >>>>>>>> >>>>>>>> >>>>>>>> we can eventually move them to RecordCompilationTests in a >>>>>>>> separate effort >>>>>>> >>>>>>> Ok - but do they check all the combinations that you gave >>>>>>> recently added to the other test? Do they need to be made more >>>>>>> powerful? >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Maurizio >>>>>>>> >>>>>>>> Vicente >>>>>>>>> >>>>>>>>> On 16/01/2020 21:24, Vicente Romero wrote: >>>>>>>>>> Please review the fix for [1] at [2]. Some background: >>>>>>>>>> >>>>>>>>>> Annotations applied to record components are propagated to >>>>>>>>>> the corresponding record member so if an annotation has >>>>>>>>>> target: FIELD, it is propagated to the corresponding FIELD, >>>>>>>>>> if it has target METHOD, it is propagated to the accessor and >>>>>>>>>> so on. But at the moment when method members are generated >>>>>>>>>> there is no enough information to propagate only the right >>>>>>>>>> annotations. So all the annotations are propagated to all the >>>>>>>>>> possible locations. >>>>>>>>>> >>>>>>>>>> So there is a point when we need to remove all the >>>>>>>>>> annotations that are not in place before going on with the >>>>>>>>>> annotation party. On top of the above there is the issue that >>>>>>>>>> there is no AST representing record components, just symbols >>>>>>>>>> so the corresponding field has been holding all the >>>>>>>>>> annotations and it's metadata has been modified as if it was >>>>>>>>>> both a field and a record component. >>>>>>>>>> >>>>>>>>>> So there are two places where we need to trim annotations >>>>>>>>>> from: the metadata of the symbol and / or the modifiers in >>>>>>>>>> the AST. Whatever is in the metadata will be written to the >>>>>>>>>> class file, whatever is in the modifiers could be see by >>>>>>>>>> annotation processors. >>>>>>>>>> >>>>>>>>>> The metadata contains both type annotations and declaration >>>>>>>>>> annotations. Type annotations are all in the right place as >>>>>>>>>> they are applicable to all the types of the corresponding >>>>>>>>>> record members generated by the compiler. But we could need >>>>>>>>>> to remove declaration annotations. So for declaration >>>>>>>>>> annotations if they are not applicable to the given record >>>>>>>>>> member it will be needed to remove them. For the AST >>>>>>>>>> modifiers if the annotation is not applicable either as type >>>>>>>>>> annotation and or declaration annotation, only in the last >>>>>>>>>> case it will be removed. >>>>>>>>>> >>>>>>>>>> So it could be that an annotation is removed as a declaration >>>>>>>>>> annotation but it is kept in the AST modifier for further >>>>>>>>>> inspection by annotation processors. >>>>>>>>>> >>>>>>>>>> For example: >>>>>>>>>> >>>>>>>>>> ??? import java.lang.annotation.*; >>>>>>>>>> >>>>>>>>>> ??? @Target({ElementType.TYPE_USE, >>>>>>>>>> ElementType.RECORD_COMPONENT}) >>>>>>>>>> ??? @Retention(RetentionPolicy.RUNTIME) >>>>>>>>>> ??? @interface Anno { } >>>>>>>>>> >>>>>>>>>> ??? record R(@Anno String s) {} >>>>>>>>>> >>>>>>>>>> just before Enter ends we will have for the case of the >>>>>>>>>> generated field: >>>>>>>>>> ? - @Anno in the modifier >>>>>>>>>> ? - @Anno as a type annotation >>>>>>>>>> ? - @Anno as a declaration annotation >>>>>>>>>> >>>>>>>>>> the last one should be removed because the annotation has not >>>>>>>>>> FIELD as target but it was applied as a declaration >>>>>>>>>> annotation because the field was being treated both as a >>>>>>>>>> field and as a record component. Once we reach the point when >>>>>>>>>> the corresponding annotations have been copied to the record >>>>>>>>>> component, the field doesn't need to hold annotations that >>>>>>>>>> are not intended for it anymore. Still @Anno has to be kept >>>>>>>>>> in the AST's modifiers as it is applicable as a type >>>>>>>>>> annotation to the type of the field. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vicente >>>>>>>>>> >>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236210 >>>>>>>>>> [2] http://cr.openjdk.java.net/~vromero/8236210/webrev.00/ >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From jan.lahoda at oracle.com Fri Jan 24 08:45:43 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 24 Jan 2020 09:45:43 +0100 Subject: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof In-Reply-To: <1967341931.477168.1579800245335.JavaMail.zimbra@u-pem.fr> References: <3c16b477-1c54-82f3-448b-3067a1481c45@oracle.com> <1967341931.477168.1579800245335.JavaMail.zimbra@u-pem.fr> Message-ID: On 23. 01. 20 18:24, Remi Forax wrote: > > > ----- Mail original ----- >> De: "jan lahoda" >> ?: "compiler-dev" >> Envoy?: Jeudi 23 Janvier 2020 18:10:36 >> Objet: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof > >> Hi, >> >> When javac compiles: >> o instanceof String s >> >> it desugars this to: >> >> (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String >> && (s = (String)s$temp) == (String)s$temp) >> >> The "(s = (String)s$temp) == (String)s$temp)" is there to set the >> variable "s" to the correct, and still return/have a boolean value. But >> this produces several unnecessary instructions for the comparison - >> second cast and unnecessary test/jump. This can be changed to: >> >> (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String >> && (let s = (String)s$temp; in true)) >> >> I.e. the (s = (String)s$temp) == (String)s$temp) is replaced with >> >> (let s = (String)s$temp; in true) >> >> This is a let expression that will execute the assignment as a statement >> and then return true without any tests. This eliminates the unnecessary >> cast and test/jump, producing a smaller code (see bytecode before and >> after below). >> > > Nice ! > You can shave two more bytes (the first two instructions) by detecting that the left part of instanceof is already a local variable, so you don't need the first let. Right, I was thinking of that, but inclined to not do that, as it is a little tricky (esp. to test) and we don't do it on other places (like in switch over string), so it might be a more general effort. Thanks, Jan > >> Proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8237528/webrev.00/index.html >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8237528 >> >> How does this look? >> > > R?mi > >> Jan From forax at univ-mlv.fr Fri Jan 24 09:05:05 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 24 Jan 2020 10:05:05 +0100 (CET) Subject: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof In-Reply-To: References: <3c16b477-1c54-82f3-448b-3067a1481c45@oracle.com> <1967341931.477168.1579800245335.JavaMail.zimbra@u-pem.fr> Message-ID: <817169340.676596.1579856705364.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "jan lahoda" > ?: "Remi Forax" > Cc: "compiler-dev" > Envoy?: Vendredi 24 Janvier 2020 09:45:43 > Objet: Re: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof > On 23. 01. 20 18:24, Remi Forax wrote: >> >> >> ----- Mail original ----- >>> De: "jan lahoda" >>> ?: "compiler-dev" >>> Envoy?: Jeudi 23 Janvier 2020 18:10:36 >>> Objet: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for >>> instanceof >> >>> Hi, >>> >>> When javac compiles: >>> o instanceof String s >>> >>> it desugars this to: >>> >>> (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String >>> && (s = (String)s$temp) == (String)s$temp) >>> >>> The "(s = (String)s$temp) == (String)s$temp)" is there to set the >>> variable "s" to the correct, and still return/have a boolean value. But >>> this produces several unnecessary instructions for the comparison - >>> second cast and unnecessary test/jump. This can be changed to: >>> >>> (let /*synthetic*/ final Object s$temp = o in s$temp instanceof String >>> && (let s = (String)s$temp; in true)) >>> >>> I.e. the (s = (String)s$temp) == (String)s$temp) is replaced with >>> >>> (let s = (String)s$temp; in true) >>> >>> This is a let expression that will execute the assignment as a statement >>> and then return true without any tests. This eliminates the unnecessary >>> cast and test/jump, producing a smaller code (see bytecode before and >>> after below). >>> >> >> Nice ! >> You can shave two more bytes (the first two instructions) by detecting that the >> left part of instanceof is already a local variable, so you don't need the >> first let. > > Right, I was thinking of that, but inclined to not do that, as it is a > little tricky (esp. to test) and we don't do it on other places (like in > switch over string), so it might be a more general effort. Ok. yes, removing the let when not needed can be done in several places at once. BTW, switch over something is not where we should search for clue because as you now, different kinds of switch behave differently from the bytecode POV, i stumble on this example recently, an empty switch over a String use requireNonNull instead of hashCode while an empty switch over an enum use ordinal. It's not a big deal until you introduce jep 358 that leaks how null check are done at bytecode level. > > Thanks, > Jan R?mi > >> >>> Proposed patch: >>> http://cr.openjdk.java.net/~jlahoda/8237528/webrev.00/index.html >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8237528 >>> >>> How does this look? >>> >> >> R?mi >> > >> Jan From maurizio.cimadamore at oracle.com Fri Jan 24 12:15:21 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 24 Jan 2020 12:15:21 +0000 Subject: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof In-Reply-To: References: <3c16b477-1c54-82f3-448b-3067a1481c45@oracle.com> <1967341931.477168.1579800245335.JavaMail.zimbra@u-pem.fr> Message-ID: +1 Maurizio On 24/01/2020 08:45, Jan Lahoda wrote: > Right, I was thinking of that, but inclined to not do that, as it is a > little tricky (esp. to test) and we don't do it on other places (like > in switch over string), so it might be a more general effort. From jan.lahoda at oracle.com Fri Jan 24 14:04:46 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 24 Jan 2020 15:04:46 +0100 Subject: RFR: JDK-8236997 tools/javac tests fail with --illegal-access=deny In-Reply-To: <7EE0A011-0A75-40F5-A1D5-6A3DD174E699@oracle.com> References: <7EE0A011-0A75-40F5-A1D5-6A3DD174E699@oracle.com> Message-ID: <7185b0e2-7ffc-a624-2844-bc5f3665b26e@oracle.com> Overall, looks fine to me. A few comments: -in test/langtools/tools/javac/classwriter/ExtraAttributes.java, calling .options several times will clear the values set by previous invocations. The plugin here will start as it is an autostart plugin, so I guess I'd suggest to remove the first call to .options, as the first call is not really needed -in test/langtools/tools/javac/failover/CheckAttributedTree.java, I would suggest to return back the "java.desktop" after "@modules". It is not needed to compile or run the test itself, but the test is trying to compile all other tests as well, and "java.desktop" will prevent attempts to run the test on limited JDKs without java.desktop (which is expected) -I am afraid there is another test using the combo test framework in the jdk (as opposed to langtools) tests: test/jdk/java/lang/reflect/Proxy/ProxyGeneratorCombo.java That one should receive the same handling as the other combo tests (this is the only test outside of langtools I was able to find). Jan On 23. 01. 20 17:13, Adam Sotona wrote: > Hi, > I would like to ask for review of tools/javac tests patch (attached) so > the tests work correctly with?--illegal-access=deny switch. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8236997 > > Please let me know if this is OK or if there are any issues with the > proposed patch. > > Thank you, > Adam > > From adam.sotona at oracle.com Fri Jan 24 15:16:34 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Fri, 24 Jan 2020 16:16:34 +0100 Subject: RFR: JDK-8236997 tools/javac tests fail with --illegal-access=deny In-Reply-To: <7185b0e2-7ffc-a624-2844-bc5f3665b26e@oracle.com> References: <7EE0A011-0A75-40F5-A1D5-6A3DD174E699@oracle.com> <7185b0e2-7ffc-a624-2844-bc5f3665b26e@oracle.com> Message-ID: <85864AEC-7D41-40A2-83FA-1231448FC604@oracle.com> Thank you for the review, all three comments are fixed in the attached patch. Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8236997-2.patch Type: application/octet-stream Size: 23253 bytes Desc: not available URL: -------------- next part -------------- > On 24 Jan 2020, at 15:04, Jan Lahoda wrote: > > Overall, looks fine to me. A few comments: > -in test/langtools/tools/javac/classwriter/ExtraAttributes.java, calling .options several times will clear the values set by previous invocations. The plugin here will start as it is an autostart plugin, so I guess I'd suggest to remove the first call to .options, as the first call is not really needed > > -in test/langtools/tools/javac/failover/CheckAttributedTree.java, I would suggest to return back the "java.desktop" after "@modules". It is not needed to compile or run the test itself, but the test is trying to compile all other tests as well, and "java.desktop" will prevent attempts to run the test on limited JDKs without java.desktop (which is expected) > > -I am afraid there is another test using the combo test framework in the jdk (as opposed to langtools) tests: > test/jdk/java/lang/reflect/Proxy/ProxyGeneratorCombo.java > > That one should receive the same handling as the other combo tests (this is the only test outside of langtools I was able to find). > > Jan > > On 23. 01. 20 17:13, Adam Sotona wrote: >> Hi, >> I would like to ask for review of tools/javac tests patch (attached) so the tests work correctly with --illegal-access=deny switch. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8236997 >> Please let me know if this is OK or if there are any issues with the proposed patch. >> Thank you, >> Adam From bsrbnd at gmail.com Sat Jan 25 12:50:08 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 25 Jan 2020 13:50:08 +0100 Subject: False positive compilation of a method reference with type parameters In-Reply-To: <5489101579787963@vla1-3991b5027d7d.qloud-c.yandex.net> References: <8151711579367797@iva8-5e86d95f65ab.qloud-c.yandex.net> <5489101579787963@vla1-3991b5027d7d.qloud-c.yandex.net> Message-ID: Nikita, Maybe someone else could confirm but I believe the current behavior is correct, see JLS ?15.12.2.1 [1]: "This clause implies that a non-generic method may be potentially applicable to an invocation that supplies explicit type arguments. Indeed, it may turn out to be applicable. In such a case, the type arguments will simply be ignored." Which means that "cons(int var)" is potentially applicable too and is also the chosen one. Simply try to remove it and the compilation will fail as expected. Best regards, Bernard On Thu, 23 Jan 2020 at 15:00, Nikita Eshkeev wrote: > > > [DUPLICATED FROM jdk-dev] > > > Greetings, > > I expect the compilation of the following code should fail, but the > compilation is successful: > > public class Demo { > static void cons(T c) { System.out.println(c.getClass()); } > static void cons(int var) { System.out.println("int"); } > > public static void main(String[] args) { > java.util.function.IntConsumer cons1 = Demo::cons; // <-- the type parameter is ignored > java.util.function.Consumer cons2 = Demo::cons; // <-- wrong type parameter for the consumer > cons1.accept(5); > cons2.accept(5); > } > } > > $ javac Demo.java ; java Demo > int > int > > I checked for both java-8 > $ java -version > openjdk version "1.8.0_232" > OpenJDK Runtime Environment (build 1.8.0_232-b09) > OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode) > > and java-11: > $ java -version > openjdk version "11.0.5" 2019-10-15 > OpenJDK Runtime Environment (build 11.0.5+10) > OpenJDK 64-Bit Server VM (build 11.0.5+10, mixed mode) > > My OS: Arch Linux funcs 5.4.8-arch1-1 #1 SMP PREEMPT Sat, 04 Jan 2020 > 23:46:18 +0000 x86_64 GNU/Linux > > -- > Sincerely, > Nikita Eshkeev > From vicente.romero at oracle.com Mon Jan 27 16:37:02 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 27 Jan 2020 11:37:02 -0500 Subject: RFR: JDK-8235149: javac parser is too aggressive on ambiguous expressions using identifier: record Message-ID: <11c9af7d-6443-9461-3d90-13d716421daa@oracle.com> Hi, Please review the fix for [1] at [2] which fixes a too aggressive approach in the parser which is issuing errors for acceptable used of the `record` identifier in cases when the preview feature flag is not set. Thanks, Vicente PS, as part of the patch I have also removed a couple of debug statements from RecordCompilationTests in an unrelated test. [1] https://bugs.openjdk.java.net/browse/JDK-8235149 [2] http://cr.openjdk.java.net/~vromero/8235149/webrev.00/ From vicente.romero at oracle.com Mon Jan 27 22:45:25 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 27 Jan 2020 17:45:25 -0500 Subject: RFR: [Backport] JDK14-8235778: No compilation error reported when a record is declared in a local class Message-ID: <2731b334-69bb-272f-42d4-3aa757beb87c@oracle.com> Please review backport of bug [1] into JDK14. The fix was initially pushed to JDK15. The fix for JDK14 can be seen at [2]. The initial review thread for the fix that got pushed into JDK15 can be seen at [3]. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8235778 [2] http://cr.openjdk.java.net/~vromero/8235778_jdk14/webrev.00/ [3] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014076.html From maurizio.cimadamore at oracle.com Mon Jan 27 23:26:14 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Jan 2020 23:26:14 +0000 Subject: RFR: [Backport] JDK14-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <2731b334-69bb-272f-42d4-3aa757beb87c@oracle.com> References: <2731b334-69bb-272f-42d4-3aa757beb87c@oracle.com> Message-ID: <60a736b1-2300-7229-cc84-af894afce2a3@oracle.com> Looks good Maurizio On 27/01/2020 22:45, Vicente Romero wrote: > Please review backport of bug [1] into JDK14. The fix was initially > pushed to JDK15. The fix for JDK14 can be seen at [2]. The initial > review thread for the fix that got pushed into JDK15 can be seen at [3]. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8235778 > [2] http://cr.openjdk.java.net/~vromero/8235778_jdk14/webrev.00/ > [3] > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014076.html From maurizio.cimadamore at oracle.com Mon Jan 27 23:30:35 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Jan 2020 23:30:35 +0000 Subject: RFR: JDK-8235149: javac parser is too aggressive on ambiguous expressions using identifier: record In-Reply-To: <11c9af7d-6443-9461-3d90-13d716421daa@oracle.com> References: <11c9af7d-6443-9461-3d90-13d716421daa@oracle.com> Message-ID: <38c9cacb-28f3-c4d3-3f0e-fd7c22cfbbbb@oracle.com> Looks good. Partially related question - is it normal/expected that we issue warning for a restricted type name even when preview features are disabled? Maurizio On 27/01/2020 16:37, Vicente Romero wrote: > Hi, > > Please review the fix for [1] at [2] which fixes a too aggressive > approach in the parser which is issuing errors for acceptable used of > the `record` identifier in cases when the preview feature flag is not > set. > > Thanks, > Vicente > > PS, as part of the patch I have also removed a couple of debug > statements from RecordCompilationTests in an unrelated test. > > [1] https://bugs.openjdk.java.net/browse/JDK-8235149 > [2] http://cr.openjdk.java.net/~vromero/8235149/webrev.00/ From vicente.romero at oracle.com Mon Jan 27 23:44:05 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 27 Jan 2020 18:44:05 -0500 Subject: RFR: JDK-8235149: javac parser is too aggressive on ambiguous expressions using identifier: record In-Reply-To: <38c9cacb-28f3-c4d3-3f0e-fd7c22cfbbbb@oracle.com> References: <11c9af7d-6443-9461-3d90-13d716421daa@oracle.com> <38c9cacb-28f3-c4d3-3f0e-fd7c22cfbbbb@oracle.com> Message-ID: On 1/27/20 6:30 PM, Maurizio Cimadamore wrote: > Looks good. > > Partially related question - is it normal/expected that we issue > warning for a restricted type name even when preview features are > disabled? in the case of records we decided to issue a warning for its use as a type even if preview features were disabled. I think to remember that we enabled the warning in JDK 13 to warn users in advance > > Maurizio Vicente > > On 27/01/2020 16:37, Vicente Romero wrote: >> Hi, >> >> Please review the fix for [1] at [2] which fixes a too aggressive >> approach in the parser which is issuing errors for acceptable used of >> the `record` identifier in cases when the preview feature flag is not >> set. >> >> Thanks, >> Vicente >> >> PS, as part of the patch I have also removed a couple of debug >> statements from RecordCompilationTests in an unrelated test. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235149 >> [2] http://cr.openjdk.java.net/~vromero/8235149/webrev.00/ From maurizio.cimadamore at oracle.com Mon Jan 27 23:45:31 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Jan 2020 23:45:31 +0000 Subject: RFR: JDK-8235149: javac parser is too aggressive on ambiguous expressions using identifier: record In-Reply-To: References: <11c9af7d-6443-9461-3d90-13d716421daa@oracle.com> <38c9cacb-28f3-c4d3-3f0e-fd7c22cfbbbb@oracle.com> Message-ID: On 27/01/2020 23:44, Vicente Romero wrote: > > > On 1/27/20 6:30 PM, Maurizio Cimadamore wrote: >> Looks good. >> >> Partially related question - is it normal/expected that we issue >> warning for a restricted type name even when preview features are >> disabled? > > in the case of records we decided to issue a warning for its use as a > type even if preview features were disabled. I think to remember that > we enabled the warning in JDK 13 to warn users in advance Ok, thanks Maurizio > >> >> Maurizio > > Vicente > >> >> On 27/01/2020 16:37, Vicente Romero wrote: >>> Hi, >>> >>> Please review the fix for [1] at [2] which fixes a too aggressive >>> approach in the parser which is issuing errors for acceptable used >>> of the `record` identifier in cases when the preview feature flag is >>> not set. >>> >>> Thanks, >>> Vicente >>> >>> PS, as part of the patch I have also removed a couple of debug >>> statements from RecordCompilationTests in an unrelated test. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235149 >>> [2] http://cr.openjdk.java.net/~vromero/8235149/webrev.00/ > From amaembo at gmail.com Tue Jan 28 07:51:29 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 28 Jan 2020 14:51:29 +0700 Subject: RFR: [Backport] JDK14-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <60a736b1-2300-7229-cc84-af894afce2a3@oracle.com> References: <2731b334-69bb-272f-42d4-3aa757beb87c@oracle.com> <60a736b1-2300-7229-cc84-af894afce2a3@oracle.com> Message-ID: Hello! Why a record inside the local record is not allowed, given that the local record is implicitly static and static members are allowed inside? Could you please point me where this is disabled in the specification? Thanks. With best regards, Tagir Valeev. On Tue, Jan 28, 2020 at 6:29 AM Maurizio Cimadamore wrote: > > Looks good > > Maurizio > > On 27/01/2020 22:45, Vicente Romero wrote: > > Please review backport of bug [1] into JDK14. The fix was initially > > pushed to JDK15. The fix for JDK14 can be seen at [2]. The initial > > review thread for the fix that got pushed into JDK15 can be seen at [3]. > > > > Thanks, > > Vicente > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8235778 > > [2] http://cr.openjdk.java.net/~vromero/8235778_jdk14/webrev.00/ > > [3] > > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014076.html From maurizio.cimadamore at oracle.com Tue Jan 28 09:11:10 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 Jan 2020 09:11:10 +0000 Subject: RFR: [Backport] JDK14-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: References: <2731b334-69bb-272f-42d4-3aa757beb87c@oracle.com> <60a736b1-2300-7229-cc84-af894afce2a3@oracle.com> Message-ID: <2628b5f5-c3d9-72b4-6ce6-dfcab9364844@oracle.com> Good point - I? don't think this was the intent of the fix - but this test: assertFail("compiler.err.record.declaration.not.allowed.in.inner.classes", 519 """ 520 class Outer { 521 void m() { 522 record A() { 523 record B() { } 524 } 525 } 526 } 527 """); Seems wrong/non conformant with the spec. The problem with the fix is that it bans records if they happen to be declared inside a 'type'. There are at least three cases where this doesn't create (at least in principle) any issues: * record inside interfaces (interfaces are always static) * record inside enum (enums are always static) * record inside static nested class * record inside record (records are always static) Now I believe that the first three are implicitly handled by the fact that such records are not considered 'local' by javac (you cannot have enums or static classes inside a method), so the check tweaked by this patch doesn't apply. But record inside a local record is a possibility. We should probably add extra tests for all these cases. Maurizio On 28/01/2020 07:51, Tagir Valeev wrote: > Hello! > > Why a record inside the local record is not allowed, given that the > local record is implicitly static and static members are allowed > inside? Could you please point me where this is disabled in the > specification? Thanks. > > With best regards, > Tagir Valeev. > > On Tue, Jan 28, 2020 at 6:29 AM Maurizio Cimadamore > wrote: >> Looks good >> >> Maurizio >> >> On 27/01/2020 22:45, Vicente Romero wrote: >>> Please review backport of bug [1] into JDK14. The fix was initially >>> pushed to JDK15. The fix for JDK14 can be seen at [2]. The initial >>> review thread for the fix that got pushed into JDK15 can be seen at [3]. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235778 >>> [2] http://cr.openjdk.java.net/~vromero/8235778_jdk14/webrev.00/ >>> [3] >>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014076.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandrikov at gmail.com Wed Jan 29 11:23:55 2020 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Wed, 29 Jan 2020 12:23:55 +0100 Subject: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof Message-ID: Hi, > I.e. the (s = (String)s$temp) == (String)s$temp) is replaced with > (let s = (String)s$temp; in true) Looks like an update of comment was forgotten - see tiny patch below. And please excuse me for missing the original RFR thread. diff -r 9fb094231eee src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java Wed Jan 29 11:04:00 2020 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java Wed Jan 29 12:13:25 2020 +0100 @@ -151,7 +151,7 @@ if (tree.pattern.hasTag(Tag.BINDINGPATTERN)) { //E instanceof T N //=> - //(let T' N$temp = E; N$temp instanceof T && (N = (T) N$temp == (T) N$temp)) + //(let T' N$temp = E; N$temp instanceof T && (N = (T) N$temp; in true)) JCBindingPattern patt = (JCBindingPattern)tree.pattern; VarSymbol pattSym = patt.symbol; Type tempType = tree.expr.type.hasTag(BOT) ? Regards, Evgeny -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jan 29 12:06:51 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 29 Jan 2020 13:06:51 +0100 Subject: RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof In-Reply-To: References: Message-ID: <75ba3abf-452b-faf2-d5f8-91ea444255ee@oracle.com> Right, thanks. I'll fix with some future patch. Thanks, Jan On 29. 01. 20 12:23, Evgeny Mandrikov wrote: > Hi, > > > I.e. the (s = (String)s$temp) == (String)s$temp) is replaced with > > (let s = (String)s$temp; in true) > > Looks like an update of comment was forgotten?- see tiny patch below. > > And please excuse me for missing the original RFR thread. > > > diff -r 9fb094231eee > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java > ? ? ? ?Wed Jan 29 11:04:00 2020 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java > ? ? ? ?Wed Jan 29 12:13:25 2020 +0100 > @@ -151,7 +151,7 @@ > ? ? ? ? ?if (tree.pattern.hasTag(Tag.BINDINGPATTERN)) { > ? ? ? ? ? ? ?//E instanceof T N > ? ? ? ? ? ? ?//=> > - ? ? ? ? ? ?//(let T' N$temp = E; N$temp instanceof T && (N = (T) > N$temp == (T) N$temp)) > + ? ? ? ? ? ?//(let T' N$temp = E; N$temp instanceof T && (N = (T) > N$temp; in true)) > ? ? ? ? ? ? ?JCBindingPattern patt = (JCBindingPattern)tree.pattern; > ? ? ? ? ? ? ?VarSymbol pattSym = patt.symbol; > ? ? ? ? ? ? ?Type tempType = tree.expr.type.hasTag(BOT) ? > > > Regards, > Evgeny > From David.Grieve at microsoft.com Fri Jan 31 18:36:42 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Fri, 31 Jan 2020 18:36:42 +0000 Subject: Possible compiler bug? Code compiles on 8 but not 11 Message-ID: I have some code that compiles on 8 but not on 11. With 11 (11.0.5, to be exact), the compiler gives an error: > Factory.java > Error:(9, 25) java: incompatible types: java.lang.Object cannot be converted to Manager This can be fixed with an explicit cast. But it seems to me that the cast should not be needed. I'm hoping to get an answer for why this compiles cleanly on 8, but not 11. I have uploaded a small sample that reproduces to http://cr.openjdk.java.net/~dgrieve/javac-bug.zip From alex.buckley at oracle.com Fri Jan 31 18:58:39 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 31 Jan 2020 10:58:39 -0800 Subject: Possible compiler bug? Code compiles on 8 but not 11 In-Reply-To: References: Message-ID: Hi David, This is a question of whether javac is conforming to the JLS, and if so, whether the JLS is correct. It's best in such cases to quote the smallest possible code sample in inline text. Oracle's javac team is not looking to reproduce issues in the manner of a support organization, but rather to understand as precisely as possible what's going on in the type system. Alex On 1/31/2020 10:36 AM, David Grieve wrote: > I have some code that compiles on 8 but not on 11. With 11 (11.0.5, to be exact), the compiler gives an error: > >> Factory.java >> Error:(9, 25) java: incompatible types: java.lang.Object cannot be converted to Manager > > This can be fixed with an explicit cast. But it seems to me that the cast should not be needed. > > I'm hoping to get an answer for why this compiles cleanly on 8, but not 11. > > I have uploaded a small sample that reproduces to http://cr.openjdk.java.net/~dgrieve/javac-bug.zip > From David.Grieve at microsoft.com Fri Jan 31 20:13:01 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Fri, 31 Jan 2020 20:13:01 +0000 Subject: [EXTERNAL] Re: Possible compiler bug? Code compiles on 8 but not 11 In-Reply-To: References: Message-ID: Understood. Like I said, casting solves the problem, so I am not looking for support. I thought you might be interested in a case where compilation breaks on 11. I will try to distill the code to something that can be put inline. > -----Original Message----- > From: compiler-dev On Behalf Of > Alex Buckley > Sent: Friday, January 31, 2020 1:59 PM > To: compiler-dev at openjdk.java.net > Subject: [EXTERNAL] Re: Possible compiler bug? Code compiles on 8 but not > 11 > > Hi David, > > This is a question of whether javac is conforming to the JLS, and if so, > whether the JLS is correct. It's best in such cases to quote the smallest > possible code sample in inline text. Oracle's javac team is not looking to > reproduce issues in the manner of a support organization, but rather to > understand as precisely as possible what's going on in the type system. > > Alex > > On 1/31/2020 10:36 AM, David Grieve wrote: > > I have some code that compiles on 8 but not on 11. With 11 (11.0.5, to be > exact), the compiler gives an error: > > > >> Factory.java > >> Error:(9, 25) java: incompatible types: java.lang.Object cannot be > converted to Manager > > > > This can be fixed with an explicit cast. But it seems to me that the cast > should not be needed. > > > > I'm hoping to get an answer for why this compiles cleanly on 8, but not 11. > > > > I have uploaded a small sample that reproduces to > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjd > k.java.net%2F~dgrieve%2Fjavac- > bug.zip&data=02%7C01%7Cdavid.grieve%40microsoft.com%7C5b62d5e > 00aa04bfc305308d7a6806653%7C72f988bf86f141af91ab2d7cd011db47%7C1 > %7C0%7C637160944402111070&sdata=kB7DeYrkwvE7VZkYRg%2B0osPP > ucvJZdGaKvyiux1Wbp0%3D&reserved=0 > >