From andrew_m_leonard at uk.ibm.com Wed Jul 1 10:34:18 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 1 Jul 2020 11:34:18 +0100 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 In-Reply-To: References: Message-ID: Hi, is anyone able to help sponsoring this please? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: compiler-dev at openjdk.java.net Date: 26/06/2020 11:40 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 Hi, Please can I request a sponsor and review for the fix to bug JDK-8248231? (https://bugs.openjdk.java.net/browse/JDK-8248231) webrev for review: http://cr.openjdk.java.net/~aleonard/8248231/webrev.00/ The problem with incorrect encoding of deserializeLambda was discovered by the openj9 VM team on a platform where the default encoding is not UTF-8 (eg.EBCDIC platforms), which eluded to the problem that the deserializeLambda was not been encoded correctly when the lambda char did not map to an ASCII compatible range. The fix testcase replicates the problem by using a suitable UTF-8 char that does not map. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Jul 1 18:02:09 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 1 Jul 2020 11:02:09 -0700 Subject: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3 In-Reply-To: <4774b5e1-0b78-bba0-95f2-445cdcab72b3@oracle.com> References: <87877fd1-5413-7518-a2e6-d6d2132f6356@oracle.com> <3f816bd3-bc9d-8f94-db98-94fd0423948d@oracle.com> <85933330-a0e2-74cf-876c-42b64eb28482@oracle.com> <4774b5e1-0b78-bba0-95f2-445cdcab72b3@oracle.com> Message-ID: <19bde5be-c14b-fd5d-0c23-a7dfc9bfa2f0@oracle.com> +1 -- Jon On 6/26/20 6:13 AM, Jan Lahoda wrote: > Hi, > > I propose to split the data update (for JDK 15 and for backports) and > the tool/CreateSymbols update (for JDK 16+). So I've created: > https://bugs.openjdk.java.net/browse/JDK-8248405 > > for the latter. Lets keep JDK-8244763 only for the former, i.e. for > this patch: > http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/ > > I believe the data patch is reviewed, and is not controversial. Please > let me know if you see any issues with this split. > > Thanks, > ?? Jan > > On 01. 06. 20 10:07, Jan Lahoda wrote: >> Further testing revealed some issues with the patch, especially: >> -use of un-encoded version when deleting the old data for the version >> (so the data deletion failed for versions > 9) >> -need to delete old module data as well >> -when searching for existing methods and fields, we need to continue >> the search to find the best existing candidate (the code still had a >> for loop break, so only the first match was found). >> >> I apologize for missing those in the first review. >> >> Delta webrev: >> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-01-create-symbols/ >> >> Full updated webrev: >> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-create-symbols/ >> >> Does this look OK? >> >> Thanks! >> ???? Jan >> >> On 28. 05. 20 16:47, Jonathan Gibbons wrote: >>> Looks good to me. >>> >>> -- Jon >>> >>> On 5/18/20 9:36 AM, Jan Lahoda wrote: >>>> I apologize, I used a wrong patch for the "data" webrev. The "class >>>> name java/util/jar/Attributes$Name" entry in java.base-7.sym.txt is >>>> first adding field descriptions, and then removing the old ones: >>>> --- >>>>> class name java/util/jar/Attributes$Name >>>>> field name EXTENSION_INSTALLATION descriptor >>>>> Ljava/util/jar/Attributes$Name; flags 19 >>>>> field name IMPLEMENTATION_VENDOR_ID descriptor >>>>> Ljava/util/jar/Attributes$Name; flags 19 >>>>> field name IMPLEMENTATION_URL descriptor >>>>> Ljava/util/jar/Attributes$Name; flags 19 >>>>> -field name EXTENSION_INSTALLATION descriptor >>>>> Ljava/util/jar/Attributes$Name; >>>>> -field name IMPLEMENTATION_VENDOR_ID descriptor >>>>> Ljava/util/jar/Attributes$Name; >>>>> -field name IMPLEMENTATION_URL descriptor >>>>> Ljava/util/jar/Attributes$Name;--- >>>> >>>> The correct order (and the order generated by the tool in the >>>> webrev.00-create-symbols/ webrev) is to first remove the field >>>> descriptions and then add the new ones: >>>> --- >>>>> class name java/util/jar/Attributes$Name >>>>> -field name EXTENSION_INSTALLATION descriptor >>>>> Ljava/util/jar/Attributes$Name; >>>>> -field name IMPLEMENTATION_VENDOR_ID descriptor >>>>> Ljava/util/jar/Attributes$Name; >>>>> -field name IMPLEMENTATION_URL descriptor >>>>> Ljava/util/jar/Attributes$Name; >>>>> field name EXTENSION_INSTALLATION descriptor >>>>> Ljava/util/jar/Attributes$Name; flags 19 >>>>> field name IMPLEMENTATION_VENDOR_ID descriptor >>>>> Ljava/util/jar/Attributes$Name; flags 19 >>>>> field name IMPLEMENTATION_URL descriptor >>>>> Ljava/util/jar/Attributes$Name; flags 19 >>>> --- >>>> >>>> An updated webrev is the correct data is here: >>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/ >>>> >>>> The only change is the above difference in order of entries in >>>> Attributes$Name. >>>> >>>> Sorry for trouble. >>>> >>>> Jan >>>> >>>> On 18. 05. 20 16:55, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> Some new APIs have been introduced in JSR 337 MR3 (JDK 8). We >>>>> should update the historical data for JDK 8 with these new APIs. >>>>> >>>>> As this was the first time we need to update data for a release >>>>> that other release data use as a baseline, it was necessary to >>>>> improve the CreateSymbols tool a little: >>>>> -adding ability to ignore synchronized and native flags for >>>>> methods (as these don't affect the API) >>>>> -when analyzing a new entry (method/field/class), and multiple >>>>> existing entries compatible with the new one exist, the existing >>>>> entry that matches the baseline is chosen (this helps to eliminate >>>>> unnecessary entries, esp. when the synchronized or native flag >>>>> changes) >>>>> -when replacing/updating a release data, the original approach was >>>>> to remove the data for the release, and read them from classfiles, >>>>> and build the record again from scratch. This does not work well >>>>> for baseline data, so the new approach is: >>>>> --keep all the existing data >>>>> --the new data are load into a new auxiliary slot, called "$" >>>>> --the old data for the given release are deleted >>>>> --the auxiliary release is renamed from "$" to the correct release >>>>> name >>>>> >>>>> Together these changes allow to minimize the updates to JDK 8 >>>>> data, to mostly only changes in the MR3, with some extra changes >>>>> like new/removed overrides (where the superclass has the method >>>>> that is/was overridden). >>>>> >>>>> The proposed changes to CreateSymbols are: >>>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-create-symbols/ >>>>> >>>>> The proposed updates to the historical data are: >>>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-data/ >>>>> >>>>> Note the changes only apply for JDK 8 historical data, so JDK 8 >>>>> data are updated, and JDK 7 and 9 data undo the changes. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244763 >>>>> >>>>> The intent is to backport to JDK 11u. >>>>> >>>>> How does this look? >>>>> >>>>> Thanks! >>>>> >>>>> Jan From jan.lahoda at oracle.com Thu Jul 2 13:11:20 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 2 Jul 2020 15:11:20 +0200 Subject: RFR: JDK-8248641: Trees.getScope returns incorrect results for code inside a rule case Message-ID: <33414814-d992-7957-32b0-ad0913376eff@oracle.com> Hi, When calling Trees.getScope for a TreePath that is inside a rule case (i.e. "case ->"), the results are wrong/do not reflect the elements declared inside the enclosing method. The reason is that, for rule cases, JCCase tree is keeping "body", which represents what is in the source code. And this body is wrapped and put into "stats", which are basically the statements for an ordinary case. This means that javac can typically only work over the "stats". When TreeCopied copies the JCCase tree, it will duplicate both "stats" and "body" separately, leading to a duplication in trees. And then Attr.breakTree points to the requested tree from "body", but that one is never attributed, and so the appropriate scope is never captured. The proposed patch here is to only duplicate "stats", and then take appropriate "body" from "stats", leading to only one copy of the tree. Webrev: http://cr.openjdk.java.net/~jlahoda/8248641/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8248641 How does this look? Thanks, Jan From andrew_m_leonard at uk.ibm.com Mon Jul 6 11:01:42 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 6 Jul 2020 12:01:42 +0100 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 In-Reply-To: References: Message-ID: Any sponsors please? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: compiler-dev at openjdk.java.net Date: 26/06/2020 11:40 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 Hi, Please can I request a sponsor and review for the fix to bug JDK-8248231? (https://bugs.openjdk.java.net/browse/JDK-8248231) webrev for review: http://cr.openjdk.java.net/~aleonard/8248231/webrev.00/ The problem with incorrect encoding of deserializeLambda was discovered by the openj9 VM team on a platform where the default encoding is not UTF-8 (eg.EBCDIC platforms), which eluded to the problem that the deserializeLambda was not been encoded correctly when the lambda char did not map to an ASCII compatible range. The fix testcase replicates the problem by using a suitable UTF-8 char that does not map. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From TOSHIONA at jp.ibm.com Mon Jul 6 14:51:46 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Mon, 6 Jul 2020 23:51:46 +0900 Subject: RFR: JDK-8233829: javac cannot find non-ASCII module name under non-UTF8 environment In-Reply-To: References: <6eb52787-0ebd-1487-52c2-67cbfa04a6a4@oracle.com> Message-ID: Hi, Ping. Could someone review this fix, please? Best regards, Toshio Nakamura > From: Toshio 5 Nakamura/Japan/IBM > To: Jonathan Gibbons > Cc: compiler-dev at openjdk.java.net > Date: 2020/06/01 18:05 > Subject: Re: RFR: JDK-8233829: javac cannot find non-ASCII module > name under non-UTF8 environment > > Hi Jon, > > Could you look at this fix, if possible? > Any comments or suggestions are welcome. > > Webrev.02: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8233829 > > Best regards, > > Toshio Nakamura > > From: "Toshio 5 Nakamura" > > To: Jonathan Gibbons > > Cc: compiler-dev at openjdk.java.net > > Date: 2020/05/15 00:23 > > Subject: [EXTERNAL] Re: RFR: JDK-8233829: javac cannot find non- > > ASCII module name under non-UTF8 environment > > Sent by: "compiler-dev" > > > > Hi Jon, > > > > Thank you for comments. > > > > Could you check webrev.02 which contains a testcase? > > Actually, this is not a direct test of the original problem since > > non-English Windows is required. > > But, I realized the patch fixed Unicode Surrogate Pair case, as well. > > It's caused by difference between Standard UTF-8 and Modified UTF-8, > > and it can be checked on English environment. > > > > I confirmed the test failed without the patch and passed with the patch. > > Tier1 tests also pass on Linux and Windows. > > > > Webrev.02: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/ > > > > Best regards, > > > > Toshio Nakamura > > > > Jonathan Gibbons wrote on 2020/05/1411:50:03: > > > > > From: Jonathan Gibbons > > > To: Toshio 5 Nakamura , compiler-dev at openjdk.java.net > > > Date: 2020/05/14 11:50 > > > Subject: [EXTERNAL] Re: RFR: JDK-8233829: javac cannot find non- > > > ASCII module name under non-UTF8 environment > > > > > > Hi, > > > Normally, bug fixes like this this should be accompanied by a > > > corresponding regression test. While it may be a bit tricky to write > > > a test for this situation, it seems like it would be worth having > > > the test if possible. > > > -- Jon > > > On 5/13/20 7:11 PM, Toshio 5 Nakamura wrote: > > > Hi, > > > > > > Can anyone please review this fix? > > > Revised the patch simpler. In my understanding, the encoding is > > > modified UTF-8 instead of standard UTF-8 in this case. So, the fix > > > uses Convert utility class. > > > > > > Webrev.01: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.01/ > > > > > > Best regards, > > > Toshio Nakamura > > > > > > > From: Toshio 5 Nakamura/Japan/IBM > > > > To: compiler-dev at openjdk.java.net > > > > Date: 2020/04/16 21:39 > > > > Subject: RFR: JDK-8233829: Non-ASCII module name cannot be handled > > > > under non-UTF8 environment > > > > > > > > Hi all, > > > > > > > > Could you review this fix? Also, I'd like to ask a sponsor of the fix, since > > > > I'm not a committer. > > > > > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8233829 > > > > Webrev: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.00/ > > > > > > > > If module name is in non-ASCII and environment is in non-UTF8, > > > > javac's "--add-modules" option cannot find the module. > > > > > > > > com.sun.tools.javac.jvm.ModuleNameReader.utf8Mapper uses > > > > String(byte[], int, int). > > > > In problematic case, the String was generated by default encoding > > > > which wasn't UTF8. > > > > For example, Japanese Windows uses MS932 (Shift_JIS) encoding. > > > > The byte[] in utf8Mapper method is always decoded by UTF-8. > > > > > > > > Tier1 tests on Linux and Windows passed. > > > > > > > > Best Regards, > > > > Toshio Nakamura -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Mon Jul 6 19:39:17 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 6 Jul 2020 21:39:17 +0200 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac In-Reply-To: <21A12194-2F55-4E6D-8D30-B8143781DBFA@oracle.com> References: <7BB770AF-AB6A-447F-A8F2-E850851F365D@oracle.com> <21A12194-2F55-4E6D-8D30-B8143781DBFA@oracle.com> Message-ID: Hi Adam & Vicente, I wrote the original patch and as far as I can remember, Adam is right that it's only replacing 'bound' with 'getUpperBound()' and the current difference looks therefore pertinent in the sense that the call to 'isIntersectionOrUnionType' seems to come from another patch that might be backported too? But note that this isn't an approval as I'm not a Reviewer and I would need to look at your patch more attentively. Cheers, Bernard On Mon, 29 Jun 2020 at 11:40, Adam Sotona wrote: > > I've double-checked it, the patch is only replacing .bound with .getUpperBound() and implementing the .getUpperBound(). > The semantical change by implementing .isIntersectionOrUnionType() comes from some other patch. > > Adam > > On 26 Jun 2020, at 18:27, Vicente Romero wrote: > > but isn't the case the the original patch is returning true if the upper bound of the type variable is a union or an intersection while the patch adapted to 11 is only returning true if that upper bound is an intersection? what would happen if is is an union? > > Vicente > > On 6/26/20 2:39 AM, Adam Sotona wrote: > > Hi Vicente, > I found the code isIntersectionOrUnionType(Type t) is already there - that is why the patch conflict appears. > > Thanks, > Adam > > On 25 Jun 2020, at 21:57, Vicente Romero wrote: > > Hi Adam, > > On 6/23/20 6:55 AM, Adam Sotona wrote: > > Hi, > Please review backport of 8193367 into JDK 11. > > Original patch at http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 has just minor conflicts in copyright headers and in one code fragment with JDK 11 repository. > > New patch differs in functionality with the original just in one block in src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: > < - if (tv.bound.getKind() == TypeKind.INTERSECTION) { > < + if (tv.getUpperBound().getKind() == TypeKind.INTERSECTION) { > > > this difference seems like an important semantic change compared to what the original patch is doing. I guess you will need to port method: `boolean isIntersectionOrUnionType(Type t)` too > > versus: > > - return isIntersectionOrUnionType(tv.bound); > > + return isIntersectionOrUnionType(tv.getUpperBound()); > > Patched JDK 11 passed all Tier 1, 2 and 3 tests. > > Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 > Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ > Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 > > Thanks, > Adam > > > Thanks, > Vicente > > > > From jonathan.gibbons at oracle.com Mon Jul 6 23:02:52 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 6 Jul 2020 16:02:52 -0700 Subject: RFR: JDK-8233829: javac cannot find non-ASCII module name under non-UTF8 environment In-Reply-To: References: <6eb52787-0ebd-1487-52c2-67cbfa04a6a4@oracle.com> Message-ID: Sorry for the delay; I have reviewed the code and the new test, and verified the test works as expected. I will push the fix for you. -- Jon On 7/6/20 7:51 AM, Toshio 5 Nakamura wrote: > > Hi, > > Ping. Could someone review this fix, please? > > Best regards, > Toshio Nakamura > > > From: Toshio 5 Nakamura/Japan/IBM > > To: Jonathan Gibbons > > Cc: compiler-dev at openjdk.java.net > > Date: 2020/06/01 18:05 > > Subject: Re: RFR: JDK-8233829: javac cannot find non-ASCII module > > name under non-UTF8 environment > > > > Hi Jon, > > > > Could you look at this fix, if possible? > > Any comments or suggestions are welcome. > > > > Webrev.02: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8233829 > > > > Best regards, > > > > Toshio Nakamura > > > > From: "Toshio 5 Nakamura" > > > To: Jonathan Gibbons > > > Cc: compiler-dev at openjdk.java.net > > > Date: 2020/05/15 00:23 > > > Subject: [EXTERNAL] Re: RFR: JDK-8233829: javac cannot find non- > > > ASCII module name under non-UTF8 environment > > > Sent by: "compiler-dev" > > > > > > Hi Jon, > > > > > > Thank you for comments. > > > > > > Could you check webrev.02 which contains a testcase? > > > Actually, this is not a direct test of the original problem since > > > non-English Windows is required. > > > But, I realized the patch fixed Unicode Surrogate Pair case, as well. > > > It's caused by difference between Standard UTF-8 and Modified UTF-8, > > > and it can be checked on English environment. > > > > > > I confirmed the test failed without the patch and passed with the > patch. > > > Tier1 tests also pass on Linux and Windows. > > > > > > Webrev.02: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/ > > > > > > Best regards, > > > > > > Toshio Nakamura > > > > > > Jonathan Gibbons wrote on > 2020/05/1411:50:03: > > > > > > > From: Jonathan Gibbons > > > > To: Toshio 5 Nakamura , > compiler-dev at openjdk.java.net > > > > Date: 2020/05/14 11:50 > > > > Subject: [EXTERNAL] Re: RFR: JDK-8233829: javac cannot find non- > > > > ASCII module name under non-UTF8 environment > > > > > > > > Hi, > > > > Normally, bug fixes like this this should be accompanied by a > > > > corresponding regression test. While it may be a bit tricky to write > > > > a test for this situation, it seems like it would be worth having > > > > the test if possible. > > > > -- Jon > > > > On 5/13/20 7:11 PM, Toshio 5 Nakamura wrote: > > > > Hi, > > > > > > > > Can anyone please review this fix? > > > > Revised the patch simpler. In my understanding, the encoding is > > > > modified UTF-8 instead of standard UTF-8 in this case. So, the fix > > > > uses Convert utility class. > > > > > > > > Webrev.01: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.01/ > > > > > > > > Best regards, > > > > Toshio Nakamura > > > > > > > > > From: Toshio 5 Nakamura/Japan/IBM > > > > > To: compiler-dev at openjdk.java.net > > > > > Date: 2020/04/16 21:39 > > > > > Subject: RFR: JDK-8233829: Non-ASCII module name cannot be > handled > > > > > under non-UTF8 environment > > > > > > > > > > Hi all, > > > > > > > > > > Could you review this fix? Also, I'd like to ask a sponsor of > the fix, since > > > > > I'm not a committer. > > > > > > > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8233829 > > > > > Webrev: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.00/ > > > > > > > > > > If module name is in non-ASCII and environment is in non-UTF8, > > > > > javac's "--add-modules" option cannot find the module. > > > > > > > > > > com.sun.tools.javac.jvm.ModuleNameReader.utf8Mapper uses > > > > > String(byte[], int, int). > > > > > In problematic case, the String was generated by default encoding > > > > > which wasn't UTF8. > > > > > For example, Japanese Windows uses MS932 (Shift_JIS) encoding. > > > > > The byte[] in utf8Mapper method is always decoded by UTF-8. > > > > > > > > > > Tier1 tests on Linux and Windows passed. > > > > > > > > > > Best Regards, > > > > > Toshio Nakamura > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TOSHIONA at jp.ibm.com Tue Jul 7 01:08:31 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Tue, 7 Jul 2020 01:08:31 +0000 Subject: RFR: JDK-8233829: javac cannot find non-ASCII module name under non-UTF8 environment In-Reply-To: References: , <6eb52787-0ebd-1487-52c2-67cbfa04a6a4@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jul 7 14:33:50 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Jul 2020 10:33:50 -0400 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 In-Reply-To: References: Message-ID: looks good to me, Vicente On 7/6/20 7:01 AM, Andrew Leonard wrote: > Any sponsors please? > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Andrew Leonard/UK/IBM > To: compiler-dev at openjdk.java.net > Date: 26/06/2020 11:40 > Subject: RFR and sponsor: 8248231: deserializeLambda created with > wrong encoding if platform encoding not UTF-8 > ------------------------------------------------------------------------ > > > Hi, > Please can I request a sponsor and review for the fix to bug > JDK-8248231? (https://bugs.openjdk.java.net/browse/JDK-8248231) > webrev for review: > http://cr.openjdk.java.net/~aleonard/8248231/webrev.00/ > > The problem with incorrect encoding of deserializeLambda was > discovered by the openj9 VM team on a platform where the default > encoding is not UTF-8 (eg.EBCDIC platforms), which eluded to the > problem that the deserializeLambda was not been encoded correctly when > the lambda char did not map to an ASCII compatible range. The fix > testcase replicates the problem by using a suitable UTF-8 char that > does not map. > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Tue Jul 7 15:22:16 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 7 Jul 2020 16:22:16 +0100 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 In-Reply-To: References: Message-ID: Thank you Vincente, Would you be able to sponsor pushing this please? I also need a 2nd review please, anyone? Thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Vicente Romero To: Andrew Leonard , compiler-dev at openjdk.java.net Date: 07/07/2020 15:34 Subject: [EXTERNAL] Re: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 looks good to me, Vicente On 7/6/20 7:01 AM, Andrew Leonard wrote: Any sponsors please? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: compiler-dev at openjdk.java.net Date: 26/06/2020 11:40 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 Hi, Please can I request a sponsor and review for the fix to bug JDK-8248231? (https://bugs.openjdk.java.net/browse/JDK-8248231) webrev for review: http://cr.openjdk.java.net/~aleonard/8248231/webrev.00/ The problem with incorrect encoding of deserializeLambda was discovered by the openj9 VM team on a platform where the default encoding is not UTF-8 (eg.EBCDIC platforms), which eluded to the problem that the deserializeLambda was not been encoded correctly when the lambda char did not map to an ASCII compatible range. The fix testcase replicates the problem by using a suitable UTF-8 char that does not map. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jul 7 17:05:47 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 7 Jul 2020 10:05:47 -0700 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 In-Reply-To: References: Message-ID: <23d35ab8-5cf6-2c33-108e-721a375a131a@oracle.com> The two-reviewer rule used by HotSpot is not used in other areas of the JDK, including javac. -Joe On 7/7/2020 8:22 AM, Andrew Leonard wrote: > Thank you Vincente, > Would you be able to sponsor pushing this please? > > I also need a 2nd review please, anyone? > > Thanks, > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Vicente Romero > To: Andrew Leonard , > compiler-dev at openjdk.java.net > Date: 07/07/2020 15:34 > Subject: [EXTERNAL] Re: RFR and sponsor: 8248231: deserializeLambda > created with wrong encoding if platform encoding not UTF-8 > ------------------------------------------------------------------------ > > > > looks good to me, > Vicente > > On 7/6/20 7:01 AM, Andrew Leonard wrote: > Any sponsors please? > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: _andrew_m_leonard at uk.ibm.com_ > > > > > > From: Andrew Leonard/UK/IBM > To: _compiler-dev at openjdk.java.net_ > Date: 26/06/2020 11:40 > Subject: RFR and sponsor: 8248231: deserializeLambda created with > wrong encoding if platform encoding not UTF-8 > ------------------------------------------------------------------------ > > > Hi, > Please can I request a sponsor and review for the fix to bug > JDK-8248231? (_https://bugs.openjdk.java.net/browse/JDK-8248231_) > webrev for review: > _http://cr.openjdk.java.net/~aleonard/8248231/webrev.00/_ > > The problem with incorrect encoding of deserializeLambda was > discovered by the openj9 VM team on a platform where the default > encoding is not UTF-8 (eg.EBCDIC platforms), which eluded to the > problem that the deserializeLambda was not been encoded correctly when > the lambda char did not map to an ASCII compatible range. The fix > testcase replicates the problem by using a suitable UTF-8 char that > does not map. > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: _andrew_m_leonard at uk.ibm.com_ > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jul 7 17:38:52 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Jul 2020 13:38:52 -0400 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 In-Reply-To: References: Message-ID: sure I can push it for you, Vicente On 7/7/20 11:22 AM, Andrew Leonard wrote: > Thank you Vincente, > Would you be able to sponsor pushing this please? > > I also need a 2nd review please, anyone? > > Thanks, > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Vicente Romero > To: Andrew Leonard , > compiler-dev at openjdk.java.net > Date: 07/07/2020 15:34 > Subject: [EXTERNAL] Re: RFR and sponsor: 8248231: deserializeLambda > created with wrong encoding if platform encoding not UTF-8 > ------------------------------------------------------------------------ > > > > looks good to me, > Vicente > > On 7/6/20 7:01 AM, Andrew Leonard wrote: > Any sponsors please? > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: _andrew_m_leonard at uk.ibm.com_ > > > > > > From: Andrew Leonard/UK/IBM > To: _compiler-dev at openjdk.java.net_ > Date: 26/06/2020 11:40 > Subject: RFR and sponsor: 8248231: deserializeLambda created with > wrong encoding if platform encoding not UTF-8 > ------------------------------------------------------------------------ > > > Hi, > Please can I request a sponsor and review for the fix to bug > JDK-8248231? (_https://bugs.openjdk.java.net/browse/JDK-8248231_) > webrev for review: > _http://cr.openjdk.java.net/~aleonard/8248231/webrev.00/_ > > The problem with incorrect encoding of deserializeLambda was > discovered by the openj9 VM team on a platform where the default > encoding is not UTF-8 (eg.EBCDIC platforms), which eluded to the > problem that the deserializeLambda was not been encoded correctly when > the lambda char did not map to an ASCII compatible range. The fix > testcase replicates the problem by using a suitable UTF-8 char that > does not map. > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: _andrew_m_leonard at uk.ibm.com_ > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jul 7 18:56:33 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Jul 2020 14:56:33 -0400 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac In-Reply-To: References: <7BB770AF-AB6A-447F-A8F2-E850851F365D@oracle.com> <21A12194-2F55-4E6D-8D30-B8143781DBFA@oracle.com> Message-ID: Hi Bernard, Adam located the other issue [1] that needs to be backported before the backport for JDK-8193367. Once [1] has been backported JDK-8193367 can also be backporte as-is, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8213703 On 7/6/20 3:39 PM, B. Blaser wrote: > Hi Adam & Vicente, > > I wrote the original patch and as far as I can remember, Adam is right > that it's only replacing 'bound' with 'getUpperBound()' and the > current difference looks therefore pertinent in the sense that the > call to 'isIntersectionOrUnionType' seems to come from another patch > that might be backported too? But note that this isn't an approval as > I'm not a Reviewer and I would need to look at your patch more > attentively. > > Cheers, > Bernard > > On Mon, 29 Jun 2020 at 11:40, Adam Sotona wrote: >> I've double-checked it, the patch is only replacing .bound with .getUpperBound() and implementing the .getUpperBound(). >> The semantical change by implementing .isIntersectionOrUnionType() comes from some other patch. >> >> Adam >> >> On 26 Jun 2020, at 18:27, Vicente Romero wrote: >> >> but isn't the case the the original patch is returning true if the upper bound of the type variable is a union or an intersection while the patch adapted to 11 is only returning true if that upper bound is an intersection? what would happen if is is an union? >> >> Vicente >> >> On 6/26/20 2:39 AM, Adam Sotona wrote: >> >> Hi Vicente, >> I found the code isIntersectionOrUnionType(Type t) is already there - that is why the patch conflict appears. >> >> Thanks, >> Adam >> >> On 25 Jun 2020, at 21:57, Vicente Romero wrote: >> >> Hi Adam, >> >> On 6/23/20 6:55 AM, Adam Sotona wrote: >> >> Hi, >> Please review backport of 8193367 into JDK 11. >> >> Original patch at http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 has just minor conflicts in copyright headers and in one code fragment with JDK 11 repository. >> >> New patch differs in functionality with the original just in one block in src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: >> < - if (tv.bound.getKind() == TypeKind.INTERSECTION) { >> < + if (tv.getUpperBound().getKind() == TypeKind.INTERSECTION) { >> >> >> this difference seems like an important semantic change compared to what the original patch is doing. I guess you will need to port method: `boolean isIntersectionOrUnionType(Type t)` too >> >> versus: >>> - return isIntersectionOrUnionType(tv.bound); >>> + return isIntersectionOrUnionType(tv.getUpperBound()); >> Patched JDK 11 passed all Tier 1, 2 and 3 tests. >> >> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 >> Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ >> Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 >> >> Thanks, >> Adam >> >> >> Thanks, >> Vicente >> >> >> >> From vicente.romero at oracle.com Tue Jul 7 19:15:16 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Jul 2020 15:15:16 -0400 Subject: RFR: JDK-8248641: Trees.getScope returns incorrect results for code inside a rule case In-Reply-To: <33414814-d992-7957-32b0-ad0913376eff@oracle.com> References: <33414814-d992-7957-32b0-ad0913376eff@oracle.com> Message-ID: <651117e6-2b50-8ac2-355c-bd1725fa40af@oracle.com> looks good, Vicente On 7/2/20 9:11 AM, Jan Lahoda wrote: > Hi, > > When calling Trees.getScope for a TreePath that is inside a rule case > (i.e. "case ->"), the results are wrong/do not reflect the elements > declared inside the enclosing method. > > The reason is that, for rule cases, JCCase tree is keeping "body", > which represents what is in the source code. And this body is wrapped > and put into "stats", which are basically the statements for an > ordinary case. This means that javac can typically only work over the > "stats". When TreeCopied copies the JCCase tree, it will duplicate > both "stats" and "body" separately, leading to a duplication in trees. > And then Attr.breakTree points to the requested tree from "body", but > that one is never attributed, and so the appropriate scope is never > captured. > > The proposed patch here is to only duplicate "stats", and then take > appropriate "body" from "stats", leading to only one copy of the tree. > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8248641/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8248641 > > How does this look? > > Thanks, > ??? Jan From jan.lahoda at oracle.com Tue Jul 7 19:17:22 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 7 Jul 2020 21:17:22 +0200 Subject: RFR (backport 11u): JDK-8244763: Update --release 8 symbol information after JSR 337 MR3 Message-ID: Hi, I'd like to ask for a review of a backport of: https://bugs.openjdk.java.net/browse/JDK-8244763 https://hg.openjdk.java.net/jdk/jdk15/rev/d0b86d63c00f The patch unfortunately does not apply cleanly, so manual fixes were needed, but the backport patch should be conceptually the same as the original one. Proposed backport webrev: http://cr.openjdk.java.net/~jlahoda/8244763/webrev.backport.00/ Original review thread: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-May/014537.html Does this look reasonable? Thanks, Jan From andrew_m_leonard at uk.ibm.com Tue Jul 7 19:31:55 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 7 Jul 2020 20:31:55 +0100 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 In-Reply-To: References: Message-ID: Thank you Vicente Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Vicente Romero To: Andrew Leonard Cc: compiler-dev at openjdk.java.net Date: 07/07/2020 18:41 Subject: [EXTERNAL] Re: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 sure I can push it for you, Vicente On 7/7/20 11:22 AM, Andrew Leonard wrote: Thank you Vincente, Would you be able to sponsor pushing this please? I also need a 2nd review please, anyone? Thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Vicente Romero To: Andrew Leonard , compiler-dev at openjdk.java.net Date: 07/07/2020 15:34 Subject: [EXTERNAL] Re: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 looks good to me, Vicente On 7/6/20 7:01 AM, Andrew Leonard wrote: Any sponsors please? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: compiler-dev at openjdk.java.net Date: 26/06/2020 11:40 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 Hi, Please can I request a sponsor and review for the fix to bug JDK-8248231? (https://bugs.openjdk.java.net/browse/JDK-8248231) webrev for review: http://cr.openjdk.java.net/~aleonard/8248231/webrev.00/ The problem with incorrect encoding of deserializeLambda was discovered by the openj9 VM team on a platform where the default encoding is not UTF-8 (eg.EBCDIC platforms), which eluded to the problem that the deserializeLambda was not been encoded correctly when the lambda char did not map to an ASCII compatible range. The fix testcase replicates the problem by using a suitable UTF-8 char that does not map. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Jul 7 20:36:46 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 7 Jul 2020 13:36:46 -0700 Subject: RFR (backport 11u): JDK-8244763: Update --release 8 symbol information after JSR 337 MR3 In-Reply-To: References: Message-ID: <54703e3c-1ce8-ace6-aeba-9272b972862d@oracle.com> Jan, Looks good to me. That being said, it looks like the underlying versions of CreateSymbols are somewhat different in 11u and 15, which is confirmed by looking at the Frames view in the webrevs for mainline and for the backport. The differences seem enough that backporting patches seems more questionable.? I know we don't backport symbol changes often, but if we get to do it again, it might be worth looking at whether we can make the different versions of the tool more similar. -- Jon On 7/7/20 12:17 PM, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of a backport of: > https://bugs.openjdk.java.net/browse/JDK-8244763 > https://hg.openjdk.java.net/jdk/jdk15/rev/d0b86d63c00f > > The patch unfortunately does not apply cleanly, so manual fixes were > needed, but the backport patch should be conceptually the same as the > original one. > > Proposed backport webrev: > http://cr.openjdk.java.net/~jlahoda/8244763/webrev.backport.00/ > > Original review thread: > https://mail.openjdk.java.net/pipermail/compiler-dev/2020-May/014537.html > > Does this look reasonable? > > Thanks, > ??? Jan From joe.darcy at oracle.com Wed Jul 8 02:23:32 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 7 Jul 2020 19:23:32 -0700 Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty Message-ID: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> Hello, Please review the webev and CSR for ??? JDK-8248983: Add Name.isEmpty ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249005 ??? webrev: http://cr.openjdk.java.net/~darcy/8248983.0/ In its current form, this fix can only be pushed *after* the minimum boot JDK in the JDK 16 build is updated to JDK 15. Otherwise, the default method on CharSequence is not necessarily present. To be pushed earlier, the default method on Name would need to be changed to host an implementation that didn't delegate to CharSequence.isEmpty. It would not be difficult to take that route instead with a follow-up bug to change the implementation of the default method later. Thanks, -Joe From james.laskey at oracle.com Wed Jul 8 11:59:33 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 8 Jul 2020 08:59:33 -0300 Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> Message-ID: <7176CDB7-D076-4EB9-9B30-8D08BFE43F06@oracle.com> +1 That dreaded bootstrap curse. If only we had chinstraps. > On Jul 7, 2020, at 11:23 PM, Joe Darcy wrote: > > Hello, > > Please review the webev and CSR for > > JDK-8248983: Add Name.isEmpty > CSR: https://bugs.openjdk.java.net/browse/JDK-8249005 > webrev: http://cr.openjdk.java.net/~darcy/8248983.0/ > > In its current form, this fix can only be pushed *after* the minimum boot JDK in the JDK 16 build is updated to JDK 15. Otherwise, the default method on CharSequence is not necessarily present. > > To be pushed earlier, the default method on Name would need to be changed to host an implementation that didn't delegate to CharSequence.isEmpty. It would not be difficult to take that route instead with a follow-up bug to change the implementation of the default method later. > > Thanks, > > -Joe > From forax at univ-mlv.fr Wed Jul 8 12:15:52 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 8 Jul 2020 14:15:52 +0200 (CEST) Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> Message-ID: <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> HI Joe, I don't understand the value that this method provides, because either the JDK 15 is the bootstrap JDK and in this case, this code is useless because CharSequence.isEmpty() already provides the right behavior, or you don't and it will not compile. So either you write it to delegate to length() so you are not dependent of JDK 15 being the bootstrap JDK or you do nothing and you will get isEmpty() for free when the JDK 15 will be the bootstrap JDK. public interface Name extends CharSequence { /** + * Returns {@code true} if this is an empty name with a length of + * zero; returns {@code false} otherwise. + * @return {@code true} for an empty name and {@code false} otherwise. + * + * @since 16 + */ + default boolean isEmpty() { + return length() == 0; + } regards, R?mi ----- Mail original ----- > De: "joe darcy" > ?: "compiler-dev" > Envoy?: Mercredi 8 Juillet 2020 04:23:32 > Objet: JDK 16 RFR of JDK-8248983: Add Name.isEmpty > Hello, > > Please review the webev and CSR for > > ??? JDK-8248983: Add Name.isEmpty > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249005 > ??? webrev: http://cr.openjdk.java.net/~darcy/8248983.0/ > > In its current form, this fix can only be pushed *after* the minimum > boot JDK in the JDK 16 build is updated to JDK 15. Otherwise, the > default method on CharSequence is not necessarily present. > > To be pushed earlier, the default method on Name would need to be > changed to host an implementation that didn't delegate to > CharSequence.isEmpty. It would not be difficult to take that route > instead with a follow-up bug to change the implementation of the default > method later. > > Thanks, > > -Joe From joe.darcy at oracle.com Wed Jul 8 16:23:21 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 8 Jul 2020 09:23:21 -0700 Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> Message-ID: <42a1f0d9-64da-cf87-4842-8bf96f0756b0@oracle.com> Hi Remi, The value of the method is to provide a reference point within the javax.lang.model API for the "empty name" concept. The goal for the code in the body of Name.isEmpty is to have as little as possible, preferably just delegating to CharSequence.isEmpty. I'd prefer to have the empty name links point to the method Name.isEmpty rather than CharSequence.isEmpty, hence defining a minimal Name.isEmpty method within the API. HTH, -Joe On 7/8/2020 5:15 AM, Remi Forax wrote: > HI Joe, > I don't understand the value that this method provides, > because either the JDK 15 is the bootstrap JDK and in this case, this code is useless because CharSequence.isEmpty() already provides the right behavior, > or you don't and it will not compile. > > So either you write it to delegate to length() so you are not dependent of JDK 15 being the bootstrap JDK or you do nothing and you will get isEmpty() for free when the JDK 15 will be the bootstrap JDK. > > public interface Name extends CharSequence { > /** > + * Returns {@code true} if this is an empty name with a length of > + * zero; returns {@code false} otherwise. > + * @return {@code true} for an empty name and {@code false} otherwise. > + * > + * @since 16 > + */ > + default boolean isEmpty() { > + return length() == 0; > + } > > regards, > R?mi > > ----- Mail original ----- >> De: "joe darcy" >> ?: "compiler-dev" >> Envoy?: Mercredi 8 Juillet 2020 04:23:32 >> Objet: JDK 16 RFR of JDK-8248983: Add Name.isEmpty >> Hello, >> >> Please review the webev and CSR for >> >> ??? JDK-8248983: Add Name.isEmpty >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249005 >> ??? webrev: http://cr.openjdk.java.net/~darcy/8248983.0/ >> >> In its current form, this fix can only be pushed *after* the minimum >> boot JDK in the JDK 16 build is updated to JDK 15. Otherwise, the >> default method on CharSequence is not necessarily present. >> >> To be pushed earlier, the default method on Name would need to be >> changed to host an implementation that didn't delegate to >> CharSequence.isEmpty. It would not be difficult to take that route >> instead with a follow-up bug to change the implementation of the default >> method later. >> >> Thanks, >> >> -Joe From forax at univ-mlv.fr Wed Jul 8 22:31:58 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 9 Jul 2020 00:31:58 +0200 (CEST) Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <42a1f0d9-64da-cf87-4842-8bf96f0756b0@oracle.com> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> <42a1f0d9-64da-cf87-4842-8bf96f0756b0@oracle.com> Message-ID: <1000196621.16339.1594247518109.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "joe darcy" > ?: "Remi Forax" > Cc: "compiler-dev" > Envoy?: Mercredi 8 Juillet 2020 18:23:21 > Objet: Re: JDK 16 RFR of JDK-8248983: Add Name.isEmpty > Hi Remi, > > The value of the method is to provide a reference point within the > javax.lang.model API for the "empty name" concept. The goal for the code > in the body of Name.isEmpty is to have as little as possible, preferably > just delegating to CharSequence.isEmpty. I'd prefer to have the empty > name links point to the method Name.isEmpty rather than > CharSequence.isEmpty, hence defining a minimal Name.isEmpty method > within the API. I can buy that the concept of empty name is important, following what you are saying, length() should be re-abstracted for the exact same reason. I think i prefer to follow the current implementation of Name that explain the concept of empty name in the top level javadoc of Name, and fix the sentence "An empty Name has a length of zero." to mention isEmpty. > > HTH, > > -Joe R?mi > > On 7/8/2020 5:15 AM, Remi Forax wrote: >> HI Joe, >> I don't understand the value that this method provides, >> because either the JDK 15 is the bootstrap JDK and in this case, this code is >> useless because CharSequence.isEmpty() already provides the right behavior, >> or you don't and it will not compile. >> >> So either you write it to delegate to length() so you are not dependent of JDK >> 15 being the bootstrap JDK or you do nothing and you will get isEmpty() for >> free when the JDK 15 will be the bootstrap JDK. >> >> public interface Name extends CharSequence { >> /** >> + * Returns {@code true} if this is an empty name with a length of >> + * zero; returns {@code false} otherwise. >> + * @return {@code true} for an empty name and {@code false} otherwise. >> + * >> + * @since 16 >> + */ >> + default boolean isEmpty() { >> + return length() == 0; >> + } >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "joe darcy" >>> ?: "compiler-dev" >>> Envoy?: Mercredi 8 Juillet 2020 04:23:32 >>> Objet: JDK 16 RFR of JDK-8248983: Add Name.isEmpty >>> Hello, >>> >>> Please review the webev and CSR for >>> >>> ??? JDK-8248983: Add Name.isEmpty >>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249005 >>> ??? webrev: http://cr.openjdk.java.net/~darcy/8248983.0/ >>> >>> In its current form, this fix can only be pushed *after* the minimum >>> boot JDK in the JDK 16 build is updated to JDK 15. Otherwise, the >>> default method on CharSequence is not necessarily present. >>> >>> To be pushed earlier, the default method on Name would need to be >>> changed to host an implementation that didn't delegate to >>> CharSequence.isEmpty. It would not be difficult to take that route >>> instead with a follow-up bug to change the implementation of the default >>> method later. >>> >>> Thanks, >>> > >> -Joe From joe.darcy at oracle.com Wed Jul 8 22:34:02 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 8 Jul 2020 15:34:02 -0700 Subject: FYI, JSR 269 under maintenance review for Java SE 15 changes Message-ID: Hello, FYI, JSR 269, covering the javax.lang.model and javax.annotation.processing packages, is under maintenance review for the changes made in Java SE 15: https://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index9.html -Joe From jonathan.gibbons at oracle.com Thu Jul 9 00:05:08 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 8 Jul 2020 17:05:08 -0700 Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <1000196621.16339.1594247518109.JavaMail.zimbra@u-pem.fr> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> <42a1f0d9-64da-cf87-4842-8bf96f0756b0@oracle.com> <1000196621.16339.1594247518109.JavaMail.zimbra@u-pem.fr> Message-ID: <56a14991-f146-a4ff-fcb1-614fec8715e2@oracle.com> On 7/8/20 3:31 PM, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "joe darcy" >> ?: "Remi Forax" >> Cc: "compiler-dev" >> Envoy?: Mercredi 8 Juillet 2020 18:23:21 >> Objet: Re: JDK 16 RFR of JDK-8248983: Add Name.isEmpty >> Hi Remi, >> >> The value of the method is to provide a reference point within the >> javax.lang.model API for the "empty name" concept. The goal for the code >> in the body of Name.isEmpty is to have as little as possible, preferably >> just delegating to CharSequence.isEmpty. I'd prefer to have the empty >> name links point to the method Name.isEmpty rather than >> CharSequence.isEmpty, hence defining a minimal Name.isEmpty method >> within the API. > I can buy that the concept of empty name is important, following what you are saying, length() should be re-abstracted for the exact same reason. > I think i prefer to follow the current implementation of Name that explain the concept of empty name in the top level javadoc of Name, and fix the sentence "An empty Name has a length of zero." to mention isEmpty. The concept of 'empty name' could be explained in the class comment for Name, as R?mi suggests, and enclosed or prefixed by some HTML that defines an 'id' such as "empty-name" that can be referenced from other locations, without having to introduce a new method for the concept. (But, for me, I'm OK either way.) -- Jon > >> HTH, >> >> -Joe > R?mi > >> On 7/8/2020 5:15 AM, Remi Forax wrote: >>> HI Joe, >>> I don't understand the value that this method provides, >>> because either the JDK 15 is the bootstrap JDK and in this case, this code is >>> useless because CharSequence.isEmpty() already provides the right behavior, >>> or you don't and it will not compile. >>> >>> So either you write it to delegate to length() so you are not dependent of JDK >>> 15 being the bootstrap JDK or you do nothing and you will get isEmpty() for >>> free when the JDK 15 will be the bootstrap JDK. >>> >>> public interface Name extends CharSequence { >>> /** >>> + * Returns {@code true} if this is an empty name with a length of >>> + * zero; returns {@code false} otherwise. >>> + * @return {@code true} for an empty name and {@code false} otherwise. >>> + * >>> + * @since 16 >>> + */ >>> + default boolean isEmpty() { >>> + return length() == 0; >>> + } >>> >>> regards, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "joe darcy" >>>> ?: "compiler-dev" >>>> Envoy?: Mercredi 8 Juillet 2020 04:23:32 >>>> Objet: JDK 16 RFR of JDK-8248983: Add Name.isEmpty >>>> Hello, >>>> >>>> Please review the webev and CSR for >>>> >>>> ??? JDK-8248983: Add Name.isEmpty >>>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249005 >>>> ??? webrev: http://cr.openjdk.java.net/~darcy/8248983.0/ >>>> >>>> In its current form, this fix can only be pushed *after* the minimum >>>> boot JDK in the JDK 16 build is updated to JDK 15. Otherwise, the >>>> default method on CharSequence is not necessarily present. >>>> >>>> To be pushed earlier, the default method on Name would need to be >>>> changed to host an implementation that didn't delegate to >>>> CharSequence.isEmpty. It would not be difficult to take that route >>>> instead with a follow-up bug to change the implementation of the default >>>> method later. >>>> >>>> Thanks, >>>> >>>> -Joe From vicente.romero at oracle.com Thu Jul 9 02:31:26 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 Jul 2020 22:31:26 -0400 Subject: RFR: JDK15-8242529: javac defines type annotations incorrectly for record members (constructor and property accessor) Message-ID: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> Hi, Please review fix for [1] at [2]. Current record implementation is not forward nested type annotations to generated members like in: record R(@RegularAnnotation @TypeAnnotation Callable<@TypeAnnotation ?> foo) {} This patch is fixing one issue that show up in two different generated record members: ??? - the accessor corresponding to the record component ??? - the corresponding parameter in the canonical constructor The issue is that the current implementation is not able to correctly generate the annotated types for these components when such an annotated type has "inner" type annotations like it is the case of `foo` in the example which has `TypeAnnotation` applied to the wildcard. In the case of the corresponding parameter in the canonical constructor the annotated type was generated correctly but the class file reflected the internal type annotation as applied to a field not to a method parameter. In the case of the accessor the inner annotation was not there at all. The patch is making a copy of the expression defining the type of the record component and placing it that the right place for both generated members. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8242529 [2] http://cr.openjdk.java.net/~vromero/8242529/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Thu Jul 9 16:06:12 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Jul 2020 09:06:12 -0700 Subject: RFR: JDK15-8242529: javac defines type annotations incorrectly for record members (constructor and property accessor) In-Reply-To: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> References: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> Message-ID: <287A33AB-6775-4521-AE6B-31A530EB2204@oracle.com> Hi Vicente, The asserts look regular in all four cases, I think :-) If so we can consolidate the check into a single method, off the top of my head: RecordComponent recordComponent = RecordNotPreservingNestedTypeAnnotationsTest.class.getRecordComponents()[0]; check(recordComponent.getAnnotations(), recordComponent.getAnnotatedType()); Method accessor = recordComponent.getAccessor(); check(accessor.getAnnotations(), accessor.getAnnotatedReturnType()); Constructor constructor = RecordNotPreservingNestedTypeAnnotationsTest.class.getConstructor(Callable.class); check(constructor.getParameterAnnotations()[0], constructor.getAnnotatedParameterTypes()[0]); Field field = RecordNotPreservingNestedTypeAnnotationsTest.class.getDeclaredField(recordComponent.getName()); check(field.getAnnotations(), field.getAnnotatedType()); ); Does that work? Paul. > On Jul 8, 2020, at 7:31 PM, Vicente Romero wrote: > > Hi, > > Please review fix for [1] at [2]. Current record implementation is not forward nested type annotations to generated members like in: > > record R(@RegularAnnotation @TypeAnnotation Callable<@TypeAnnotation ?> foo) {} > This patch is fixing one issue that show up in two different generated record members: > - the accessor corresponding to the record component > - the corresponding parameter in the canonical constructor > > The issue is that the current implementation is not able to correctly generate the annotated types for these components when such an annotated type has "inner" type annotations like it is the case of `foo` in the example which has `TypeAnnotation` applied to the wildcard. In the case of the corresponding parameter in the canonical constructor the annotated type was generated correctly but the class file reflected the internal type annotation as applied to a field not to a method parameter. In the case of the accessor the inner annotation was not there at all. The patch is making a copy of the expression defining the type of the record component and placing it that the right place for both generated members. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8242529 > [2] http://cr.openjdk.java.net/~vromero/8242529/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jul 9 16:25:57 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 9 Jul 2020 18:25:57 +0200 Subject: RFR: JDK15-8242529: javac defines type annotations incorrectly for record members (constructor and property accessor) In-Reply-To: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> References: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> Message-ID: Looks good to me. A minor nit might be to move the JCVariableDecl recordField into the then section of the subsequent if (so that it is not computed unless necessary). Jan On 09. 07. 20 4:31, Vicente Romero wrote: > Hi, > > Please review fix for [1] at [2]. Current record implementation is not > forward nested type annotations to generated members like in: > > record R(@RegularAnnotation @TypeAnnotation Callable<@TypeAnnotation ?> foo) {} > > This patch is fixing one issue that show up in two different generated > record members: > ??? - the accessor corresponding to the record component > ??? - the corresponding parameter in the canonical constructor > > The issue is that the current implementation is not able to correctly > generate the annotated types for these components when such an annotated > type has "inner" type annotations like it is the case of `foo` in the > example which has `TypeAnnotation` applied to the wildcard. In the case > of the corresponding parameter in the canonical constructor the > annotated type was generated correctly but the class file reflected the > internal type annotation as applied to a field not to a method > parameter. In the case of the accessor the inner annotation was not > there at all. The patch is making a copy of the expression defining the > type of the record component and placing it that the right place for > both generated members. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8242529 > [2] http://cr.openjdk.java.net/~vromero/8242529/webrev.00/ From vicente.romero at oracle.com Thu Jul 9 18:25:32 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Jul 2020 14:25:32 -0400 Subject: RFR: JDK15-8242529: javac defines type annotations incorrectly for record members (constructor and property accessor) In-Reply-To: <287A33AB-6775-4521-AE6B-31A530EB2204@oracle.com> References: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> <287A33AB-6775-4521-AE6B-31A530EB2204@oracle.com> Message-ID: <0a2e7d84-46c8-96a5-c8a8-0f1c0ac39272@oracle.com> Hi Paul, Thanks for the feedback, I have uploaded another iteration at [1] how does it look? Vicente [1] http://cr.openjdk.java.net/~vromero/8242529/webrev.01/ On 7/9/20 12:06 PM, Paul Sandoz wrote: > Hi Vicente, > > The asserts look regular in all four cases, I think :-) If so we can > consolidate the check into a single method, off the top of my head: > > ? RecordComponent recordComponent = > RecordNotPreservingNestedTypeAnnotationsTest.class.getRecordComponents()[0]; > ? check(recordComponent.getAnnotations(), > recordComponent.getAnnotatedType()); > > ??Method accessor = recordComponent.getAccessor(); > ? check(accessor.getAnnotations(), accessor.getAnnotatedReturnType()); > > Constructor constructor = > RecordNotPreservingNestedTypeAnnotationsTest.class.getConstructor(Callable.class); > check(constructor.getParameterAnnotations()[0], > constructor.getAnnotatedParameterTypes()[0]); > > ? Field field = > RecordNotPreservingNestedTypeAnnotationsTest.class.getDeclaredField(recordComponent.getName()); > > ? check(field.getAnnotations(), field.getAnnotatedType()); > ); > > Does that work? > > Paul. > >> On Jul 8, 2020, at 7:31 PM, Vicente Romero > > wrote: >> >> Hi, >> >> Please review fix for [1] at [2]. Current record implementation is >> not forward nested type annotations to generated members like in: >> >> record R(@RegularAnnotation @TypeAnnotation Callable<@TypeAnnotation ?> foo) {} >> This patch is fixing one issue that show up in two different >> generated record members: >> ??? - the accessor corresponding to the record component >> ??? - the corresponding parameter in the canonical constructor >> >> The issue is that the current implementation is not able to correctly >> generate the annotated types for these components when such an >> annotated type has "inner" type annotations like it is the case of >> `foo` in the example which has `TypeAnnotation` applied to the >> wildcard. In the case of the corresponding parameter in the canonical >> constructor the annotated type was generated correctly but the class >> file reflected the internal type annotation as applied to a field not >> to a method parameter. In the case of the accessor the inner >> annotation was not there at all. The patch is making a copy of the >> expression defining the type of the record component and placing it >> that the right place for both generated members. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8242529 >> [2] http://cr.openjdk.java.net/~vromero/8242529/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Jul 9 18:27:05 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Jul 2020 14:27:05 -0400 Subject: RFR: JDK15-8242529: javac defines type annotations incorrectly for record members (constructor and property accessor) In-Reply-To: References: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> Message-ID: <6076955c-6d82-5e87-51c9-4132d862bfce@oracle.com> thanks for the review, I updated the review at [1] including yours and Paul's suggestion, Vicente [1] http://cr.openjdk.java.net/~vromero/8242529/webrev.01/ On 7/9/20 12:25 PM, Jan Lahoda wrote: > Looks good to me. A minor nit might be to move the JCVariableDecl > recordField into the then section of the subsequent if (so that it is > not computed unless necessary). > > Jan > > On 09. 07. 20 4:31, Vicente Romero wrote: >> Hi, >> >> Please review fix for [1] at [2]. Current record implementation is >> not forward nested type annotations to generated members like in: >> >> record R(@RegularAnnotation @TypeAnnotation Callable<@TypeAnnotation >> ?> foo) {} >> >> This patch is fixing one issue that show up in two different >> generated record members: >> ???? - the accessor corresponding to the record component >> ???? - the corresponding parameter in the canonical constructor >> >> The issue is that the current implementation is not able to correctly >> generate the annotated types for these components when such an >> annotated type has "inner" type annotations like it is the case of >> `foo` in the example which has `TypeAnnotation` applied to the >> wildcard. In the case of the corresponding parameter in the canonical >> constructor the annotated type was generated correctly but the class >> file reflected the internal type annotation as applied to a field not >> to a method parameter. In the case of the accessor the inner >> annotation was not there at all. The patch is making a copy of the >> expression defining the type of the record component and placing it >> that the right place for both generated members. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8242529 >> [2] http://cr.openjdk.java.net/~vromero/8242529/webrev.00/ From paul.sandoz at oracle.com Thu Jul 9 18:34:47 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Jul 2020 11:34:47 -0700 Subject: RFR: JDK15-8242529: javac defines type annotations incorrectly for record members (constructor and property accessor) In-Reply-To: <0a2e7d84-46c8-96a5-c8a8-0f1c0ac39272@oracle.com> References: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> <287A33AB-6775-4521-AE6B-31A530EB2204@oracle.com> <0a2e7d84-46c8-96a5-c8a8-0f1c0ac39272@oracle.com> Message-ID: <7C9452AC-67FA-448A-B9BD-BB41EA85948B@oracle.com> Much better! Suggest you also remove the duplication getAnnotatedActualTypeArguments, such as: var annoTypeArgs = ((AnnotatedParameterizedType) annoType).getAnnotatedActualTypeArguments(); Assert.check(annoTypeArgs.length == 1); Assert.check(annoTypeArgs[0].getAnnotations()[0] instanceof TypeAnnotation); Up to you, no need for another review. Paul. > On Jul 9, 2020, at 11:25 AM, Vicente Romero wrote: > > Hi Paul, > > Thanks for the feedback, I have uploaded another iteration at [1] how does it look? > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8242529/webrev.01/ > > On 7/9/20 12:06 PM, Paul Sandoz wrote: >> Hi Vicente, >> >> The asserts look regular in all four cases, I think :-) If so we can consolidate the check into a single method, off the top of my head: >> >> RecordComponent recordComponent = RecordNotPreservingNestedTypeAnnotationsTest.class.getRecordComponents()[0]; >> check(recordComponent.getAnnotations(), recordComponent.getAnnotatedType()); >> >> Method accessor = recordComponent.getAccessor(); >> check(accessor.getAnnotations(), accessor.getAnnotatedReturnType()); >> >> Constructor constructor = RecordNotPreservingNestedTypeAnnotationsTest.class.getConstructor(Callable.class); >> check(constructor.getParameterAnnotations()[0], constructor.getAnnotatedParameterTypes()[0]); >> >> Field field = RecordNotPreservingNestedTypeAnnotationsTest.class.getDeclaredField(recordComponent.getName()); >> check(field.getAnnotations(), field.getAnnotatedType()); >> ); >> >> Does that work? >> >> Paul. >> >>> On Jul 8, 2020, at 7:31 PM, Vicente Romero > wrote: >>> >>> Hi, >>> >>> Please review fix for [1] at [2]. Current record implementation is not forward nested type annotations to generated members like in: >>> >>> record R(@RegularAnnotation @TypeAnnotation Callable<@TypeAnnotation ?> foo) {} >>> This patch is fixing one issue that show up in two different generated record members: >>> - the accessor corresponding to the record component >>> - the corresponding parameter in the canonical constructor >>> >>> The issue is that the current implementation is not able to correctly generate the annotated types for these components when such an annotated type has "inner" type annotations like it is the case of `foo` in the example which has `TypeAnnotation` applied to the wildcard. In the case of the corresponding parameter in the canonical constructor the annotated type was generated correctly but the class file reflected the internal type annotation as applied to a field not to a method parameter. In the case of the accessor the inner annotation was not there at all. The patch is making a copy of the expression defining the type of the record component and placing it that the right place for both generated members. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8242529 >>> [2] http://cr.openjdk.java.net/~vromero/8242529/webrev.00/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Jul 9 18:48:33 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Jul 2020 14:48:33 -0400 Subject: RFR: JDK15-8242529: javac defines type annotations incorrectly for record members (constructor and property accessor) In-Reply-To: <7C9452AC-67FA-448A-B9BD-BB41EA85948B@oracle.com> References: <94852813-0ea9-ecd2-7052-4766fcea832f@oracle.com> <287A33AB-6775-4521-AE6B-31A530EB2204@oracle.com> <0a2e7d84-46c8-96a5-c8a8-0f1c0ac39272@oracle.com> <7C9452AC-67FA-448A-B9BD-BB41EA85948B@oracle.com> Message-ID: <690f25b5-6ade-faf5-7298-0c9effaa5df4@oracle.com> ok will do before pushing, Thanks, Vicente On 7/9/20 2:34 PM, Paul Sandoz wrote: > Much better! > > Suggest you also remove the duplication > getAnnotatedActualTypeArguments, such as: > > var annoTypeArgs = ((AnnotatedParameterizedType) > annoType).getAnnotatedActualTypeArguments(); > Assert.check(annoTypeArgs.length == 1); > Assert.check(annoTypeArgs[0].getAnnotations()[0] instanceof > TypeAnnotation); > > Up to you, no need for another review. > > Paul. > >> On Jul 9, 2020, at 11:25 AM, Vicente Romero >> > wrote: >> >> Hi Paul, >> >> Thanks for the feedback, I have uploaded another iteration at [1] how >> does it look? >> >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8242529/webrev.01/ >> >> On 7/9/20 12:06 PM, Paul Sandoz wrote: >>> Hi Vicente, >>> >>> The asserts look regular in all four cases, I think :-) If so we can >>> consolidate the check into a single method, off the top of my head: >>> >>> ? RecordComponent recordComponent = >>> RecordNotPreservingNestedTypeAnnotationsTest.class.getRecordComponents()[0]; >>> ? check(recordComponent.getAnnotations(), >>> recordComponent.getAnnotatedType()); >>> >>> ??Method accessor = recordComponent.getAccessor(); >>> check(accessor.getAnnotations(), accessor.getAnnotatedReturnType()); >>> >>> Constructor constructor = >>> RecordNotPreservingNestedTypeAnnotationsTest.class.getConstructor(Callable.class); >>> check(constructor.getParameterAnnotations()[0], >>> constructor.getAnnotatedParameterTypes()[0]); >>> >>> Field field = >>> RecordNotPreservingNestedTypeAnnotationsTest.class.getDeclaredField(recordComponent.getName()); >>> >>> ? check(field.getAnnotations(), field.getAnnotatedType()); >>> ); >>> >>> Does that work? >>> >>> Paul. >>> >>>> On Jul 8, 2020, at 7:31 PM, Vicente Romero >>>> > wrote: >>>> >>>> Hi, >>>> >>>> Please review fix for [1] at [2]. Current record implementation is >>>> not forward nested type annotations to generated members like in: >>>> >>>> record R(@RegularAnnotation @TypeAnnotation Callable<@TypeAnnotation ?> foo) {} >>>> This patch is fixing one issue that show up in two different >>>> generated record members: >>>> ??? - the accessor corresponding to the record component >>>> ??? - the corresponding parameter in the canonical constructor >>>> >>>> The issue is that the current implementation is not able to >>>> correctly generate the annotated types for these components when >>>> such an annotated type has "inner" type annotations like it is the >>>> case of `foo` in the example which has `TypeAnnotation` applied to >>>> the wildcard. In the case of the corresponding parameter in the >>>> canonical constructor the annotated type was generated correctly >>>> but the class file reflected the internal type annotation as >>>> applied to a field not to a method parameter. In the case of the >>>> accessor the inner annotation was not there at all. The patch is >>>> making a copy of the expression defining the type of the record >>>> component and placing it that the right place for both generated >>>> members. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8242529 >>>> [2] http://cr.openjdk.java.net/~vromero/8242529/webrev.00/ >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Jul 9 19:25:44 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 9 Jul 2020 12:25:44 -0700 Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <56a14991-f146-a4ff-fcb1-614fec8715e2@oracle.com> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> <42a1f0d9-64da-cf87-4842-8bf96f0756b0@oracle.com> <1000196621.16339.1594247518109.JavaMail.zimbra@u-pem.fr> <56a14991-f146-a4ff-fcb1-614fec8715e2@oracle.com> Message-ID: <3a7fa431-2d94-376e-fa88-e561ae8f8b1a@oracle.com> On 7/8/2020 5:05 PM, Jonathan Gibbons wrote: > > On 7/8/20 3:31 PM, forax at univ-mlv.fr wrote: >> ----- Mail original ----- >>> [snip] >> I can buy that the concept of empty name is important, following what >> you are saying, length() should be re-abstracted for the exact same >> reason. >> I think i prefer to follow the current implementation of Name that >> explain the concept of empty name in the top level javadoc of Name, >> and fix the sentence "An empty Name has a length of zero." to mention >> isEmpty. > > The concept of 'empty name' could be explained in the class comment > for Name, as R?mi suggests, and enclosed or prefixed by some HTML that > defines an 'id' such as "empty-name" that can be referenced from other > locations, without having to introduce a new method for the concept. > (But, for me, I'm OK either way.) > Following the approach suggested by Jon, here is a version that defines and HTML anchor and does *not* introduce a method override: ??? http://cr.openjdk.java.net/~darcy/8248983.1/ Patch below. I think this is an improvement over the current API and a bit simpler. If others agree, I'll go forward with this change and withdraw the CSR. Thanks for the reviews, -Joe --- old/src/java.compiler/share/classes/javax/lang/model/element/Element.java 2020-07-09 10:40:04.677417445 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/Element.java 2020-07-09 10:40:04.289417445 -0700 @@ -137,7 +137,7 @@ ????? * ????? * If this element represents an unnamed {@linkplain ????? * PackageElement#getSimpleName package} or unnamed {@linkplain -???? * ModuleElement#getSimpleName module}, an empty name is returned. +???? * ModuleElement#getSimpleName module}, an empty name is returned. ????? * ????? * If it represents a {@linkplain ExecutableElement#getSimpleName ????? * constructor}, the name "{@code }" is returned.? If it @@ -146,7 +146,7 @@ ????? * ????? * If it represents an {@linkplain TypeElement#getSimpleName ????? * anonymous class} or {@linkplain ExecutableElement#getSimpleName -???? * instance initializer}, an empty name is returned. +???? * instance initializer}, an empty name is returned. ????? * ????? * @return the simple name of this element ????? * @see PackageElement#getSimpleName --- old/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java 2020-07-09 10:40:05.517417445 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java 2020-07-09 10:40:05.089417445 -0700 @@ -146,7 +146,7 @@ ????? * initializer.? For a constructor, the name {@code ""} is ????? * returned, for a static initializer, the name {@code ""} ????? * is returned, and for an anonymous class or instance -???? * initializer, an empty name is returned. +???? * initializer, an empty name is returned. ????? * ????? * @return the simple name of a constructor, method, or ????? * initializer --- old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2020-07-09 10:40:06.349417445 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2020-07-09 10:40:05.893417445 -0700 @@ -51,7 +51,7 @@ ???? /** ????? * Returns the fully qualified name of this module.? For an -???? * {@linkplain #isUnnamed() unnamed module}, an empty name is returned. +???? * {@linkplain #isUnnamed() unnamed module}, an empty name is returned. ????? * ????? * @apiNote If the module name consists of one identifier, then ????? * this method returns that identifier, which is deemed to be @@ -69,7 +69,7 @@ ???? /** ????? * Returns the simple name of this module.? For an {@linkplain -???? * #isUnnamed() unnamed module}, an empty name is returned. +???? * #isUnnamed() unnamed module}, an empty name is returned. ????? * ????? * @apiNote If the module name consists of one identifier, then ????? * this method returns that identifier.? If the module name --- old/src/java.compiler/share/classes/javax/lang/model/element/Name.java 2020-07-09 10:40:07.253417445 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/Name.java 2020-07-09 10:40:06.785417445 -0700 @@ -33,7 +33,7 @@ ? * implementation are usable in collections while {@code Name}s from ? * different implementations may not work properly in collections. ? * - *

An empty {@code Name} has a length of zero. + *

An {@linkplain CharSequence#isEmpty() empty} {@code Name} has a {@linkplain CharSequence#length() length} of zero. ? * ? *

In the context of {@linkplain ? * javax.annotation.processing.ProcessingEnvironment annotation --- old/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java 2020-07-09 10:40:08.017417445 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java 2020-07-09 10:40:07.617417445 -0700 @@ -53,7 +53,7 @@ ???? /** ????? * Returns the fully qualified name of this package. ????? * This is also known as the package's canonical name. -???? * For an {@linkplain #isUnnamed() unnamed package}, an empty name is returned. +???? * For an {@linkplain #isUnnamed() unnamed package}, an empty name is returned. ????? * ????? * @apiNote The fully qualified name of a named package that is ????? * not a subpackage of a named package is its simple name. The @@ -70,7 +70,7 @@ ???? /** ????? * Returns the simple name of this package.? For an {@linkplain -???? * #isUnnamed() unnamed package}, an empty name is returned. +???? * #isUnnamed() unnamed package}, an empty name is returned. ????? * ????? * @return the simple name of this package or an empty name if ????? * this is an unnamed package --- old/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java 2020-07-09 10:40:08.761417445 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java 2020-07-09 10:40:08.361417445 -0700 @@ -121,7 +121,7 @@ ????? * Returns the fully qualified name of this type element. ????? * More precisely, it returns the canonical name. ????? * For local and anonymous classes, which do not have canonical names, -???? * an empty name is returned. +???? * an empty name is returned. ????? * ????? *

The name of a generic type does not include any reference ????? * to its formal type parameters. @@ -141,7 +141,7 @@ ???? /** ????? * Returns the simple name of this type element. ????? * -???? * For an anonymous class, an empty name is returned. +???? * For an anonymous class, an empty name is returned. ????? * ????? * @return the simple name of this class or interface, ????? * an empty name for an anonymous class From forax at univ-mlv.fr Thu Jul 9 19:30:37 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 9 Jul 2020 21:30:37 +0200 (CEST) Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <3a7fa431-2d94-376e-fa88-e561ae8f8b1a@oracle.com> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> <42a1f0d9-64da-cf87-4842-8bf96f0756b0@oracle.com> <1000196621.16339.1594247518109.JavaMail.zimbra@u-pem.fr> <56a14991-f146-a4ff-fcb1-614fec8715e2@oracle.com> <3a7fa431-2d94-376e-fa88-e561ae8f8b1a@oracle.com> Message-ID: <1516917086.880246.1594323037621.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "joe darcy" > ?: "jonathan gibbons" , "Remi Forax" > Cc: "compiler-dev" > Envoy?: Jeudi 9 Juillet 2020 21:25:44 > Objet: Re: JDK 16 RFR of JDK-8248983: Add Name.isEmpty > On 7/8/2020 5:05 PM, Jonathan Gibbons wrote: >> >> On 7/8/20 3:31 PM, forax at univ-mlv.fr wrote: >>> ----- Mail original ----- >>>> > [snip] > > >>> I can buy that the concept of empty name is important, following what >>> you are saying, length() should be re-abstracted for the exact same >>> reason. >>> I think i prefer to follow the current implementation of Name that >>> explain the concept of empty name in the top level javadoc of Name, >>> and fix the sentence "An empty Name has a length of zero." to mention >>> isEmpty. >> >> The concept of 'empty name' could be explained in the class comment >> for Name, as R?mi suggests, and enclosed or prefixed by some HTML that >> defines an 'id' such as "empty-name" that can be referenced from other >> locations, without having to introduce a new method for the concept. >> (But, for me, I'm OK either way.) >> > > Following the approach suggested by Jon, here is a version that defines > and HTML anchor and does *not* introduce a method override: > > ??? http://cr.openjdk.java.net/~darcy/8248983.1/ > > Patch below. > > I think this is an improvement over the current API and a bit simpler. > If others agree, I'll go forward with this change and withdraw the CSR. Looks good to me :) > > Thanks for the reviews, > > -Joe regards, R?mi > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/Element.java > 2020-07-09 10:40:04.677417445 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/Element.java > 2020-07-09 10:40:04.289417445 -0700 > @@ -137,7 +137,7 @@ > ????? * > ????? * If this element represents an unnamed {@linkplain > ????? * PackageElement#getSimpleName package} or unnamed {@linkplain > -???? * ModuleElement#getSimpleName module}, an empty name is returned. > +???? * ModuleElement#getSimpleName module}, an href=Name.html#empty_name>empty name is returned. > ????? * > ????? * If it represents a {@linkplain ExecutableElement#getSimpleName > ????? * constructor}, the name "{@code }" is returned.? If it > @@ -146,7 +146,7 @@ > ????? * > ????? * If it represents an {@linkplain TypeElement#getSimpleName > ????? * anonymous class} or {@linkplain ExecutableElement#getSimpleName > -???? * instance initializer}, an empty name is returned. > +???? * instance initializer}, an empty > name is returned. > ????? * > ????? * @return the simple name of this element > ????? * @see PackageElement#getSimpleName > --- > old/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java > 2020-07-09 10:40:05.517417445 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java > 2020-07-09 10:40:05.089417445 -0700 > @@ -146,7 +146,7 @@ > ????? * initializer.? For a constructor, the name {@code ""} is > ????? * returned, for a static initializer, the name {@code ""} > ????? * is returned, and for an anonymous class or instance > -???? * initializer, an empty name is returned. > +???? * initializer, an empty name is > returned. > ????? * > ????? * @return the simple name of a constructor, method, or > ????? * initializer > --- > old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java > 2020-07-09 10:40:06.349417445 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java > 2020-07-09 10:40:05.893417445 -0700 > @@ -51,7 +51,7 @@ > > ???? /** > ????? * Returns the fully qualified name of this module.? For an > -???? * {@linkplain #isUnnamed() unnamed module}, an empty name is returned. > +???? * {@linkplain #isUnnamed() unnamed module}, an href=Name.html#empty_name>empty name is returned. > ????? * > ????? * @apiNote If the module name consists of one identifier, then > ????? * this method returns that identifier, which is deemed to be > @@ -69,7 +69,7 @@ > > ???? /** > ????? * Returns the simple name of this module.? For an {@linkplain > -???? * #isUnnamed() unnamed module}, an empty name is returned. > +???? * #isUnnamed() unnamed module}, an href=Name.html#empty_name>empty name is returned. > ????? * > ????? * @apiNote If the module name consists of one identifier, then > ????? * this method returns that identifier.? If the module name > --- > old/src/java.compiler/share/classes/javax/lang/model/element/Name.java > 2020-07-09 10:40:07.253417445 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/Name.java > 2020-07-09 10:40:06.785417445 -0700 > @@ -33,7 +33,7 @@ > ? * implementation are usable in collections while {@code Name}s from > ? * different implementations may not work properly in collections. > ? * > - *

An empty {@code Name} has a length of zero. > + *

An {@linkplain CharSequence#isEmpty() empty} > {@code Name} has a {@linkplain CharSequence#length() length} of zero. > ? * > ? *

In the context of {@linkplain > ? * javax.annotation.processing.ProcessingEnvironment annotation > --- > old/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java > 2020-07-09 10:40:08.017417445 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java > 2020-07-09 10:40:07.617417445 -0700 > @@ -53,7 +53,7 @@ > ???? /** > ????? * Returns the fully qualified name of this package. > ????? * This is also known as the package's canonical name. > -???? * For an {@linkplain #isUnnamed() unnamed package}, an empty name > is returned. > +???? * For an {@linkplain #isUnnamed() unnamed package}, an href=Name.html#empty_name>empty name is returned. > ????? * > ????? * @apiNote The fully qualified name of a named package that is > ????? * not a subpackage of a named package is its simple name. The > @@ -70,7 +70,7 @@ > > ???? /** > ????? * Returns the simple name of this package.? For an {@linkplain > -???? * #isUnnamed() unnamed package}, an empty name is returned. > +???? * #isUnnamed() unnamed package}, an href=Name.html#empty_name>empty name is returned. > ????? * > ????? * @return the simple name of this package or an empty name if > ????? * this is an unnamed package > --- > old/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > 2020-07-09 10:40:08.761417445 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > 2020-07-09 10:40:08.361417445 -0700 > @@ -121,7 +121,7 @@ > ????? * Returns the fully qualified name of this type element. > ????? * More precisely, it returns the canonical name. > ????? * For local and anonymous classes, which do not have canonical names, > -???? * an empty name is returned. > +???? * an empty name is returned. > ????? * > ????? *

The name of a generic type does not include any reference > ????? * to its formal type parameters. > @@ -141,7 +141,7 @@ > ???? /** > ????? * Returns the simple name of this type element. > ????? * > -???? * For an anonymous class, an empty name is returned. > +???? * For an anonymous class, an empty > name is returned. > ????? * > ????? * @return the simple name of this class or interface, > ????? * an empty name for an anonymous class From jonathan.gibbons at oracle.com Thu Jul 9 19:32:29 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 9 Jul 2020 12:32:29 -0700 Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <3a7fa431-2d94-376e-fa88-e561ae8f8b1a@oracle.com> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> <42a1f0d9-64da-cf87-4842-8bf96f0756b0@oracle.com> <1000196621.16339.1594247518109.JavaMail.zimbra@u-pem.fr> <56a14991-f146-a4ff-fcb1-614fec8715e2@oracle.com> <3a7fa431-2d94-376e-fa88-e561ae8f8b1a@oracle.com> Message-ID: <3efc646f-a2aa-7345-b664-56e74b2332ef@oracle.com> Joe, I like this approach. I have one minor suggestion: in the following fragment you could move `id=...` onto the `

` element and then eliminate `` and `` -- Jon On 7/9/20 12:25 PM, Joe Darcy wrote: > > + *

An {@linkplain CharSequence#isEmpty() empty} > {@code Name} has a {@linkplain CharSequence#length() length} of zero. From joe.darcy at oracle.com Thu Jul 9 19:39:30 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 9 Jul 2020 12:39:30 -0700 Subject: JDK 16 RFR of JDK-8248983: Add Name.isEmpty In-Reply-To: <3efc646f-a2aa-7345-b664-56e74b2332ef@oracle.com> References: <90baebf8-92f0-7816-d42a-9146f63497b9@oracle.com> <1241479415.1917551.1594210552626.JavaMail.zimbra@u-pem.fr> <42a1f0d9-64da-cf87-4842-8bf96f0756b0@oracle.com> <1000196621.16339.1594247518109.JavaMail.zimbra@u-pem.fr> <56a14991-f146-a4ff-fcb1-614fec8715e2@oracle.com> <3a7fa431-2d94-376e-fa88-e561ae8f8b1a@oracle.com> <3efc646f-a2aa-7345-b664-56e74b2332ef@oracle.com> Message-ID: <7f88aa13-12ce-7335-912f-82dcfa04c418@oracle.com> Thanks Jon. I'll make this change, double-check the links work, update the copyright and reflow paragraphs before pushing. Cheers, -Joe On 7/9/2020 12:32 PM, Jonathan Gibbons wrote: > Joe, > > I like this approach. I have one minor suggestion: in the following > fragment you could move `id=...` onto the `

` element and then > eliminate `` and `` > > -- Jon > > On 7/9/20 12:25 PM, Joe Darcy wrote: >> >> + *

An {@linkplain CharSequence#isEmpty() >> empty} {@code Name} has a {@linkplain CharSequence#length() length} >> of zero. From andrew_m_leonard at uk.ibm.com Fri Jul 10 08:24:06 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 10 Jul 2020 09:24:06 +0100 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" Message-ID: Hi Vicente, Would you be able to review, perform a submit test and merge this fix please? I am suspecting the intermittent test failure is due to a specific test machine LANG/locale setup, which I know will produce the mentioned failure. I have added setting LANG & LANGUAGE to the test spawned javac Process, which I think should have been set. webrev: http://cr.openjdk.java.net/~aleonard/8249079/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8249079 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Tue Jul 14 10:04:08 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 14 Jul 2020 11:04:08 +0100 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" In-Reply-To: References: Message-ID: Is anyone able to help review and test this please? Can anyone tell me if the problem is still failing? I have been unable to recreate in my environment having run several 100 iterations. I am hoping this webrev might cover the machine specific issue. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: compiler-dev Cc: "Vicente Romero" Date: 10/07/2020 09:24 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" Hi Vicente, Would you be able to review, perform a submit test and merge this fix please? I am suspecting the intermittent test failure is due to a specific test machine LANG/locale setup, which I know will produce the mentioned failure. I have added setting LANG & LANGUAGE to the test spawned javac Process, which I think should have been set. webrev: http://cr.openjdk.java.net/~aleonard/8249079/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8249079 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Jul 14 10:45:50 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 Jul 2020 10:45:50 +0000 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" In-Reply-To: References: Message-ID: Hi Andrew, we?ve had this error in our latest CI builds for Sapmachine/OpenJDK 16: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_x86_64/6/ https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_ppc64le/5/ Furthermore we saw some probably related issue here: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_ppc64/6/ ERROR: Cannot delete workspace :Malformed input or input contains unmappable characters: /home/jenkins/slave-home/workspace/build-16-pr-validation-linux_ppc64/test_report_jdk/JTwork/scratch/0/TestLambdaFileEncodingSerialization$ABC??????.class Error when executing cleanup post condition: hudson.AbortException: Cannot delete workspace: Malformed input or input contains unmappable characters: /home/jenkins/slave-home/workspace/build-16-pr-validation-linux_ppc64/test_report_jdk/JTwork/scratch/0/TestLambdaFileEncodingSerialization$ABC??????.class at hudson.plugins.ws_cleanup.WsCleanup.perform(WsCleanup.java:242) I?m currently retrying to see if we can reproduce this. If so, I?m willing to try your patch? Cheers Christoph From: compiler-dev On Behalf Of Andrew Leonard Sent: Dienstag, 14. Juli 2020 12:04 To: compiler-dev Cc: Vicente Romero Subject: Re: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" Is anyone able to help review and test this please? Can anyone tell me if the problem is still failing? I have been unable to recreate in my environment having run several 100 iterations. I am hoping this webrev might cover the machine specific issue. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: compiler-dev > Cc: "Vicente Romero" > Date: 10/07/2020 09:24 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" ________________________________ Hi Vicente, Would you be able to review, perform a submit test and merge this fix please? I am suspecting the intermittent test failure is due to a specific test machine LANG/locale setup, which I know will produce the mentioned failure. I have added setting LANG & LANGUAGE to the test spawned javac Process, which I think should have been set. webrev: http://cr.openjdk.java.net/~aleonard/8249079/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8249079 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Tue Jul 14 12:26:49 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 14 Jul 2020 13:26:49 +0100 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" In-Reply-To: References: Message-ID: Thanks Christoph, I am fairly sure the problem occurs due to the test spawned javac Process not having the correct LANG encoding to support the UTF-8 class name characters, hence why this patch sets the full set of LC_ALL, LANG and LANGUAGE, as I am suspecting on some machines where the hosting environment might have these set differently. Your Jenkins links are useful thanks. If it is still an issue, then I think I will need to remove the test and re-think how to verify the use case, which we discovered on our z/OS port where the default file encoding is EBCDIC. Appreciate your help Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: "Langer, Christoph" To: Andrew Leonard , compiler-dev Cc: Vicente Romero Date: 14/07/2020 11:46 Subject: [EXTERNAL] RE: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" Hi Andrew, we?ve had this error in our latest CI builds for Sapmachine/OpenJDK 16: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_x86_64/6/ https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_ppc64le/5/ Furthermore we saw some probably related issue here: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_ppc64/6/ ERROR: Cannot delete workspace :Malformed input or input contains unmappable characters: /home/jenkins/slave-home/workspace/build-16-pr-validation-linux_ppc64/test_report_jdk/JTwork/scratch/0/TestLambdaFileEncodingSerialization$ABC ??????.class Error when executing cleanup post condition: hudson.AbortException: Cannot delete workspace: Malformed input or input contains unmappable characters: /home/jenkins/slave-home/workspace/build-16-pr-validation-linux_ppc64/test_report_jdk/JTwork/scratch/0/TestLambdaFileEncodingSerialization$ABC ??????.class at hudson.plugins.ws_cleanup.WsCleanup.perform(WsCleanup.java:242) I?m currently retrying to see if we can reproduce this. If so, I?m willing to try your patch? Cheers Christoph From: compiler-dev On Behalf Of Andrew Leonard Sent: Dienstag, 14. Juli 2020 12:04 To: compiler-dev Cc: Vicente Romero Subject: Re: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" Is anyone able to help review and test this please? Can anyone tell me if the problem is still failing? I have been unable to recreate in my environment having run several 100 iterations. I am hoping this webrev might cover the machine specific issue. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: compiler-dev Cc: "Vicente Romero" Date: 10/07/2020 09:24 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" Hi Vicente, Would you be able to review, perform a submit test and merge this fix please? I am suspecting the intermittent test failure is due to a specific test machine LANG/locale setup, which I know will produce the mentioned failure. I have added setting LANG & LANGUAGE to the test spawned javac Process, which I think should have been set. webrev: http://cr.openjdk.java.net/~aleonard/8249079/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8249079 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Jul 14 12:59:21 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 Jul 2020 12:59:21 +0000 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" In-Reply-To: References: Message-ID: Hi Andrew, hm, I added this commit: https://github.com/SAP/SapMachine/pull/686/commits/0a79573d4a6480f1d2504a5e81580a9142564ced and re-ran our pipeline. Unfortunately it still fails: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_x86_64/8/ I?ll try to take a deeper look. Best regards Christoph From: Andrew Leonard Sent: Dienstag, 14. Juli 2020 14:27 To: Langer, Christoph Cc: compiler-dev ; Vicente Romero Subject: RE: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" Thanks Christoph, I am fairly sure the problem occurs due to the test spawned javac Process not having the correct LANG encoding to support the UTF-8 class name characters, hence why this patch sets the full set of LC_ALL, LANG and LANGUAGE, as I am suspecting on some machines where the hosting environment might have these set differently. Your Jenkins links are useful thanks. If it is still an issue, then I think I will need to remove the test and re-think how to verify the use case, which we discovered on our z/OS port where the default file encoding is EBCDIC. Appreciate your help Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: "Langer, Christoph" > To: Andrew Leonard >, compiler-dev > Cc: Vicente Romero > Date: 14/07/2020 11:46 Subject: [EXTERNAL] RE: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" ________________________________ Hi Andrew, we?ve had this error in our latest CI builds for Sapmachine/OpenJDK 16: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_x86_64/6/ https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_ppc64le/5/ Furthermore we saw some probably related issue here: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-16-pr-validation-linux_ppc64/6/ ERROR: Cannot delete workspace :Malformed input or input contains unmappable characters: /home/jenkins/slave-home/workspace/build-16-pr-validation-linux_ppc64/test_report_jdk/JTwork/scratch/0/TestLambdaFileEncodingSerialization$ABC??????.class Error when executing cleanup post condition: hudson.AbortException: Cannot delete workspace: Malformed input or input contains unmappable characters: /home/jenkins/slave-home/workspace/build-16-pr-validation-linux_ppc64/test_report_jdk/JTwork/scratch/0/TestLambdaFileEncodingSerialization$ABC??????.class at hudson.plugins.ws_cleanup.WsCleanup.perform(WsCleanup.java:242) I?m currently retrying to see if we can reproduce this. If so, I?m willing to try your patch? Cheers Christoph From: compiler-dev > On Behalf Of Andrew Leonard Sent: Dienstag, 14. Juli 2020 12:04 To: compiler-dev > Cc: Vicente Romero > Subject: Re: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" Is anyone able to help review and test this please? Can anyone tell me if the problem is still failing? I have been unable to recreate in my environment having run several 100 iterations. I am hoping this webrev might cover the machine specific issue. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: compiler-dev > Cc: "Vicente Romero" > Date: 10/07/2020 09:24 Subject: RFR: 8249079: LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]" ________________________________ Hi Vicente, Would you be able to review, perform a submit test and merge this fix please? I am suspecting the intermittent test failure is due to a specific test machine LANG/locale setup, which I know will produce the mentioned failure. I have added setting LANG & LANGUAGE to the test spawned javac Process, which I think should have been set. webrev: http://cr.openjdk.java.net/~aleonard/8249079/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8249079 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jul 15 03:04:12 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 14 Jul 2020 23:04:12 -0400 Subject: RFR: JDK-8247790: javac shouldn't allow type variable references from local static declarations In-Reply-To: References: <38331418-c8a5-8f63-b4cc-3ccc66a8138d@oracle.com> <13097ca3-2fed-bcc3-9e63-0f8113c198af@oracle.com> Message-ID: Hi, I have realized of a couple of issues on the last iteration of the patch so I have produced a new one at [1]. How does it look? Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.02/ On 6/29/20 2:53 PM, Vicente Romero wrote: > Hi Jan, > > Thanks for your review, there have been a lot of internal discussion > about the spec and the examples you proposed. Given that this spec is > new, it is hard to see where the lines are. Your examples are good, > thanks, and I have added them as additional tests. I didn't see how to > leverage on the existing "staticOnly" flag. Instead in order to > implement this assertion in the spec see [1]: > > * If the type name appears in a nested class or interface > declaration of /C/, then the immediately enclosing class or > interface declaration of the type name must specify an inner class > (8.1.3 > ) > declared in the body of /m/, or an inner class of an inner class > declared in the body of /m/. > > I added a helper method named: "isInnerClassOfMethod", but this one > still needs the original environment, as an alternative I can pass the > enclosing class relative to the original environment but still, what > do you think? > > Thanks, > Vicente > > [1] > https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-6.5.5.1 > new webrev: http://cr.openjdk.java.net/~vromero/8247790/webrev.01/ > > On 6/23/20 5:12 AM, Jan Lahoda wrote: >> Hi Vicente, >> >> I think this is a good direction, but probably not sufficient. My >> question would be if it is possible to piggy back more on the >> existing "staticOnly" flag, instead of checking the innermost >> environment. >> >> Specifically, consider this example: >> --- >> package javaapplication29; >> >> public class JavaApplication29 { >> >> ??? public static void main(String[] args) { >> ??????? String hello = "hello"; >> ??????? interface I { >> ??????????? public default void test1() { >> ??????????????? class X { >> ??????????????????? public void test2() { >> ??????????????????????? System.err.println(hello); >> ??????????????????????? T t = null; >> ??????????????????? } >> ??????????????? } >> ??????????????? new X().test2(); >> ??????????? } >> ??????? } >> ??????? record R(int i) { >> ??????????? public void test1() { >> ??????????????? class X { >> ??????????????????? public void test2() { >> ??????????????????????? System.err.println(hello); >> ??????????????????????? T t = null; >> ??????????????????? } >> ??????????????? } >> ??????????????? new X().test2(); >> ??????????? } >> ??????? } >> ??????? enum E { >> ??????????? A; >> ??????????? public void test1() { >> ??????????????? class X { >> ??????????????????? public void test2() { >> ??????????????????????? System.err.println(hello); >> ??????????????????????? T t = null; >> ??????????????????? } >> ??????????????? } >> ??????????????? new X().test2(); >> ??????????? } >> ??????? } >> ??????? new I() {}.test1(); >> ??????? new R(0).test1(); >> ??????? E.A.test1(); >> ??? } >> >> } >> --- >> >> The behavior here does not seem to be quite right - there are no >> errors reported, but javac crashes on "E", produces wrong classfile >> for "I" and suspicious (but working) classfile for "R". >> >> Jan >> >> On 23. 06. 20 0:29, Vicente Romero wrote: >>> Hi, >>> >>> Please review the fix for [1] at [2]. The issue here is that local >>> interfaces, enums and records shouldn't be allow to refer to type >>> variables defined in an enclosing context. The compiler was checking >>> for this if the type variables were defined by the enclosing class >>> but references to type variables defined by the enclosing method >>> were allowed. This patch is covering this gap, >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8247790 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jul 15 20:40:58 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 15 Jul 2020 16:40:58 -0400 Subject: RFR: JDK-8247790: javac shouldn't allow type variable references from local static declarations In-Reply-To: References: <38331418-c8a5-8f63-b4cc-3ccc66a8138d@oracle.com> <13097ca3-2fed-bcc3-9e63-0f8113c198af@oracle.com> Message-ID: <141099be-6568-48cd-8359-223f3c3042a4@oracle.com> Hi Jan, I have updated the patch and added more tests after our offline chat, please see [1]. How does it look? Vicente [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.03/ On 7/14/20 11:04 PM, Vicente Romero wrote: > Hi, > > I have realized of a couple of issues on the last iteration of the > patch so I have produced a new one at [1]. How does it look? > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.02/ > > On 6/29/20 2:53 PM, Vicente Romero wrote: >> Hi Jan, >> >> Thanks for your review, there have been a lot of internal discussion >> about the spec and the examples you proposed. Given that this spec is >> new, it is hard to see where the lines are. Your examples are good, >> thanks, and I have added them as additional tests. I didn't see how >> to leverage on the existing "staticOnly" flag. Instead in order to >> implement this assertion in the spec see [1]: >> >> * If the type name appears in a nested class or interface >> declaration of /C/, then the immediately enclosing class or >> interface declaration of the type name must specify an inner >> class (8.1.3 >> ) >> declared in the body of /m/, or an inner class of an inner class >> declared in the body of /m/. >> >> I added a helper method named: "isInnerClassOfMethod", but this one >> still needs the original environment, as an alternative I can pass >> the enclosing class relative to the original environment but still, >> what do you think? >> >> Thanks, >> Vicente >> >> [1] >> https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-6.5.5.1 >> new webrev: http://cr.openjdk.java.net/~vromero/8247790/webrev.01/ >> >> On 6/23/20 5:12 AM, Jan Lahoda wrote: >>> Hi Vicente, >>> >>> I think this is a good direction, but probably not sufficient. My >>> question would be if it is possible to piggy back more on the >>> existing "staticOnly" flag, instead of checking the innermost >>> environment. >>> >>> Specifically, consider this example: >>> --- >>> package javaapplication29; >>> >>> public class JavaApplication29 { >>> >>> ??? public static void main(String[] args) { >>> ??????? String hello = "hello"; >>> ??????? interface I { >>> ??????????? public default void test1() { >>> ??????????????? class X { >>> ??????????????????? public void test2() { >>> ??????????????????????? System.err.println(hello); >>> ??????????????????????? T t = null; >>> ??????????????????? } >>> ??????????????? } >>> ??????????????? new X().test2(); >>> ??????????? } >>> ??????? } >>> ??????? record R(int i) { >>> ??????????? public void test1() { >>> ??????????????? class X { >>> ??????????????????? public void test2() { >>> ??????????????????????? System.err.println(hello); >>> ??????????????????????? T t = null; >>> ??????????????????? } >>> ??????????????? } >>> ??????????????? new X().test2(); >>> ??????????? } >>> ??????? } >>> ??????? enum E { >>> ??????????? A; >>> ??????????? public void test1() { >>> ??????????????? class X { >>> ??????????????????? public void test2() { >>> ??????????????????????? System.err.println(hello); >>> ??????????????????????? T t = null; >>> ??????????????????? } >>> ??????????????? } >>> ??????????????? new X().test2(); >>> ??????????? } >>> ??????? } >>> ??????? new I() {}.test1(); >>> ??????? new R(0).test1(); >>> ??????? E.A.test1(); >>> ??? } >>> >>> } >>> --- >>> >>> The behavior here does not seem to be quite right - there are no >>> errors reported, but javac crashes on "E", produces wrong classfile >>> for "I" and suspicious (but working) classfile for "R". >>> >>> Jan >>> >>> On 23. 06. 20 0:29, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review the fix for [1] at [2]. The issue here is that local >>>> interfaces, enums and records shouldn't be allow to refer to type >>>> variables defined in an enclosing context. The compiler was >>>> checking for this if the type variables were defined by the >>>> enclosing class but references to type variables defined by the >>>> enclosing method were allowed. This patch is covering this gap, >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.00/ >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8247790 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jul 15 20:50:09 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 15 Jul 2020 22:50:09 +0200 Subject: RFR: JDK-8247790: javac shouldn't allow type variable references from local static declarations In-Reply-To: <141099be-6568-48cd-8359-223f3c3042a4@oracle.com> References: <38331418-c8a5-8f63-b4cc-3ccc66a8138d@oracle.com> <13097ca3-2fed-bcc3-9e63-0f8113c198af@oracle.com> <141099be-6568-48cd-8359-223f3c3042a4@oracle.com> Message-ID: <5f676ac2-dd63-8416-2e0f-84eb23f0c57e@oracle.com> Looks good to me. Thanks for updating the patch! Jan On 15. 07. 20 22:40, Vicente Romero wrote: > Hi Jan, > > I have updated the patch and added more tests after our offline chat, > please see [1]. How does it look? > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.03/ > > On 7/14/20 11:04 PM, Vicente Romero wrote: >> Hi, >> >> I have realized of a couple of issues on the last iteration of the >> patch so I have produced a new one at [1]. How does it look? >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.02/ >> >> On 6/29/20 2:53 PM, Vicente Romero wrote: >>> Hi Jan, >>> >>> Thanks for your review, there have been a lot of internal discussion >>> about the spec and the examples you proposed. Given that this spec is >>> new, it is hard to see where the lines are. Your examples are good, >>> thanks, and I have added them as additional tests. I didn't see how >>> to leverage on the existing "staticOnly" flag. Instead in order to >>> implement this assertion in the spec see [1]: >>> >>> * If the type name appears in a nested class or interface >>> declaration of /C/, then the immediately enclosing class or >>> interface declaration of the type name must specify an inner >>> class (8.1.3 >>> ) >>> declared in the body of /m/, or an inner class of an inner class >>> declared in the body of /m/. >>> >>> I added a helper method named: "isInnerClassOfMethod", but this one >>> still needs the original environment, as an alternative I can pass >>> the enclosing class relative to the original environment but still, >>> what do you think? >>> >>> Thanks, >>> Vicente >>> >>> [1] >>> https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-6.5.5.1 >>> new webrev: http://cr.openjdk.java.net/~vromero/8247790/webrev.01/ >>> >>> On 6/23/20 5:12 AM, Jan Lahoda wrote: >>>> Hi Vicente, >>>> >>>> I think this is a good direction, but probably not sufficient. My >>>> question would be if it is possible to piggy back more on the >>>> existing "staticOnly" flag, instead of checking the innermost >>>> environment. >>>> >>>> Specifically, consider this example: >>>> --- >>>> package javaapplication29; >>>> >>>> public class JavaApplication29 { >>>> >>>> ??? public static void main(String[] args) { >>>> ??????? String hello = "hello"; >>>> ??????? interface I { >>>> ??????????? public default void test1() { >>>> ??????????????? class X { >>>> ??????????????????? public void test2() { >>>> ??????????????????????? System.err.println(hello); >>>> ??????????????????????? T t = null; >>>> ??????????????????? } >>>> ??????????????? } >>>> ??????????????? new X().test2(); >>>> ??????????? } >>>> ??????? } >>>> ??????? record R(int i) { >>>> ??????????? public void test1() { >>>> ??????????????? class X { >>>> ??????????????????? public void test2() { >>>> ??????????????????????? System.err.println(hello); >>>> ??????????????????????? T t = null; >>>> ??????????????????? } >>>> ??????????????? } >>>> ??????????????? new X().test2(); >>>> ??????????? } >>>> ??????? } >>>> ??????? enum E { >>>> ??????????? A; >>>> ??????????? public void test1() { >>>> ??????????????? class X { >>>> ??????????????????? public void test2() { >>>> ??????????????????????? System.err.println(hello); >>>> ??????????????????????? T t = null; >>>> ??????????????????? } >>>> ??????????????? } >>>> ??????????????? new X().test2(); >>>> ??????????? } >>>> ??????? } >>>> ??????? new I() {}.test1(); >>>> ??????? new R(0).test1(); >>>> ??????? E.A.test1(); >>>> ??? } >>>> >>>> } >>>> --- >>>> >>>> The behavior here does not seem to be quite right - there are no >>>> errors reported, but javac crashes on "E", produces wrong classfile >>>> for "I" and suspicious (but working) classfile for "R". >>>> >>>> Jan >>>> >>>> On 23. 06. 20 0:29, Vicente Romero wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for [1] at [2]. The issue here is that local >>>>> interfaces, enums and records shouldn't be allow to refer to type >>>>> variables defined in an enclosing context. The compiler was >>>>> checking for this if the type variables were defined by the >>>>> enclosing class but references to type variables defined by the >>>>> enclosing method were allowed. This patch is covering this gap, >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.00/ >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8247790 >>> >> > From vicente.romero at oracle.com Wed Jul 15 20:51:35 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 15 Jul 2020 16:51:35 -0400 Subject: RFR: JDK-8247790: javac shouldn't allow type variable references from local static declarations In-Reply-To: <5f676ac2-dd63-8416-2e0f-84eb23f0c57e@oracle.com> References: <38331418-c8a5-8f63-b4cc-3ccc66a8138d@oracle.com> <13097ca3-2fed-bcc3-9e63-0f8113c198af@oracle.com> <141099be-6568-48cd-8359-223f3c3042a4@oracle.com> <5f676ac2-dd63-8416-2e0f-84eb23f0c57e@oracle.com> Message-ID: thanks for the reviews Vicente On 7/15/20 4:50 PM, Jan Lahoda wrote: > Looks good to me. Thanks for updating the patch! > > Jan > > On 15. 07. 20 22:40, Vicente Romero wrote: >> Hi Jan, >> >> I have updated the patch and added more tests after our offline chat, >> please see [1]. How does it look? >> >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.03/ >> >> On 7/14/20 11:04 PM, Vicente Romero wrote: >>> Hi, >>> >>> I have realized of a couple of issues on the last iteration of the >>> patch so I have produced a new one at [1]. How does it look? >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.02/ >>> >>> On 6/29/20 2:53 PM, Vicente Romero wrote: >>>> Hi Jan, >>>> >>>> Thanks for your review, there have been a lot of internal >>>> discussion about the spec and the examples you proposed. Given that >>>> this spec is new, it is hard to see where the lines are. Your >>>> examples are good, thanks, and I have added them as additional >>>> tests. I didn't see how to leverage on the existing "staticOnly" >>>> flag. Instead in order to implement this assertion in the spec see >>>> [1]: >>>> >>>> ? * If the type name appears in a nested class or interface >>>> ??? declaration of /C/, then the immediately enclosing class or >>>> ??? interface declaration of the type name must specify an inner >>>> ??? class (8.1.3 >>>> ) >>>> ??? declared in the body of /m/, or an inner class of an inner class >>>> ??? declared in the body of /m/. >>>> >>>> I added a helper method named: "isInnerClassOfMethod", but this one >>>> still needs the original environment, as an alternative I can pass >>>> the enclosing class relative to the original environment but still, >>>> what do you think? >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] >>>> https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-6.5.5.1 >>>> new webrev: http://cr.openjdk.java.net/~vromero/8247790/webrev.01/ >>>> >>>> On 6/23/20 5:12 AM, Jan Lahoda wrote: >>>>> Hi Vicente, >>>>> >>>>> I think this is a good direction, but probably not sufficient. My >>>>> question would be if it is possible to piggy back more on the >>>>> existing "staticOnly" flag, instead of checking the innermost >>>>> environment. >>>>> >>>>> Specifically, consider this example: >>>>> --- >>>>> package javaapplication29; >>>>> >>>>> public class JavaApplication29 { >>>>> >>>>> ??? public static void main(String[] args) { >>>>> ??????? String hello = "hello"; >>>>> ??????? interface I { >>>>> ??????????? public default void test1() { >>>>> ??????????????? class X { >>>>> ??????????????????? public void test2() { >>>>> ??????????????????????? System.err.println(hello); >>>>> ??????????????????????? T t = null; >>>>> ??????????????????? } >>>>> ??????????????? } >>>>> ??????????????? new X().test2(); >>>>> ??????????? } >>>>> ??????? } >>>>> ??????? record R(int i) { >>>>> ??????????? public void test1() { >>>>> ??????????????? class X { >>>>> ??????????????????? public void test2() { >>>>> ??????????????????????? System.err.println(hello); >>>>> ??????????????????????? T t = null; >>>>> ??????????????????? } >>>>> ??????????????? } >>>>> ??????????????? new X().test2(); >>>>> ??????????? } >>>>> ??????? } >>>>> ??????? enum E { >>>>> ??????????? A; >>>>> ??????????? public void test1() { >>>>> ??????????????? class X { >>>>> ??????????????????? public void test2() { >>>>> ??????????????????????? System.err.println(hello); >>>>> ??????????????????????? T t = null; >>>>> ??????????????????? } >>>>> ??????????????? } >>>>> ??????????????? new X().test2(); >>>>> ??????????? } >>>>> ??????? } >>>>> ??????? new I() {}.test1(); >>>>> ??????? new R(0).test1(); >>>>> ??????? E.A.test1(); >>>>> ??? } >>>>> >>>>> } >>>>> --- >>>>> >>>>> The behavior here does not seem to be quite right - there are no >>>>> errors reported, but javac crashes on "E", produces wrong >>>>> classfile for "I" and suspicious (but working) classfile for "R". >>>>> >>>>> Jan >>>>> >>>>> On 23. 06. 20 0:29, Vicente Romero wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix for [1] at [2]. The issue here is that >>>>>> local interfaces, enums and records shouldn't be allow to refer >>>>>> to type variables defined in an enclosing context. The compiler >>>>>> was checking for this if the type variables were defined by the >>>>>> enclosing class but references to type variables defined by the >>>>>> enclosing method were allowed. This patch is covering this gap, >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.00/ >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8247790 >>>> >>> >> From jan.lahoda at oracle.com Thu Jul 16 12:57:10 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 16 Jul 2020 14:57:10 +0200 Subject: RFR: JDK-8249261: AssertionError in StructuralStuckChecker Message-ID: Hi, For (erroneous) code like: p(T::t ? 1 : 0); there is a failed assert in DeferredAttr.DeferredAttrNode.StructuralStuckChecker.visitReference: Assert.checkNonNull(tree.getOverloadKind()); The given JCMemberReference (for "T::t") does not have an overload kind set. This is because it never goes through ArgumentAttr, as the target type is known. I suspect a reasonable solution is for the StructuralStuckChecker to not run on conditions in the conditional expression, which is what the proposed patch is doing. But ideas for a better solution are welcome. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8249261/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8249261 What do you think? Thanks, Jan From maurizio.cimadamore at oracle.com Thu Jul 16 13:20:26 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 16 Jul 2020 14:20:26 +0100 Subject: RFR: JDK-8249261: AssertionError in StructuralStuckChecker In-Reply-To: References: Message-ID: <79b9db51-dda9-d5ee-b334-c0a3ef684eb4@oracle.com> This is a fine fix, I'd suggest adding a comment which explains the need for the override (e.g. skip over condition) or it might look cryptic in few months. No need for another review. Maurizio On 16/07/2020 13:57, Jan Lahoda wrote: > Hi, > > For (erroneous) code like: > p(T::t ? 1 : 0); > > there is a failed assert in > DeferredAttr.DeferredAttrNode.StructuralStuckChecker.visitReference: > Assert.checkNonNull(tree.getOverloadKind()); > > The given JCMemberReference (for "T::t") does not have an overload > kind set. This is because it never goes through ArgumentAttr, as the > target type is known. > > I suspect a reasonable solution is for the StructuralStuckChecker to > not run on conditions in the conditional expression, which is what the > proposed patch is doing. But ideas for a better solution are welcome. > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8249261/webrev.00/index.html > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8249261 > > What do you think? > > Thanks, > ??? Jan From joe.darcy at oracle.com Fri Jul 17 02:07:36 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Jul 2020 19:07:36 -0700 Subject: JDK 16 RFR of JDK-8249632: remove no-arg constructor from ToolProvider Message-ID: <5def3fed-c708-5109-b712-766532d84d08@oracle.com> Hello, Please review the removal of a deprecated-for-removal constructor: ??? JDK-8249632: remove no-arg constructor from ToolProvider ??? webrev: http://cr.openjdk.java.net/~darcy/8249632.0/ ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249644 Patch below; thanks, -Joe --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java 2020-07-16 18:59:58.685000000 -0700 +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java 2020-07-16 18:59:58.025000000 -0700 @@ -45,12 +45,6 @@ ???? private static final String systemJavaCompilerName?? = "com.sun.tools.javac.api.JavacTool"; ???? /** -???? * Do not call. -???? */ -??? @Deprecated(forRemoval=true, since="14") -??? public ToolProvider() {} - -??? /** ????? * Returns the Java programming language compiler provided ????? * with this platform. ????? *

The file manager returned by calling From joe.darcy at oracle.com Fri Jul 17 02:08:30 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Jul 2020 19:08:30 -0700 Subject: JDK 16 RFR of JDK-8249632: remove no-arg constructor from ToolProvider In-Reply-To: <5def3fed-c708-5109-b712-766532d84d08@oracle.com> References: <5def3fed-c708-5109-b712-766532d84d08@oracle.com> Message-ID: <1b5717b0-564d-0d74-8ee5-32e1e2a2907d@oracle.com> PS Clean build and langtools regression test run with the constructor removed. -Joe On 7/16/2020 7:07 PM, Joe Darcy wrote: > Hello, > > Please review the removal of a deprecated-for-removal constructor: > > ??? JDK-8249632: remove no-arg constructor from ToolProvider > ??? webrev: http://cr.openjdk.java.net/~darcy/8249632.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249644 > > Patch below; thanks, > > -Joe > > --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java > 2020-07-16 18:59:58.685000000 -0700 > +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java > 2020-07-16 18:59:58.025000000 -0700 > @@ -45,12 +45,6 @@ > ???? private static final String systemJavaCompilerName?? = > "com.sun.tools.javac.api.JavacTool"; > > ???? /** > -???? * Do not call. > -???? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public ToolProvider() {} > - > -??? /** > ????? * Returns the Java programming language compiler provided > ????? * with this platform. > ????? *

The file manager returned by calling > From jonathan.gibbons at oracle.com Fri Jul 17 02:52:51 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 16 Jul 2020 19:52:51 -0700 Subject: JDK 16 RFR of JDK-8249632: remove no-arg constructor from ToolProvider In-Reply-To: <5def3fed-c708-5109-b712-766532d84d08@oracle.com> References: <5def3fed-c708-5109-b712-766532d84d08@oracle.com> Message-ID: I'm surprised you're removing it like that: won't it just come back as a default constructor? Don't you just want to make it private to make it disappear from the public API? -- Jon On 7/16/20 7:07 PM, Joe Darcy wrote: > Hello, > > Please review the removal of a deprecated-for-removal constructor: > > ??? JDK-8249632: remove no-arg constructor from ToolProvider > ??? webrev: http://cr.openjdk.java.net/~darcy/8249632.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249644 > > Patch below; thanks, > > -Joe > > --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java > 2020-07-16 18:59:58.685000000 -0700 > +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java > 2020-07-16 18:59:58.025000000 -0700 > @@ -45,12 +45,6 @@ > ???? private static final String systemJavaCompilerName?? = > "com.sun.tools.javac.api.JavacTool"; > > ???? /** > -???? * Do not call. > -???? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public ToolProvider() {} > - > -??? /** > ????? * Returns the Java programming language compiler provided > ????? * with this platform. > ????? *

The file manager returned by calling > From joe.darcy at oracle.com Fri Jul 17 04:52:57 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Jul 2020 21:52:57 -0700 Subject: JDK 16 RFR of JDK-8249632: remove no-arg constructor from ToolProvider In-Reply-To: References: <5def3fed-c708-5109-b712-766532d84d08@oracle.com> Message-ID: <7c1644a5-4995-bb11-55c8-bb5eec076cf3@oracle.com> *sigh* Yes, you're right -- I'll redo the fix making the constructor private. I'll have to try to get that -Xlint warning about default constructors into javac one of these releases! -Joe On 7/16/2020 7:52 PM, Jonathan Gibbons wrote: > I'm surprised you're removing it like that: won't it just come back as > a default constructor? > > Don't you just want to make it private to make it disappear from the > public API? > > -- Jon > > On 7/16/20 7:07 PM, Joe Darcy wrote: >> Hello, >> >> Please review the removal of a deprecated-for-removal constructor: >> >> ??? JDK-8249632: remove no-arg constructor from ToolProvider >> ??? webrev: http://cr.openjdk.java.net/~darcy/8249632.0/ >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249644 >> >> Patch below; thanks, >> >> -Joe >> >> --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java >> 2020-07-16 18:59:58.685000000 -0700 >> +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java >> 2020-07-16 18:59:58.025000000 -0700 >> @@ -45,12 +45,6 @@ >> ???? private static final String systemJavaCompilerName?? = >> "com.sun.tools.javac.api.JavacTool"; >> >> ???? /** >> -???? * Do not call. >> -???? */ >> -??? @Deprecated(forRemoval=true, since="14") >> -??? public ToolProvider() {} >> - >> -??? /** >> ????? * Returns the Java programming language compiler provided >> ????? * with this platform. >> ????? *

The file manager returned by calling >> From vicente.romero at oracle.com Fri Jul 17 15:15:52 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 17 Jul 2020 11:15:52 -0400 Subject: RFR: JDK-8245652: some tests at RecordCompilationTests are resetting the wrong compilation options Message-ID: <011e2ca9-4101-a877-8029-e2240586bcd6@oracle.com> Please review this simple fix for [1] at [2]. Test RecordCompilationTests is executed twice with and without a simple annotation processor. This is because some record code is only stressed if an annotation processor is present. But some individual tests were changing the compilation options individually without resetting them to its previous value. This patch is fixing that, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8245652 [2] http://cr.openjdk.java.net/~vromero/8245652/webrev.00 From joe.darcy at oracle.com Fri Jul 17 17:31:40 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 17 Jul 2020 10:31:40 -0700 Subject: JDK 16 RFR of JDK-8249632: remove no-arg constructor from ToolProvider In-Reply-To: <7c1644a5-4995-bb11-55c8-bb5eec076cf3@oracle.com> References: <5def3fed-c708-5109-b712-766532d84d08@oracle.com> <7c1644a5-4995-bb11-55c8-bb5eec076cf3@oracle.com> Message-ID: <081c9966-1ee3-433d-9479-47fa5f0c396f@oracle.com> Update ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249644 ??? webrev: http://cr.openjdk.java.net/~darcy/8249632.1/ and patch below. Build and langtools regression test still pass. Thanks, -Joe --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java 2020-07-17 10:26:50.446004000 -0700 +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java 2020-07-17 10:26:49.794004000 -0700 @@ -44,11 +44,7 @@ ???? private static final String systemJavaCompilerModule = "jdk.compiler"; ???? private static final String systemJavaCompilerName?? = "com.sun.tools.javac.api.JavacTool"; -??? /** -???? * Do not call. -???? */ -??? @Deprecated(forRemoval=true, since="14") -??? public ToolProvider() {} +??? private ToolProvider() {} ???? /** ????? * Returns the Java programming language compiler provided On 7/16/2020 9:52 PM, Joe Darcy wrote: > *sigh* Yes, you're right -- I'll redo the fix making the constructor > private. I'll have to try to get that -Xlint warning about default > constructors into javac one of these releases! > > -Joe > > On 7/16/2020 7:52 PM, Jonathan Gibbons wrote: >> I'm surprised you're removing it like that: won't it just come back >> as a default constructor? >> >> Don't you just want to make it private to make it disappear from the >> public API? >> >> -- Jon >> >> On 7/16/20 7:07 PM, Joe Darcy wrote: >>> Hello, >>> >>> Please review the removal of a deprecated-for-removal constructor: >>> >>> ??? JDK-8249632: remove no-arg constructor from ToolProvider >>> ??? webrev: http://cr.openjdk.java.net/~darcy/8249632.0/ >>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249644 >>> >>> Patch below; thanks, >>> >>> -Joe >>> >>> --- >>> old/src/java.compiler/share/classes/javax/tools/ToolProvider.java >>> 2020-07-16 18:59:58.685000000 -0700 >>> +++ >>> new/src/java.compiler/share/classes/javax/tools/ToolProvider.java >>> 2020-07-16 18:59:58.025000000 -0700 >>> @@ -45,12 +45,6 @@ >>> ???? private static final String systemJavaCompilerName?? = >>> "com.sun.tools.javac.api.JavacTool"; >>> >>> ???? /** >>> -???? * Do not call. >>> -???? */ >>> -??? @Deprecated(forRemoval=true, since="14") >>> -??? public ToolProvider() {} >>> - >>> -??? /** >>> ????? * Returns the Java programming language compiler provided >>> ????? * with this platform. >>> ????? *

The file manager returned by calling >>> From joe.darcy at oracle.com Fri Jul 17 19:33:27 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 17 Jul 2020 12:33:27 -0700 Subject: RFR: JDK-8245652: some tests at RecordCompilationTests are resetting the wrong compilation options In-Reply-To: <011e2ca9-4101-a877-8029-e2240586bcd6@oracle.com> References: <011e2ca9-4101-a877-8029-e2240586bcd6@oracle.com> Message-ID: <0210df8c-0829-e2d7-7f07-752fc6b96d81@oracle.com> Looks fine; cheers, -Joe On 7/17/2020 8:15 AM, Vicente Romero wrote: > Please review this simple fix for [1] at [2]. Test > RecordCompilationTests is executed twice with and without a simple > annotation processor. This is because some record code is only > stressed if an annotation processor is present. But some individual > tests were changing the compilation options individually without > resetting them to its previous value. This patch is fixing that, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8245652 > [2] http://cr.openjdk.java.net/~vromero/8245652/webrev.00 From vicente.romero at oracle.com Fri Jul 17 19:36:24 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 17 Jul 2020 15:36:24 -0400 Subject: RFR: JDK-8243057: compilation of annotated static record fields fails with NPE Message-ID: <37080e07-13bb-82f7-ae1e-b43287e00251@oracle.com> Please review fix for [1] at [2]. At method Check::validateAnnotation the condition used to determine if a field is or not a record field was wrong. As a consequence static fields were considered as record fields. This doesn't have any consequence unless they are annotated. This patch is fixing this issue. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8243057 [2] http://cr.openjdk.java.net/~vromero/8243057/webrev.00/ From jonathan.gibbons at oracle.com Fri Jul 17 23:23:17 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 17 Jul 2020 16:23:17 -0700 Subject: JDK 16 RFR of JDK-8249632: remove no-arg constructor from ToolProvider In-Reply-To: <081c9966-1ee3-433d-9479-47fa5f0c396f@oracle.com> References: <5def3fed-c708-5109-b712-766532d84d08@oracle.com> <7c1644a5-4995-bb11-55c8-bb5eec076cf3@oracle.com> <081c9966-1ee3-433d-9479-47fa5f0c396f@oracle.com> Message-ID: +1 On 7/17/20 10:31 AM, Joe Darcy wrote: > Update > > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249644 > ??? webrev: http://cr.openjdk.java.net/~darcy/8249632.1/ > > and patch below. Build and langtools regression test still pass. > > Thanks, > > -Joe > > --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java > 2020-07-17 10:26:50.446004000 -0700 > +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java > 2020-07-17 10:26:49.794004000 -0700 > @@ -44,11 +44,7 @@ > ???? private static final String systemJavaCompilerModule = > "jdk.compiler"; > ???? private static final String systemJavaCompilerName?? = > "com.sun.tools.javac.api.JavacTool"; > > -??? /** > -???? * Do not call. > -???? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public ToolProvider() {} > +??? private ToolProvider() {} > > ???? /** > ????? * Returns the Java programming language compiler provided > > > On 7/16/2020 9:52 PM, Joe Darcy wrote: >> *sigh* Yes, you're right -- I'll redo the fix making the constructor >> private. I'll have to try to get that -Xlint warning about default >> constructors into javac one of these releases! >> >> -Joe >> >> On 7/16/2020 7:52 PM, Jonathan Gibbons wrote: >>> I'm surprised you're removing it like that: won't it just come back >>> as a default constructor? >>> >>> Don't you just want to make it private to make it disappear from the >>> public API? >>> >>> -- Jon >>> >>> On 7/16/20 7:07 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> Please review the removal of a deprecated-for-removal constructor: >>>> >>>> ??? JDK-8249632: remove no-arg constructor from ToolProvider >>>> ??? webrev: http://cr.openjdk.java.net/~darcy/8249632.0/ >>>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8249644 >>>> >>>> Patch below; thanks, >>>> >>>> -Joe >>>> >>>> --- >>>> old/src/java.compiler/share/classes/javax/tools/ToolProvider.java >>>> 2020-07-16 18:59:58.685000000 -0700 >>>> +++ >>>> new/src/java.compiler/share/classes/javax/tools/ToolProvider.java >>>> 2020-07-16 18:59:58.025000000 -0700 >>>> @@ -45,12 +45,6 @@ >>>> ???? private static final String systemJavaCompilerName?? = >>>> "com.sun.tools.javac.api.JavacTool"; >>>> >>>> ???? /** >>>> -???? * Do not call. >>>> -???? */ >>>> -??? @Deprecated(forRemoval=true, since="14") >>>> -??? public ToolProvider() {} >>>> - >>>> -??? /** >>>> ????? * Returns the Java programming language compiler provided >>>> ????? * with this platform. >>>> ????? *

The file manager returned by calling >>>> From fw at deneb.enyo.de Sun Jul 19 08:01:46 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 19 Jul 2020 10:01:46 +0200 Subject: Invalid symbolic links on the module source path Message-ID: <87a6zwndat.fsf@mid.deneb.enyo.de> Emacs creates dangling symbolic links while source files are edited, as a form of lock file. These have names of the form ".#Main.java" (for a source file called Main.java). Should javac skip reading these non-source files, based on their name? Presently, javac attempts to open these files and reports an error, terminating the compilation. (I wonder if there is a reasonably straightforward way to work around this using a JavaFileManager.) From adinn at redhat.com Sun Jul 19 08:48:29 2020 From: adinn at redhat.com (Andrew Dinn) Date: Sun, 19 Jul 2020 09:48:29 +0100 Subject: Invalid symbolic links on the module source path In-Reply-To: <87a6zwndat.fsf@mid.deneb.enyo.de> References: <87a6zwndat.fsf@mid.deneb.enyo.de> Message-ID: <20a3dacf-3ead-ff80-9346-9214b9efe7e4@redhat.com> On 19/07/2020 09:01, Florian Weimer wrote: > Emacs creates dangling symbolic links while source files are edited, > as a form of lock file. These have names of the form ".#Main.java" > (for a source file called Main.java). Should javac skip reading these > non-source files, based on their name? > > Presently, javac attempts to open these files and reports an error, > terminating the compilation. > > (I wonder if there is a reasonably straightforward way to work around > this using a JavaFileManager.) I actually like this behaviour because it stops me rebuilding whren I have unsaved edits to JDK sources (n.b. the JVM build also fails if it picks up one of these files via a wildcard substitution). So ... it's not a bug it's a feature -- and quite a useful one as far as I am concerned ;-) regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From fw at deneb.enyo.de Sun Jul 19 09:52:22 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 19 Jul 2020 11:52:22 +0200 Subject: Invalid symbolic links on the module source path In-Reply-To: <20a3dacf-3ead-ff80-9346-9214b9efe7e4@redhat.com> (Andrew Dinn's message of "Sun, 19 Jul 2020 09:48:29 +0100") References: <87a6zwndat.fsf@mid.deneb.enyo.de> <20a3dacf-3ead-ff80-9346-9214b9efe7e4@redhat.com> Message-ID: <871rl7omqx.fsf@mid.deneb.enyo.de> * Andrew Dinn: > On 19/07/2020 09:01, Florian Weimer wrote: >> Emacs creates dangling symbolic links while source files are edited, >> as a form of lock file. These have names of the form ".#Main.java" >> (for a source file called Main.java). Should javac skip reading these >> non-source files, based on their name? >> >> Presently, javac attempts to open these files and reports an error, >> terminating the compilation. >> >> (I wonder if there is a reasonably straightforward way to work around >> this using a JavaFileManager.) > > I actually like this behaviour because it stops me rebuilding whren I > have unsaved edits to JDK sources (n.b. the JVM build also fails if it > picks up one of these files via a wildcard substitution). > > So ... it's not a bug it's a feature -- and quite a useful one as far as > I am concerned ;-) That's actually a good point. I was triggering rebuilds once .#*.java files popped up. Those rebuilds obviously fail all the time. Once I started ignore .#* files in the change detection logic, the experience is actually fairly pleasant. From jonathan.gibbons at oracle.com Sun Jul 19 16:57:15 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 19 Jul 2020 09:57:15 -0700 Subject: Invalid symbolic links on the module source path In-Reply-To: <871rl7omqx.fsf@mid.deneb.enyo.de> References: <87a6zwndat.fsf@mid.deneb.enyo.de> <20a3dacf-3ead-ff80-9346-9214b9efe7e4@redhat.com> <871rl7omqx.fsf@mid.deneb.enyo.de> Message-ID: <24de4bd6-42ac-aa37-efe6-8711d327f1ef@oracle.com> Florian, Andrew, I see this conversation, but it sounds like there's no javac action required at this point. If there were to be action, it may be appropriate to have the file manager ignore non-identifier file names by default. -- Jon On 7/19/20 2:52 AM, Florian Weimer wrote: > * Andrew Dinn: > >> On 19/07/2020 09:01, Florian Weimer wrote: >>> Emacs creates dangling symbolic links while source files are edited, >>> as a form of lock file. These have names of the form ".#Main.java" >>> (for a source file called Main.java). Should javac skip reading these >>> non-source files, based on their name? >>> >>> Presently, javac attempts to open these files and reports an error, >>> terminating the compilation. >>> >>> (I wonder if there is a reasonably straightforward way to work around >>> this using a JavaFileManager.) >> I actually like this behaviour because it stops me rebuilding whren I >> have unsaved edits to JDK sources (n.b. the JVM build also fails if it >> picks up one of these files via a wildcard substitution). >> >> So ... it's not a bug it's a feature -- and quite a useful one as far as >> I am concerned ;-) > That's actually a good point. I was triggering rebuilds once .#*.java > files popped up. Those rebuilds obviously fail all the time. Once I > started ignore .#* files in the change detection logic, the experience > is actually fairly pleasant. From vicente.romero at oracle.com Mon Jul 20 16:53:02 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 20 Jul 2020 12:53:02 -0400 Subject: RFR: JDK-8243057: compilation of annotated static record fields fails with NPE In-Reply-To: <37080e07-13bb-82f7-ae1e-b43287e00251@oracle.com> References: <37080e07-13bb-82f7-ae1e-b43287e00251@oracle.com> Message-ID: <71665506-724f-3bf8-e642-40c61c8fea75@oracle.com> ping, it is a simple review, Vicente On 7/17/20 3:36 PM, Vicente Romero wrote: > Please review fix for [1] at [2]. At method Check::validateAnnotation > the condition used to determine if a field is or not a record field > was wrong. As a consequence static fields were considered as record > fields. This doesn't have any consequence unless they are annotated. > This patch is fixing this issue. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8243057 > [2] http://cr.openjdk.java.net/~vromero/8243057/webrev.00/ From jan.lahoda at oracle.com Tue Jul 21 08:50:52 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 21 Jul 2020 10:50:52 +0200 Subject: RFR: JDK-8243057: compilation of annotated static record fields fails with NPE In-Reply-To: <71665506-724f-3bf8-e642-40c61c8fea75@oracle.com> References: <37080e07-13bb-82f7-ae1e-b43287e00251@oracle.com> <71665506-724f-3bf8-e642-40c61c8fea75@oracle.com> Message-ID: <725f8e2a-9e42-ba32-656e-50e708c7961f@oracle.com> Hi Vicente, I am sorry, but saying "s.flags_field == $mask" feels somewhat dangerous to me - what if there are other (valid) flags that can be added to record components/fields? My understanding was that the record members are marked with the RECORD flag, should it be enough to say: boolean isRecordField = declarationTree.hasTag(VARDEF) && (s.flags_field & RECORD) != 0 && s.owner.kind == TYP; ? Thanks, Jan On 20. 07. 20 18:53, Vicente Romero wrote: > ping, it is a simple review, > > Vicente > > On 7/17/20 3:36 PM, Vicente Romero wrote: >> Please review fix for [1] at [2]. At method Check::validateAnnotation >> the condition used to determine if a field is or not a record field >> was wrong. As a consequence static fields were considered as record >> fields. This doesn't have any consequence unless they are annotated. >> This patch is fixing this issue. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243057 >> [2] http://cr.openjdk.java.net/~vromero/8243057/webrev.00/ > From vicente.romero at oracle.com Tue Jul 21 13:57:27 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 21 Jul 2020 09:57:27 -0400 Subject: RFR: JDK-8243057: compilation of annotated static record fields fails with NPE In-Reply-To: <725f8e2a-9e42-ba32-656e-50e708c7961f@oracle.com> References: <37080e07-13bb-82f7-ae1e-b43287e00251@oracle.com> <71665506-724f-3bf8-e642-40c61c8fea75@oracle.com> <725f8e2a-9e42-ba32-656e-50e708c7961f@oracle.com> Message-ID: Hi Jan, Thanks for the review. the RECORD flag is applied to static fields too what about: boolean isRecordField = isRecordMember && !s.isStatic() && declarationTree.hasTag(VARDEF) && s.owner.kind ==TYP; ? I have made this change at [1], Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.01/ On 7/21/20 4:50 AM, Jan Lahoda wrote: > Hi Vicente, > > I am sorry, but saying "s.flags_field == $mask" feels somewhat > dangerous to me - what if there are other (valid) flags that can be > added to record components/fields? > > My understanding was that the record members are marked with the > RECORD flag, should it be enough to say: > boolean isRecordField = declarationTree.hasTag(VARDEF) && > ??????? (s.flags_field & RECORD) != 0 && > ??????? s.owner.kind == TYP; > ? > > Thanks, > ??? Jan > > On 20. 07. 20 18:53, Vicente Romero wrote: >> ping, it is a simple review, >> >> Vicente >> >> On 7/17/20 3:36 PM, Vicente Romero wrote: >>> Please review fix for [1] at [2]. At method >>> Check::validateAnnotation the condition used to determine if a field >>> is or not a record field was wrong. As a consequence static fields >>> were considered as record fields. This doesn't have any consequence >>> unless they are annotated. This patch is fixing this issue. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8243057 >>> [2] http://cr.openjdk.java.net/~vromero/8243057/webrev.00/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jul 21 15:40:12 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 21 Jul 2020 11:40:12 -0400 Subject: RFR: JDK-8243057: compilation of annotated static record fields fails with NPE In-Reply-To: References: <37080e07-13bb-82f7-ae1e-b43287e00251@oracle.com> <71665506-724f-3bf8-e642-40c61c8fea75@oracle.com> <725f8e2a-9e42-ba32-656e-50e708c7961f@oracle.com> Message-ID: <0ab2d00e-89b9-dc76-6d96-5718594778b1@oracle.com> Hi Jan, Yep you are right but given that isRecordMember already have the info about the record flag we can rewrite the condition as: boolean isRecordField = isRecordMember && declarationTree.hasTag(VARDEF) && s.owner.kind ==TYP; [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.02/ Sorry for the noise, Vicente On 7/21/20 9:57 AM, Vicente Romero wrote: > Hi Jan, > > Thanks for the review. the RECORD flag is applied to static fields too > what about: > > boolean isRecordField = isRecordMember && > !s.isStatic() && > declarationTree.hasTag(VARDEF) && > s.owner.kind ==TYP; > ? > I have made this change at [1], > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.01/ > > On 7/21/20 4:50 AM, Jan Lahoda wrote: >> Hi Vicente, >> >> I am sorry, but saying "s.flags_field == $mask" feels somewhat >> dangerous to me - what if there are other (valid) flags that can be >> added to record components/fields? >> >> My understanding was that the record members are marked with the >> RECORD flag, should it be enough to say: >> boolean isRecordField = declarationTree.hasTag(VARDEF) && >> ??????? (s.flags_field & RECORD) != 0 && >> ??????? s.owner.kind == TYP; >> ? >> >> Thanks, >> ??? Jan >> >> On 20. 07. 20 18:53, Vicente Romero wrote: >>> ping, it is a simple review, >>> >>> Vicente >>> >>> On 7/17/20 3:36 PM, Vicente Romero wrote: >>>> Please review fix for [1] at [2]. At method >>>> Check::validateAnnotation the condition used to determine if a >>>> field is or not a record field was wrong. As a consequence static >>>> fields were considered as record fields. This doesn't have any >>>> consequence unless they are annotated. This patch is fixing this >>>> issue. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8243057 >>>> [2] http://cr.openjdk.java.net/~vromero/8243057/webrev.00/ >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnape09 at gmail.com Wed Jul 22 20:45:12 2020 From: jnape09 at gmail.com (John Napier) Date: Wed, 22 Jul 2020 15:45:12 -0500 Subject: JDK-7120669 Message-ID: <6E6D7A55-6ACD-4A4A-9F6F-A77F1329B6D5@gmail.com> Hey all, https://bugs.openjdk.java.net/browse/JDK-7120669 is a bug I and my teams at work run into all the time: I was curious if there was any plan to incorporate a fix for it in an upcoming release, and if so, what the intended resolution was? -John -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Jul 23 17:00:42 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 23 Jul 2020 10:00:42 -0700 Subject: JDK 16 RFR of JDK-8250213: Address use of default constructors in com.sun.source.util Message-ID: <7636038a-bee1-9847-b544-6f72624a8770@oracle.com> Hello, Please review the webrev and CSR to address: ??? JDK-8250213: Address use of default constructors in com.sun.source.util ??? webrev: http://cr.openjdk.java.net/~darcy/8250213.0/ ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250215 For the com.sun.source classes, I add the previous implicit public no-arg constructors as all those classes look to intend to allow instantiation of themselves or of subclasses. For com.sun.tools.javac.Main, the constructor seems unintended as all the members of the class are static. Patch below; before pushed, I'll update the copyright years, etc. Thanks, -Joe --- old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java 2020-07-23 09:48:38.498747851 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java 2020-07-23 09:48:38.082955836 -0700 @@ -39,6 +39,11 @@ ? */ ?public class DocTreePathScanner extends DocTreeScanner { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public DocTreePathScanner() {} + +??? /** ????? * Scans a tree from a position identified by a tree path. ????? * @param path the path ????? * @param p a value to be passed to visitor methods --- old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java 2020-07-23 09:48:39.330331881 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java 2020-07-23 09:48:38.886553865 -0700 @@ -68,6 +68,10 @@ ? * @since 1.8 ? */ ?public class DocTreeScanner implements DocTreeVisitor { +??? /** +???? * Constructor for subclasses to call. +???? */ +??? public DocTreeScanner() {} ???? /** ????? * Scans a single node. --- old/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java 2020-07-23 09:48:40.109941910 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java 2020-07-23 09:48:39.682155894 -0700 @@ -47,6 +47,11 @@ ? */ ?public abstract class DocTrees extends Trees { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public DocTrees() {} + +??? /** ????? * Returns a DocTrees object for a given CompilationTask. ????? * @param task the compilation task for which to get the Trees object ????? * @return the DocTrees object --- old/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java 2020-07-23 09:48:40.873559937 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java 2020-07-23 09:48:40.441775922 -0700 @@ -50,6 +50,10 @@ ? * @since 1.6 ? */ ?public abstract class JavacTask implements CompilationTask { +??? /** +???? * Constructor for subclasses to call. +???? */ +??? public JavacTask() {} ???? /** ????? * Returns the {@code JavacTask} for a {@code ProcessingEnvironment}. --- old/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java 2020-07-23 09:48:41.721135968 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java 2020-07-23 09:48:41.257367951 -0700 @@ -43,6 +43,10 @@ ? * @since 1.6 ? */ ?public class TreePathScanner extends TreeScanner { +??? /** +???? * Constructor for subclasses to call. +???? */ +??? public TreePathScanner() {} ???? /** ????? * Scans a tree from a position identified by a TreePath. --- old/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java 2020-07-23 09:48:42.564713999 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java 2020-07-23 09:48:42.100945982 -0700 @@ -75,6 +75,10 @@ ? * @since 1.6 ? */ ?public class TreeScanner implements TreeVisitor { +??? /** +???? * Constructor for subclasses to call. +???? */ +??? public TreeScanner() {} ???? /** ????? * Scans a single node. --- old/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java 2020-07-23 09:48:43.408292029 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java 2020-07-23 09:48:43.012490015 -0700 @@ -53,6 +53,11 @@ ? */ ?public abstract class Trees { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public Trees() {} + +??? /** ????? * Returns a Trees object for a given CompilationTask. ????? * @param task the compilation task for which to get the Trees object ????? * @throws IllegalArgumentException if the task does not support the Trees API. --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java 2020-07-23 09:48:44.231880059 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java 2020-07-23 09:48:43.812090044 -0700 @@ -34,6 +34,8 @@ ? * module for details on replacement APIs. ? */ ?public class Main { +??? @Deprecated(since="16", forRemoval=true) +??? public Main(){} ???? /** Main entry point for the launcher. ????? *? Note: This method calls System.exit. From jonathan.gibbons at oracle.com Thu Jul 23 17:10:09 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 23 Jul 2020 10:10:09 -0700 Subject: JDK 16 RFR of JDK-8250213: Address use of default constructors in com.sun.source.util In-Reply-To: <7636038a-bee1-9847-b544-6f72624a8770@oracle.com> References: <7636038a-bee1-9847-b544-6f72624a8770@oracle.com> Message-ID: Joe, If a constructor is documented as being for subclasses to call, it should really be a protected constructor. Some of the affected classes are abstract, thus forcing the use of subtypes.? Other classes are not abstract although it is hard to imagine a legitimate use for them to be used directly. For those non-abstract classes, should we be looking at a slightly bigger change. If we can't change the signature of the class or constructor, should we at least improve the documentation for these classes? I'm not necessarily suggesting to d that in this changeset; I'm just wondering aloud how best to improve these classes. -- Jon On 7/23/20 10:00 AM, Joe Darcy wrote: > Hello, > > Please review the webrev and CSR to address: > > ??? JDK-8250213: Address use of default constructors in > com.sun.source.util > ??? webrev: http://cr.openjdk.java.net/~darcy/8250213.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250215 > > For the com.sun.source classes, I add the previous implicit public > no-arg constructors as all those classes look to intend to allow > instantiation of themselves or of subclasses. For > com.sun.tools.javac.Main, the constructor seems unintended as all the > members of the class are static. > > Patch below; before pushed, I'll update the copyright years, etc. > > Thanks, > > -Joe > > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java > 2020-07-23 09:48:38.498747851 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java > 2020-07-23 09:48:38.082955836 -0700 > @@ -39,6 +39,11 @@ > ? */ > ?public class DocTreePathScanner extends DocTreeScanner { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public DocTreePathScanner() {} > + > +??? /** > ????? * Scans a tree from a position identified by a tree path. > ????? * @param path the path > ????? * @param p a value to be passed to visitor methods > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java > 2020-07-23 09:48:39.330331881 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java > 2020-07-23 09:48:38.886553865 -0700 > @@ -68,6 +68,10 @@ > ? * @since 1.8 > ? */ > ?public class DocTreeScanner implements DocTreeVisitor { > +??? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public DocTreeScanner() {} > > ???? /** > ????? * Scans a single node. > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java > 2020-07-23 09:48:40.109941910 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java > 2020-07-23 09:48:39.682155894 -0700 > @@ -47,6 +47,11 @@ > ? */ > ?public abstract class DocTrees extends Trees { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public DocTrees() {} > + > +??? /** > ????? * Returns a DocTrees object for a given CompilationTask. > ????? * @param task the compilation task for which to get the Trees > object > ????? * @return the DocTrees object > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java > 2020-07-23 09:48:40.873559937 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java > 2020-07-23 09:48:40.441775922 -0700 > @@ -50,6 +50,10 @@ > ? * @since 1.6 > ? */ > ?public abstract class JavacTask implements CompilationTask { > +??? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public JavacTask() {} > > ???? /** > ????? * Returns the {@code JavacTask} for a {@code > ProcessingEnvironment}. > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java > 2020-07-23 09:48:41.721135968 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java > 2020-07-23 09:48:41.257367951 -0700 > @@ -43,6 +43,10 @@ > ? * @since 1.6 > ? */ > ?public class TreePathScanner extends TreeScanner { > +??? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public TreePathScanner() {} > > ???? /** > ????? * Scans a tree from a position identified by a TreePath. > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java > 2020-07-23 09:48:42.564713999 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java > 2020-07-23 09:48:42.100945982 -0700 > @@ -75,6 +75,10 @@ > ? * @since 1.6 > ? */ > ?public class TreeScanner implements TreeVisitor { > +??? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public TreeScanner() {} > > ???? /** > ????? * Scans a single node. > --- old/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java > 2020-07-23 09:48:43.408292029 -0700 > +++ new/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java > 2020-07-23 09:48:43.012490015 -0700 > @@ -53,6 +53,11 @@ > ? */ > ?public abstract class Trees { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public Trees() {} > + > +??? /** > ????? * Returns a Trees object for a given CompilationTask. > ????? * @param task the compilation task for which to get the Trees > object > ????? * @throws IllegalArgumentException if the task does not support > the Trees API. > --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java > 2020-07-23 09:48:44.231880059 -0700 > +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java > 2020-07-23 09:48:43.812090044 -0700 > @@ -34,6 +34,8 @@ > ? * module for details on replacement APIs. > ? */ > ?public class Main { > +??? @Deprecated(since="16", forRemoval=true) > +??? public Main(){} > > ???? /** Main entry point for the launcher. > ????? *? Note: This method calls System.exit. > From joe.darcy at oracle.com Thu Jul 23 17:17:09 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 23 Jul 2020 10:17:09 -0700 Subject: JDK 16 RFR of JDK-8250213: Address use of default constructors in com.sun.source.util In-Reply-To: References: <7636038a-bee1-9847-b544-6f72624a8770@oracle.com> Message-ID: <859e01f1-2f87-ab28-4481-764e0ea67908@oracle.com> Hi Jon, For the non-abstract classes, I'm happy to change the verbiage to the true (if not very informative) "Creates a $FOO." Longer term, deprecating the unintended constructors for removal would be fine too. (This patch is the first in a series to clean-up the JDK with the intention of introducing a new lint warning for using default constructors.) Thanks, -Joe On 7/23/2020 10:10 AM, Jonathan Gibbons wrote: > Joe, > > If a constructor is documented as being for subclasses to call, it > should really be a protected constructor. > > Some of the affected classes are abstract, thus forcing the use of > subtypes.? Other classes are not abstract although it is hard to > imagine a legitimate use for them to be used directly. For those > non-abstract classes, should we be looking at a slightly bigger > change. If we can't change the signature of the class or constructor, > should we at least improve the documentation for these classes? I'm > not necessarily suggesting to d that in this changeset; I'm just > wondering aloud how best to improve these classes. > > -- Jon > > On 7/23/20 10:00 AM, Joe Darcy wrote: >> Hello, >> >> Please review the webrev and CSR to address: >> >> ??? JDK-8250213: Address use of default constructors in >> com.sun.source.util >> ??? webrev: http://cr.openjdk.java.net/~darcy/8250213.0/ >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250215 >> >> For the com.sun.source classes, I add the previous implicit public >> no-arg constructors as all those classes look to intend to allow >> instantiation of themselves or of subclasses. For >> com.sun.tools.javac.Main, the constructor seems unintended as all the >> members of the class are static. >> >> Patch below; before pushed, I'll update the copyright years, etc. >> >> Thanks, >> >> -Joe >> >> --- >> old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java >> 2020-07-23 09:48:38.498747851 -0700 >> +++ >> new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java >> 2020-07-23 09:48:38.082955836 -0700 >> @@ -39,6 +39,11 @@ >> ? */ >> ?public class DocTreePathScanner extends DocTreeScanner { >> ???? /** >> +???? * Constructor for subclasses to call. >> +???? */ >> +??? public DocTreePathScanner() {} >> + >> +??? /** >> ????? * Scans a tree from a position identified by a tree path. >> ????? * @param path the path >> ????? * @param p a value to be passed to visitor methods >> --- >> old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java >> 2020-07-23 09:48:39.330331881 -0700 >> +++ >> new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java >> 2020-07-23 09:48:38.886553865 -0700 >> @@ -68,6 +68,10 @@ >> ? * @since 1.8 >> ? */ >> ?public class DocTreeScanner implements DocTreeVisitor { >> +??? /** >> +???? * Constructor for subclasses to call. >> +???? */ >> +??? public DocTreeScanner() {} >> >> ???? /** >> ????? * Scans a single node. >> --- >> old/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java >> 2020-07-23 09:48:40.109941910 -0700 >> +++ >> new/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java >> 2020-07-23 09:48:39.682155894 -0700 >> @@ -47,6 +47,11 @@ >> ? */ >> ?public abstract class DocTrees extends Trees { >> ???? /** >> +???? * Constructor for subclasses to call. >> +???? */ >> +??? public DocTrees() {} >> + >> +??? /** >> ????? * Returns a DocTrees object for a given CompilationTask. >> ????? * @param task the compilation task for which to get the Trees >> object >> ????? * @return the DocTrees object >> --- >> old/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java >> 2020-07-23 09:48:40.873559937 -0700 >> +++ >> new/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java >> 2020-07-23 09:48:40.441775922 -0700 >> @@ -50,6 +50,10 @@ >> ? * @since 1.6 >> ? */ >> ?public abstract class JavacTask implements CompilationTask { >> +??? /** >> +???? * Constructor for subclasses to call. >> +???? */ >> +??? public JavacTask() {} >> >> ???? /** >> ????? * Returns the {@code JavacTask} for a {@code >> ProcessingEnvironment}. >> --- >> old/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java >> 2020-07-23 09:48:41.721135968 -0700 >> +++ >> new/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java >> 2020-07-23 09:48:41.257367951 -0700 >> @@ -43,6 +43,10 @@ >> ? * @since 1.6 >> ? */ >> ?public class TreePathScanner extends TreeScanner { >> +??? /** >> +???? * Constructor for subclasses to call. >> +???? */ >> +??? public TreePathScanner() {} >> >> ???? /** >> ????? * Scans a tree from a position identified by a TreePath. >> --- >> old/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java >> 2020-07-23 09:48:42.564713999 -0700 >> +++ >> new/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java >> 2020-07-23 09:48:42.100945982 -0700 >> @@ -75,6 +75,10 @@ >> ? * @since 1.6 >> ? */ >> ?public class TreeScanner implements TreeVisitor { >> +??? /** >> +???? * Constructor for subclasses to call. >> +???? */ >> +??? public TreeScanner() {} >> >> ???? /** >> ????? * Scans a single node. >> --- old/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java >> 2020-07-23 09:48:43.408292029 -0700 >> +++ new/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java >> 2020-07-23 09:48:43.012490015 -0700 >> @@ -53,6 +53,11 @@ >> ? */ >> ?public abstract class Trees { >> ???? /** >> +???? * Constructor for subclasses to call. >> +???? */ >> +??? public Trees() {} >> + >> +??? /** >> ????? * Returns a Trees object for a given CompilationTask. >> ????? * @param task the compilation task for which to get the Trees >> object >> ????? * @throws IllegalArgumentException if the task does not support >> the Trees API. >> --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java >> 2020-07-23 09:48:44.231880059 -0700 >> +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java >> 2020-07-23 09:48:43.812090044 -0700 >> @@ -34,6 +34,8 @@ >> ? * module for details on replacement APIs. >> ? */ >> ?public class Main { >> +??? @Deprecated(since="16", forRemoval=true) >> +??? public Main(){} >> >> ???? /** Main entry point for the launcher. >> ????? *? Note: This method calls System.exit. >> From vicente.romero at oracle.com Fri Jul 24 04:38:45 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 24 Jul 2020 00:38:45 -0400 Subject: RFR: JDK-8243057: compilation of annotated static record fields fails with NPE In-Reply-To: <0ab2d00e-89b9-dc76-6d96-5718594778b1@oracle.com> References: <37080e07-13bb-82f7-ae1e-b43287e00251@oracle.com> <71665506-724f-3bf8-e642-40c61c8fea75@oracle.com> <725f8e2a-9e42-ba32-656e-50e708c7961f@oracle.com> <0ab2d00e-89b9-dc76-6d96-5718594778b1@oracle.com> Message-ID: <70618e48-b4c6-a8d3-7ce6-36adb5919e07@oracle.com> Hi Jan, I have updated the webrev as we discussed offline [1], Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.03/ On 7/21/20 11:40 AM, Vicente Romero wrote: > Hi Jan, > > Yep you are right but given that isRecordMember already have the info > about the record flag we can rewrite the condition as: > > boolean isRecordField = isRecordMember && > declarationTree.hasTag(VARDEF) && > s.owner.kind ==TYP; > [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.02/ > > Sorry for the noise, > Vicente > > On 7/21/20 9:57 AM, Vicente Romero wrote: >> Hi Jan, >> >> Thanks for the review. the RECORD flag is applied to static fields >> too what about: >> >> boolean isRecordField = isRecordMember && >> !s.isStatic() && >> declarationTree.hasTag(VARDEF) && >> s.owner.kind ==TYP; >> ? >> I have made this change at [1], >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.01/ >> >> On 7/21/20 4:50 AM, Jan Lahoda wrote: >>> Hi Vicente, >>> >>> I am sorry, but saying "s.flags_field == $mask" feels somewhat >>> dangerous to me - what if there are other (valid) flags that can be >>> added to record components/fields? >>> >>> My understanding was that the record members are marked with the >>> RECORD flag, should it be enough to say: >>> boolean isRecordField = declarationTree.hasTag(VARDEF) && >>> ??????? (s.flags_field & RECORD) != 0 && >>> ??????? s.owner.kind == TYP; >>> ? >>> >>> Thanks, >>> ??? Jan >>> >>> On 20. 07. 20 18:53, Vicente Romero wrote: >>>> ping, it is a simple review, >>>> >>>> Vicente >>>> >>>> On 7/17/20 3:36 PM, Vicente Romero wrote: >>>>> Please review fix for [1] at [2]. At method >>>>> Check::validateAnnotation the condition used to determine if a >>>>> field is or not a record field was wrong. As a consequence static >>>>> fields were considered as record fields. This doesn't have any >>>>> consequence unless they are annotated. This patch is fixing this >>>>> issue. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8243057 >>>>> [2] http://cr.openjdk.java.net/~vromero/8243057/webrev.00/ >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Jul 24 08:27:29 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 24 Jul 2020 10:27:29 +0200 Subject: RFR: JDK-8243057: compilation of annotated static record fields fails with NPE In-Reply-To: <70618e48-b4c6-a8d3-7ce6-36adb5919e07@oracle.com> References: <37080e07-13bb-82f7-ae1e-b43287e00251@oracle.com> <71665506-724f-3bf8-e642-40c61c8fea75@oracle.com> <725f8e2a-9e42-ba32-656e-50e708c7961f@oracle.com> <0ab2d00e-89b9-dc76-6d96-5718594778b1@oracle.com> <70618e48-b4c6-a8d3-7ce6-36adb5919e07@oracle.com> Message-ID: <6c20d605-213d-66f7-c444-2f2af2badfcb@oracle.com> Looks good to me. Thanks, Jan On 24. 07. 20 6:38, Vicente Romero wrote: > Hi Jan, > > I have updated the webrev as we discussed offline [1], > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.03/ > > On 7/21/20 11:40 AM, Vicente Romero wrote: >> Hi Jan, >> >> Yep you are right but given that isRecordMember already have the info >> about the record flag we can rewrite the condition as: >> >> boolean isRecordField = isRecordMember && >> declarationTree.hasTag(VARDEF) && >> s.owner.kind ==TYP; >> [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.02/ >> >> Sorry for the noise, >> Vicente >> >> On 7/21/20 9:57 AM, Vicente Romero wrote: >>> Hi Jan, >>> >>> Thanks for the review. the RECORD flag is applied to static fields >>> too what about: >>> >>> boolean isRecordField = isRecordMember && >>> !s.isStatic() && >>> declarationTree.hasTag(VARDEF) && >>> s.owner.kind ==TYP; >>> ? >>> I have made this change at [1], >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8243057/webrev.01/ >>> >>> On 7/21/20 4:50 AM, Jan Lahoda wrote: >>>> Hi Vicente, >>>> >>>> I am sorry, but saying "s.flags_field == $mask" feels somewhat >>>> dangerous to me - what if there are other (valid) flags that can be >>>> added to record components/fields? >>>> >>>> My understanding was that the record members are marked with the >>>> RECORD flag, should it be enough to say: >>>> boolean isRecordField = declarationTree.hasTag(VARDEF) && >>>> ??????? (s.flags_field & RECORD) != 0 && >>>> ??????? s.owner.kind == TYP; >>>> ? >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>> On 20. 07. 20 18:53, Vicente Romero wrote: >>>>> ping, it is a simple review, >>>>> >>>>> Vicente >>>>> >>>>> On 7/17/20 3:36 PM, Vicente Romero wrote: >>>>>> Please review fix for [1] at [2]. At method >>>>>> Check::validateAnnotation the condition used to determine if a >>>>>> field is or not a record field was wrong. As a consequence static >>>>>> fields were considered as record fields. This doesn't have any >>>>>> consequence unless they are annotated. This patch is fixing this >>>>>> issue. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8243057 >>>>>> [2] http://cr.openjdk.java.net/~vromero/8243057/webrev.00/ >>>>> >>> >> > From vicente.romero at oracle.com Fri Jul 24 15:00:01 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 24 Jul 2020 11:00:01 -0400 Subject: RFR: JDK-8249829: javac is issuing an incorrect static access error Message-ID: <52c2dcf6-f33c-6c92-6bcb-21f1dc1d99c3@oracle.com> Please review fix for [1] at [2]. This is a follow up of JDK-8247790, the checks added to forbid local static types to access type and local variables defined out of theirs scope was not totally correct and was issuing an error for code like: import java.security.*; class Test { static Test newInstance(Object provider) { return new Test() { private final PrivilegedExceptionAction action =new PrivilegedExceptionAction() { public KeyStore run()throws Exception { if (provider ==null) {} <-------- compiler was issuing an error because of this access return null; } }; }; } } Thanks, Vicente https://bugs.openjdk.java.net/browse/JDK-8249829 http://cr.openjdk.java.net/~vromero/8249829/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jul 27 10:27:11 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Jul 2020 11:27:11 +0100 Subject: Type inference: bug or feature? In-Reply-To: <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com> References: <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com> Message-ID: <86d4c0ad-e757-a335-efdd-aa14b4d93a25@oracle.com> On 27/07/2020 11:26, Maurizio Cimadamore wrote: > CC'ing compiler-dev > > Hi Justin, > the behavior you are observing is normal. For a Java expression to be > able to be influenced by type inference it has to be a poly expression > (where poly stands for _many_ as in, the same expression can have many > types). > > At the time we did Java 8 we briefly considered making cast > expressions part of the poly expression dance (like lambdas, method > references, method calls, parens, new creation expression, > conditionals and switch expression - see JLS 15.2), but the rule which > dictate cast conversion (JLS 5.5) are so complex (as they have to take > into account possibility for unchecked cast, etc.) that it felt like > touching them was a very risky move, with no clear benefit. > > The behavior you see is caused by the fact that the cast expression > acts as a "shield" - that is, whenever a method call appears after a > cast expression (as in your case), the method call is type-checked as > if it were in isolation, and _then_ the result of type checking is > validated against the cast. In other words, your example is no > different than doing: > > var x = (List)(Object)emptyList(Number.class); > > > That is, the emptyList call will see no meaningful target type (just > Object), so Number will be inferred and a List will be > returned, which will then be incompatible with the type of the cast > expression (List). > > Your second set of examples, since it does not make use of cast > expressions, works as expected, as the target type can freely flow > inside the method call typing, and thus influence the type inference > result (e.g. the inference engine now sees two constraints, for > Integer and for Number, and is of course able to pick the "best" one). > > Hope this helps. > > Cheers > Maurizio > > On 26/07/2020 18:22, Justin Dekeyser wrote: >> Dear all, >> >> I'm not sure but I think I've found a bug in Java type inference >> mechanism. >> It may also be a feature, so I'll expose the problem to you below; in >> terms >> of Integer, Number and List, although you'll quickly realize it will >> work >> wrong in any similar situation. >> >> Let's assume I have >> >> static List emptyList(Class magnet) { >> ??? return Collections.emptyList(); >> } >> >> Then the following codes does not compile (for the same reason): >> >> var x = (List) emptyList(Number.class); >> List x = (List) emptyList(Number.class); >> >> incompatible types: List cannot be converted to List >> >> however, the following do compile: >> >> var x = emptyList(Number.class); // inferred to List >> List x = emptyList(Number.class); // no mistake here, it's >> Integer >> on the left >> >> Is this the expected behavior? Why does casting operation here interfere >> with type inference like this? >> >> Regards, >> >> Justin Dekeyser >> >> >> >> >> >> >> Garanti >> sans virus. www.avast.com >> >> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From jan.lahoda at oracle.com Mon Jul 27 10:53:38 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 27 Jul 2020 12:53:38 +0200 Subject: RFR: JDK-8249829: javac is issuing an incorrect static access error In-Reply-To: <52c2dcf6-f33c-6c92-6bcb-21f1dc1d99c3@oracle.com> References: <52c2dcf6-f33c-6c92-6bcb-21f1dc1d99c3@oracle.com> Message-ID: <80226cd9-d337-ab15-4ee6-580d979b66cc@oracle.com> Looks OK. Jan On 24. 07. 20 17:00, Vicente Romero wrote: > Please review fix for [1] at [2]. This is a follow up of JDK-8247790, > the checks added to forbid local static types to access type and local > variables defined out of theirs scope was not totally correct and was > issuing an error for code like: > > import java.security.*; > class Test { > static Test newInstance(Object provider) { > return new Test() { > private final PrivilegedExceptionAction action =new PrivilegedExceptionAction() { > public KeyStore run()throws Exception { > if (provider ==null) {} <-------- compiler was issuing an error because of this access > return null; > } > }; > }; > } > } > > Thanks, > Vicente > > https://bugs.openjdk.java.net/browse/JDK-8249829 > http://cr.openjdk.java.net/~vromero/8249829/webrev.00/ From jan.lahoda at oracle.com Mon Jul 27 12:46:52 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 27 Jul 2020 14:46:52 +0200 Subject: RFR: JDK-8248641: Trees.getScope returns incorrect results for code inside a rule case In-Reply-To: <651117e6-2b50-8ac2-355c-bd1725fa40af@oracle.com> References: <33414814-d992-7957-32b0-ad0913376eff@oracle.com> <651117e6-2b50-8ac2-355c-bd1725fa40af@oracle.com> Message-ID: <9555ccaa-0f3e-d823-290d-9b73a3f8e835@oracle.com> Hi, The existing patch is always filling out the JCCase.body, even for statement cases (unlike the parser, which leaves the body empty/null for statement cases). While I don't think there's anything directly broken by this, it may be better to keep JCCase.body null for statement cases to keep consistency with the normal non-copied trees. Updated patch: http://cr.openjdk.java.net/~jlahoda/8248641/webrev.01/ What do you think? Thanks, Jan On 07. 07. 20 21:15, Vicente Romero wrote: > looks good, > Vicente > > On 7/2/20 9:11 AM, Jan Lahoda wrote: >> Hi, >> >> When calling Trees.getScope for a TreePath that is inside a rule case >> (i.e. "case ->"), the results are wrong/do not reflect the elements >> declared inside the enclosing method. >> >> The reason is that, for rule cases, JCCase tree is keeping "body", >> which represents what is in the source code. And this body is wrapped >> and put into "stats", which are basically the statements for an >> ordinary case. This means that javac can typically only work over the >> "stats". When TreeCopied copies the JCCase tree, it will duplicate >> both "stats" and "body" separately, leading to a duplication in trees. >> And then Attr.breakTree points to the requested tree from "body", but >> that one is never attributed, and so the appropriate scope is never >> captured. >> >> The proposed patch here is to only duplicate "stats", and then take >> appropriate "body" from "stats", leading to only one copy of the tree. >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8248641/webrev.00/ >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8248641 >> >> How does this look? >> >> Thanks, >> ??? Jan > From vicente.romero at oracle.com Mon Jul 27 14:06:32 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 27 Jul 2020 10:06:32 -0400 Subject: RFR: JDK-8249829: javac is issuing an incorrect static access error In-Reply-To: <80226cd9-d337-ab15-4ee6-580d979b66cc@oracle.com> References: <52c2dcf6-f33c-6c92-6bcb-21f1dc1d99c3@oracle.com> <80226cd9-d337-ab15-4ee6-580d979b66cc@oracle.com> Message-ID: thanks for the review, Vicente On 7/27/20 6:53 AM, Jan Lahoda wrote: > Looks OK. > > Jan > > On 24. 07. 20 17:00, Vicente Romero wrote: >> Please review fix for [1] at [2]. This is a follow up of JDK-8247790, >> the checks added to forbid local static types to access type and >> local variables defined out of theirs scope was not totally correct >> and was issuing an error for code like: >> >> import java.security.*; >> class Test { >> ???? static Test newInstance(Object provider) { >> ???????? return new Test() { >> ???????????? private final PrivilegedExceptionAction action >> =new PrivilegedExceptionAction() { >> ???????????????? public KeyStore run()throws Exception { >> ???????????????????? if (provider ==null) {}? <-------- compiler was >> issuing an error because of this access >> ???????????????????? return null; >> ???????????????? } >> ???????????? }; >> ???????? }; >> ???? } >> } >> >> Thanks, >> Vicente >> >> https://bugs.openjdk.java.net/browse/JDK-8249829 >> http://cr.openjdk.java.net/~vromero/8249829/webrev.00/ From joe.darcy at oracle.com Mon Jul 27 16:25:11 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 27 Jul 2020 09:25:11 -0700 Subject: JDK 16 RFR of JDK-8250213: Address use of default constructors in com.sun.source.util In-Reply-To: <859e01f1-2f87-ab28-4481-764e0ea67908@oracle.com> References: <7636038a-bee1-9847-b544-6f72624a8770@oracle.com> <859e01f1-2f87-ab28-4481-764e0ea67908@oracle.com> Message-ID: Hi Jon, Updated webrev to improve the docs for non-abstract classes: ??? http://cr.openjdk.java.net/~darcy/8250213.1/ Patch below. For the network version of these changes, as follow-up work? Alan may change the public constructor of abstract classes to protected. Thanks, -Joe --- old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java 2020-07-27 09:20:26.556000000 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java 2020-07-27 09:20:25.476000000 -0700 @@ -39,6 +39,11 @@ ? */ ?public class DocTreePathScanner extends DocTreeScanner { ???? /** +???? * Constructs a {@code DocTreePathScanner}. +???? */ +??? public DocTreePathScanner() {} + +??? /** ????? * Scans a tree from a position identified by a tree path. ????? * @param path the path ????? * @param p a value to be passed to visitor methods --- old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java 2020-07-27 09:20:28.600000000 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java 2020-07-27 09:20:27.504000000 -0700 @@ -68,6 +68,10 @@ ? * @since 1.8 ? */ ?public class DocTreeScanner implements DocTreeVisitor { +??? /** +???? * Constructs a {@code DocTreeScanner}. +???? */ +??? public DocTreeScanner() {} ???? /** ????? * Scans a single node. --- old/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java 2020-07-27 09:20:30.312000000 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java 2020-07-27 09:20:29.492000000 -0700 @@ -47,6 +47,11 @@ ? */ ?public abstract class DocTrees extends Trees { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public DocTrees() {} + +??? /** ????? * Returns a DocTrees object for a given CompilationTask. ????? * @param task the compilation task for which to get the Trees object ????? * @return the DocTrees object --- old/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java 2020-07-27 09:20:32.088000000 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java 2020-07-27 09:20:31.224000000 -0700 @@ -50,6 +50,10 @@ ? * @since 1.6 ? */ ?public abstract class JavacTask implements CompilationTask { +??? /** +???? * Constructor for subclasses to call. +???? */ +??? public JavacTask() {} ???? /** ????? * Returns the {@code JavacTask} for a {@code ProcessingEnvironment}. --- old/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java 2020-07-27 09:20:33.688000000 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java 2020-07-27 09:20:32.804000000 -0700 @@ -43,6 +43,10 @@ ? * @since 1.6 ? */ ?public class TreePathScanner extends TreeScanner { +??? /** +???? * Constructs a {@code TreePathScanner}. +???? */ +??? public TreePathScanner() {} ???? /** ????? * Scans a tree from a position identified by a TreePath. --- old/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java 2020-07-27 09:20:35.172000000 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java 2020-07-27 09:20:34.448000000 -0700 @@ -75,6 +75,10 @@ ? * @since 1.6 ? */ ?public class TreeScanner implements TreeVisitor { +??? /** +???? * Constructs a {@code TreeScanner}. +???? */ +??? public TreeScanner() {} ???? /** ????? * Scans a single node. --- old/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java 2020-07-27 09:20:36.912000000 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java 2020-07-27 09:20:36.004000000 -0700 @@ -53,6 +53,11 @@ ? */ ?public abstract class Trees { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public Trees() {} + +??? /** ????? * Returns a Trees object for a given CompilationTask. ????? * @param task the compilation task for which to get the Trees object ????? * @throws IllegalArgumentException if the task does not support the Trees API. --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java 2020-07-27 09:20:38.680000000 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java 2020-07-27 09:20:37.764000000 -0700 @@ -34,6 +34,11 @@ ? * module for details on replacement APIs. ? */ ?public class Main { +??? /** +???? * Do not call. +???? */ +??? @Deprecated(since="16", forRemoval=true) +??? public Main(){} ???? /** Main entry point for the launcher. ????? *? Note: This method calls System.exit. On 7/23/2020 10:17 AM, Joe Darcy wrote: > Hi Jon, > > For the non-abstract classes, I'm happy to change the verbiage to the > true (if not very informative) "Creates a $FOO." > > Longer term, deprecating the unintended constructors for removal would > be fine too. (This patch is the first in a series to clean-up the JDK > with the intention of introducing a new lint warning for using default > constructors.) > > Thanks, > > -Joe > > From vicente.romero at oracle.com Mon Jul 27 17:09:09 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 27 Jul 2020 13:09:09 -0400 Subject: RFR: JDK-8248641: Trees.getScope returns incorrect results for code inside a rule case In-Reply-To: <9555ccaa-0f3e-d823-290d-9b73a3f8e835@oracle.com> References: <33414814-d992-7957-32b0-ad0913376eff@oracle.com> <651117e6-2b50-8ac2-355c-bd1725fa40af@oracle.com> <9555ccaa-0f3e-d823-290d-9b73a3f8e835@oracle.com> Message-ID: looks good, but shouldn't the test include cases for which the body is not null? Vicente On 7/27/20 8:46 AM, Jan Lahoda wrote: > Hi, > > The existing patch is always filling out the JCCase.body, even for > statement cases (unlike the parser, which leaves the body empty/null > for statement cases). While I don't think there's anything directly > broken by this, it may be better to keep JCCase.body null for > statement cases to keep consistency with the normal non-copied trees. > > Updated patch: > http://cr.openjdk.java.net/~jlahoda/8248641/webrev.01/ > > What do you think? > > Thanks, > ??? Jan > > On 07. 07. 20 21:15, Vicente Romero wrote: >> looks good, >> Vicente >> >> On 7/2/20 9:11 AM, Jan Lahoda wrote: >>> Hi, >>> >>> When calling Trees.getScope for a TreePath that is inside a rule >>> case (i.e. "case ->"), the results are wrong/do not reflect the >>> elements declared inside the enclosing method. >>> >>> The reason is that, for rule cases, JCCase tree is keeping "body", >>> which represents what is in the source code. And this body is >>> wrapped and put into "stats", which are basically the statements for >>> an ordinary case. This means that javac can typically only work over >>> the "stats". When TreeCopied copies the JCCase tree, it will >>> duplicate both "stats" and "body" separately, leading to a >>> duplication in trees. And then Attr.breakTree points to the >>> requested tree from "body", but that one is never attributed, and so >>> the appropriate scope is never captured. >>> >>> The proposed patch here is to only duplicate "stats", and then take >>> appropriate "body" from "stats", leading to only one copy of the tree. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8248641/webrev.00/ >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8248641 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From vicente.romero at oracle.com Mon Jul 27 17:12:04 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 27 Jul 2020 13:12:04 -0400 Subject: RFR: JDK-8248641: Trees.getScope returns incorrect results for code inside a rule case In-Reply-To: References: <33414814-d992-7957-32b0-ad0913376eff@oracle.com> <651117e6-2b50-8ac2-355c-bd1725fa40af@oracle.com> <9555ccaa-0f3e-d823-290d-9b73a3f8e835@oracle.com> Message-ID: <03056a1e-eb8e-f6ba-f73a-fe14bc4f52e1@oracle.com> On 7/27/20 1:09 PM, Vicente Romero wrote: > looks good, but shouldn't the test include cases for which the body is > not null? hit the send button too soon, I meant, shouldn't the test explicitly check that the body is not null for the rest of the cases? > > Vicente > > On 7/27/20 8:46 AM, Jan Lahoda wrote: >> Hi, >> >> The existing patch is always filling out the JCCase.body, even for >> statement cases (unlike the parser, which leaves the body empty/null >> for statement cases). While I don't think there's anything directly >> broken by this, it may be better to keep JCCase.body null for >> statement cases to keep consistency with the normal non-copied trees. >> >> Updated patch: >> http://cr.openjdk.java.net/~jlahoda/8248641/webrev.01/ >> >> What do you think? >> >> Thanks, >> ??? Jan >> >> On 07. 07. 20 21:15, Vicente Romero wrote: >>> looks good, >>> Vicente >>> >>> On 7/2/20 9:11 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> When calling Trees.getScope for a TreePath that is inside a rule >>>> case (i.e. "case ->"), the results are wrong/do not reflect the >>>> elements declared inside the enclosing method. >>>> >>>> The reason is that, for rule cases, JCCase tree is keeping "body", >>>> which represents what is in the source code. And this body is >>>> wrapped and put into "stats", which are basically the statements >>>> for an ordinary case. This means that javac can typically only work >>>> over the "stats". When TreeCopied copies the JCCase tree, it will >>>> duplicate both "stats" and "body" separately, leading to a >>>> duplication in trees. And then Attr.breakTree points to the >>>> requested tree from "body", but that one is never attributed, and >>>> so the appropriate scope is never captured. >>>> >>>> The proposed patch here is to only duplicate "stats", and then take >>>> appropriate "body" from "stats", leading to only one copy of the tree. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8248641/webrev.00/ >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8248641 >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> ??? Jan >>> > From jonathan.gibbons at oracle.com Mon Jul 27 17:19:55 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 27 Jul 2020 10:19:55 -0700 Subject: JDK 16 RFR of JDK-8250213: Address use of default constructors in com.sun.source.util In-Reply-To: References: <7636038a-bee1-9847-b544-6f72624a8770@oracle.com> <859e01f1-2f87-ab28-4481-764e0ea67908@oracle.com> Message-ID: <0ebc89a8-0a7e-7795-9a90-c22857215d3c@oracle.com> +1 On 7/27/20 9:25 AM, Joe Darcy wrote: > Hi Jon, > > Updated webrev to improve the docs for non-abstract classes: > > ??? http://cr.openjdk.java.net/~darcy/8250213.1/ > > Patch below. For the network version of these changes, as follow-up > work? Alan may change the public constructor of abstract classes to > protected. > > Thanks, > > -Joe > > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java > 2020-07-27 09:20:26.556000000 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreePathScanner.java > 2020-07-27 09:20:25.476000000 -0700 > @@ -39,6 +39,11 @@ > ? */ > ?public class DocTreePathScanner extends DocTreeScanner { > ???? /** > +???? * Constructs a {@code DocTreePathScanner}. > +???? */ > +??? public DocTreePathScanner() {} > + > +??? /** > ????? * Scans a tree from a position identified by a tree path. > ????? * @param path the path > ????? * @param p a value to be passed to visitor methods > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java > 2020-07-27 09:20:28.600000000 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java > 2020-07-27 09:20:27.504000000 -0700 > @@ -68,6 +68,10 @@ > ? * @since 1.8 > ? */ > ?public class DocTreeScanner implements DocTreeVisitor { > +??? /** > +???? * Constructs a {@code DocTreeScanner}. > +???? */ > +??? public DocTreeScanner() {} > > ???? /** > ????? * Scans a single node. > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java > 2020-07-27 09:20:30.312000000 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java > 2020-07-27 09:20:29.492000000 -0700 > @@ -47,6 +47,11 @@ > ? */ > ?public abstract class DocTrees extends Trees { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public DocTrees() {} > + > +??? /** > ????? * Returns a DocTrees object for a given CompilationTask. > ????? * @param task the compilation task for which to get the Trees > object > ????? * @return the DocTrees object > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java > 2020-07-27 09:20:32.088000000 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java > 2020-07-27 09:20:31.224000000 -0700 > @@ -50,6 +50,10 @@ > ? * @since 1.6 > ? */ > ?public abstract class JavacTask implements CompilationTask { > +??? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public JavacTask() {} > > ???? /** > ????? * Returns the {@code JavacTask} for a {@code > ProcessingEnvironment}. > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java > 2020-07-27 09:20:33.688000000 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/TreePathScanner.java > 2020-07-27 09:20:32.804000000 -0700 > @@ -43,6 +43,10 @@ > ? * @since 1.6 > ? */ > ?public class TreePathScanner extends TreeScanner { > +??? /** > +???? * Constructs a {@code TreePathScanner}. > +???? */ > +??? public TreePathScanner() {} > > ???? /** > ????? * Scans a tree from a position identified by a TreePath. > --- > old/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java > 2020-07-27 09:20:35.172000000 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java > 2020-07-27 09:20:34.448000000 -0700 > @@ -75,6 +75,10 @@ > ? * @since 1.6 > ? */ > ?public class TreeScanner implements TreeVisitor { > +??? /** > +???? * Constructs a {@code TreeScanner}. > +???? */ > +??? public TreeScanner() {} > > ???? /** > ????? * Scans a single node. > --- old/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java > 2020-07-27 09:20:36.912000000 -0700 > +++ new/src/jdk.compiler/share/classes/com/sun/source/util/Trees.java > 2020-07-27 09:20:36.004000000 -0700 > @@ -53,6 +53,11 @@ > ? */ > ?public abstract class Trees { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public Trees() {} > + > +??? /** > ????? * Returns a Trees object for a given CompilationTask. > ????? * @param task the compilation task for which to get the Trees > object > ????? * @throws IllegalArgumentException if the task does not support > the Trees API. > --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java > 2020-07-27 09:20:38.680000000 -0700 > +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java > 2020-07-27 09:20:37.764000000 -0700 > @@ -34,6 +34,11 @@ > ? * module for details on replacement APIs. > ? */ > ?public class Main { > +??? /** > +???? * Do not call. > +???? */ > +??? @Deprecated(since="16", forRemoval=true) > +??? public Main(){} > > ???? /** Main entry point for the launcher. > ????? *? Note: This method calls System.exit. > > On 7/23/2020 10:17 AM, Joe Darcy wrote: >> Hi Jon, >> >> For the non-abstract classes, I'm happy to change the verbiage to the >> true (if not very informative) "Creates a $FOO." >> >> Longer term, deprecating the unintended constructors for removal >> would be fine too. (This patch is the first in a series to clean-up >> the JDK with the intention of introducing a new lint warning for >> using default constructors.) >> >> Thanks, >> >> -Joe >> >> From vicente.romero at oracle.com Tue Jul 28 01:23:04 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 27 Jul 2020 21:23:04 -0400 Subject: RFR: JDK-8250629: do not allow C-style array declaration in record components Message-ID: <693fa758-638e-a72f-a8c8-02020ff3d28a@oracle.com> Please review fix for [1] along with the corresponding CSR at [2], the fix perse is at [3]. This fix is syncing the compiler with the spec for records. Basically the latest version of the spec, see [4] doesn't allow C-style array syntax when declaring record components, so code like: record R(int i[]) {} shouldn't be accepted by the compiler. Thanks, Vicente [1] Bug: https://bugs.openjdk.java.net/browse/JDK-8250629 [2] CSR: https://bugs.openjdk.java.net/browse/JDK-8250647 [3] http://cr.openjdk.java.net/~vromero/8250629/webrev.00/ [4] http://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/records-jls.html#jls-8.10.1 From jan.lahoda at oracle.com Tue Jul 28 10:29:17 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 28 Jul 2020 12:29:17 +0200 Subject: RFR: JDK-8248641: Trees.getScope returns incorrect results for code inside a rule case In-Reply-To: <03056a1e-eb8e-f6ba-f73a-fe14bc4f52e1@oracle.com> References: <33414814-d992-7957-32b0-ad0913376eff@oracle.com> <651117e6-2b50-8ac2-355c-bd1725fa40af@oracle.com> <9555ccaa-0f3e-d823-290d-9b73a3f8e835@oracle.com> <03056a1e-eb8e-f6ba-f73a-fe14bc4f52e1@oracle.com> Message-ID: <3a900296-2354-0437-bcff-ac1e5e1ec3ad@oracle.com> On 27. 07. 20 19:12, Vicente Romero wrote: > > > On 7/27/20 1:09 PM, Vicente Romero wrote: >> looks good, but shouldn't the test include cases for which the body is >> not null? > > hit the send button too soon, I meant, shouldn't the test explicitly > check that the body is not null for the rest of the cases? Sure, why not: http://cr.openjdk.java.net/~jlahoda/8248641/webrev.02/ Does this look fine? Thanks, Jan >> >> Vicente >> >> On 7/27/20 8:46 AM, Jan Lahoda wrote: >>> Hi, >>> >>> The existing patch is always filling out the JCCase.body, even for >>> statement cases (unlike the parser, which leaves the body empty/null >>> for statement cases). While I don't think there's anything directly >>> broken by this, it may be better to keep JCCase.body null for >>> statement cases to keep consistency with the normal non-copied trees. >>> >>> Updated patch: >>> http://cr.openjdk.java.net/~jlahoda/8248641/webrev.01/ >>> >>> What do you think? >>> >>> Thanks, >>> ??? Jan >>> >>> On 07. 07. 20 21:15, Vicente Romero wrote: >>>> looks good, >>>> Vicente >>>> >>>> On 7/2/20 9:11 AM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> When calling Trees.getScope for a TreePath that is inside a rule >>>>> case (i.e. "case ->"), the results are wrong/do not reflect the >>>>> elements declared inside the enclosing method. >>>>> >>>>> The reason is that, for rule cases, JCCase tree is keeping "body", >>>>> which represents what is in the source code. And this body is >>>>> wrapped and put into "stats", which are basically the statements >>>>> for an ordinary case. This means that javac can typically only work >>>>> over the "stats". When TreeCopied copies the JCCase tree, it will >>>>> duplicate both "stats" and "body" separately, leading to a >>>>> duplication in trees. And then Attr.breakTree points to the >>>>> requested tree from "body", but that one is never attributed, and >>>>> so the appropriate scope is never captured. >>>>> >>>>> The proposed patch here is to only duplicate "stats", and then take >>>>> appropriate "body" from "stats", leading to only one copy of the tree. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8248641/webrev.00/ >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8248641 >>>>> >>>>> How does this look? >>>>> >>>>> Thanks, >>>>> ??? Jan >>>> >> > From vicente.romero at oracle.com Tue Jul 28 12:42:46 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 28 Jul 2020 08:42:46 -0400 Subject: RFR: JDK-8248641: Trees.getScope returns incorrect results for code inside a rule case In-Reply-To: <3a900296-2354-0437-bcff-ac1e5e1ec3ad@oracle.com> References: <33414814-d992-7957-32b0-ad0913376eff@oracle.com> <651117e6-2b50-8ac2-355c-bd1725fa40af@oracle.com> <9555ccaa-0f3e-d823-290d-9b73a3f8e835@oracle.com> <03056a1e-eb8e-f6ba-f73a-fe14bc4f52e1@oracle.com> <3a900296-2354-0437-bcff-ac1e5e1ec3ad@oracle.com> Message-ID: <52f6c602-9676-34a9-675c-b942e5299b67@oracle.com> yep looks good to me, thanks for making the change, Vicente On 7/28/20 6:29 AM, Jan Lahoda wrote: > On 27. 07. 20 19:12, Vicente Romero wrote: >> >> >> On 7/27/20 1:09 PM, Vicente Romero wrote: >>> looks good, but shouldn't the test include cases for which the body >>> is not null? >> >> hit the send button too soon, I meant, shouldn't the test explicitly >> check that the body is not null for the rest of the cases? > > Sure, why not: > http://cr.openjdk.java.net/~jlahoda/8248641/webrev.02/ > > Does this look fine? > > Thanks, > ??? Jan > >>> >>> Vicente >>> >>> On 7/27/20 8:46 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> The existing patch is always filling out the JCCase.body, even for >>>> statement cases (unlike the parser, which leaves the body >>>> empty/null for statement cases). While I don't think there's >>>> anything directly broken by this, it may be better to keep >>>> JCCase.body null for statement cases to keep consistency with the >>>> normal non-copied trees. >>>> >>>> Updated patch: >>>> http://cr.openjdk.java.net/~jlahoda/8248641/webrev.01/ >>>> >>>> What do you think? >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>> On 07. 07. 20 21:15, Vicente Romero wrote: >>>>> looks good, >>>>> Vicente >>>>> >>>>> On 7/2/20 9:11 AM, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> When calling Trees.getScope for a TreePath that is inside a rule >>>>>> case (i.e. "case ->"), the results are wrong/do not reflect the >>>>>> elements declared inside the enclosing method. >>>>>> >>>>>> The reason is that, for rule cases, JCCase tree is keeping >>>>>> "body", which represents what is in the source code. And this >>>>>> body is wrapped and put into "stats", which are basically the >>>>>> statements for an ordinary case. This means that javac can >>>>>> typically only work over the "stats". When TreeCopied copies the >>>>>> JCCase tree, it will duplicate both "stats" and "body" >>>>>> separately, leading to a duplication in trees. And then >>>>>> Attr.breakTree points to the requested tree from "body", but that >>>>>> one is never attributed, and so the appropriate scope is never >>>>>> captured. >>>>>> >>>>>> The proposed patch here is to only duplicate "stats", and then >>>>>> take appropriate "body" from "stats", leading to only one copy of >>>>>> the tree. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~jlahoda/8248641/webrev.00/ >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8248641 >>>>>> >>>>>> How does this look? >>>>>> >>>>>> Thanks, >>>>>> ??? Jan >>>>> >>> >> From vicente.romero at oracle.com Wed Jul 29 12:46:22 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 29 Jul 2020 08:46:22 -0400 Subject: RFR: JDK-8250629: do not allow C-style array declaration in record components In-Reply-To: <693fa758-638e-a72f-a8c8-02020ff3d28a@oracle.com> References: <693fa758-638e-a72f-a8c8-02020ff3d28a@oracle.com> Message-ID: ping On 7/27/20 9:23 PM, Vicente Romero wrote: > Please review fix for [1] along with the corresponding CSR at [2], the > fix perse is at [3]. This fix is syncing the compiler with the spec > for records. Basically the latest version of the spec, see [4] doesn't > allow C-style array syntax when declaring record components, so code > like: > > record R(int i[]) {} > > shouldn't be accepted by the compiler. > > Thanks, > Vicente > > [1] Bug: https://bugs.openjdk.java.net/browse/JDK-8250629 > [2] CSR: https://bugs.openjdk.java.net/browse/JDK-8250647 > [3] http://cr.openjdk.java.net/~vromero/8250629/webrev.00/ > [4] > http://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/records-jls.html#jls-8.10.1 > From jan.lahoda at oracle.com Wed Jul 29 13:15:19 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 29 Jul 2020 15:15:19 +0200 Subject: RFR: JDK-8250629: do not allow C-style array declaration in record components In-Reply-To: References: <693fa758-638e-a72f-a8c8-02020ff3d28a@oracle.com> Message-ID: Looks OK to me. Jan On 29. 07. 20 14:46, Vicente Romero wrote: > ping > > On 7/27/20 9:23 PM, Vicente Romero wrote: >> Please review fix for [1] along with the corresponding CSR at [2], the >> fix perse is at [3]. This fix is syncing the compiler with the spec >> for records. Basically the latest version of the spec, see [4] doesn't >> allow C-style array syntax when declaring record components, so code >> like: >> >> record R(int i[]) {} >> >> shouldn't be accepted by the compiler. >> >> Thanks, >> Vicente >> >> [1] Bug: https://bugs.openjdk.java.net/browse/JDK-8250629 >> [2] CSR: https://bugs.openjdk.java.net/browse/JDK-8250647 >> [3] http://cr.openjdk.java.net/~vromero/8250629/webrev.00/ >> [4] >> http://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/records-jls.html#jls-8.10.1 >> >> > From vicente.romero at oracle.com Wed Jul 29 19:08:19 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 29 Jul 2020 15:08:19 -0400 Subject: RFR: JDK-8250741: an annotation interface may not be declared as a local interface Message-ID: <3adf0982-16e0-927f-ec45-6684299e1b14@oracle.com> Please review at [1] the fix for [2] with corresponding CSR at [3]. The spec for Local Static Interfaces and Enum Classes [4] states that: |An annotation interface (9.6) may not be declared as a local interface| javac is accepting local annotations though. This fix is closing that gap between the compiler and the spec, Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8250741/webrev.00 [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8250741 [3] CSR: https://bugs.openjdk.java.net/browse/JDK-8250790 [4] https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-14.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jul 29 20:10:28 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 29 Jul 2020 13:10:28 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created Message-ID: Hello, Please review the code changes and CSR for ??? JDK-8071961: Add javac lint warning when a default constructor is created ??? webrev: http://cr.openjdk.java.net/~darcy/8071961.5/ ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250795 Some background on the design of the warning and broader usage context, while default constructors can be convenient for informal code, they can be a bit troublesome for more formal APIs, such as the public classes of packages in the JDK. One issue is that default constructors do not have javadoc. Another is that a class that semantically should not be instantiated, say it is a solely a holder for? static constants and methods, can get instantiated and subclassed. (Subclasssing such a class is an anti-pattern to allow use short names for the static members, which is no longer necessary since static imports as of Java SE 5.0.) Until they were recently fixed, there were about one hundred remaining default constructors in the JDK API outside of the client libraries ( JDK-8250212 Address reliance on default constructors in the JDK (umbrella) ). Other occurrences of this issue were sporadically fixed over the years ( JDK-8236695, JDK-8177153, JDK-8071959, etc.). In terms of detailed criteria to issue the new warnings, there was the usual tension in warnings between reducing false positives and false negatives. For example, warning for *any* default constructor, even in a throw-away class, would be more annoying than helpful. With some guidance from the JDK code base, criteria in the current patch are a default constructor merits a warning if: * The class is in a named package and the packaged has an unqualified export from its module AND * The class is public and, if it is a nested class, all of its lexically enclosing types are public too. An unqualified export, where the package is available to use to any module and not just named ones, was taken to indicate classes in the package can comprise a "formal API". It would be simple to change this to an unqualified export, but I wanted to avoid unwanted instances of a new warning. If a public nested class is a non-public enclosing class, the nested class is not directly part of the exported API. These combinations of kinds of exports and nesting are tested in the tests in the DefaultCtor directory. The text of the warning message implies what criteria are being used: ?# 0: symbol, 1: symbol, 2: symbol ?compiler.warn.default-ctor=\ ???? class {0} in exported package {1} of module {2} relies on a default (implicit) constructor Once the javac-related changes are reviewed, I'll send a RFR out to build-dev for the make system updates. Basically modules whose use of default constructors has not been addressed (java.desktop, jdk.accessibility, jdk.unsupported.desktop, etc.) have the new warning disabled. Thanks, -Joe From alex.buckley at oracle.com Thu Jul 30 00:15:46 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 29 Jul 2020 17:15:46 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: References: Message-ID: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> On 7/29/2020 1:10 PM, Joe Darcy wrote: > Please review the code changes and CSR for > > ??? JDK-8071961: Add javac lint warning when a default constructor is > created > ??? webrev: http://cr.openjdk.java.net/~darcy/8071961.5/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250795 I like the idea of warning about irregular aspects of exported classes, such as having an implicitly declared ("default") ctor, or implementing an unexported interface. These constructs are not always wrong, but they affect how code in other modules can couple to code in this module, so system architects may appreciate lint warnings in this area. > The text of the warning message implies what criteria are being used: > > ?# 0: symbol, 1: symbol, 2: symbol > ?compiler.warn.default-ctor=\ > ???? class {0} in exported package {1} of module {2} relies on a > default (implicit) constructor Recommend "exposes" rather than "relies on". We're in the domain of modules, where "relies on" / "depends on" will be taken in connection with `requires`. Also, I recommend dropping "(implicit)". I believe the dominant term in use is "default", and I think this is not the place for parenthetical expressions that can be misinterpreted. I would even label the warning as exposed-default-ctor. ("A default ctor is exposed if it is implicitly declared in a public class of an exported package in a named module. If the class is nested, then ...") Alex From joe.darcy at oracle.com Thu Jul 30 01:45:12 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 29 Jul 2020 18:45:12 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> Message-ID: Hello, On 7/29/2020 5:15 PM, Alex Buckley wrote: > On 7/29/2020 1:10 PM, Joe Darcy wrote: >> Please review the code changes and CSR for >> >> ???? JDK-8071961: Add javac lint warning when a default constructor >> is created >> ???? webrev: http://cr.openjdk.java.net/~darcy/8071961.5/ >> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8250795 > > I like the idea of warning about irregular aspects of exported > classes, such as having an implicitly declared ("default") ctor, or > implementing an unexported interface. These constructs are not always > wrong, but they affect how code in other modules can couple to code in > this module, so system architects may appreciate lint warnings in this > area. > >> The text of the warning message implies what criteria are being used: >> >> ??# 0: symbol, 1: symbol, 2: symbol >> ??compiler.warn.default-ctor=\ >> ????? class {0} in exported package {1} of module {2} relies on a >> default (implicit) constructor > > Recommend "exposes" rather than "relies on". We're in the domain of > modules, where "relies on" / "depends on" will be taken in connection > with `requires`. Okay. > > Also, I recommend dropping "(implicit)". I believe the dominant term > in use is "default", and I think this is not the place for > parenthetical expressions that can be misinterpreted. Hmm. How about something like: ??? Since it does not declare an explicit constructor, class {0} in exported package {1} of module {2} exposes a default constructor As with a number of terms in the JLS, "default" is used in multiple contexts with different meanings ("default methods" vs a "default constructor", etc.). The main point to convey here to the reader of the message is that the *absence* of something is causing the warning. The location the warning is reported is the start of the class declaration. Cheers, -Joe From jonathan.gibbons at oracle.com Thu Jul 30 03:16:56 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 29 Jul 2020 20:16:56 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> Message-ID: On 7/29/20 6:45 PM, Joe Darcy wrote: > Hello, > > On 7/29/2020 5:15 PM, Alex Buckley wrote: >> On 7/29/2020 1:10 PM, Joe Darcy wrote: >>> Please review the code changes and CSR for >>> >>> ???? JDK-8071961: Add javac lint warning when a default constructor >>> is created >>> ???? webrev: http://cr.openjdk.java.net/~darcy/8071961.5/ >>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8250795 >> >> I like the idea of warning about irregular aspects of exported >> classes, such as having an implicitly declared ("default") ctor, or >> implementing an unexported interface. These constructs are not always >> wrong, but they affect how code in other modules can couple to code >> in this module, so system architects may appreciate lint warnings in >> this area. >> >>> The text of the warning message implies what criteria are being used: >>> >>> ??# 0: symbol, 1: symbol, 2: symbol >>> ??compiler.warn.default-ctor=\ >>> ????? class {0} in exported package {1} of module {2} relies on a >>> default (implicit) constructor >> >> Recommend "exposes" rather than "relies on". We're in the domain of >> modules, where "relies on" / "depends on" will be taken in connection >> with `requires`. > > Okay. > >> >> Also, I recommend dropping "(implicit)". I believe the dominant term >> in use is "default", and I think this is not the place for >> parenthetical expressions that can be misinterpreted. > > > Hmm. How about something like: > > ??? Since it does not declare an explicit constructor, class {0} in > exported package {1} of module {2} exposes a default constructor > > As with a number of terms in the JLS, "default" is used in multiple > contexts with different meanings ("default methods" vs a "default > constructor", etc.). The main point to convey here to the reader of > the message is that the *absence* of something is causing the warning. > The location the warning is reported is the start of the class > declaration. > > Cheers, > > -Joe > Since there can only be one default constructor, it seems strange to use the indefinite article, instead of the definite one. -- Jon From joe.darcy at oracle.com Thu Jul 30 04:32:54 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 29 Jul 2020 21:32:54 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> Message-ID: <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com> On 7/29/2020 8:16 PM, Jonathan Gibbons wrote: > > On 7/29/20 6:45 PM, Joe Darcy wrote: >> Hello, >> >> On 7/29/2020 5:15 PM, Alex Buckley wrote: >>> On 7/29/2020 1:10 PM, Joe Darcy wrote: >>>> Please review the code changes and CSR for >>>> >>>> ???? JDK-8071961: Add javac lint warning when a default constructor >>>> is created >>>> ???? webrev: http://cr.openjdk.java.net/~darcy/8071961.5/ >>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8250795 >>> >>> I like the idea of warning about irregular aspects of exported >>> classes, such as having an implicitly declared ("default") ctor, or >>> implementing an unexported interface. These constructs are not >>> always wrong, but they affect how code in other modules can couple >>> to code in this module, so system architects may appreciate lint >>> warnings in this area. >>> >>>> The text of the warning message implies what criteria are being used: >>>> >>>> ??# 0: symbol, 1: symbol, 2: symbol >>>> ??compiler.warn.default-ctor=\ >>>> ????? class {0} in exported package {1} of module {2} relies on a >>>> default (implicit) constructor >>> >>> Recommend "exposes" rather than "relies on". We're in the domain of >>> modules, where "relies on" / "depends on" will be taken in >>> connection with `requires`. >> >> Okay. >> >>> >>> Also, I recommend dropping "(implicit)". I believe the dominant term >>> in use is "default", and I think this is not the place for >>> parenthetical expressions that can be misinterpreted. >> >> >> Hmm. How about something like: >> >> ??? Since it does not declare an explicit constructor, class {0} in >> exported package {1} of module {2} exposes a default constructor >> >> As with a number of terms in the JLS, "default" is used in multiple >> contexts with different meanings ("default methods" vs a "default >> constructor", etc.). The main point to convey here to the reader of >> the message is that the *absence* of something is causing the >> warning. The location the warning is reported is the start of the >> class declaration. >> >> Cheers, >> >> -Joe >> > Since there can only be one default constructor, it seems strange to > use the indefinite article, instead of the definite one. > Perhaps a bit better as ??? Since it does not declare any explicit constructors, class {0} in exported package {1} of module {2} exposes a default constructor using "a default constructor" since (across different classes), there are many default constructors. -Joe From alex.buckley at oracle.com Thu Jul 30 07:51:49 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 30 Jul 2020 00:51:49 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com> References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com> Message-ID: On 7/29/2020 9:32 PM, Joe Darcy wrote: > Perhaps a bit better as > > ??? Since it does not declare any explicit constructors, class {0} in > exported package {1} of module {2} exposes a default constructor I get your point about warning for the absence of something, in which case the lint warning should be `missing-explicit-ctor` and the message should be: class {0} in exported package {1} of module {2} is missing an explicit constructor; clients rely on the default constructor However, what if a class explicitly declares a ctor with the same shape as the default ctor? JLS 13.1 teaches that a class file doesn't distinguish an explicitly declared ctor with the right shape versus the implicitly declared ctor. ("the following constructs are declared implicitly in source code, but are not marked as mandated because only formal parameters can be so marked in a class file: - Default constructors of classes ...") Alex From jan.lahoda at oracle.com Thu Jul 30 10:27:26 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 30 Jul 2020 12:27:26 +0200 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: References: Message-ID: <8cc0e6f9-3642-aac4-19b9-fb1451de6734@oracle.com> Hi Joe, Thanks for this addition! A few comments for your consideration: -the logic in checkDefaultConstructor could probably be simplified - going from "c" the symbol, and as long as the symbol being check is a TYP and PUBLIC, go to its owner. E.g. like: if (lint.isEnabled(Lint.LintCategory.DEFAULT_CTOR) && Feature.MODULES.allowedInSource(source)) { Symbol test = c; while (test.kind == TYP && (test.flags() & PUBLIC) != 0) { test = test.owner; } if (test.kind != PCK) { return ; } -not sure if the check for unnamed package is needed, but it would be nice to have a test verifying proper behavior for unnamed packages, unnamed module and in non-module mode (i.e. JDK 8 mode). -should the warning be suppressable? We would need to defer the warning using deferredLintHandler and check if it was already suppressed. -should protected classes (classes with effectively protected access) be covered as well? -for tests like this, I would suggest to consider using TestRunner, ModuleTestBase or another framework we use for programmatic tests, to avoid adding many small files for testcases, but I don't mind those too much. See e.g.: test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java Jan On 29. 07. 20 22:10, Joe Darcy wrote: > Hello, > > Please review the code changes and CSR for > > ??? JDK-8071961: Add javac lint warning when a default constructor is > created > ??? webrev: http://cr.openjdk.java.net/~darcy/8071961.5/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250795 > > Some background on the design of the warning and broader usage context, > while default constructors can be convenient for informal code, they can > be a bit troublesome for more formal APIs, such as the public classes of > packages in the JDK. One issue is that default constructors do not have > javadoc. Another is that a class that semantically should not be > instantiated, say it is a solely a holder for? static constants and > methods, can get instantiated and subclassed. (Subclasssing such a class > is an anti-pattern to allow use short names for the static members, > which is no longer necessary since static imports as of Java SE 5.0.) > > Until they were recently fixed, there were about one hundred remaining > default constructors in the JDK API outside of the client libraries ( > JDK-8250212 Address reliance on default constructors in the JDK > (umbrella) ). Other occurrences of this issue were sporadically fixed > over the years ( JDK-8236695, JDK-8177153, JDK-8071959, etc.). > > In terms of detailed criteria to issue the new warnings, there was the > usual tension in warnings between reducing false positives and false > negatives. For example, warning for *any* default constructor, even in a > throw-away class, would be more annoying than helpful. With some > guidance from the JDK code base, criteria in the current patch are a > default constructor merits a warning if: > > * The class is in a named package and the packaged has an unqualified > export from its module AND > * The class is public and, if it is a nested class, all of its lexically > enclosing types are public too. > > An unqualified export, where the package is available to use to any > module and not just named ones, was taken to indicate classes in the > package can comprise a "formal API". It would be simple to change this > to an unqualified export, but I wanted to avoid unwanted instances of a > new warning. If a public nested class is a non-public enclosing class, > the nested class is not directly part of the exported API. These > combinations of kinds of exports and nesting are tested in the tests in > the DefaultCtor directory. > > The text of the warning message implies what criteria are being used: > > ?# 0: symbol, 1: symbol, 2: symbol > ?compiler.warn.default-ctor=\ > ???? class {0} in exported package {1} of module {2} relies on a > default (implicit) constructor > > Once the javac-related changes are reviewed, I'll send a RFR out to > build-dev for the make system updates. Basically modules whose use of > default constructors has not been addressed (java.desktop, > jdk.accessibility, jdk.unsupported.desktop, etc.) have the new warning > disabled. > > Thanks, > > -Joe > From vicente.romero at oracle.com Thu Jul 30 13:59:22 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 30 Jul 2020 09:59:22 -0400 Subject: RFR: JDK-8250741: an annotation interface may not be declared as a local interface In-Reply-To: <3adf0982-16e0-927f-ec45-6684299e1b14@oracle.com> References: <3adf0982-16e0-927f-ec45-6684299e1b14@oracle.com> Message-ID: ping, I will also need the CSR to be reviewed, Thanks! Vicente On 7/29/20 3:08 PM, Vicente Romero wrote: > Please review at [1] the fix for [2] with corresponding CSR at [3]. > The spec for Local Static Interfaces and Enum Classes [4] states that: > > |An annotation interface (9.6) may not be declared as a local interface| > javac is accepting local annotations though. This fix is closing that > gap between the compiler and the spec, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8250741/webrev.00 > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8250741 > [3] CSR: https://bugs.openjdk.java.net/browse/JDK-8250790 > [4] > https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-14.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jul 30 15:02:05 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 30 Jul 2020 17:02:05 +0200 Subject: RFR: JDK-8250741: an annotation interface may not be declared as a local interface In-Reply-To: <3adf0982-16e0-927f-ec45-6684299e1b14@oracle.com> References: <3adf0982-16e0-927f-ec45-6684299e1b14@oracle.com> Message-ID: <0226e5b3-84dc-f31f-3ba8-b474d3d1570e@oracle.com> Hi Vicente, I've added myself as a reviewer on the CSR, and tried to tweak it a little - but feel free to do any changes necessary. For the patch, it overall looks good, two suggestions though: -in Check.java, I'd suggest to use && instead of & for the boolean operator (as it seems cleaner to me -it seems to me there is no test that explicitly verifies the updated behavior. It would be nice to have one - possibly as simple as keeping/adjusting: * @compile/fail/ref=IllegalAnnotation.out -XDrawDiagnostics --enable-preview -source ${jdk.version} IllegalAnnotation.java in IllegalAnnotation.java. Thanks, Jan On 29. 07. 20 21:08, Vicente Romero wrote: > Please review at [1] the fix for [2] with corresponding CSR at [3]. The > spec for Local Static Interfaces and Enum Classes [4] states that: > > |An annotation interface (9.6) may not be declared as a local interface| > > javac is accepting local annotations though. This fix is closing that > gap between the compiler and the spec, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8250741/webrev.00 > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8250741 > [3] CSR: https://bugs.openjdk.java.net/browse/JDK-8250790 > [4] > https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-14.3 From joe.darcy at oracle.com Thu Jul 30 17:15:10 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 Jul 2020 10:15:10 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com> Message-ID: <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com> On 7/30/2020 12:51 AM, Alex Buckley wrote: > On 7/29/2020 9:32 PM, Joe Darcy wrote: >> Perhaps a bit better as >> >> ???? Since it does not declare any explicit constructors, class {0} >> in exported package {1} of module {2} exposes a default constructor > > I get your point about warning for the absence of something, in which > case the lint warning should be `missing-explicit-ctor` and the > message should be: > > ? class {0} in exported package {1} of module {2} is missing an > explicit constructor; clients rely on the default constructor > > However, what if a class explicitly declares a ctor with the same > shape as the default ctor? JLS 13.1 teaches that a class file doesn't > distinguish an explicitly declared ctor with the right shape versus > the implicitly declared ctor. ("the following constructs are declared > implicitly in source code, but are not marked as mandated because only > formal parameters can be so marked in a class file: - Default > constructors of classes ...") > Operationally, the warning is only issued if the compiler generates the default constructor when compiling the source file. -Joe From alex.buckley at oracle.com Thu Jul 30 18:17:22 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 30 Jul 2020 11:17:22 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com> References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com> <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com> Message-ID: <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com> On 7/30/2020 10:15 AM, Joe Darcy wrote: > On 7/30/2020 12:51 AM, Alex Buckley wrote: >> On 7/29/2020 9:32 PM, Joe Darcy wrote: >>> Perhaps a bit better as >>> >>> ???? Since it does not declare any explicit constructors, class {0} >>> in exported package {1} of module {2} exposes a default constructor >> >> I get your point about warning for the absence of something, in which >> case the lint warning should be `missing-explicit-ctor` and the >> message should be: >> >> ? class {0} in exported package {1} of module {2} is missing an >> explicit constructor; clients rely on the default constructor >> >> However, what if a class explicitly declares a ctor with the same >> shape as the default ctor? JLS 13.1 teaches that a class file doesn't >> distinguish an explicitly declared ctor with the right shape versus >> the implicitly declared ctor. ("the following constructs are declared >> implicitly in source code, but are not marked as mandated because only >> formal parameters can be so marked in a class file: - Default >> constructors of classes ...") >> > Operationally, the warning is only issued if the compiler generates the > default constructor when compiling the source file. Of course! Everything is easy with the right framing. Knowing when the message occurs allows us to characterize the plight of clients more clearly: class {0} in exported package {1} of module {2} is missing an explicit constructor; clients *will rely* on the default constructor Or does it? Suppose a class is declared with an explicit ctor, compiled, distributed, other classes instantiate it via the explicit ctor, everything is good. Then, someone accidentally deletes the explicit ctor. Happily, -Xlint:all is here to save the day -- but its "missing an explicit constructor" message seems to suggest that clients will automatically be migrated to rely on the (newly emitted) default ctor. Oops, wrong! The message should therefore confess that "clients must rely on the default constructor" -- whose tone rightly suggests there is something iffy about relying on it. Alex From vicente.romero at oracle.com Thu Jul 30 19:46:35 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 30 Jul 2020 15:46:35 -0400 Subject: RFR: JDK-8250741: an annotation interface may not be declared as a local interface In-Reply-To: <0226e5b3-84dc-f31f-3ba8-b474d3d1570e@oracle.com> References: <3adf0982-16e0-927f-ec45-6684299e1b14@oracle.com> <0226e5b3-84dc-f31f-3ba8-b474d3d1570e@oracle.com> Message-ID: Hi Jan, Thanks for the review, On 7/30/20 11:02 AM, Jan Lahoda wrote: > Hi Vicente, > > I've added myself as a reviewer on the CSR, and tried to tweak it a > little - but feel free to do any changes necessary. thanks looks good > > For the patch, it overall looks good, two suggestions though: > -in Check.java, I'd suggest to use && instead of & for the boolean > operator (as it seems cleaner to me oops, sure > -it seems to me there is no test that explicitly verifies the updated > behavior. It would be nice to have one - possibly as simple as > keeping/adjusting: > ?* @compile/fail/ref=IllegalAnnotation.out -XDrawDiagnostics > --enable-preview -source ${jdk.version} IllegalAnnotation.java sure > > in IllegalAnnotation.java. > > Thanks, > ??? Jan I have updated the webrev at [1] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8250741/webrev.01 > > On 29. 07. 20 21:08, Vicente Romero wrote: >> Please review at [1] the fix for [2] with corresponding CSR at [3]. >> The spec for Local Static Interfaces and Enum Classes [4] states that: >> >> |An annotation interface (9.6) may not be declared as a local interface| >> >> javac is accepting local annotations though. This fix is closing that >> gap between the compiler and the spec, >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8250741/webrev.00 >> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8250741 >> [3] CSR: https://bugs.openjdk.java.net/browse/JDK-8250790 >> [4] >> https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-14.3 From joe.darcy at oracle.com Fri Jul 31 01:33:58 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 Jul 2020 18:33:58 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com> References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com> <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com> <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com> Message-ID: On 7/30/2020 11:17 AM, Alex Buckley wrote: > On 7/30/2020 10:15 AM, Joe Darcy wrote: >> On 7/30/2020 12:51 AM, Alex Buckley wrote: >>> On 7/29/2020 9:32 PM, Joe Darcy wrote: >>>> Perhaps a bit better as >>>> >>>> ???? Since it does not declare any explicit constructors, class {0} >>>> in exported package {1} of module {2} exposes a default constructor >>> >>> I get your point about warning for the absence of something, in >>> which case the lint warning should be `missing-explicit-ctor` and >>> the message should be: >>> >>> ? class {0} in exported package {1} of module {2} is missing an >>> explicit constructor; clients rely on the default constructor >>> >>> However, what if a class explicitly declares a ctor with the same >>> shape as the default ctor? JLS 13.1 teaches that a class file >>> doesn't distinguish an explicitly declared ctor with the right shape >>> versus the implicitly declared ctor. ("the following constructs are >>> declared implicitly in source code, but are not marked as mandated >>> because only formal parameters can be so marked in a class file: - >>> Default constructors of classes ...") >>> >> Operationally, the warning is only issued if the compiler generates >> the default constructor when compiling the source file. > > Of course! Everything is easy with the right framing. Knowing when the > message occurs allows us to characterize the plight of clients more > clearly: > > class {0} in exported package {1} of module {2} is missing an explicit > constructor; clients *will rely* on the default constructor > > Or does it? Suppose a class is declared with an explicit ctor, > compiled, distributed, other classes instantiate it via the explicit > ctor, everything is good. Then, someone accidentally deletes the > explicit ctor. Happily, -Xlint:all is here to save the day -- but its > "missing an explicit constructor" message seems to suggest that > clients will automatically be migrated to rely on the (newly emitted) > default ctor. Oops, wrong! The message should therefore confess that > "clients must rely on the default constructor" -- whose tone rightly > suggests there is something iffy about relying on it. > Like most javac lint warnings, this one being proposed to be triggered by inclusion of a default constructor is localized in nature. From my perspective, the situation being noted? is a not a separate (re)compilation hazard or even indirectly an issue for the clients. (From earlier in the thread, since the MANDATED information is not persisted into the class file, the compiler cannot reliably warn callers of a default constructor such a constructor is being called, if that is a concern.) Rather, the message is to the author/maintainer of class Foo being compiled -- "BTW, since you left one out, clients of your class Foo will see a constructor not present in your source code. Make sure your are okay with that and all it implies." -Joe From joe.darcy at oracle.com Fri Jul 31 05:21:49 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 Jul 2020 22:21:49 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: <8cc0e6f9-3642-aac4-19b9-fb1451de6734@oracle.com> References: <8cc0e6f9-3642-aac4-19b9-fb1451de6734@oracle.com> Message-ID: <8a20dcea-3349-1381-d18e-785d82a28cf5@oracle.com> Hi Jan, Thanks for the review. The next iteration is at: ??? http://cr.openjdk.java.net/~darcy/8071961.6 At least one more iteration will be needed on the engineering front; a few comments and questions below. On 7/30/2020 3:27 AM, Jan Lahoda wrote: > Hi Joe, > > Thanks for this addition! A few comments for your consideration: > -the logic in checkDefaultConstructor could probably be simplified - > going from "c" the symbol, and as long as the symbol being check is a > TYP and PUBLIC, go to its owner. E.g. like: > ??????? if (lint.isEnabled(Lint.LintCategory.DEFAULT_CTOR) && > ??????????? Feature.MODULES.allowedInSource(source)) { > ??????????? Symbol test = c; > ??????????? while (test.kind == TYP && (test.flags() & PUBLIC) != 0) { > ??????????????? test = test.owner; > ??????????? } > ??????????? if (test.kind != PCK) { > ??????????????? return ; > ??????????? } > > -not sure if the check for unnamed package is needed, but it would be > nice to have a test verifying proper behavior for unnamed packages, > unnamed module and in non-module mode (i.e. JDK 8 mode). Adding test/langtools/tools/javac/warnings/DefaultCtor/NoWarningCases.java (http://cr.openjdk.java.net/~darcy/8071961.6/test/langtools/tools/javac/warnings/DefaultCtor/NoWarningCases.java.html) test/langtools/tools/javac/warnings/DefaultCtor/NoWarningRecord.java (http://cr.openjdk.java.net/~darcy/8071961.6/test/langtools/tools/javac/warnings/DefaultCtor/NoWarningRecord.java.html) > > -should the warning be suppressable? We would need to defer the > warning using deferredLintHandler and check if it was already suppressed. Yes; it should be suppressable. I changed the starting series of checks to 3835???????? if (lint.isEnabled(LintCategory.MISSING_DECLARED_CTOR) && 3836 !lint.isSuppressed(LintCategory.MISSING_DECLARED_CTOR) && but it isn't having the desired effect; perhaps we could discuss how to resolve this off-line. I also added a check for records: 3837???????????? ((c.flags() & (ENUM? |RECORD)) == 0) && > > -should protected classes (classes with effectively protected access) > be covered as well? Hmm. I'm judging that as not necessary, for now. > > -for tests like this, I would suggest to consider using TestRunner, > ModuleTestBase or another framework we use for programmatic tests, to > avoid adding many small files for testcases, but I don't mind those > too much. See e.g.: > test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java Thanks for the pointer; I'll take a look. (I wrote the tests in the old style I was familiar with.) Cheers, -Joe From joe.darcy at oracle.com Fri Jul 31 05:39:24 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 Jul 2020 22:39:24 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com> <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com> <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com> Message-ID: <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com> On 7/30/2020 6:33 PM, Joe Darcy wrote: > On 7/30/2020 11:17 AM, Alex Buckley wrote: >> On 7/30/2020 10:15 AM, Joe Darcy wrote: >>> On 7/30/2020 12:51 AM, Alex Buckley wrote: >>>> On 7/29/2020 9:32 PM, Joe Darcy wrote: [snip] >> > Like most javac lint warnings, this one being proposed to be triggered > by inclusion of a default constructor is localized in nature. From my > perspective, the situation being noted? is a not a separate > (re)compilation hazard or even indirectly an issue for the clients. > (From earlier in the thread, since the MANDATED information is not > persisted into the class file, the compiler cannot reliably warn > callers of a default constructor such a constructor is being called, > if that is a concern.) Rather, the message is to the author/maintainer > of class Foo being compiled -- "BTW, since you left one out, clients > of your class Foo will see a constructor not present in your source > code. Make sure your are okay with that and all it implies." > PS In the next iteration of the webrev, ??? http://cr.openjdk.java.net/~darcy/8071961.6 the messages have been updated to ?185 javac.opt.Xlint.desc.missing-declared-ctor=\ ?186???? Warn about missing declared constructors in public classes in exported packages. 1763 # 0: symbol, 1: symbol, 2: symbol 1764 compiler.warn.missing-declared-ctor=\ 1765???? class {0} in exported package {1} of module {2} does not declare any explicit constructors, exposing a default constructor to clients Cheers, -Joe From jan.lahoda at oracle.com Fri Jul 31 16:03:18 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 31 Jul 2020 18:03:18 +0200 Subject: RFR: JDK-8250741: an annotation interface may not be declared as a local interface In-Reply-To: References: <3adf0982-16e0-927f-ec45-6684299e1b14@oracle.com> <0226e5b3-84dc-f31f-3ba8-b474d3d1570e@oracle.com> Message-ID: <04061921-e501-2735-f4ec-f146626450bf@oracle.com> Looks OK to me. Jan On 30. 07. 20 21:46, Vicente Romero wrote: > Hi Jan, > > Thanks for the review, > > On 7/30/20 11:02 AM, Jan Lahoda wrote: >> Hi Vicente, >> >> I've added myself as a reviewer on the CSR, and tried to tweak it a >> little - but feel free to do any changes necessary. > > thanks looks good >> >> For the patch, it overall looks good, two suggestions though: >> -in Check.java, I'd suggest to use && instead of & for the boolean >> operator (as it seems cleaner to me > > oops, sure > >> -it seems to me there is no test that explicitly verifies the updated >> behavior. It would be nice to have one - possibly as simple as >> keeping/adjusting: >> ?* @compile/fail/ref=IllegalAnnotation.out -XDrawDiagnostics >> --enable-preview -source ${jdk.version} IllegalAnnotation.java > > sure > >> >> in IllegalAnnotation.java. >> >> Thanks, >> ??? Jan > > I have updated the webrev at [1] > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8250741/webrev.01 >> >> On 29. 07. 20 21:08, Vicente Romero wrote: >>> Please review at [1] the fix for [2] with corresponding CSR at [3]. >>> The spec for Local Static Interfaces and Enum Classes [4] states that: >>> >>> |An annotation interface (9.6) may not be declared as a local interface| >>> >>> javac is accepting local annotations though. This fix is closing that >>> gap between the compiler and the spec, >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8250741/webrev.00 >>> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8250741 >>> [3] CSR: https://bugs.openjdk.java.net/browse/JDK-8250790 >>> [4] >>> https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-14.3 >>> > From alex.buckley at oracle.com Fri Jul 31 16:23:05 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 31 Jul 2020 09:23:05 -0700 Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com> References: <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com> <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com> <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com> <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com> <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com> Message-ID: <28afc2b2-3bc2-e0df-f555-5aedb86f89e6@oracle.com> On 7/30/2020 10:39 PM, Joe Darcy wrote: > PS In the next iteration of the webrev, > > ??? http://cr.openjdk.java.net/~darcy/8071961.6 > > the messages have been updated to > > ?185 javac.opt.Xlint.desc.missing-declared-ctor=\ > ?186???? Warn about missing declared constructors in public classes in > exported packages. > > 1763 # 0: symbol, 1: symbol, 2: symbol > 1764 compiler.warn.missing-declared-ctor=\ > 1765???? class {0} in exported package {1} of module {2} does not > declare any explicit constructors, exposing a default constructor to > clients These messages look very good. Alex