From jonathan.gibbons at oracle.com Sun Dec 1 00:04:12 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 30 Nov 2019 16:04:12 -0800 Subject: RFR: JDK-8233524: Wrong module name for "package P is declared in the unnamed module, but module M does not read it" In-Reply-To: References: Message-ID: Good catch; looks OK to me. -- Jon On 11/28/19 8:43 AM, Jan Lahoda wrote: > Hi, > > There is a small mistake (with bad consequences) in compiler.properties: > --- > # {0} - package in which the invisible class is declared > # {1} - current module > # 0: symbol, 1: symbol > compiler.misc.not.def.access.does.not.read.unnamed=\ > ??? package {0} is declared in the unnamed module, but module {0} does > not read it > --- > > Note the use of {0} after module - but based on the comment above (and > the code that uses this error message), the module is in {1}. The > proposal is to simply fix this as: > --- > # {0} - package in which the invisible class is declared > # {1} - current module > # 0: symbol, 1: symbol > compiler.misc.not.def.access.does.not.read.unnamed=\ > ??? package {0} is declared in the unnamed module, but module {1} does > not read it > --- > > Webrev: http://cr.openjdk.java.net/~jlahoda/8233524/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8233524 > > How does this look? > > Thanks, > ??? Jan From joe.darcy at oracle.com Mon Dec 2 06:17:06 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 1 Dec 2019 22:17:06 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <3805c12d-d476-0f09-3344-a0f7e215c34b@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> <3805c12d-d476-0f09-3344-a0f7e215c34b@oracle.com> Message-ID: <1824646f-00f5-13c0-0873-6ea6f04137c3@oracle.com> Hi Vicente, I took the liberty of adding the necessary directory-level jtreg config files to enable the feature and updated the tests accordingly: ??? https://hg.openjdk.java.net/amber/amber/rev/c91826d62310 (The feature is enabled by default in for the langtools tests, but disabled by default elsewhere.) HTH, -Joe On 11/29/2019 3:12 PM, Vicente Romero wrote: > Hi Joe, > > All the tests that have an explicit -source 14 are that way because > of, I think to remember, a bug in jtreg that doesn't expand the > ${some.property} macro for those tests. I don't remember the details > though > > Thanks, > Vicente > > On 11/29/19 9:59 AM, Joe Darcy wrote: >> Hi Vicente, >> >> Please change all uses of >> >> ??? @compile --enable-preview -source 14 >> >> in jtreg tags to to >> >> ??? @compile --enable-preview -source ${jdk.version} >> >> The former structure will spuriously fail when the JDK 14 -> 15 >> transition occurs. >> >> Also, publishing delta-webrevs between iterations in additional to >> full webrev would help track the incremental changes. >> >> Thanks, >> >> -Joe >> >> On 11/28/2019 8:05 AM, Vicente Romero wrote: >>> Hi again, >>> >>> Sorry but I realized that I forgot to remove some code on the >>> compiler side. The code removed is small, before we were issuing an >>> error if some serialization methods were declared as record members. >>> That section was removed from the spec. I have prepared another >>> iteration with this change at [1] >>> >>> Thanks, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >>> >>> On 11/27/19 11:37 PM, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review the code for the records feature at [1]. This webrev >>>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>>> more! Must of the code has been reviewed but there have been some >>>> changes since reviewers saw it. Also this is the first time an >>>> integral webrev is sent out for review. Last changes on top of my >>>> mind since last review iterations: >>>> >>>> On the compiler implementation: >>>> - it has been adapted to the last version of the language spec [2], >>>> as a reference the JVM spec is at [3]. This implied some changes in >>>> determining if a user defined constructor is the canonical or not. >>>> Now if a constructor is override-equivalent to a signature derived >>>> from the record components, then it is considered the canonical >>>> constructor. And any canonical constructor should satisfy a set of >>>> restrictions, see section 8.10.4 Record Constructor Declarations of >>>> the specification. >>>> - It was also added a check to make sure that accessors are not >>>> generic. >>>> - And that the canonical constructor, if user defined, is not >>>> explicitly invoking any other constructor. >>>> - The list of forbidden record component names has also been updated. >>>> - new error messages have been added >>>> >>>> APIs: >>>> - there have been some API editing in java.lang.Record, >>>> java.lang.runtime.ObjectMethods and >>>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>>> javax.lang.model (some visitors were added) >>>> >>>> On the JVM implementation: >>>> - some logging capabilities have been added to classFileParser.cpp >>>> to provide the reason for which the Record attribute has been ignored >>>> >>>> Reflection: >>>> - there are several new changes to the implementation of >>>> java.lang.reflect.RecordComponent apart from the spec changes >>>> mentioned before. >>>> >>>> bug fixes in >>>> - compiler >>>> - serialization, >>>> - JVM, etc >>>> >>>> As a reference the last iteration of the previous reviews can be >>>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>>> reflection and serialization, >>>> >>>> TIA, >>>> Vicente >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>>> [2] >>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>>> [3] >>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>>> >>> > From maurizio.cimadamore at oracle.com Mon Dec 2 15:00:54 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 2 Dec 2019 15:00:54 +0000 Subject: RFR: JDK-8234922: No compilation error reported not reported for a binding variable when loop broken with label In-Reply-To: <2aa88b22-a77a-60b6-d2e7-5d22ca6b326e@oracle.com> References: <35d29b86-42fa-01ea-8581-c7d6fa0e0fa7@oracle.com> <2aa88b22-a77a-60b6-d2e7-5d22ca6b326e@oracle.com> Message-ID: Approved Thanks Maurizio On 29/11/2019 11:25, Jan Lahoda wrote: > On 28. 11. 19 19:43, Maurizio Cimadamore wrote: >> Looks good - I wonder if we really need to store all trees from the >> outer loop down to the break statement. > > Thanks. > >> >> Shouldn't we just add trees that could potentially be targets of a >> break? (e.g. labels, switch and other loops) > > We can - updated patch: > http://cr.openjdk.java.net/~jlahoda/8234922/webrev.01/ > > Thanks, > ??? Jan > >> >> Maurizio >> >> On 28/11/2019 15:11, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234922 >>> >>> The problem described there is basically: >>> --- >>> public class PatternTest { >>> ??? public static void test(Object o) { >>> ??????? A: >>> ??????? do { >>> ??????????? break A; >>> ??????? } while (!(o instanceof String v)); >>> ??????? System.out.println("Got: " + v); >>> ??? } >>> } >>> --- >>> >>> This should not compile, as "v" should not be in scope for the >>> System.out.println, but javac fails to detect the break, as the >>> break breaks to a labeled statement, not to the loop. The proposed >>> patch solves not only this, but also break to any statement that is >>> not inside the given loop. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8234922/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan From coleen.phillimore at oracle.com Mon Dec 2 16:52:54 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 2 Dec 2019 11:52:54 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <1263a30d-a04a-b821-d110-69ba52f1e1f7@oracle.com> (resending to all the lists) Hi, I've looked at the hotspot code again, and it looks good.? Nice work, Harold and Vincente! Coleen On 11/27/19 11:37 PM, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and > more! Must of the code has been reviewed but there have been some > changes since reviewers saw it. Also this is the first time an > integral webrev is sent out for review. Last changes on top of my mind > since last review iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as > a reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from > the record components, then it is considered the canonical > constructor. And any canonical constructor should satisfy a set of > restrictions, see section 8.10.4 Record Constructor Declarations of > the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not > explicitly invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes > mentioned before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection > and serialization, > > TIA, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From vicente.romero at oracle.com Mon Dec 2 21:07:39 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 2 Dec 2019 16:07:39 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <1824646f-00f5-13c0-0873-6ea6f04137c3@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> <3805c12d-d476-0f09-3344-a0f7e215c34b@oracle.com> <1824646f-00f5-13c0-0873-6ea6f04137c3@oracle.com> Message-ID: thanks Joe, Vicente On 12/2/19 1:17 AM, Joe Darcy wrote: > Hi Vicente, > > I took the liberty of adding the necessary directory-level jtreg > config files to enable the feature and updated the tests accordingly: > > ??? https://hg.openjdk.java.net/amber/amber/rev/c91826d62310 > > (The feature is enabled by default in for the langtools tests, but > disabled by default elsewhere.) > > HTH, > > -Joe > > On 11/29/2019 3:12 PM, Vicente Romero wrote: >> Hi Joe, >> >> All the tests that have an explicit -source 14 are that way because >> of, I think to remember, a bug in jtreg that doesn't expand the >> ${some.property} macro for those tests. I don't remember the details >> though >> >> Thanks, >> Vicente >> >> On 11/29/19 9:59 AM, Joe Darcy wrote: >>> Hi Vicente, >>> >>> Please change all uses of >>> >>> ??? @compile --enable-preview -source 14 >>> >>> in jtreg tags to to >>> >>> ??? @compile --enable-preview -source ${jdk.version} >>> >>> The former structure will spuriously fail when the JDK 14 -> 15 >>> transition occurs. >>> >>> Also, publishing delta-webrevs between iterations in additional to >>> full webrev would help track the incremental changes. >>> >>> Thanks, >>> >>> -Joe >>> >>> On 11/28/2019 8:05 AM, Vicente Romero wrote: >>>> Hi again, >>>> >>>> Sorry but I realized that I forgot to remove some code on the >>>> compiler side. The code removed is small, before we were issuing an >>>> error if some serialization methods were declared as record >>>> members. That section was removed from the spec. I have prepared >>>> another iteration with this change at [1] >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >>>> >>>> On 11/27/19 11:37 PM, Vicente Romero wrote: >>>>> Hi, >>>>> >>>>> Please review the code for the records feature at [1]. This webrev >>>>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>>>> more! Must of the code has been reviewed but there have been some >>>>> changes since reviewers saw it. Also this is the first time an >>>>> integral webrev is sent out for review. Last changes on top of my >>>>> mind since last review iterations: >>>>> >>>>> On the compiler implementation: >>>>> - it has been adapted to the last version of the language spec >>>>> [2], as a reference the JVM spec is at [3]. This implied some >>>>> changes in determining if a user defined constructor is the >>>>> canonical or not. Now if a constructor is override-equivalent to a >>>>> signature derived from the record components, then it is >>>>> considered the canonical constructor. And any canonical >>>>> constructor should satisfy a set of restrictions, see section >>>>> 8.10.4 Record Constructor Declarations of the specification. >>>>> - It was also added a check to make sure that accessors are not >>>>> generic. >>>>> - And that the canonical constructor, if user defined, is not >>>>> explicitly invoking any other constructor. >>>>> - The list of forbidden record component names has also been updated. >>>>> - new error messages have been added >>>>> >>>>> APIs: >>>>> - there have been some API editing in java.lang.Record, >>>>> java.lang.runtime.ObjectMethods and >>>>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>>>> javax.lang.model (some visitors were added) >>>>> >>>>> On the JVM implementation: >>>>> - some logging capabilities have been added to classFileParser.cpp >>>>> to provide the reason for which the Record attribute has been ignored >>>>> >>>>> Reflection: >>>>> - there are several new changes to the implementation of >>>>> java.lang.reflect.RecordComponent apart from the spec changes >>>>> mentioned before. >>>>> >>>>> bug fixes in >>>>> - compiler >>>>> - serialization, >>>>> - JVM, etc >>>>> >>>>> As a reference the last iteration of the previous reviews can be >>>>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>>>> reflection and serialization, >>>>> >>>>> TIA, >>>>> Vicente >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>>>> >>>>> [2] >>>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>>>> [3] >>>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>>>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>>>> >>>> >> From hannes.wallnoefer at oracle.com Mon Dec 2 21:13:50 2019 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 2 Dec 2019 22:13:50 +0100 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <0BAD6EC6-2DA0-4022-BC64-1673560FB7EA@oracle.com> Hi Vicente, I?ve looked at the Javadoc changes again, everything looks good to me. Hannes > Am 28.11.2019 um 05:37 schrieb Vicente Romero : > > Hi, > > Please review the code for the records feature at [1]. This webrev includes all: APIs, runtime, compiler, serialization, javadoc, and more! Must of the code has been reviewed but there have been some changes since reviewers saw it. Also this is the first time an integral webrev is sent out for review. Last changes on top of my mind since last review iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as a reference the JVM spec is at [3]. This implied some changes in determining if a user defined constructor is the canonical or not. Now if a constructor is override-equivalent to a signature derived from the record components, then it is considered the canonical constructor. And any canonical constructor should satisfy a set of restrictions, see section 8.10.4 Record Constructor Declarations of the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not explicitly invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of java.lang.reflect.RecordComponent apart from the spec changes mentioned before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found at [4] under folders: compiler, hotspot_runtime, javadoc, reflection and serialization, > > TIA, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > [3] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From lois.foltan at oracle.com Mon Dec 2 21:56:24 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 2 Dec 2019 16:56:24 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <1263a30d-a04a-b821-d110-69ba52f1e1f7@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <1263a30d-a04a-b821-d110-69ba52f1e1f7@oracle.com> Message-ID: <300a8f8e-6db7-f73b-d212-c68f496c782d@oracle.com> I've looked over the hotspot code again as well.? Looks good, you have my review! Lois On 12/2/2019 11:52 AM, coleen.phillimore at oracle.com wrote: > (resending to all the lists) > > Hi, I've looked at the hotspot code again, and it looks good. Nice > work, Harold and Vincente! > > Coleen > > > On 11/27/19 11:37 PM, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> > From david.holmes at oracle.com Tue Dec 3 00:36:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Dec 2019 10:36:35 +1000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Vicente, I have also re-examined all the hotspot related code and everything looks fine - and very neat (kudos to you and Harold!). A couple of nits: src/hotspot/share/classfile/classFileParser.cpp src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp Typo: + // u2 attributs_count; --- src/hotspot/share/classfile/javaClasses.cpp You are using CHECK_0 in RecordComponent::create but that method returns oop. That seems wrong to me, but I see many other oop returning methods also use CHECK_0 so I'll take that up separately. (It's only a cosmetic issue.) --- test/hotspot/jtreg/runtime/records/abstractRecord.jcod 27 // This test is an Record marked as abstract. s/an/a/ --- Thanks, David ----- On 28/11/2019 2:37 pm, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and more! > Must of the code has been reviewed but there have been some changes > since reviewers saw it. Also this is the first time an integral webrev > is sent out for review. Last changes on top of my mind since last review > iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as a > reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from the > record components, then it is considered the canonical constructor. And > any canonical constructor should satisfy a set of restrictions, see > section 8.10.4 Record Constructor Declarations of the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not explicitly > invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes mentioned > before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection and > serialization, > > TIA, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From john.r.rose at oracle.com Tue Dec 3 01:08:54 2019 From: john.r.rose at oracle.com (John Rose) Date: Mon, 2 Dec 2019 17:08:54 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: On Dec 2, 2019, at 4:36 PM, David Holmes wrote: > > You are using CHECK_0 in RecordComponent::create but that method returns oop. That seems wrong to me, but I see many other oop returning methods also use CHECK_0 so I'll take that up separately. (It's only a cosmetic issue.) CHECK_NULL is clearly preferable. At some point IIRC it was more than just cosmetics, because we were getting warning noise about `return 0` converting to NULL, from some C++ compiler or other. AFAIK such warnings can still happen. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Dec 3 05:27:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Dec 2019 15:27:36 +1000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <7bfe7b80-caa8-70e4-9d51-03aa39b29a4b@oracle.com> On 3/12/2019 11:08 am, John Rose wrote: > On Dec 2, 2019, at 4:36 PM, David Holmes > wrote: >> >> You are using CHECK_0 in RecordComponent::create but that method >> returns oop. That seems wrong to me, but I see many other oop >> returning methods also use CHECK_0 so I'll take that up separately. >> (It's only a cosmetic issue.) > > CHECK_NULL is clearly preferable. ?At some point IIRC it was more > than just cosmetics, because we were getting warning noise about > `return 0` converting to NULL, from some C++ compiler or other. > AFAIK such warnings can still happen. That was my recollection too (I know we fixed some CHECK_0 -> CHECK_FALSE usages for bool methods). I have filed: https://bugs.openjdk.java.net/browse/JDK-8235225 to fix the existing code. Vicente should make this change to his code before pushing (no need to see new webrev). Thanks, David > ? John From joe.darcy at oracle.com Tue Dec 3 05:36:40 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 2 Dec 2019 21:36:40 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> Message-ID: <7e816aeb-7918-9426-2f6c-5d11d3ee263d@oracle.com> Hi Vicente, These comments are based on http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ I looked over the core-libs and javax.lang.model changes. As a non-essential cleanup, in src/java.base/share/classes/java/io/ObjectOutputStream.java: 1444???????????? final boolean isRecord = isRecord(obj.getClass()) ? true : false; 1445???????????? if (isRecord) { 1446???????????????? writeRecordData(obj,desc); 1447???????????? } else if (desc.isExternalizable() && !desc.isProxy()) { would be clearer as 1445???????????? if (isRecord(obj.getClass())) { 1446???????????????? writeRecordData(obj,desc); 1447???????????? } else if (desc.isExternalizable() && !desc.isProxy()) { Also as a potential refactoring, in java.lang.Class, it would be clearer if the native getRecordComponents0 method returned a RecordComponent[] rather than an Object[] as it is elsewhere documented that only the VM can create RecordComponent objects. In src/java.base/share/classes/sun/reflect/annotation/TypeAnnotation.java, the obsolete way on indicating preview-ness is used. Please fix before pushing: ? 93???????? THROWS, ? 94???????? /** ? 95????????? * @deprecated This target is part of a preview feature and may be removed ? 96????????? * if the preview feature is removed. ? 97????????? */ ? 98???????? @Deprecated(forRemoval=true, since="14") ? 99???????? @SuppressWarnings("removal") ?100???????? RECORD_COMPONENT; No re-review is needed. Thanks, -Joe From chris.hegarty at oracle.com Tue Dec 3 12:38:05 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 Dec 2019 12:38:05 +0000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <7e816aeb-7918-9426-2f6c-5d11d3ee263d@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> <7e816aeb-7918-9426-2f6c-5d11d3ee263d@oracle.com> Message-ID: <9CABD094-6548-43D5-813E-9A5EB98682AD@oracle.com> Hi Joe, > On 3 Dec 2019, at 05:36, Joe Darcy wrote: > > ... > > As a non-essential cleanup, in src/java.base/share/classes/java/io/ObjectOutputStream.java: > > 1444 final boolean isRecord = isRecord(obj.getClass()) ? true : false; > 1445 if (isRecord) { > 1446 writeRecordData(obj,desc); > 1447 } else if (desc.isExternalizable() && !desc.isProxy()) { > > would be clearer as > > 1445 if (isRecord(obj.getClass())) { > 1446 writeRecordData(obj,desc); > 1447 } else if (desc.isExternalizable() && !desc.isProxy()) { Remi brought up similar on amber-dev ( and the implement has been updated ). https://mail.openjdk.java.net/pipermail/amber-dev/2019-December/005334.html -Chris. From maurizio.cimadamore at oracle.com Tue Dec 3 15:46:20 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 3 Dec 2019 15:46:20 +0000 Subject: JDK-8221373 (?) Missing checkcast in void-returning lambda In-Reply-To: References: Message-ID: <6ed97ac4-cb92-288b-f1e1-e7571e5312a3@oracle.com> Hi, sorry for the delay. I've checked JDK-8221373 and, honestly, I'm not sure there's anything to fix. Synthetic casts are only emitted when there's a target. If you rewrite the example, dropping the lambda expression: abstract class Test { interface I { ??? X d(); } abstract I c(); ? void f() { ???? this.c().d(); //1 ? } } The callsite in (1) is translated as follows: ???????? 0: aload_0 ???????? 1: invokevirtual #2????????????????? // Method c:()LTest$I; ???????? 4: invokeinterface #3,? 1??????????? // InterfaceMethod Test$I.d:()Ljava/lang/Object; ???????? 9: pop ??????? 10: return Again, no checkcast here. So I'd say that the fix we did back than brought consistency between these two cases, which is IMHO, a good thing. Maurizio On 30/10/2019 12:40, B. Blaser wrote: > Hi, > > Looking a bit at JDK-8221373, I'd like to make sure we are going in > the right direction before posting a RFR. > > Going back to JDK-8203338, we decided in [1] to take the functional > descriptor's erased return type as translation target which might > cause some side-effects like in Liam's void-returning lambda where no > 'checkcast' are emitted anymore. > So my question is rather simple, should we put in place something > closer to the initial fix I suggested in [2] to preserve the original > erased expression typing? > > Thanks, > Bernard > > [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012086.html > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012076.html From jan.lahoda at oracle.com Tue Dec 3 16:37:16 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 3 Dec 2019 17:37:16 +0100 Subject: RFR: JDK-8234899: Compiler reports AssertionError for conditional operator ? : and pattern matching for instanceof Message-ID: <6526e64e-610d-616c-55ad-2ac9eb9e5566@oracle.com> Hi, Consider code like: boolean result = t ? true : (!(o1 instanceof String a3)); When javac starts to generate "(!(o1 instanceof String a3))", there is the "false" jump pending. The "!" operator is generating its operand in the genCond mode. But, the handling for LetExpr (into which the pattern matching is translated) will not explicitly resolve the pending jump (i.e. terminate the jump right before the code for ("o1 instanceof String a3"). But as the desugared code for "o1 instanceof String a3" will create a new variable, the pending jump is resolved at the point the variable is generated - but that is already too late. And hence an AssertionError, or other trouble may happen. The proposal is to resolve (terminate) the pending jumps before generating a LetExpr in condition mode (as is done in non-condition mode). A similar problem may happen for switch expressions, so the proposal is to resolve the jumps for switch expressions as well. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8234899/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8234899 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Tue Dec 3 17:06:53 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 3 Dec 2019 17:06:53 +0000 Subject: RFR: JDK-8234899: Compiler reports AssertionError for conditional operator ? : and pattern matching for instanceof In-Reply-To: <6526e64e-610d-616c-55ad-2ac9eb9e5566@oracle.com> References: <6526e64e-610d-616c-55ad-2ac9eb9e5566@oracle.com> Message-ID: <870e3752-d5b4-0fdc-cb6d-07c1a899b6bd@oracle.com> I must surely have missed something because I could follow where the fix was going (which is strange for pending jumps-related changes :-) ). Congrats for the devious test. It's approved for me. Maurizio On 03/12/2019 16:37, Jan Lahoda wrote: > Hi, > > Consider code like: > boolean result = t ? true : (!(o1 instanceof String a3)); > > When javac starts to generate "(!(o1 instanceof String a3))", there is > the "false" jump pending. The "!" operator is generating its operand > in the genCond mode. But, the handling for LetExpr (into which the > pattern matching is translated) will not explicitly resolve the > pending jump (i.e. terminate the jump right before the code for ("o1 > instanceof String a3"). But as the desugared code for "o1 instanceof > String a3" will create a new variable, the pending jump is resolved at > the point the variable is generated - but that is already too late. > And hence an AssertionError, or other trouble may happen. > > The proposal is to resolve (terminate) the pending jumps before > generating a LetExpr in condition mode (as is done in non-condition > mode). > > A similar problem may happen for switch expressions, so the proposal > is to resolve the jumps for switch expressions as well. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8234899/webrev.00/ > JBS: > https://bugs.openjdk.java.net/browse/JDK-8234899 > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Tue Dec 3 22:47:23 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 3 Dec 2019 17:47:23 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <1c6520f1-90c2-aeee-706a-b4de9dafdaa0@oracle.com> Hi David, On 12/2/19 7:36 PM, David Holmes wrote: > Hi Vicente, > > I have also re-examined all the hotspot related code and everything > looks fine - and very neat (kudos to you and Harold!). thanks, yep Harold has made most of the work here, I just wrote the initial prototype a while ago, > > A couple of nits: > > src/hotspot/share/classfile/classFileParser.cpp > src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp > > Typo: > > + //??? u2 attributs_count; > > --- > > src/hotspot/share/classfile/javaClasses.cpp > > You are using CHECK_0 in RecordComponent::create but that method > returns oop. That seems wrong to me, but I see many other oop > returning methods also use CHECK_0 so I'll take that up separately. > (It's only a cosmetic issue.) > > --- > > test/hotspot/jtreg/runtime/records/abstractRecord.jcod > > 27 // This test is an Record marked as abstract. > > s/an/a/ > > --- > > Thanks, > David Thanks for the review, Vicente > ----- > > > On 28/11/2019 2:37 pm, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> From mandy.chung at oracle.com Tue Dec 3 23:32:11 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 Dec 2019 15:32:11 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Vicente, I reviewed jvm.h, jvm.cpp, and the changes in java.base but only skimmed on the serialization change from this version: http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ Class::getRecordComponents ?? - JVM_GetRecordComponents creates a new RecordComponent array or a zero-length array if not a record.?? The copying is not needed. I would recommend to include the spec of JVM_GetRecordComponents in jvm.h. Class.c 80 {"getRecordComponents0", "()[" OBJ, (void *)&JVM_GetRecordComponents}, 81 {"isRecord0", "()Z", (void *)&JVM_IsRecord}, Formatting nit: the new lines can be aligned with the existing lines/columns. java/lang/runtime/package-info.java.html I think this package summary should also have @PreviewFeature, shouldn't it? RecordComponent.java 247 * Return the record class which declares this record component. s/Return/Returns/ to be consistent with other methods. I'd expect that the webrev should show the runtime tests are renamed rather than hg add/hg remove (that would make it easier to review). Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Wed Dec 4 09:58:04 2019 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Wed, 4 Dec 2019 15:28:04 +0530 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Vicente, I made one more pass over the code - Overall looks good to me and I don't have additional comments over and above the comments shared so far. +1 Thanks Srikanth On 28/11/19 10:07 AM, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and > more! Must of the code has been reviewed but there have been some > changes since reviewers saw it. Also this is the first time an > integral webrev is sent out for review. Last changes on top of my mind > since last review iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as > a reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from > the record components, then it is considered the canonical > constructor. And any canonical constructor should satisfy a set of > restrictions, see section 8.10.4 Record Constructor Declarations of > the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not > explicitly invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes > mentioned before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection > and serialization, > > TIA, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From vicente.romero at oracle.com Wed Dec 4 14:07:56 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 4 Dec 2019 09:07:56 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <3cc46428-7ab4-a9bc-0c4d-c6a674b8f080@oracle.com> Hi, Thanks a lot to all reviewers. This is the header of the changeset I'm planning to push. There have been a ton of people working on the development and / or the review process and I don't want to forget anyone. Please let me know if I'm missing someone: 8225054: Compiler implementation for records 8225052: javax.lang.model support for records 8225053: Preview APIs support for records 8225055: Javadoc for records 8226314: com.sun.source support for records 8227113: Specification for java.lang.Record 8233526: JVM support for records Summary: implementation of records in the compiler and the JVM, including serialization, reflection and APIs support Reviewed-by: mcimadamore, briangoetz, alanb, darcy, jrose, jlahoda, coleenp, dholmes, lfoltan, mchung, sadayapalam, hannesw Contributed-by: vicente.romero at oracle.com, brian.goetz at oracle.com, maurizio.cimadamore at oracle.com, harold.seigel at oracle.com, joe.darcy at oracle.com, jonathan.gibbons at oracle.com, chris.hegarty at oracle.com, jan.lahoda at oracle.com Thanks to all, Vicente From vicente.romero at oracle.com Wed Dec 4 17:49:41 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 4 Dec 2019 12:49:41 -0500 Subject: REF: problem-listing two tests as part of the records change Message-ID: <4fe27c16-72b0-c941-3e2a-8c505c2cd5e2@oracle.com> Please review this small change to the problem list. This change will be part of the records effort. These two tests are failing right now but we plan to fix this asap. As the change is two small I have inlined it here: diff -r f90eefff864e -r cb15096bd3ec test/langtools/ProblemList.txt --- a/test/langtools/ProblemList.txt??? Tue Dec 03 20:23:53 2019 -0800 +++ b/test/langtools/ProblemList.txt??? Wed Dec 04 11:10:33 2019 -0500 @@ -37,6 +37,7 @@ ?jdk/jshell/UserJdiUserRemoteTest.java 8173079??? linux-all ?jdk/jshell/UserInputTest.java 8169536??? generic-all +jdk/jshell/CompletenessTest.java 8235338??? generic-all ?########################################################################### ?# @@ -55,6 +56,7 @@ ?tools/javac/modules/SourceInSymlinkTest.java 8180263??? windows-all??? fails when run on a subst drive ?tools/javac/importscope/T8193717.java 8203925??? generic-all??? the test requires too much memory ?tools/javac/options/BCPOrSystemNotSpecified.java 8231179??? windows-all??? fails when creating a test bootclasspath +tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java 8235339??? generic-all??? fails after new annotation target RECORD_COMPONENT was introduced ?########################################################################### ?# Thanks, Vicente From james.laskey at oracle.com Wed Dec 4 19:03:14 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 4 Dec 2019 15:03:14 -0400 Subject: RFR: JDK-8232681 ArrayIndexOutOfBoundsException with text blocks in javac when using -Xlint Message-ID: <4E3F5711-BC4B-44B2-8C0E-5FE36C6222F1@oracle.com> Please review this small changeset. Missing an empty array check. Thank you. Cheers, -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8232681/webrev.01/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8232681 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Thu Dec 5 02:10:32 2019 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 5 Dec 2019 07:40:32 +0530 Subject: RFR: JDK-8232681 ArrayIndexOutOfBoundsException with text blocks in javac when using -Xlint In-Reply-To: <4E3F5711-BC4B-44B2-8C0E-5FE36C6222F1@oracle.com> References: <4E3F5711-BC4B-44B2-8C0E-5FE36C6222F1@oracle.com> Message-ID: <413615e8-a349-63a1-b773-c66d1cb4d680@oracle.com> Looks good. -Sundar On 05/12/19 12:33 am, Jim Laskey wrote: > Please review this small changeset. Missing an empty array check. > Thank you. > > Cheers, > > -- Jim > > > webrev: http://cr.openjdk.java.net/~jlaskey/8232681/webrev.01/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8232681 > > From james.laskey at oracle.com Thu Dec 5 02:38:30 2019 From: james.laskey at oracle.com (James Laskey) Date: Wed, 4 Dec 2019 22:38:30 -0400 Subject: RFR: JDK-8232681 ArrayIndexOutOfBoundsException with text blocks in javac when using -Xlint In-Reply-To: <413615e8-a349-63a1-b773-c66d1cb4d680@oracle.com> References: <413615e8-a349-63a1-b773-c66d1cb4d680@oracle.com> Message-ID: <8A17C11A-7995-4D41-B7B3-1B1717A9295C@oracle.com> Thank you. On the road. > On Dec 4, 2019, at 10:10 PM, sundararajan.athijegannathan at oracle.com wrote: > > ?Looks good. > > -Sundar > >> On 05/12/19 12:33 am, Jim Laskey wrote: >> Please review this small changeset. Missing an empty array check. Thank you. >> >> Cheers, >> >> -- Jim >> >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8232681/webrev.01/index.html >> jbs: https://bugs.openjdk.java.net/browse/JDK-8232681 >> >> From joe.darcy at oracle.com Thu Dec 5 03:29:46 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 4 Dec 2019 19:29:46 -0800 Subject: JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters Message-ID: <3edf8df2-c800-0c03-7078-6b86301e5295@oracle.com> Hello, First on the build front, the -source/-target used in the bootstrap build of langtools was stuck at 9; in the change I'm proposing to update it to 13, the minimum boot JDK: --- old/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:42.209000999 -0800 +++ new/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:41.925000999 -0800 @@ -345,7 +345,7 @@ ?? # When compiling code to be executed by the Boot JDK, force compatibility with the ?? # oldest supported bootjdk. -? BOOT_JDK_SOURCETARGET="-source 9 -target 9" +? BOOT_JDK_SOURCETARGET="-source 13 -target 13" ?? AC_SUBST(BOOT_JDK_SOURCETARGET) ?? AC_SUBST(JAVAC_FLAGS) This should get added to the list of files updated when the boot JDK is revved. On the javax.lang.model front, with the changes for records pushed into JDK 14 there is now a ElementScanner14 class and I think it is time to address ??? JDK-8224630: ElementScannerN, N > 9 should scan type parameters ??? http://cr.openjdk.java.net/~darcy/8224630.0/ ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235371 As the bug title implies, the existing scanner classes don't touch type parameters, which is arguably a bug. The scanners mostly touch enclosed elements, but they do also touch method/constructor parameters which are not considered to be enclosed elements. In its current form, the webrev relies on the test previously added for RoundEnvironment. However, I acknowledge it would be possible to add tests for this particular change. Thanks, -Joe From maurizio.cimadamore at oracle.com Thu Dec 5 08:51:59 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Dec 2019 08:51:59 +0000 Subject: JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters In-Reply-To: <3edf8df2-c800-0c03-7078-6b86301e5295@oracle.com> References: <3edf8df2-c800-0c03-7078-6b86301e5295@oracle.com> Message-ID: Looks good - I agree we should proactively update this on every release. Maurizio On 05/12/2019 03:29, Joe Darcy wrote: > Hello, > > First on the build front, the -source/-target used in the bootstrap > build of langtools was stuck at 9; in the change I'm proposing to > update it to 13, the minimum boot JDK: > > --- old/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:42.209000999 -0800 > +++ new/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:41.925000999 -0800 > @@ -345,7 +345,7 @@ > > ?? # When compiling code to be executed by the Boot JDK, force > compatibility with the > ?? # oldest supported bootjdk. > -? BOOT_JDK_SOURCETARGET="-source 9 -target 9" > +? BOOT_JDK_SOURCETARGET="-source 13 -target 13" > ?? AC_SUBST(BOOT_JDK_SOURCETARGET) > > ?? AC_SUBST(JAVAC_FLAGS) > > This should get added to the list of files updated when the boot JDK > is revved. > > On the javax.lang.model front, with the changes for records pushed > into JDK 14 there is now a ElementScanner14 class and I think it is > time to address > > ??? JDK-8224630: ElementScannerN, N > 9 should scan type parameters > ??? http://cr.openjdk.java.net/~darcy/8224630.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235371 > > As the bug title implies, the existing scanner classes don't touch > type parameters, which is arguably a bug. The scanners mostly touch > enclosed elements, but they do also touch method/constructor > parameters which are not considered to be enclosed elements. > > In its current form, the webrev relies on the test previously added > for RoundEnvironment. However, I acknowledge it would be possible to > add tests for this particular change. > > Thanks, > > -Joe > From bsrbnd at gmail.com Thu Dec 5 10:52:25 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 5 Dec 2019 11:52:25 +0100 Subject: JDK-8221373 (?) Missing checkcast in void-returning lambda In-Reply-To: <6ed97ac4-cb92-288b-f1e1-e7571e5312a3@oracle.com> References: <6ed97ac4-cb92-288b-f1e1-e7571e5312a3@oracle.com> Message-ID: Hi Maurizio, Thanks for the confirmation, your analysis is similar to my past JBS comment. Should I then close this issues as "won't fix"? Ciao, Bernard On Tue, 3 Dec 2019 at 16:46, Maurizio Cimadamore wrote: > > Hi, > sorry for the delay. I've checked JDK-8221373 and, honestly, I'm not > sure there's anything to fix. Synthetic casts are only emitted when > there's a target. If you rewrite the example, dropping the lambda > expression: > > abstract class Test { > > interface I { > X d(); > } > > abstract I c(); > > void f() { > this.c().d(); //1 > } > } > > The callsite in (1) is translated as follows: > > 0: aload_0 > 1: invokevirtual #2 // Method c:()LTest$I; > 4: invokeinterface #3, 1 // InterfaceMethod > Test$I.d:()Ljava/lang/Object; > 9: pop > 10: return > > Again, no checkcast here. So I'd say that the fix we did back than > brought consistency between these two cases, which is IMHO, a good thing. > > Maurizio > > On 30/10/2019 12:40, B. Blaser wrote: > > Hi, > > > > Looking a bit at JDK-8221373, I'd like to make sure we are going in > > the right direction before posting a RFR. > > > > Going back to JDK-8203338, we decided in [1] to take the functional > > descriptor's erased return type as translation target which might > > cause some side-effects like in Liam's void-returning lambda where no > > 'checkcast' are emitted anymore. > > So my question is rather simple, should we put in place something > > closer to the initial fix I suggested in [2] to preserve the original > > erased expression typing? > > > > Thanks, > > Bernard > > > > [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012086.html > > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012076.html From maurizio.cimadamore at oracle.com Thu Dec 5 10:53:18 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Dec 2019 10:53:18 +0000 Subject: JDK-8221373 (?) Missing checkcast in void-returning lambda In-Reply-To: References: <6ed97ac4-cb92-288b-f1e1-e7571e5312a3@oracle.com> Message-ID: <309d72a7-569c-52f1-98c7-9490ab5862f7@oracle.com> I believe so, thanks Maurizio On 05/12/2019 10:52, B. Blaser wrote: > Hi Maurizio, > > Thanks for the confirmation, your analysis is similar to my past JBS comment. > Should I then close this issues as "won't fix"? > > Ciao, > Bernard > > On Tue, 3 Dec 2019 at 16:46, Maurizio Cimadamore > wrote: >> Hi, >> sorry for the delay. I've checked JDK-8221373 and, honestly, I'm not >> sure there's anything to fix. Synthetic casts are only emitted when >> there's a target. If you rewrite the example, dropping the lambda >> expression: >> >> abstract class Test { >> >> interface I { >> X d(); >> } >> >> abstract I c(); >> >> void f() { >> this.c().d(); //1 >> } >> } >> >> The callsite in (1) is translated as follows: >> >> 0: aload_0 >> 1: invokevirtual #2 // Method c:()LTest$I; >> 4: invokeinterface #3, 1 // InterfaceMethod >> Test$I.d:()Ljava/lang/Object; >> 9: pop >> 10: return >> >> Again, no checkcast here. So I'd say that the fix we did back than >> brought consistency between these two cases, which is IMHO, a good thing. >> >> Maurizio >> >> On 30/10/2019 12:40, B. Blaser wrote: >>> Hi, >>> >>> Looking a bit at JDK-8221373, I'd like to make sure we are going in >>> the right direction before posting a RFR. >>> >>> Going back to JDK-8203338, we decided in [1] to take the functional >>> descriptor's erased return type as translation target which might >>> cause some side-effects like in Liam's void-returning lambda where no >>> 'checkcast' are emitted anymore. >>> So my question is rather simple, should we put in place something >>> closer to the initial fix I suggested in [2] to preserve the original >>> erased expression typing? >>> >>> Thanks, >>> Bernard >>> >>> [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012086.html >>> [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012076.html From jan.lahoda at oracle.com Thu Dec 5 15:59:37 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 5 Dec 2019 16:59:37 +0100 Subject: RFR; JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records Message-ID: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> Hi, This is a patch to improve the behavior of jshell w.r.t. records, including fixing the recently problem-listed CompletenessTest.java. Notes on the patch: -added jdk.jshell.Snippet.SubKind.RECORD_SUBKIND, similar to ENUM_SUBKIND. CSR for this change for review is here: https://bugs.openjdk.java.net/browse/JDK-8235421 -moved setting the record final from JavacParsert to Check.checkFlags (as jshell was struggling with the modifier being set in parser, and checkFlags seems to be a better place anyway) -improved JavacParser.isRecordStart to take EOF into account - this could be moved to jshell if too dangerous, but might be good for javac for error recovery -Pretty (JCClassDecl.toString()) should now print records as records instead of classes. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8235338/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8235338 How does this look? Thanks, Jan From erik.joelsson at oracle.com Thu Dec 5 17:06:25 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 5 Dec 2019 09:06:25 -0800 Subject: JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters In-Reply-To: <3edf8df2-c800-0c03-7078-6b86301e5295@oracle.com> References: <3edf8df2-c800-0c03-7078-6b86301e5295@oracle.com> Message-ID: <58ec9c21-fc46-589f-5ff2-b0c223b04cc1@oracle.com> On 2019-12-04 19:29, Joe Darcy wrote: > Hello, > > First on the build front, the -source/-target used in the bootstrap > build of langtools was stuck at 9; in the change I'm proposing to > update it to 13, the minimum boot JDK: > > --- old/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:42.209000999 -0800 > +++ new/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:41.925000999 -0800 > @@ -345,7 +345,7 @@ > > ?? # When compiling code to be executed by the Boot JDK, force > compatibility with the > ?? # oldest supported bootjdk. > -? BOOT_JDK_SOURCETARGET="-source 9 -target 9" > +? BOOT_JDK_SOURCETARGET="-source 13 -target 13" > ?? AC_SUBST(BOOT_JDK_SOURCETARGET) > I had missed this configuration. Ideally I want all the versions that need updating for each new release collected into the version-numbers file, or even better, be derived from existing numbers in there. Would it be ok to just derive this number from the list of valid bootjdk versions? /Erik > AC_SUBST(JAVAC_FLAGS) > > This should get added to the list of files updated when the boot JDK > is revved. > > On the javax.lang.model front, with the changes for records pushed > into JDK 14 there is now a ElementScanner14 class and I think it is > time to address > > ??? JDK-8224630: ElementScannerN, N > 9 should scan type parameters > ??? http://cr.openjdk.java.net/~darcy/8224630.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235371 > > As the bug title implies, the existing scanner classes don't touch > type parameters, which is arguably a bug. The scanners mostly touch > enclosed elements, but they do also touch method/constructor > parameters which are not considered to be enclosed elements. > > In its current form, the webrev relies on the test previously added > for RoundEnvironment. However, I acknowledge it would be possible to > add tests for this particular change. > > Thanks, > > -Joe > From joe.darcy at oracle.com Thu Dec 5 17:20:29 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 5 Dec 2019 09:20:29 -0800 Subject: JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters In-Reply-To: <58ec9c21-fc46-589f-5ff2-b0c223b04cc1@oracle.com> References: <3edf8df2-c800-0c03-7078-6b86301e5295@oracle.com> <58ec9c21-fc46-589f-5ff2-b0c223b04cc1@oracle.com> Message-ID: On 12/5/2019 9:06 AM, Erik Joelsson wrote: > On 2019-12-04 19:29, Joe Darcy wrote: >> Hello, >> >> First on the build front, the -source/-target used in the bootstrap >> build of langtools was stuck at 9; in the change I'm proposing to >> update it to 13, the minimum boot JDK: >> >> --- old/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:42.209000999 -0800 >> +++ new/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:41.925000999 -0800 >> @@ -345,7 +345,7 @@ >> >> ?? # When compiling code to be executed by the Boot JDK, force >> compatibility with the >> ?? # oldest supported bootjdk. >> -? BOOT_JDK_SOURCETARGET="-source 9 -target 9" >> +? BOOT_JDK_SOURCETARGET="-source 13 -target 13" >> ?? AC_SUBST(BOOT_JDK_SOURCETARGET) >> > I had missed this configuration. Ideally I want all the versions that > need updating for each new release collected into the version-numbers > file, or even better, be derived from existing numbers in there. Would > it be ok to just derive this number from the list of valid bootjdk > versions? I agree deriving the source/target values from a centralized version numbers location is preferable. I tracked down this file since I want to use "var" in this changeset, a Java 10 language feature, and got unexpected compilation errors. How about I push the current changes while a fuller build fix is worked on? -Joe From robert.field at oracle.com Thu Dec 5 19:23:55 2019 From: robert.field at oracle.com (Robert Field) Date: Thu, 5 Dec 2019 11:23:55 -0800 Subject: RFR; JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records In-Reply-To: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> References: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> Message-ID: Maybe it is just me, but adding support for records in JShell as well as seemingly correcting the compiler's processing of records under a bug for a JShell test failure seems inappropriate. Probably could be addressed by creating a RFE that covers it. I assume the CSR needs to be approved before this is pushed.? The CSR has the same naming issue. Otherwise looks fine. -Robert On 12/5/19 7:59 AM, Jan Lahoda wrote: > Hi, > > This is a patch to improve the behavior of jshell w.r.t. records, > including fixing the recently problem-listed CompletenessTest.java. > > Notes on the patch: > -added jdk.jshell.Snippet.SubKind.RECORD_SUBKIND, similar to > ENUM_SUBKIND. CSR for this change for review is here: > https://bugs.openjdk.java.net/browse/JDK-8235421 > -moved setting the record final from JavacParsert to Check.checkFlags > (as jshell was struggling with the modifier being set in parser, and > checkFlags seems to be a better place anyway) > -improved JavacParser.isRecordStart to take EOF into account - this > could be moved to jshell if too dangerous, but might be good for javac > for error recovery > -Pretty (JCClassDecl.toString()) should now print records as records > instead of classes. > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8235338/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235338 > > How does this look? > > Thanks, > ??? Jan From joe.darcy at oracle.com Thu Dec 5 19:38:32 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 5 Dec 2019 11:38:32 -0800 Subject: RFR; JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records In-Reply-To: References: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> Message-ID: On 12/5/2019 11:23 AM, Robert Field wrote: > Maybe it is just me, but adding support for records in JShell as well > as seemingly correcting the compiler's processing of records under a > bug for a JShell test failure seems inappropriate. Probably could be > addressed by creating a RFE that covers it. > > I assume the CSR needs to be approved before this is pushed.? The CSR > has the same naming issue. > Yes, that is the correct process; CSR approval before pushing. Thanks, -Joe From erik.joelsson at oracle.com Thu Dec 5 21:16:33 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 5 Dec 2019 13:16:33 -0800 Subject: JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters In-Reply-To: References: <3edf8df2-c800-0c03-7078-6b86301e5295@oracle.com> <58ec9c21-fc46-589f-5ff2-b0c223b04cc1@oracle.com> Message-ID: <4f08cd95-8b10-25ad-2376-470b4b347cd3@oracle.com> Fine with me. /Erik On 2019-12-05 09:20, Joe Darcy wrote: > On 12/5/2019 9:06 AM, Erik Joelsson wrote: >> On 2019-12-04 19:29, Joe Darcy wrote: >>> Hello, >>> >>> First on the build front, the -source/-target used in the bootstrap >>> build of langtools was stuck at 9; in the change I'm proposing to >>> update it to 13, the minimum boot JDK: >>> >>> --- old/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:42.209000999 >>> -0800 >>> +++ new/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:41.925000999 >>> -0800 >>> @@ -345,7 +345,7 @@ >>> >>> ?? # When compiling code to be executed by the Boot JDK, force >>> compatibility with the >>> ?? # oldest supported bootjdk. >>> -? BOOT_JDK_SOURCETARGET="-source 9 -target 9" >>> +? BOOT_JDK_SOURCETARGET="-source 13 -target 13" >>> ?? AC_SUBST(BOOT_JDK_SOURCETARGET) >>> >> I had missed this configuration. Ideally I want all the versions that >> need updating for each new release collected into the version-numbers >> file, or even better, be derived from existing numbers in there. >> Would it be ok to just derive this number from the list of valid >> bootjdk versions? > > > I agree deriving the source/target values from a centralized version > numbers location is preferable. I tracked down this file since I want > to use "var" in this changeset, a Java 10 language feature, and got > unexpected compilation errors. > > How about I push the current changes while a fuller build fix is > worked on? > > -Joe > From joe.darcy at oracle.com Thu Dec 5 21:22:51 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 5 Dec 2019 13:22:51 -0800 Subject: JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters In-Reply-To: <4f08cd95-8b10-25ad-2376-470b4b347cd3@oracle.com> References: <3edf8df2-c800-0c03-7078-6b86301e5295@oracle.com> <58ec9c21-fc46-589f-5ff2-b0c223b04cc1@oracle.com> <4f08cd95-8b10-25ad-2376-470b4b347cd3@oracle.com> Message-ID: <56eeb9c1-439a-e263-90a5-9b6e21863494@oracle.com> Thanks; filed JDK-8235445: "Update boot-jdk.m4 to derive -source/-target from centralized location". -Joe On 12/5/2019 1:16 PM, Erik Joelsson wrote: > Fine with me. > > /Erik > > On 2019-12-05 09:20, Joe Darcy wrote: >> On 12/5/2019 9:06 AM, Erik Joelsson wrote: >>> On 2019-12-04 19:29, Joe Darcy wrote: >>>> Hello, >>>> >>>> First on the build front, the -source/-target used in the bootstrap >>>> build of langtools was stuck at 9; in the change I'm proposing to >>>> update it to 13, the minimum boot JDK: >>>> >>>> --- old/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:42.209000999 >>>> -0800 >>>> +++ new/make/autoconf/boot-jdk.m4??? 2019-12-04 19:16:41.925000999 >>>> -0800 >>>> @@ -345,7 +345,7 @@ >>>> >>>> ?? # When compiling code to be executed by the Boot JDK, force >>>> compatibility with the >>>> ?? # oldest supported bootjdk. >>>> -? BOOT_JDK_SOURCETARGET="-source 9 -target 9" >>>> +? BOOT_JDK_SOURCETARGET="-source 13 -target 13" >>>> ?? AC_SUBST(BOOT_JDK_SOURCETARGET) >>>> >>> I had missed this configuration. Ideally I want all the versions >>> that need updating for each new release collected into the >>> version-numbers file, or even better, be derived from existing >>> numbers in there. Would it be ok to just derive this number from the >>> list of valid bootjdk versions? >> >> >> I agree deriving the source/target values from a centralized version >> numbers location is preferable. I tracked down this file since I want >> to use "var" in this changeset, a Java 10 language feature, and got >> unexpected compilation errors. >> >> How about I push the current changes while a fuller build fix is >> worked on? >> >> -Joe >> From jonathan.gibbons at oracle.com Thu Dec 5 21:35:56 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 5 Dec 2019 13:35:56 -0800 Subject: JDK-8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs Message-ID: <9eb7b090-095f-5fde-e634-f407330f614b@oracle.com> Please review a small change to javac, to use java.net.URL instead of java.nio.file.Path to evaluate the Class-Path in a JAR-file manifest. There is no test because: * the change mirrors a corresponding change in jdk.internal.loader.URLClassPath * the change is simple * it would be complicated to set up a multi-platform multi-protocol test The change is a subset of the code in URLClassPath (just the `tryResolveFile` method) because javac only supports the use of local JAR files (and not JAR files accessed by other URL protocols.) -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8218268 Webrev: http://cr.openjdk.java.net/~jjg/8218268/webrev/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Dec 6 01:22:44 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 5 Dec 2019 17:22:44 -0800 Subject: Annotation Processing issues on modules In-Reply-To: References: Message-ID: <7d2c482f-81fb-2e3c-6476-8a70cff28978@oracle.com> Forwarding to compiler-dev; dropping jdk-dev. -- Jon On 12/05/2019 04:01 PM, Jeremy Kuhn wrote: > Hi, > > I've been working lately on an IoC/DI framework for Java 9+ which relies on > annotation processing and code generation. I'm actually defining > annotations on modules and I discovered couple of bugs during the > processing of these annotations in the Java compiler. > > The first one is when we want to print a compilation message targeting a > module's annotation, it exists on all versions since JDK 9. Let's say we > have the following module descriptor: > > @SampleAnnotation > module sampleModule { > > } > > and a properly configured annotation processor to process the > @SampleAnnotation, if we do: > > this.processingEnv.getMessager().printMessage(Kind.MANDATORY_WARNING, > "Module warning", element, annotationMirror); > > where element corresponds to the sampleModule and annotationMirror to the > @SampleAnnotation, the compiler crash with a java.lang.AssertionError: > > An annotation processor threw an uncaught exception. > Consult the following stack trace for details. > java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitTree(JCTree.java:3235) > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitModuleDef(JCTree.java:3227) > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2780) > at > jdk.compiler/com.sun.tools.javac.model.JavacElements.matchAnnoToTree(JavacElements.java:298) > at > jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:743) > at > jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:108) > at > jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:87) > at > processor/com.example.processor.ModuleWarnProcessor.lambda$process$1(ModuleWarnProcessor.java:21) > at > java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) > at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) > at > java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274) > at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) > at > java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) > at > java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) > at > processor/com.example.processor.ModuleWarnProcessor.process(ModuleWarnProcessor.java:19) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1023) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:939) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1267) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1381) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1263) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:935) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) > > I've been able to track down the issue in > com.sun.tools.javac.model.JavacElements#matchAnnoToTree(), the Vis class > does not implement the visitModuleDef() method and as a result it is not > possible to find module's annotations hence the AssertionError. > > The second issue occurs when you want to use imports in a module-info.java > file, if you do so the file is simply ignored during annotation processing. > This issue also exists on all versions since JDK 9. Let's say we have the > following module descriptor: > > import com.example.SampleAnnotation; > > @SampleAnnotation > module sampleModule { > > } > > and a properly configured annotation processor to process the > @com.example.SampleAnnotation, the compiler simply doesn't take the module > into account when processing annotation. > > I've been able to track down the issue in > com.sun.tools.javac.processing.JavacProcessingEnvironment#getModuleInfoFiles() > > private List getModuleInfoFiles(List JCCompilationUnit> units) { > List modules = List.nil(); > for (JCCompilationUnit unit : units) { > if (isModuleInfo(unit.sourcefile, JavaFileObject.Kind.SOURCE) && > unit.defs.nonEmpty() && > unit.defs.head.hasTag(Tag.MODULEDEF)) { > modules = modules.prepend(unit.modle); > } > } > return modules.reverse(); > } > > Here it is assumed that the first unit in a module descriptor has to be a > module statement however according to the java language specification, a > module descriptor can have import statements before (and this actually > compiles just fine) as a result the module is not added to the list of > modules candidates for annotation processing. > > I've also found another more tricky one which relates to the usage of > deprecated module in the module providing the annotation processor: if we > create a module which depends on a jdk deprecated module and which provides > an annotation processor, having that module on the processor module path > will make the compiler to return with nothing compiled, no error and no > output. I didn't dig too much into this as this only impacts jdk9 which > comes with deprecated modules (eg. java.se.ee), later versions don't have > any issues for now. I've stopped my investigation in the > java.lang.module.Resolver class line 181, deprecated modules are actually > not resolved. > > I have prepared patches with jtreg tests for the first two issues on the > repository head and I'd be happy to submit them. Please let me know if the > description of the issues is clear enough and how we can proceed to fix > them, I've already signed the OCA. > > Jeremy From jonathan.gibbons at oracle.com Fri Dec 6 01:48:27 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 5 Dec 2019 17:48:27 -0800 Subject: Annotation Processing issues on modules In-Reply-To: <7d2c482f-81fb-2e3c-6476-8a70cff28978@oracle.com> References: <7d2c482f-81fb-2e3c-6476-8a70cff28978@oracle.com> Message-ID: Jeremy, Thanks for all the details you have provided here, and for all the investigations you have done. It certainly sounds like you have done a great job to track down the issues. I've created two separate JBS entries for the issues you describe. JDK-8235457: Crash when reporting a message about an annotation on a module https://bugs.openjdk.java.net/browse/JDK-8235457 JDK-8235458: Problem caused by imports in a module-info.java file https://bugs.openjdk.java.net/browse/JDK-8235458 It would help if we could use separate mail threads for the two separate issues, perhaps using the specific JBS issue number in the subject line. If you can post your patches to this list (compiler-dev at openjdk.java.net) we can get them turned into webrevs for you and start a review for each of them. -- Jon On 12/05/2019 05:22 PM, Jonathan Gibbons wrote: > Forwarding to compiler-dev; dropping jdk-dev. > > -- Jon > > > On 12/05/2019 04:01 PM, Jeremy Kuhn wrote: >> Hi, >> >> I've been working lately on an IoC/DI framework for Java 9+ which >> relies on >> annotation processing and code generation. I'm actually defining >> annotations on modules and I discovered couple of bugs during the >> processing of these annotations in the Java compiler. >> >> The first one is when we want to print a compilation message targeting a >> module's annotation, it exists on all versions since JDK 9. Let's say we >> have the following module descriptor: >> >> ???? @SampleAnnotation >> ???? module sampleModule { >> >> ???? } >> >> and a properly configured annotation processor to process the >> @SampleAnnotation, if we do: >> >> this.processingEnv.getMessager().printMessage(Kind.MANDATORY_WARNING, >> "Module warning", element, annotationMirror); >> >> where element corresponds to the sampleModule and annotationMirror to >> the >> @SampleAnnotation, the compiler crash with a java.lang.AssertionError: >> >> An annotation processor threw an uncaught exception. >> Consult the following stack trace for details. >> java.lang.AssertionError >> ????? at >> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >> ????? at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitTree(JCTree.java:3235) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitModuleDef(JCTree.java:3227) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2780) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.model.JavacElements.matchAnnoToTree(JavacElements.java:298) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:743) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:108) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:87) >> >> ????? at >> processor/com.example.processor.ModuleWarnProcessor.lambda$process$1(ModuleWarnProcessor.java:21) >> >> ????? at >> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) >> >> ????? at >> java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) >> ????? at >> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) >> >> ????? at >> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) >> >> ????? at >> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274) >> >> ????? at >> java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) >> ????? at >> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) >> >> ????? at >> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) >> >> ????? at >> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) >> >> ????? at >> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) >> >> ????? at >> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) >> >> ????? at >> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) >> >> ????? at >> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) >> >> ????? at >> processor/com.example.processor.ModuleWarnProcessor.process(ModuleWarnProcessor.java:19) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1023) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:939) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1267) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1381) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1263) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:935) >> >> ????? at >> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) >> ????? at >> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) >> ????? at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >> ????? at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >> >> I've been able to track down the issue in >> com.sun.tools.javac.model.JavacElements#matchAnnoToTree(), the Vis class >> does not implement the visitModuleDef() method and as a result it is not >> possible to find module's annotations hence the AssertionError. >> >> The second issue occurs when you want to use imports in a >> module-info.java >> file, if you do so the file is simply ignored during annotation >> processing. >> This issue also exists on all versions since JDK 9. Let's say we have >> the >> following module descriptor: >> >> ???? import com.example.SampleAnnotation; >> >> ???? @SampleAnnotation >> ???? module sampleModule { >> >> ???? } >> >> and a properly configured annotation processor to process the >> @com.example.SampleAnnotation, the compiler simply doesn't take the >> module >> into account when processing annotation. >> >> I've been able to track down the issue in >> com.sun.tools.javac.processing.JavacProcessingEnvironment#getModuleInfoFiles() >> >> >> ???? private List getModuleInfoFiles(List> JCCompilationUnit> units) { >> ???????? List modules = List.nil(); >> ???????? for (JCCompilationUnit unit : units) { >> ???????????? if (isModuleInfo(unit.sourcefile, >> JavaFileObject.Kind.SOURCE) && >> ???????????????? unit.defs.nonEmpty() && >> ???????????????? unit.defs.head.hasTag(Tag.MODULEDEF)) { >> ???????????????? modules = modules.prepend(unit.modle); >> ???????????? } >> ???????? } >> ???????? return modules.reverse(); >> ???? } >> >> Here it is assumed that the first unit in a module descriptor has to >> be a >> module statement however according to the java language specification, a >> module descriptor can have import statements before (and this actually >> compiles just fine) as a result the module is not added to the list of >> modules candidates for annotation processing. >> >> I've also found another more tricky one which relates to the usage of >> deprecated module in the module providing the annotation processor: >> if we >> create a module which depends on a jdk deprecated module and which >> provides >> an annotation processor, having that module on the processor module path >> will make the compiler to return with nothing compiled, no error and no >> output. I didn't dig too much into this as this only impacts jdk9 which >> comes with deprecated modules (eg. java.se.ee), later versions don't >> have >> any issues for now. I've stopped my investigation in the >> java.lang.module.Resolver class line 181, deprecated modules are >> actually >> not resolved. >> >> I have prepared patches with jtreg tests for the first two issues on the >> repository head and I'd be happy to submit them. Please let me know >> if the >> description of the issues is clear enough and how we can proceed to fix >> them, I've already signed the OCA. >> >> Jeremy > From jonathan.gibbons at oracle.com Fri Dec 6 02:13:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 5 Dec 2019 18:13:31 -0800 Subject: RFR: JDK-8234211 allow discoverable javac plugins to be invoked by default Message-ID: <32067f97-be1a-d90d-d591-f08ac8210d09@oracle.com> Please review a small change to javac to allow plugins to opt-in to being automatically started by default if not started explicitly. The CSR for the API change has already been approved. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8234211 CSR: https://bugs.openjdk.java.net/browse/JDK-8234683 Webrev: http://cr.openjdk.java.net/~jjg/8234211/webrev.00/ From jonathan.gibbons at oracle.com Fri Dec 6 02:23:07 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 5 Dec 2019 18:23:07 -0800 Subject: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file Message-ID: <58755ce3-bf25-993f-2749-86b8407d969d@oracle.com> Please review a small change to javac to permit friendly clients to inject additional attributes into a class file. This supersedes and generalizes an existing mechanism which is difficult/impractical to use, especially in current versions of javac where split packages are strongly discouraged. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8234689 Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.00/ From jan.lahoda at oracle.com Fri Dec 6 07:57:07 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 6 Dec 2019 08:57:07 +0100 Subject: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file In-Reply-To: <58755ce3-bf25-993f-2749-86b8407d969d@oracle.com> References: <58755ce3-bf25-993f-2749-86b8407d969d@oracle.com> Message-ID: <83141923-616a-f477-d57e-e690bdc20381@oracle.com> Overall looks OK to me. Not sure if it would make sense to keep the existing method? The test will need tweaks for @bug and @summary. Jan On 06. 12. 19 3:23, Jonathan Gibbons wrote: > Please review a small change to javac to permit friendly clients to > inject additional attributes into a class file. > > This supersedes and generalizes an existing mechanism which is > difficult/impractical to use, especially > in current versions of javac where split packages are strongly discouraged. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234689 > Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.00/ > From jan.lahoda at oracle.com Fri Dec 6 11:38:53 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 6 Dec 2019 12:38:53 +0100 Subject: RFR: JDK-8235474: JShell does not handle records properly Message-ID: <8419cdd2-56bd-e16b-099a-90b3b64283c1@oracle.com> Hi, As a spin-off from: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014001.html I propose to improve the record handling in jshell. Please see the original post for some more details. Webrev: http://cr.openjdk.java.net/~jlahoda/8235474/webrev.00/ CSR for review: https://bugs.openjdk.java.net/browse/JDK-8235476 JBS: https://bugs.openjdk.java.net/browse/JDK-8235474 How does this look? Thanks, Jan From jan.lahoda at oracle.com Fri Dec 6 11:53:37 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 6 Dec 2019 12:53:37 +0100 Subject: RFR; JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records In-Reply-To: References: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> Message-ID: <3d13e3a3-3c6c-0c4f-14fc-ff4e7949e995@oracle.com> On 05. 12. 19 20:23, Robert Field wrote: > Maybe it is just me, but adding support for records in JShell as well as > seemingly correcting the compiler's processing of records under a bug > for a JShell test failure seems inappropriate. Probably could be > addressed by creating a RFE that covers it. The test failure is directly caused by the incorrect support for records in JShell. Basically, the only thing in the patch that does not have a fairly close connection to the test is the fix for Pretty. But I am OK with splitting the reports, so I've created: https://bugs.openjdk.java.net/browse/JDK-8235474 and submitted: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014014.html The patch for this bug then depends on JDK-8235474 and is here: http://cr.openjdk.java.net/~jlahoda/8235338/webrev.01/ The CSR is no longer needed for this particular bug (although it is still needed for JDK-8235474). Also moving compiler-dev on CC, since this is no longer a javac patch. Jan > > I assume the CSR needs to be approved before this is pushed.? The CSR > has the same naming issue. > > Otherwise looks fine. > > -Robert > > > On 12/5/19 7:59 AM, Jan Lahoda wrote: >> Hi, >> >> This is a patch to improve the behavior of jshell w.r.t. records, >> including fixing the recently problem-listed CompletenessTest.java. >> >> Notes on the patch: >> -added jdk.jshell.Snippet.SubKind.RECORD_SUBKIND, similar to >> ENUM_SUBKIND. CSR for this change for review is here: >> https://bugs.openjdk.java.net/browse/JDK-8235421 >> -moved setting the record final from JavacParsert to Check.checkFlags >> (as jshell was struggling with the modifier being set in parser, and >> checkFlags seems to be a better place anyway) >> -improved JavacParser.isRecordStart to take EOF into account - this >> could be moved to jshell if too dangerous, but might be good for javac >> for error recovery >> -Pretty (JCClassDecl.toString()) should now print records as records >> instead of classes. >> >> Proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8235338/webrev.00/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235338 >> >> How does this look? >> >> Thanks, >> ??? Jan From vicente.romero at oracle.com Fri Dec 6 12:21:49 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 6 Dec 2019 07:21:49 -0500 Subject: REF: JDK-8235446: confusing error message for records with no parens Message-ID: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> Please review this simple fix [1] to a bug [2] reported yesterday on amber-dev by Tagir. This fix is just improving the current error message shown for code like: record R {} instead of the current: class, record, etc expected it prints: "incorrect record declaration", how does it looks? Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8235446/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8235446 From vicente.romero at oracle.com Fri Dec 6 12:58:11 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 6 Dec 2019 07:58:11 -0500 Subject: RFR: JDK-8235474: JShell does not handle records properly In-Reply-To: <8419cdd2-56bd-e16b-099a-90b3b64283c1@oracle.com> References: <8419cdd2-56bd-e16b-099a-90b3b64283c1@oracle.com> Message-ID: <4f657b13-a0bc-f52f-fda0-4652fd89b09b@oracle.com> Hi Jan, The CSR and the patch look good to me. Nit, the local variable `isDatum` could be renamed to `isRecord`, Thanks for fixing this, Vicente On 12/6/19 6:38 AM, Jan Lahoda wrote: > Hi, > > As a spin-off from: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014001.html > > > I propose to improve the record handling in jshell. Please see the > original post for some more details. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8235474/webrev.00/ > CSR for review: https://bugs.openjdk.java.net/browse/JDK-8235476 > JBS: https://bugs.openjdk.java.net/browse/JDK-8235474 > > How does this look? > > Thanks, > ??? Jan From maurizio.cimadamore at oracle.com Fri Dec 6 13:49:01 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 13:49:01 +0000 Subject: REF: JDK-8235446: confusing error message for records with no parens In-Reply-To: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> References: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> Message-ID: <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> Hi, few comments: * is the call to checkSourceLevel needed? After all you already check for enable-preview * I think the error message should just be: "record components expected" (and perhaps we should move the position of the error message to _after_ the record keyword). Maurizio On 06/12/2019 12:21, Vicente Romero wrote: > Please review this simple fix [1] to a bug [2] reported yesterday on > amber-dev by Tagir. This fix is just improving the current error > message shown for code like: > > record R {} > > instead of the current: class, record, etc expected it prints: > "incorrect record declaration", how does it looks? > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8235446/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8235446 From maurizio.cimadamore at oracle.com Fri Dec 6 13:50:56 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 13:50:56 +0000 Subject: REF: JDK-8235446: confusing error message for records with no parens In-Reply-To: <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> References: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> Message-ID: On 06/12/2019 13:49, Maurizio Cimadamore wrote: > "record components expected" Actually, "record header expected" might be even better (that term appears in the JLS). Maurizio From amaembo at gmail.com Fri Dec 6 14:13:48 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 6 Dec 2019 21:13:48 +0700 Subject: REF: JDK-8235446: confusing error message for records with no parens In-Reply-To: References: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> Message-ID: Hello! "record header expected" sounds good to me. Thank you for fixing this! With best regards, Tagir Valeev ??, 6 ???. 2019 ?., 20:53 Maurizio Cimadamore < maurizio.cimadamore at oracle.com>: > > On 06/12/2019 13:49, Maurizio Cimadamore wrote: > > "record components expected" > > Actually, "record header expected" might be even better (that term > appears in the JLS). > > Maurizio > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Dec 6 14:19:16 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 6 Dec 2019 09:19:16 -0500 Subject: REF: JDK-8235446: confusing error message for records with no parens In-Reply-To: <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> References: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> Message-ID: <8fad23d0-0e43-3056-a741-3538a3b43ff7@oracle.com> On 12/6/19 8:49 AM, Maurizio Cimadamore wrote: > Hi, > few comments: > > * is the call to checkSourceLevel needed? After all you already check > for enable-preview the thing is that checkSourceLevel prints the warning messages that you are using a preview feature etc, that's why I put it there > > * I think the error message should just be: > > "record components expected" > > (and perhaps we should move the position of the error message to > _after_ the record keyword). ok changing the error message to: "record header expected" > > Maurizio Thanks, Vicente > > On 06/12/2019 12:21, Vicente Romero wrote: >> Please review this simple fix [1] to a bug [2] reported yesterday on >> amber-dev by Tagir. This fix is just improving the current error >> message shown for code like: >> >> record R {} >> >> instead of the current: class, record, etc expected it prints: >> "incorrect record declaration", how does it looks? >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8235446/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8235446 From maurizio.cimadamore at oracle.com Fri Dec 6 14:24:09 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 14:24:09 +0000 Subject: REF: JDK-8235446: confusing error message for records with no parens In-Reply-To: <8fad23d0-0e43-3056-a741-3538a3b43ff7@oracle.com> References: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> <8fad23d0-0e43-3056-a741-3538a3b43ff7@oracle.com> Message-ID: <88081c5a-b1e6-50e5-fef1-383edd67e984@oracle.com> On 06/12/2019 14:19, Vicente Romero wrote: > > > On 12/6/19 8:49 AM, Maurizio Cimadamore wrote: >> Hi, >> few comments: >> >> * is the call to checkSourceLevel needed? After all you already check >> for enable-preview > > the thing is that checkSourceLevel prints the warning messages that > you are using a preview feature etc, that's why I put it there Ah! forgot thanks. > >> >> * I think the error message should just be: >> >> "record components expected" >> >> (and perhaps we should move the position of the error message to >> _after_ the record keyword). > > ok changing the error message to: "record header expected" >> >> Maurizio > > Thanks, > Vicente > >> >> On 06/12/2019 12:21, Vicente Romero wrote: >>> Please review this simple fix [1] to a bug [2] reported yesterday on >>> amber-dev by Tagir. This fix is just improving the current error >>> message shown for code like: >>> >>> record R {} >>> >>> instead of the current: class, record, etc expected it prints: >>> "incorrect record declaration", how does it looks? >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8235446/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8235446 > From vicente.romero at oracle.com Fri Dec 6 14:28:03 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 6 Dec 2019 09:28:03 -0500 Subject: REF: JDK-8235446: confusing error message for records with no parens In-Reply-To: <88081c5a-b1e6-50e5-fef1-383edd67e984@oracle.com> References: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> <8fad23d0-0e43-3056-a741-3538a3b43ff7@oracle.com> <88081c5a-b1e6-50e5-fef1-383edd67e984@oracle.com> Message-ID: I have published another iteration at: http://cr.openjdk.java.net/~vromero/8235446/webrev.01/ Thanks, Vicente On 12/6/19 9:24 AM, Maurizio Cimadamore wrote: > > On 06/12/2019 14:19, Vicente Romero wrote: >> >> >> On 12/6/19 8:49 AM, Maurizio Cimadamore wrote: >>> Hi, >>> few comments: >>> >>> * is the call to checkSourceLevel needed? After all you already >>> check for enable-preview >> >> the thing is that checkSourceLevel prints the warning messages that >> you are using a preview feature etc, that's why I put it there > Ah! forgot thanks. >> >>> >>> * I think the error message should just be: >>> >>> "record components expected" >>> >>> (and perhaps we should move the position of the error message to >>> _after_ the record keyword). >> >> ok changing the error message to: "record header expected" >>> >>> Maurizio >> >> Thanks, >> Vicente >> >>> >>> On 06/12/2019 12:21, Vicente Romero wrote: >>>> Please review this simple fix [1] to a bug [2] reported yesterday >>>> on amber-dev by Tagir. This fix is just improving the current error >>>> message shown for code like: >>>> >>>> record R {} >>>> >>>> instead of the current: class, record, etc expected it prints: >>>> "incorrect record declaration", how does it looks? >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8235446/webrev.00/ >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8235446 >> From maurizio.cimadamore at oracle.com Fri Dec 6 14:29:46 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 14:29:46 +0000 Subject: REF: JDK-8235446: confusing error message for records with no parens In-Reply-To: References: <96cc2cfe-df11-b1a5-838f-16d2082f06bc@oracle.com> <2d815072-aae0-ce16-fc76-683d6271109e@oracle.com> <8fad23d0-0e43-3056-a741-3538a3b43ff7@oracle.com> <88081c5a-b1e6-50e5-fef1-383edd67e984@oracle.com> Message-ID: <0d79d6fb-c9c7-f81f-fed3-d4688d43e31d@oracle.com> Looks good! Thanks Maurizio On 06/12/2019 14:28, Vicente Romero wrote: > I have published another iteration at: > http://cr.openjdk.java.net/~vromero/8235446/webrev.01/ > > Thanks, > Vicente > > On 12/6/19 9:24 AM, Maurizio Cimadamore wrote: >> >> On 06/12/2019 14:19, Vicente Romero wrote: >>> >>> >>> On 12/6/19 8:49 AM, Maurizio Cimadamore wrote: >>>> Hi, >>>> few comments: >>>> >>>> * is the call to checkSourceLevel needed? After all you already >>>> check for enable-preview >>> >>> the thing is that checkSourceLevel prints the warning messages that >>> you are using a preview feature etc, that's why I put it there >> Ah! forgot thanks. >>> >>>> >>>> * I think the error message should just be: >>>> >>>> "record components expected" >>>> >>>> (and perhaps we should move the position of the error message to >>>> _after_ the record keyword). >>> >>> ok changing the error message to: "record header expected" >>>> >>>> Maurizio >>> >>> Thanks, >>> Vicente >>> >>>> >>>> On 06/12/2019 12:21, Vicente Romero wrote: >>>>> Please review this simple fix [1] to a bug [2] reported yesterday >>>>> on amber-dev by Tagir. This fix is just improving the current >>>>> error message shown for code like: >>>>> >>>>> record R {} >>>>> >>>>> instead of the current: class, record, etc expected it prints: >>>>> "incorrect record declaration", how does it looks? >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] http://cr.openjdk.java.net/~vromero/8235446/webrev.00/ >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8235446 >>> > From jan.lahoda at oracle.com Fri Dec 6 15:40:16 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 6 Dec 2019 16:40:16 +0100 Subject: RFR: JDK-8235483: Warnings printed during the build Message-ID: Hi, During build, several warnings are printed: --- Compiling 68 files for COMPILE_CREATE_SYMBOLS /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/util/Elements.class: warning: Cannot find annotation method 'feature()' in type 'PreviewFeature': class file for jdk.internal.PreviewFeature not found warning: unknown enum constant Feature.RECORDS reason: class file for jdk.internal.PreviewFeature$Feature not found /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/util/Elements.class: warning: Cannot find annotation method 'essentialAPI()' in type 'PreviewFeature' /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/element/TypeElement.class: warning: Cannot find annotation method 'feature()' in type 'PreviewFeature' warning: unknown enum constant Feature.RECORDS /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/element/TypeElement.class: warning: Cannot find annotation method 'essentialAPI()' in type 'PreviewFeature' 6 warnings Creating ct.sym classes --- The reason, I think, is that CreateSymbol is being compiled without access to the newest jdk.internal.PreviewFeature. CreateSymbols is using the javax.lang.model API, when javac is reading classfiles for the API, it can't find the PreviewFeature, and prints the warning. The proposed fix is to ensure CreateSymbols is compiled with the correct version of the PreviewFeature available. Webrev: http://cr.openjdk.java.net/~jlahoda/8235483/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8235483 How does this look? Thanks, Jan From erik.joelsson at oracle.com Fri Dec 6 16:07:28 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 6 Dec 2019 08:07:28 -0800 Subject: RFR: JDK-8235483: Warnings printed during the build In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-12-06 07:40, Jan Lahoda wrote: > Hi, > > During build, several warnings are printed: > --- > Compiling 68 files for COMPILE_CREATE_SYMBOLS > /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/util/Elements.class: > warning: Cannot find annotation method 'feature()' in type > 'PreviewFeature': class file for jdk.internal.PreviewFeature not found > warning: unknown enum constant Feature.RECORDS > ? reason: class file for jdk.internal.PreviewFeature$Feature not found > /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/util/Elements.class: > warning: Cannot find annotation method 'essentialAPI()' in type > 'PreviewFeature' > /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/element/TypeElement.class: > warning: Cannot find annotation method 'feature()' in type > 'PreviewFeature' > warning: unknown enum constant Feature.RECORDS > /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/element/TypeElement.class: > warning: Cannot find annotation method 'essentialAPI()' in type > 'PreviewFeature' > 6 warnings > Creating ct.sym classes > --- > > The reason, I think, is that CreateSymbol is being compiled without > access to the newest jdk.internal.PreviewFeature. CreateSymbols is > using the javax.lang.model API, when javac is reading classfiles for > the API, it can't find the PreviewFeature, and prints the warning. The > proposed fix is to ensure CreateSymbols is compiled with the correct > version of the PreviewFeature available. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8235483/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8235483 > > How does this look? > > Thanks, > ??? Jan From mandy.chung at oracle.com Fri Dec 6 19:23:10 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Dec 2019 11:23:10 -0800 Subject: JDK-8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: <9eb7b090-095f-5fde-e634-f407330f614b@oracle.com> References: <9eb7b090-095f-5fde-e634-f407330f614b@oracle.com> Message-ID: <0622a166-bbb3-adb3-aea8-195f8e4b2ac6@oracle.com> On 12/5/19 1:35 PM, Jonathan Gibbons wrote: > > Please review a small change to javac, to use java.net.URL instead of > java.nio.file.Path to evaluate the Class-Path in a JAR-file manifest. > > There is no test because: > > * the change mirrors a corresponding change in > jdk.internal.loader.URLClassPath > * the change is simple > * it would be complicated to set up a multi-platform multi-protocol test > > The change is a subset of the code in URLClassPath (just the > `tryResolveFile` method) because javac only supports the use of local > JAR files (and not JAR files accessed by other URL protocols.) > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8218268 > Webrev: http://cr.openjdk.java.net/~jjg/8218268/webrev/ > Looks fine to me.?? The two if statements can be folded into a single if statement. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Dec 6 21:00:49 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 6 Dec 2019 13:00:49 -0800 Subject: JDK-8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: <0622a166-bbb3-adb3-aea8-195f8e4b2ac6@oracle.com> References: <9eb7b090-095f-5fde-e634-f407330f614b@oracle.com> <0622a166-bbb3-adb3-aea8-195f8e4b2ac6@oracle.com> Message-ID: <16b907ec-98b7-8b76-92f5-9b7fd34722f4@oracle.com> On 12/06/2019 11:23 AM, Mandy Chung wrote: > > On 12/5/19 1:35 PM, Jonathan Gibbons wrote: >> >> Please review a small change to javac, to use java.net.URL instead of >> java.nio.file.Path to evaluate the Class-Path in a JAR-file manifest. >> >> There is no test because: >> >> * the change mirrors a corresponding change in >> jdk.internal.loader.URLClassPath >> * the change is simple >> * it would be complicated to set up a multi-platform multi-protocol >> test >> >> The change is a subset of the code in URLClassPath (just the >> `tryResolveFile` method) because javac only supports the use of local >> JAR files (and not JAR files accessed by other URL protocols.) >> >> -- Jon >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8218268 >> Webrev: http://cr.openjdk.java.net/~jjg/8218268/webrev/ >> > > Looks fine to me.?? The two if statements can be folded into a single > if statement. > > Mandy Thanks. Yes, I'll merge the two if-statements. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Fri Dec 6 21:11:33 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 6 Dec 2019 13:11:33 -0800 Subject: JDK-8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: <16b907ec-98b7-8b76-92f5-9b7fd34722f4@oracle.com> References: <9eb7b090-095f-5fde-e634-f407330f614b@oracle.com> <0622a166-bbb3-adb3-aea8-195f8e4b2ac6@oracle.com> <16b907ec-98b7-8b76-92f5-9b7fd34722f4@oracle.com> Message-ID: <0f993b60-5992-6d38-deea-3ebd8cba5ea7@oracle.com> On 12/6/2019 1:00 PM, Jonathan Gibbons wrote: > On 12/06/2019 11:23 AM, Mandy Chung wrote: >> >> Looks fine to me.?? The two if statements can be folded into a single >> if statement. >> > Thanks. Yes, I'll merge the two if-statements. > Look good to me, too. -Brent From jonathan.gibbons at oracle.com Fri Dec 6 21:19:11 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 6 Dec 2019 13:19:11 -0800 Subject: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file In-Reply-To: <83141923-616a-f477-d57e-e690bdc20381@oracle.com> References: <58755ce3-bf25-993f-2749-86b8407d969d@oracle.com> <83141923-616a-f477-d57e-e690bdc20381@oracle.com> Message-ID: <3811eb10-b254-a2bf-f279-20d8fc7498fa@oracle.com> Hi Jan, Yes, it did occur to me after the fact that we could keep the existing method if we wanted to.? I'll put it back and update the test. -- Jon On 12/05/2019 11:57 PM, Jan Lahoda wrote: > Overall looks OK to me. Not sure if it would make sense to keep the > existing method? The test will need tweaks for @bug and @summary. > > Jan > > On 06. 12. 19 3:23, Jonathan Gibbons wrote: >> Please review a small change to javac to permit friendly clients to >> inject additional attributes into a class file. >> >> This supersedes and generalizes an existing mechanism which is >> difficult/impractical to use, especially >> in current versions of javac where split packages are strongly >> discouraged. >> >> -- Jon >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234689 >> Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.00/ >> From jonathan.gibbons at oracle.com Fri Dec 6 22:10:39 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 6 Dec 2019 14:10:39 -0800 Subject: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file In-Reply-To: <3811eb10-b254-a2bf-f279-20d8fc7498fa@oracle.com> References: <58755ce3-bf25-993f-2749-86b8407d969d@oracle.com> <83141923-616a-f477-d57e-e690bdc20381@oracle.com> <3811eb10-b254-a2bf-f279-20d8fc7498fa@oracle.com> Message-ID: Updated webrev: Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.01/ -- Jon On 12/06/2019 01:19 PM, Jonathan Gibbons wrote: > Hi Jan, > > Yes, it did occur to me after the fact that we could keep the existing > method if we wanted to.? I'll put it back and update the test. > > -- Jon > > > On 12/05/2019 11:57 PM, Jan Lahoda wrote: >> Overall looks OK to me. Not sure if it would make sense to keep the >> existing method? The test will need tweaks for @bug and @summary. >> >> Jan >> >> On 06. 12. 19 3:23, Jonathan Gibbons wrote: >>> Please review a small change to javac to permit friendly clients to >>> inject additional attributes into a class file. >>> >>> This supersedes and generalizes an existing mechanism which is >>> difficult/impractical to use, especially >>> in current versions of javac where split packages are strongly >>> discouraged. >>> >>> -- Jon >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234689 >>> Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.00/ >>> > From robert.field at oracle.com Fri Dec 6 22:28:37 2019 From: robert.field at oracle.com (Robert Field) Date: Fri, 6 Dec 2019 14:28:37 -0800 Subject: RFR; JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records In-Reply-To: <3d13e3a3-3c6c-0c4f-14fc-ff4e7949e995@oracle.com> References: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> <3d13e3a3-3c6c-0c4f-14fc-ff4e7949e995@oracle.com> Message-ID: +1 On 12/6/19 3:53 AM, Jan Lahoda wrote: > On 05. 12. 19 20:23, Robert Field wrote: >> Maybe it is just me, but adding support for records in JShell as well >> as seemingly correcting the compiler's processing of records under a >> bug for a JShell test failure seems inappropriate. Probably could be >> addressed by creating a RFE that covers it. > > The test failure is directly caused by the incorrect support for > records in JShell. Basically, the only thing in the patch that does > not have a fairly close connection to the test is the fix for Pretty. > > But I am OK with splitting the reports, so I've created: > https://bugs.openjdk.java.net/browse/JDK-8235474 > and submitted: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014014.html > > > The patch for this bug then depends on JDK-8235474 and is here: > http://cr.openjdk.java.net/~jlahoda/8235338/webrev.01/ > > The CSR is no longer needed for this particular bug (although it is > still needed for JDK-8235474). Also moving compiler-dev on CC, since > this is no longer a javac patch. > > Jan > >> >> I assume the CSR needs to be approved before this is pushed. The CSR >> has the same naming issue. >> >> Otherwise looks fine. >> >> -Robert >> >> >> On 12/5/19 7:59 AM, Jan Lahoda wrote: >>> Hi, >>> >>> This is a patch to improve the behavior of jshell w.r.t. records, >>> including fixing the recently problem-listed CompletenessTest.java. >>> >>> Notes on the patch: >>> -added jdk.jshell.Snippet.SubKind.RECORD_SUBKIND, similar to >>> ENUM_SUBKIND. CSR for this change for review is here: >>> https://bugs.openjdk.java.net/browse/JDK-8235421 >>> -moved setting the record final from JavacParsert to >>> Check.checkFlags (as jshell was struggling with the modifier being >>> set in parser, and checkFlags seems to be a better place anyway) >>> -improved JavacParser.isRecordStart to take EOF into account - this >>> could be moved to jshell if too dangerous, but might be good for >>> javac for error recovery >>> -Pretty (JCClassDecl.toString()) should now print records as records >>> instead of classes. >>> >>> Proposed patch: >>> http://cr.openjdk.java.net/~jlahoda/8235338/webrev.00/ >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235338 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan From robert.field at oracle.com Fri Dec 6 22:33:47 2019 From: robert.field at oracle.com (Robert Field) Date: Fri, 6 Dec 2019 14:33:47 -0800 Subject: RFR: JDK-8235474: JShell does not handle records properly In-Reply-To: <8419cdd2-56bd-e16b-099a-90b3b64283c1@oracle.com> References: <8419cdd2-56bd-e16b-099a-90b3b64283c1@oracle.com> Message-ID: <9f747606-66ea-dd32-8f68-e76a0f31a452@oracle.com> Thumbs up on JShell changes. -Robert On 12/6/19 3:38 AM, Jan Lahoda wrote: > Hi, > > As a spin-off from: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014001.html > > > I propose to improve the record handling in jshell. Please see the > original post for some more details. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8235474/webrev.00/ > CSR for review: https://bugs.openjdk.java.net/browse/JDK-8235476 > JBS: https://bugs.openjdk.java.net/browse/JDK-8235474 > > How does this look? > > Thanks, > ??? Jan From jeremy.kuhn.java at gmail.com Fri Dec 6 23:36:34 2019 From: jeremy.kuhn.java at gmail.com (Jeremy Kuhn) Date: Sat, 7 Dec 2019 00:36:34 +0100 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module Message-ID: Hi, Following previous discussions please find enclosed a patch for the issue referenced in JDK-8235457. The com.sun.tools.javac.model.JavacElements#matchAnnoToTree() method (line 275) is invoked when reporting a message on an annotation on an element to return the tree for an annotation given the annotated element, this allows the compiler to output the correct line where the message should be displayed, however in the "Vis" class within the method the JCModuleDecl has probably been forgotten when modules were introduced in JDK-9 leading to an AssertionError crashing the compiler when an annotation processor tries to report a message on a module's annotation. In order to fix the issue, I've simply implemented the missing method visitModuleDef() in the Vis class so that modules' annotations are properly returned. You'll find a jtreg test in the patch as well, I've actually created three modules for the test: - annotation: which defines a simple module annotation - processor: which provides the annotation processor reporting a message on the module's annotation - mod: which contains a module annotated with the previous annotation The test is successful when the test run without error and the message is properly displayed by the compiler. I didn't find a way to use jtreg tags to compile modules, so I've decided to compile everything programmatically in the test main() method. Please let me know if I can be of any further assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8235457.patch Type: text/x-patch Size: 7749 bytes Desc: not available URL: From jeremy.kuhn.java at gmail.com Fri Dec 6 23:53:20 2019 From: jeremy.kuhn.java at gmail.com (Jeremy Kuhn) Date: Sat, 7 Dec 2019 00:53:20 +0100 Subject: [PATCH] JDK-8235458: Problem caused by imports in a module-info.java file Message-ID: Hi, Following previous discussions please find enclosed a patch for the issue referenced in JDK-8235458. When the compiler initiates the annotation processing environment it scans all compilation units to discover whether there are some with annotations to process and create the first round of annotation processing. This is done in the JavacProcessingEnvironment (line 1090 in the Round constructor), module info files are filtered within the getModuleInfoFiles() method (line 1515) but this method currently assumes a module info files always starts with a module declaration even though import statements can be present first according to the Java language specification as a result an annotated module with import statements is ignored during annotation processing. In order to fix the issue, I've had to loop over the unit defs to ignore any import statements until I found either a module tag in which case I can include the module in the list of modules info files to process or any other tag in which case I ignore the unit which is not a module. You'll find a jtreg test in the patch as well, I've actually created three modules for the test: - annotation: which defines a simple module annotation - processor: which provides the annotation processor reporting a message on the annotated module - mod: which contains a module annotated with the previous annotation with import statements The test is successful when the it runs without errors and the annotation is properly processed by the compiler. I didn't find a way to use jtreg tags to compile modules, so I've decided to compile everything programmatically in the test main() method. Please let me know if I can be of any further assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8235458.patch Type: text/x-patch Size: 8199 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Sat Dec 7 00:36:28 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 6 Dec 2019 16:36:28 -0800 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module In-Reply-To: References: Message-ID: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> On 12/06/2019 03:36 PM, Jeremy Kuhn wrote: > Hi, > > Following previous discussions please find enclosed a patch for the > issue referenced in JDK-8235457. > > The com.sun.tools.javac.model.JavacElements#matchAnnoToTree() method > (line 275) is invoked when reporting a message on an annotation on an > element to return the tree for an annotation given the annotated > element, this allows the compiler to output the correct line where the > message should be displayed, however in the "Vis" class within the > method the JCModuleDecl has probably been forgotten when modules were > introduced in JDK-9 leading to an AssertionError crashing the compiler > when an annotation processor tries to report a message on a module's > annotation. > > In order to fix the issue, I've simply implemented the missing method > visitModuleDef() in the Vis class so that modules' annotations are > properly returned. > > You'll find a jtreg test in the patch as well, I've actually created > three modules for the test: > - annotation: which defines a simple module annotation > - processor: which provides the annotation processor reporting a > message on the module's annotation > - mod: which contains a module annotated with the previous annotation > > The test is successful when the test run without error and the message > is properly displayed by the compiler. > > I didn't find a way to use jtreg tags to compile modules, so I've > decided to compile everything programmatically in the test main() method. > > Please let me know if I can be of any further assistance. Hi Jeremy, Thanks for providing the patch for the first of your issues. I've uploaded the patch as a webrev: http://cr.openjdk.java.net/~jjg/8235457/webrev/index.html Some comments ... Some of the files contain tab characters. Code in OpenJDK should always use spaces instead of tabs. This and other white-space rules (no trailing spaces;? source files end with newline, etc) are enforced by a Mercurial extension called jcheck, available here: http://openjdk.java.net/projects/code-tools/jcheck/ Although I acknowledge you'll see a lot of instances in test/langtools/tools/javac, we now regard the use of a directory named after a bug number as something of an anti-pattern. The same for source files and other related files. The preferred style these days is to use a "human-understandable" name, perhaps as a subdirectory in a directory of functionally related tests. Source files, including test source files, should generally have the "standard" legal header. For test files, the standard is to use GPL2 without the ClassPath Exception. In most cases, you can copy the header from a nearby file and just update the date to be the current year,? as in * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. I note you used /nodynamiccopyright/. This is just for use in files that will be compiled, and the compilation generates output (containing line-numbers) that will be compared against a "golden-file". The purpose of the comment is to mark the file to indicate it should not have a comment, on the grounds that if it had a comment and at some point in the future the header were to be changed, the test might break (i.e. if the number of lines in the header were changed, affecting line numbers in the source file. Because source files to be compiled in javac tests are often small, and because they are often dominated in size by the legal header, it is sometimes more convenient (but not required) to embed these files in strings in the main test program. Be careful when comparing javac output against golden files. Your test will almost certainly fail on Windows, because the output written by java will contain Windows-style line-terminators (\r\n), but the golden file will contain Unix-style line terminators (\n). The recommend solutions are to either convert one of the strings to be compared to be compatible with the other, or to compare them as a "list of lines". In addition, javac provides a hidden option -XDrawDiagnostics for use in cases like this, which causes it to use just the simple name of the file, and to use resource keys instead of localized strings. This helps avoid what you had to do in lines 47,48 of T8235457.java. You may have intended an additional line break in the middle of line 34. The code would be more concise if you just accessed the system properties for test.src and test.classes once and stored the results in variables to use later. Even better is to store them in type-safe variables of type File or Path instead of plain old String. Stylistically, it is nicer to use either File or Path, but not a mixture unless absolutely necessary. In general, Path (as the newer API) is the better overall choice. Also regarding consistency, you use a mixture of Arrays.asList and List.of. That's not wrong, but consistent use of List.of would be better. Cool for using? StandardLocation.ANNOTATION_PROCESSOR_MODULE_PATH. I don't think your anno processor needed to be a module, but it is nice to see that you chose to make it one. (You could have just put the processor class on the classpath and used the -processor option to specify it by name ;-) ) -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Dec 7 01:00:39 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 6 Dec 2019 17:00:39 -0800 Subject: [PATCH] JDK-8235458: Problem caused by imports in a module-info.java file In-Reply-To: References: Message-ID: On 12/06/2019 03:53 PM, Jeremy Kuhn wrote: > Hi, > > Following previous discussions please find enclosed a patch for the > issue referenced in JDK-8235458. > > When the compiler initiates the annotation processing environment it > scans all compilation units to discover whether there are some with > annotations to process and create the first round of annotation > processing. This is done in the JavacProcessingEnvironment (line 1090 > in the Round constructor), module info files are filtered within the > getModuleInfoFiles() method (line 1515) but this method currently > assumes a module info files always starts with a module declaration > even though import statements can be present first according to the > Java language specification as a result an annotated module with > import statements is ignored during annotation processing. > > In order to fix the issue, I've had to loop over the unit defs to > ignore any import statements until I found either a module tag in > which case I can include the module in the list of modules info files > to process or any other tag in which case I ignore the unit which is > not a module. > > You'll find a jtreg test in the patch as well, I've actually created > three modules for the test: > - annotation: which defines a simple module annotation > - processor: which provides the annotation processor reporting a > message on the annotated module > - mod: which contains a module annotated with the previous annotation > with import statements > > The test is successful when the it runs without errors and the > annotation is properly processed by the compiler. > > I didn't find a way to use jtreg tags to compile modules, so I've > decided to compile everything programmatically in the test main() method. > > Please let me know if I can be of any further assistance. Hi Jeremy, Thanks for providing the patch for the second of your issues. I've uploaded the patch as a webrev: http://cr.openjdk.java.net/~jjg/8235458/webrev/index.html The fix for JavacProcessingEnvironment looks OK, but as for the test, isn't this the same test from the other fix? -- Jon From joe.darcy at oracle.com Sat Dec 7 06:32:07 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 6 Dec 2019 22:32:07 -0800 Subject: JDK 15 RFR: JDK-8225361 : Start of release updates for JDK 15, includes JDK-8235497 and JDK-8235528 Message-ID: <9c055943-3794-c975-0bd7-2f3f94ea86f3@oracle.com> Hello, The time approaches to being JDK 15! Please review the general langtools API and spec updates for this: ??? http://cr.openjdk.java.net/~darcy/8225361.5/ The langtools portion includes two bugs with corresponding CSRs that also need review: ??? JDK-8235497: Add SourceVersion.RELEASE_15 ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235498 ??? JDK-8235528: Add source 15 and target 15 to javac ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235529 It might be time to retire the notion of profiles for new releases, but that can be decided another day. Thanks, -Joe From jeremy.kuhn.java at gmail.com Sat Dec 7 06:47:12 2019 From: jeremy.kuhn.java at gmail.com (Jeremy Kuhn) Date: Sat, 7 Dec 2019 07:47:12 +0100 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module In-Reply-To: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> References: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> Message-ID: Hi Jon, I take good note of your comments and get back to you with updated patches asap. As for the other bug 8235458, you're actually right to say that both tests are quite similar: annotation module is the same, processor module is almost the same except that the processor doesn't report a message on the annotation to avoid the first issue and the mod module uses import. I did that to clearly separate the two tests, there's different approaches to testing, either we test one particular issue at a time (following a bug) or we test a wider functionality and potentially other things at the same time. Since I saw many directories named after a bug number I assumed the first approach was expected but clearly I would prefer to test functionalities (and reduce code) Following your comment on names I think I'll create one folder for both tests in test/langtools/tools/javac/modules or test/langtools/tools/javac/annotations defining annotation and processor modules once. Now I can either test both issues altogether with one annotated module with import statements or create separate tests to test the import issue separately, I think that one test here would be ok because if the first test fails the other would inevitably fail as well (since the processor report message on annotation), there's no need to report twice the same error and in case of error the issue would be quite clear: either assertion error or the annotation processor doesn't process the annotation, in any case you'll know what to do. So I propose to create three patches: one for each bug fix and one for the test if that's ok for you. Regarding annotation processor module path, what can I say I like modules :-P Jeremy On Sat, Dec 7, 2019 at 1:39 AM Jonathan Gibbons wrote: > > > On 12/06/2019 03:36 PM, Jeremy Kuhn wrote: > > Hi, > > Following previous discussions please find enclosed a patch for the issue > referenced in JDK-8235457. > > The com.sun.tools.javac.model.JavacElements#matchAnnoToTree() method (line > 275) is invoked when reporting a message on an annotation on an element to > return the tree for an annotation given the annotated element, this allows > the compiler to output the correct line where the message should be > displayed, however in the "Vis" class within the method the JCModuleDecl > has probably been forgotten when modules were introduced in JDK-9 leading > to an AssertionError crashing the compiler when an annotation processor > tries to report a message on a module's annotation. > > In order to fix the issue, I've simply implemented the missing method > visitModuleDef() in the Vis class so that modules' annotations are properly > returned. > > You'll find a jtreg test in the patch as well, I've actually created three > modules for the test: > - annotation: which defines a simple module annotation > - processor: which provides the annotation processor reporting a message > on the module's annotation > - mod: which contains a module annotated with the previous annotation > > The test is successful when the test run without error and the message is > properly displayed by the compiler. > > I didn't find a way to use jtreg tags to compile modules, so I've decided > to compile everything programmatically in the test main() method. > > Please let me know if I can be of any further assistance. > > > Hi Jeremy, > > Thanks for providing the patch for the first of your issues. I've uploaded > the patch as a webrev: > http://cr.openjdk.java.net/~jjg/8235457/webrev/index.html > > Some comments ... > > Some of the files contain tab characters. Code in OpenJDK should always > use spaces instead of tabs. > This and other white-space rules (no trailing spaces; source files end > with newline, etc) are enforced > by a Mercurial extension called jcheck, available here: > http://openjdk.java.net/projects/code-tools/jcheck/ > > Although I acknowledge you'll see a lot of instances in > test/langtools/tools/javac, we now regard the > use of a directory named after a bug number as something of an > anti-pattern. The same for source > files and other related files. The preferred style these days is to use a > "human-understandable" name, > perhaps as a subdirectory in a directory of functionally related tests. > > Source files, including test source files, should generally have the > "standard" legal header. > For test files, the standard is to use GPL2 without the ClassPath > Exception. In most cases, you > can copy the header from a nearby file and just update the date to be the > current year, as in > > * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. > > I note you used /nodynamiccopyright/. This is just for use in files that > will be compiled, and the > compilation generates output (containing line-numbers) that will be > compared against a "golden-file". > The purpose of the comment is to mark the file to indicate it should not > have a comment, on the > grounds that if it had a comment and at some point in the future the > header were to be changed, > the test might break (i.e. if the number of lines in the header were > changed, affecting line numbers in > the source file. > > Because source files to be compiled in javac tests are often small, and > because they are often > dominated in size by the legal header, it is sometimes more convenient > (but not required) to embed > these files in strings in the main test program. > > Be careful when comparing javac output against golden files. Your test > will almost certainly fail on > Windows, because the output written by java will contain Windows-style > line-terminators (\r\n), but > the golden file will contain Unix-style line terminators (\n). The > recommend solutions are to either > convert one of the strings to be compared to be compatible with the other, > or to compare them > as a "list of lines". > > In addition, javac provides a hidden option -XDrawDiagnostics for use in > cases like this, which causes > it to use just the simple name of the file, and to use resource keys > instead of localized strings. > This helps avoid what you had to do in lines 47,48 of T8235457.java. > > You may have intended an additional line break in the middle of line 34. > > The code would be more concise if you just accessed the system properties > for test.src and test.classes > once and stored the results in variables to use later. Even better is to > store them in type-safe variables > of type File or Path instead of plain old String. Stylistically, it is > nicer to use either File or Path, but not > a mixture unless absolutely necessary. In general, Path (as the newer API) > is the better overall choice. > > Also regarding consistency, you use a mixture of Arrays.asList and > List.of. That's not wrong, but > consistent use of List.of would be better. > > Cool for using StandardLocation.ANNOTATION_PROCESSOR_MODULE_PATH. I don't > think your anno > processor needed to be a module, but it is nice to see that you chose to > make it one. > (You could have just put the processor class on the classpath and used the > -processor option to > specify it by name ;-) ) > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Dec 9 11:04:21 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Dec 2019 11:04:21 +0000 Subject: RFR: JDK-8235483: Warnings printed during the build In-Reply-To: References: Message-ID: Sounds sensible! Thanks Maurizio On 06/12/2019 15:40, Jan Lahoda wrote: > Hi, > > During build, several warnings are printed: > --- > Compiling 68 files for COMPILE_CREATE_SYMBOLS > /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/util/Elements.class: > warning: Cannot find annotation method 'feature()' in type > 'PreviewFeature': class file for jdk.internal.PreviewFeature not found > warning: unknown enum constant Feature.RECORDS > ? reason: class file for jdk.internal.PreviewFeature$Feature not found > /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/util/Elements.class: > warning: Cannot find annotation method 'essentialAPI()' in type > 'PreviewFeature' > /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/element/TypeElement.class: > warning: Cannot find annotation method 'feature()' in type > 'PreviewFeature' > warning: unknown enum constant Feature.RECORDS > /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/buildtools/interim_langtools_modules/java.compiler.interim/javax/lang/model/element/TypeElement.class: > warning: Cannot find annotation method 'essentialAPI()' in type > 'PreviewFeature' > 6 warnings > Creating ct.sym classes > --- > > The reason, I think, is that CreateSymbol is being compiled without > access to the newest jdk.internal.PreviewFeature. CreateSymbols is > using the javax.lang.model API, when javac is reading classfiles for > the API, it can't find the PreviewFeature, and prints the warning. The > proposed fix is to ensure CreateSymbols is compiled with the correct > version of the PreviewFeature available. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8235483/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8235483 > > How does this look? > > Thanks, > ??? Jan From jan.lahoda at oracle.com Mon Dec 9 16:05:14 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 9 Dec 2019 17:05:14 +0100 Subject: RFR: JDK-8234211 allow discoverable javac plugins to be invoked by default In-Reply-To: <32067f97-be1a-d90d-d591-f08ac8210d09@oracle.com> References: <32067f97-be1a-d90d-d591-f08ac8210d09@oracle.com> Message-ID: <51b4d3a8-5565-f572-e460-ff045e113d43@oracle.com> Looks good to me. Jan On 06. 12. 19 3:13, Jonathan Gibbons wrote: > Please review a small change to javac to allow plugins to opt-in to > being automatically started by default if not started explicitly. > > The CSR for the API change has already been approved. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234211 > CSR: https://bugs.openjdk.java.net/browse/JDK-8234683 > Webrev: http://cr.openjdk.java.net/~jjg/8234211/webrev.00/ > From jan.lahoda at oracle.com Mon Dec 9 19:20:48 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 9 Dec 2019 20:20:48 +0100 Subject: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file In-Reply-To: References: <58755ce3-bf25-993f-2749-86b8407d969d@oracle.com> <83141923-616a-f477-d57e-e690bdc20381@oracle.com> <3811eb10-b254-a2bf-f279-20d8fc7498fa@oracle.com> Message-ID: <7ea4c3e4-ea59-9451-961c-c72082b5d894@oracle.com> Looks good to me. Thanks, Jan On 06. 12. 19 23:10, Jonathan Gibbons wrote: > Updated webrev: > > Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.01/ > > -- Jon > > > On 12/06/2019 01:19 PM, Jonathan Gibbons wrote: >> Hi Jan, >> >> Yes, it did occur to me after the fact that we could keep the existing >> method if we wanted to.? I'll put it back and update the test. >> >> -- Jon >> >> >> On 12/05/2019 11:57 PM, Jan Lahoda wrote: >>> Overall looks OK to me. Not sure if it would make sense to keep the >>> existing method? The test will need tweaks for @bug and @summary. >>> >>> Jan >>> >>> On 06. 12. 19 3:23, Jonathan Gibbons wrote: >>>> Please review a small change to javac to permit friendly clients to >>>> inject additional attributes into a class file. >>>> >>>> This supersedes and generalizes an existing mechanism which is >>>> difficult/impractical to use, especially >>>> in current versions of javac where split packages are strongly >>>> discouraged. >>>> >>>> -- Jon >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234689 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.00/ >>>> >> > From forax at univ-mlv.fr Mon Dec 9 22:07:13 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 9 Dec 2019 23:07:13 +0100 (CET) Subject: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file In-Reply-To: <7ea4c3e4-ea59-9451-961c-c72082b5d894@oracle.com> References: <58755ce3-bf25-993f-2749-86b8407d969d@oracle.com> <83141923-616a-f477-d57e-e690bdc20381@oracle.com> <3811eb10-b254-a2bf-f279-20d8fc7498fa@oracle.com> <7ea4c3e4-ea59-9451-961c-c72082b5d894@oracle.com> Message-ID: <2140988881.528600.1575929233728.JavaMail.zimbra@u-pem.fr> Function should be a ToIntFunction to avoid boxing the return value from int to Integer, otherwise looks good. R?mi ----- Mail original ----- > De: "jan lahoda" > ?: "jonathan gibbons" , "compiler-dev" > Envoy?: Lundi 9 D?cembre 2019 20:20:48 > Objet: Re: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file > Looks good to me. > > Thanks, > Jan > > On 06. 12. 19 23:10, Jonathan Gibbons wrote: >> Updated webrev: >> >> Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.01/ >> >> -- Jon >> >> >> On 12/06/2019 01:19 PM, Jonathan Gibbons wrote: >>> Hi Jan, >>> >>> Yes, it did occur to me after the fact that we could keep the existing >>> method if we wanted to.? I'll put it back and update the test. >>> >>> -- Jon >>> >>> >>> On 12/05/2019 11:57 PM, Jan Lahoda wrote: >>>> Overall looks OK to me. Not sure if it would make sense to keep the >>>> existing method? The test will need tweaks for @bug and @summary. >>>> >>>> Jan >>>> >>>> On 06. 12. 19 3:23, Jonathan Gibbons wrote: >>>>> Please review a small change to javac to permit friendly clients to >>>>> inject additional attributes into a class file. >>>>> >>>>> This supersedes and generalizes an existing mechanism which is >>>>> difficult/impractical to use, especially >>>>> in current versions of javac where split packages are strongly >>>>> discouraged. >>>>> >>>>> -- Jon >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234689 >>>>> Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.00/ >>>>> >>> From jonathan.gibbons at oracle.com Mon Dec 9 22:07:06 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 14:07:06 -0800 Subject: RFR: JDK-8235597: Extend support for -XDaccessInternalAPI to plugin modules Message-ID: <3f2b4afb-ac83-c769-0013-2b1c0115babf@oracle.com> Please review a small localized change to javac, to extend the support for the existing hidden -XDaccessInternalAPI option to plugins provided as modules. The change utilizes the existing ModuleHelper.addExports method. The test is derived from the recent new test AutostartPlugins.java.? It creates a plugin in a jar file, in a module on the module path, and in a module that is linked in to the image.? The test case for the classpath is not new and is just provided for completeness. A negative test case for plugin-as-module is provided, to demonstrate that access fails without the option, and there are test cases for modules on the module path and jlinked into an image. The positive test cases just verify that non-null elements in task events can be downcast to ClassSymbol, and an internal field (the kind) accessed. No CSR, since the option is undocumented, unsupported and subject to change at any time. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8235597 Webrev: http://cr.openjdk.java.net/~jjg/8235597/webrev.00/ From jonathan.gibbons at oracle.com Mon Dec 9 22:11:43 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 14:11:43 -0800 Subject: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file In-Reply-To: <2140988881.528600.1575929233728.JavaMail.zimbra@u-pem.fr> References: <58755ce3-bf25-993f-2749-86b8407d969d@oracle.com> <83141923-616a-f477-d57e-e690bdc20381@oracle.com> <3811eb10-b254-a2bf-f279-20d8fc7498fa@oracle.com> <7ea4c3e4-ea59-9451-961c-c72082b5d894@oracle.com> <2140988881.528600.1575929233728.JavaMail.zimbra@u-pem.fr> Message-ID: <3fe9bf7c-15d9-7212-3065-f1615f13f251@oracle.com> R?mi, Thanks; I didn't know of that small group of functions. I've already pushed the code. I doubt there's any noticeable performance difference, but now would be a good time to fix it. -- Jon On 12/09/2019 02:07 PM, Remi Forax wrote: > Function should be a ToIntFunction to avoid boxing the return value from int to Integer, > otherwise looks good. > > R?mi > > ----- Mail original ----- >> De: "jan lahoda" >> ?: "jonathan gibbons" , "compiler-dev" >> Envoy?: Lundi 9 D?cembre 2019 20:20:48 >> Objet: Re: RFR: JDK-8234689 facilitate writing additional custom attributes in a class file >> Looks good to me. >> >> Thanks, >> Jan >> >> On 06. 12. 19 23:10, Jonathan Gibbons wrote: >>> Updated webrev: >>> >>> Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.01/ >>> >>> -- Jon >>> >>> >>> On 12/06/2019 01:19 PM, Jonathan Gibbons wrote: >>>> Hi Jan, >>>> >>>> Yes, it did occur to me after the fact that we could keep the existing >>>> method if we wanted to.? I'll put it back and update the test. >>>> >>>> -- Jon >>>> >>>> >>>> On 12/05/2019 11:57 PM, Jan Lahoda wrote: >>>>> Overall looks OK to me. Not sure if it would make sense to keep the >>>>> existing method? The test will need tweaks for @bug and @summary. >>>>> >>>>> Jan >>>>> >>>>> On 06. 12. 19 3:23, Jonathan Gibbons wrote: >>>>>> Please review a small change to javac to permit friendly clients to >>>>>> inject additional attributes into a class file. >>>>>> >>>>>> This supersedes and generalizes an existing mechanism which is >>>>>> difficult/impractical to use, especially >>>>>> in current versions of javac where split packages are strongly >>>>>> discouraged. >>>>>> >>>>>> -- Jon >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234689 >>>>>> Webrev: http://cr.openjdk.java.net/~jjg/8234689/webrev.00/ >>>>>> From jeremy.kuhn.java at gmail.com Mon Dec 9 23:12:16 2019 From: jeremy.kuhn.java at gmail.com (Jeremy Kuhn) Date: Tue, 10 Dec 2019 00:12:16 +0100 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module In-Reply-To: References: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> Message-ID: Hi Jon, Following my previous mail, please find enclosed updated patches: - JDK-8235457.patch provides fix for 8235457 bug - JDK-8235458.pathc provides fix for 8235458 bug - JDK-8235457-8235458.patch provides a test to validate both fixes: a processor reporting a message on an imported module annotation. JCheck doesn't complain, code is more consistent and legal header has been added. Please let me know if you need anything else. Jeremy On Sat, Dec 7, 2019 at 7:47 AM Jeremy Kuhn wrote: > Hi Jon, > > I take good note of your comments and get back to you with updated patches > asap. > > As for the other bug 8235458, you're actually right to say that both tests > are quite similar: annotation module is the same, processor module is > almost the same except that the processor doesn't report a message on the > annotation to avoid the first issue and the mod module uses import. > > I did that to clearly separate the two tests, there's different approaches > to testing, either we test one particular issue at a time (following a bug) > or we test a wider functionality and potentially other things at the same > time. Since I saw many directories named after a bug number I assumed the > first approach was expected but clearly I would prefer to test > functionalities (and reduce code) > > Following your comment on names I think I'll create one folder for both > tests in test/langtools/tools/javac/modules or > test/langtools/tools/javac/annotations defining annotation and processor > modules once. Now I can either test both issues altogether with one > annotated module with import statements or create separate tests to test > the import issue separately, I think that one test here would be ok because > if the first test fails the other would inevitably fail as well (since the > processor report message on annotation), there's no need to report twice > the same error and in case of error the issue would be quite clear: either > assertion error or the annotation processor doesn't process the annotation, > in any case you'll know what to do. > > So I propose to create three patches: one for each bug fix and one for the > test if that's ok for you. > > Regarding annotation processor module path, what can I say I like modules > :-P > > Jeremy > > On Sat, Dec 7, 2019 at 1:39 AM Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> >> >> On 12/06/2019 03:36 PM, Jeremy Kuhn wrote: >> >> Hi, >> >> Following previous discussions please find enclosed a patch for the issue >> referenced in JDK-8235457. >> >> The com.sun.tools.javac.model.JavacElements#matchAnnoToTree() method >> (line 275) is invoked when reporting a message on an annotation on an >> element to return the tree for an annotation given the annotated element, >> this allows the compiler to output the correct line where the message >> should be displayed, however in the "Vis" class within the method the >> JCModuleDecl has probably been forgotten when modules were introduced in >> JDK-9 leading to an AssertionError crashing the compiler when an annotation >> processor tries to report a message on a module's annotation. >> >> In order to fix the issue, I've simply implemented the missing method >> visitModuleDef() in the Vis class so that modules' annotations are properly >> returned. >> >> You'll find a jtreg test in the patch as well, I've actually created >> three modules for the test: >> - annotation: which defines a simple module annotation >> - processor: which provides the annotation processor reporting a message >> on the module's annotation >> - mod: which contains a module annotated with the previous annotation >> >> The test is successful when the test run without error and the message is >> properly displayed by the compiler. >> >> I didn't find a way to use jtreg tags to compile modules, so I've decided >> to compile everything programmatically in the test main() method. >> >> Please let me know if I can be of any further assistance. >> >> >> Hi Jeremy, >> >> Thanks for providing the patch for the first of your issues. I've >> uploaded the patch as a webrev: >> http://cr.openjdk.java.net/~jjg/8235457/webrev/index.html >> >> Some comments ... >> >> Some of the files contain tab characters. Code in OpenJDK should always >> use spaces instead of tabs. >> This and other white-space rules (no trailing spaces; source files end >> with newline, etc) are enforced >> by a Mercurial extension called jcheck, available here: >> http://openjdk.java.net/projects/code-tools/jcheck/ >> >> Although I acknowledge you'll see a lot of instances in >> test/langtools/tools/javac, we now regard the >> use of a directory named after a bug number as something of an >> anti-pattern. The same for source >> files and other related files. The preferred style these days is to use a >> "human-understandable" name, >> perhaps as a subdirectory in a directory of functionally related tests. >> >> Source files, including test source files, should generally have the >> "standard" legal header. >> For test files, the standard is to use GPL2 without the ClassPath >> Exception. In most cases, you >> can copy the header from a nearby file and just update the date to be the >> current year, as in >> >> * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. >> >> I note you used /nodynamiccopyright/. This is just for use in files that >> will be compiled, and the >> compilation generates output (containing line-numbers) that will be >> compared against a "golden-file". >> The purpose of the comment is to mark the file to indicate it should not >> have a comment, on the >> grounds that if it had a comment and at some point in the future the >> header were to be changed, >> the test might break (i.e. if the number of lines in the header were >> changed, affecting line numbers in >> the source file. >> >> Because source files to be compiled in javac tests are often small, and >> because they are often >> dominated in size by the legal header, it is sometimes more convenient >> (but not required) to embed >> these files in strings in the main test program. >> >> Be careful when comparing javac output against golden files. Your test >> will almost certainly fail on >> Windows, because the output written by java will contain Windows-style >> line-terminators (\r\n), but >> the golden file will contain Unix-style line terminators (\n). The >> recommend solutions are to either >> convert one of the strings to be compared to be compatible with the >> other, or to compare them >> as a "list of lines". >> >> In addition, javac provides a hidden option -XDrawDiagnostics for use in >> cases like this, which causes >> it to use just the simple name of the file, and to use resource keys >> instead of localized strings. >> This helps avoid what you had to do in lines 47,48 of T8235457.java. >> >> You may have intended an additional line break in the middle of line 34. >> >> The code would be more concise if you just accessed the system properties >> for test.src and test.classes >> once and stored the results in variables to use later. Even better is to >> store them in type-safe variables >> of type File or Path instead of plain old String. Stylistically, it is >> nicer to use either File or Path, but not >> a mixture unless absolutely necessary. In general, Path (as the newer >> API) is the better overall choice. >> >> Also regarding consistency, you use a mixture of Arrays.asList and >> List.of. That's not wrong, but >> consistent use of List.of would be better. >> >> Cool for using StandardLocation.ANNOTATION_PROCESSOR_MODULE_PATH. I >> don't think your anno >> processor needed to be a module, but it is nice to see that you chose to >> make it one. >> (You could have just put the processor class on the classpath and used >> the -processor option to >> specify it by name ;-) ) >> >> -- Jon >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8235457.patch Type: text/x-patch Size: 734 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8235457-8235458-test.patch Type: text/x-patch Size: 14002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8235458.patch Type: text/x-patch Size: 1454 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Mon Dec 9 23:15:11 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 15:15:11 -0800 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module In-Reply-To: References: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> Message-ID: <4fa6556d-f99d-b43a-d9bf-2f9d677fefba@oracle.com> Hi Jeremy, I'll go through this. My inclination to combine all three into a single changeset to push into the repos.? The fixes themselves are simple; the changeset is dominated by the test. -- Jon On 12/9/19 3:12 PM, Jeremy Kuhn wrote: > Hi Jon, > > Following my previous mail, please find enclosed updated patches: > - JDK-8235457.patch provides fix for 8235457 bug > - JDK-8235458.pathc provides fix for 8235458 bug > - JDK-8235457-8235458.patch provides a test to validate both fixes: a > processor reporting a message on an imported module annotation. > > JCheck doesn't complain, code is more consistent and legal header has > been added. > > Please let me know if you need anything else. > > Jeremy > > On Sat, Dec 7, 2019 at 7:47 AM Jeremy Kuhn > wrote: > > Hi Jon, > > I take good note of your comments and get back to you with updated > patches asap. > > As for the other bug 8235458, you're actually right to say that > both tests are quite similar: annotation module is the same, > processor module is almost the same except that the processor > doesn't report a message on the annotation to avoid the first > issue and the mod module uses import. > > I did that to clearly separate the two tests, there's different > approaches to testing, either we test one particular issue at a > time (following a bug) or we test a wider functionality and > potentially other things at the same time. Since I saw many > directories named after a bug number I assumed the first approach > was expected but clearly I would prefer to test functionalities > (and reduce code) > > Following your comment on names I think I'll create one folder for > both tests in test/langtools/tools/javac/modules or > test/langtools/tools/javac/annotations defining annotation and > processor modules once. Now I can either test both issues > altogether with one annotated module with import statements or > create separate tests to test the import issue separately, I think > that one test here would be ok because if the first test fails the > other would inevitably fail as well (since the processor report > message on annotation), there's no need to report twice the same > error and in case of error the issue would be quite clear: either > assertion error or the annotation processor doesn't process the > annotation, in any case you'll know what to do. > > So I propose to create three patches: one for each bug fix and one > for the test if that's ok for you. > > Regarding annotation processor module path, what can I say I like > modules :-P > > Jeremy > > On Sat, Dec 7, 2019 at 1:39 AM Jonathan Gibbons > > > wrote: > > > > On 12/06/2019 03:36 PM, Jeremy Kuhn wrote: >> Hi, >> >> Following previous discussions please find enclosed a patch >> for the issue referenced in JDK-8235457. >> >> The com.sun.tools.javac.model.JavacElements#matchAnnoToTree() >> method (line 275) is invoked when reporting a message on an >> annotation on an element to return the tree for an annotation >> given the annotated element, this allows the compiler to >> output the correct line where the message should be >> displayed, however in the "Vis" class within the method the >> JCModuleDecl has probably been forgotten when modules were >> introduced in JDK-9 leading to an AssertionError crashing the >> compiler when an annotation processor tries to report a >> message on a module's annotation. >> >> In order to fix the issue, I've simply implemented the >> missing method visitModuleDef() in the Vis class so that >> modules' annotations are properly returned. >> >> You'll find a jtreg test in the patch as well, I've actually >> created three modules for the test: >> - annotation: which defines a simple module annotation >> - processor: which provides the annotation processor >> reporting a message on the module's annotation >> - mod: which contains a module annotated with the previous >> annotation >> >> The test is successful when the test run without error and >> the message is properly displayed by the compiler. >> >> I didn't find a way to use jtreg tags to compile modules, so >> I've decided to compile everything programmatically in the >> test main() method. >> >> Please let me know if I can be of any further assistance. > > Hi Jeremy, > > Thanks for providing the patch for the first of your issues. > I've uploaded the patch as a webrev: > http://cr.openjdk.java.net/~jjg/8235457/webrev/index.html > > Some comments ... > > Some of the files contain tab characters. Code in OpenJDK > should always use spaces instead of tabs. > This and other white-space rules (no trailing spaces; source > files end with newline, etc) are enforced > by a Mercurial extension called jcheck, available here: > http://openjdk.java.net/projects/code-tools/jcheck/ > > Although I acknowledge you'll see a lot of instances in > test/langtools/tools/javac, we now regard the > use of a directory named after a bug number as something of an > anti-pattern. The same for source > files and other related files. The preferred style these days > is to use a "human-understandable" name, > perhaps as a subdirectory in a directory of functionally > related tests. > > Source files, including test source files, should generally > have the "standard" legal header. > For test files, the standard is to use GPL2 without the > ClassPath Exception. In most cases, you > can copy the header from a nearby file and just update the > date to be the current year,? as in > > * Copyright (c) 2019, Oracle and/or its affiliates. All rights > reserved. > > I note you used /nodynamiccopyright/. This is just for use in > files that will be compiled, and the > compilation generates output (containing line-numbers) that > will be compared against a "golden-file". > The purpose of the comment is to mark the file to indicate it > should not have a comment, on the > grounds that if it had a comment and at some point in the > future the header were to be changed, > the test might break (i.e. if the number of lines in the > header were changed, affecting line numbers in > the source file. > > Because source files to be compiled in javac tests are often > small, and because they are often > dominated in size by the legal header, it is sometimes more > convenient (but not required) to embed > these files in strings in the main test program. > > Be careful when comparing javac output against golden files. > Your test will almost certainly fail on > Windows, because the output written by java will contain > Windows-style line-terminators (\r\n), but > the golden file will contain Unix-style line terminators (\n). > The recommend solutions are to either > convert one of the strings to be compared to be compatible > with the other, or to compare them > as a "list of lines". > > In addition, javac provides a hidden option -XDrawDiagnostics > for use in cases like this, which causes > it to use just the simple name of the file, and to use > resource keys instead of localized strings. > This helps avoid what you had to do in lines 47,48 of > T8235457.java. > > You may have intended an additional line break in the middle > of line 34. > > The code would be more concise if you just accessed the system > properties for test.src and test.classes > once and stored the results in variables to use later. Even > better is to store them in type-safe variables > of type File or Path instead of plain old String. > Stylistically, it is nicer to use either File or Path, but not > a mixture unless absolutely necessary. In general, Path (as > the newer API) is the better overall choice. > > Also regarding consistency, you use a mixture of Arrays.asList > and List.of. That's not wrong, but > consistent use of List.of would be better. > > Cool for using > StandardLocation.ANNOTATION_PROCESSOR_MODULE_PATH. I don't > think your anno > processor needed to be a module, but it is nice to see that > you chose to make it one. > (You could have just put the processor class on the classpath > and used the -processor option to > specify it by name ;-) ) > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Dec 10 00:38:44 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 16:38:44 -0800 Subject: RFR: JDK-8235621: Replace use of Function with ToIntFunction Message-ID: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> Following R?mi's suggestion[1], please review a trivial change to javac to have it use ToIntFunction instead of Function<..., Integer> in the recent patch for JDK-8234689 [2]. Patch inline below. No change to the original test is necessary. JBS: https://bugs.openjdk.java.net/browse/JDK-8235621 [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014043.html [2] https://hg.openjdk.java.net/jdk/jdk/rev/17b0f051280f -- Jon diff -r 2aaa8bcb90a9 -r 1e000f399f3a src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Mon Dec 09 15:28:46 2019 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Mon Dec 09 16:12:42 2019 -0800 @@ -30,7 +30,7 @@ ?import java.util.Map; ?import java.util.Set; ?import java.util.LinkedHashSet; -import java.util.function.Function; +import java.util.function.ToIntFunction; ?import javax.tools.JavaFileManager; ?import javax.tools.FileObject; @@ -114,7 +114,7 @@ ????? */ ???? public boolean multiModuleMode; -??? private List> extraAttributeHooks = List.nil(); +??? private List> extraAttributeHooks = List.nil(); ???? /** The initial sizes of the data and constant pool buffers. ????? *? Sizes are increased when buffers get full. @@ -191,7 +191,7 @@ ???????? } ???? } -??? public void addExtraAttributes(Function addExtraAttributes) { +??? public void addExtraAttributes(ToIntFunction addExtraAttributes) { ???????? extraAttributeHooks = extraAttributeHooks.prepend(addExtraAttributes); ???? } @@ -1669,7 +1669,7 @@ ????? */ ???? protected int writeExtraAttributes(Symbol sym) { ???????? int i = 0; -??????? for (Function hook : extraAttributeHooks) { +??????? for (ToIntFunction hook : extraAttributeHooks) { ???????????? i += hook.apply(sym); ???????? } ???????? return i; From forax at univ-mlv.fr Tue Dec 10 01:20:00 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 10 Dec 2019 02:20:00 +0100 (CET) Subject: RFR: JDK-8235621: Replace use of Function with ToIntFunction In-Reply-To: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> References: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> Message-ID: <569551612.540516.1575940800028.JavaMail.zimbra@u-pem.fr> Hi Jonathan, for addExtraAttributes, the method should be public void addExtraAttributes(ToIntFunction addExtraAttributes) { for the same reason a public method should take a List and not an ArrayList, so you can call it with addExtraAttributes((Object o) -> 12); if the attribute is constant. If addExtraAttributes takes a ToIntFunction, you will have to use ToIntFunction everywhere. I should propose a new JEP to lock Dan Smith into a prison until JEP 300 [1] is delivered, because we will be able to get ride of most of those pesky wildcards (at least all the ones on functional interfaces) if that JEP is delivered. regards, R?mi [1] https://openjdk.java.net/jeps/300 ----- Mail original ----- > De: "jonathan gibbons" > ?: "compiler-dev" > Envoy?: Mardi 10 D?cembre 2019 01:38:44 > Objet: RFR: JDK-8235621: Replace use of Function with ToIntFunction > Following R?mi's suggestion[1], please review a trivial change to javac > to have it use ToIntFunction > instead of Function<..., Integer> in the recent patch for JDK-8234689 [2]. > > Patch inline below. No change to the original test is necessary. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235621 > [1] > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014043.html > [2] https://hg.openjdk.java.net/jdk/jdk/rev/17b0f051280f > > -- Jon > > diff -r 2aaa8bcb90a9 -r 1e000f399f3a > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > Mon Dec 09 15:28:46 2019 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > Mon Dec 09 16:12:42 2019 -0800 > @@ -30,7 +30,7 @@ > ?import java.util.Map; > ?import java.util.Set; > ?import java.util.LinkedHashSet; > -import java.util.function.Function; > +import java.util.function.ToIntFunction; > > ?import javax.tools.JavaFileManager; > ?import javax.tools.FileObject; > @@ -114,7 +114,7 @@ > ????? */ > ???? public boolean multiModuleMode; > > -??? private List> extraAttributeHooks = > List.nil(); > +??? private List> extraAttributeHooks = List.nil(); > > ???? /** The initial sizes of the data and constant pool buffers. > ????? *? Sizes are increased when buffers get full. > @@ -191,7 +191,7 @@ > ???????? } > ???? } > > -??? public void addExtraAttributes(Function > addExtraAttributes) { > +??? public void addExtraAttributes(ToIntFunction > addExtraAttributes) { > ???????? extraAttributeHooks = > extraAttributeHooks.prepend(addExtraAttributes); > ???? } > > @@ -1669,7 +1669,7 @@ > ????? */ > ???? protected int writeExtraAttributes(Symbol sym) { > ???????? int i = 0; > -??????? for (Function hook : extraAttributeHooks) { > +??????? for (ToIntFunction hook : extraAttributeHooks) { > ???????????? i += hook.apply(sym); > ???????? } > ???????? return i; From jonathan.gibbons at oracle.com Tue Dec 10 01:20:22 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 17:20:22 -0800 Subject: JDK 15 RFR: JDK-8225361 : Start of release updates for JDK 15, includes JDK-8235497 and JDK-8235528 In-Reply-To: <9c055943-3794-c975-0bd7-2f3f94ea86f3@oracle.com> References: <9c055943-3794-c975-0bd7-2f3f94ea86f3@oracle.com> Message-ID: <1b96e156-01c2-0c16-3c73-da4d7850f4df@oracle.com> The comment for 14 could be updated, in http://cr.openjdk.java.net/~darcy/8225361.5/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java.sdiff.html or else (later) we should just simplify/drop these comments and rely on Source.Feature which is inherently more accurate. Changes in this file do not seem to be directly version related: test/langtools/tools/javac/records/RecordMemberTests.java I've not looked in detail at the contents of the make/data/symbols files. -- Jon On 12/6/19 10:32 PM, Joe Darcy wrote: > Hello, > > The time approaches to being JDK 15! Please review the general > langtools API and spec updates for this: > > ??? http://cr.openjdk.java.net/~darcy/8225361.5/ > > The langtools portion includes two bugs with corresponding CSRs that > also need review: > > ??? JDK-8235497: Add SourceVersion.RELEASE_15 > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235498 > > ??? JDK-8235528: Add source 15 and target 15 to javac > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235529 > > It might be time to retire the notion of profiles for new releases, > but that can be decided another day. > > Thanks, > > -Joe > From jonathan.gibbons at oracle.com Tue Dec 10 01:28:23 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 17:28:23 -0800 Subject: RFR: JDK-8235621: Replace use of Function with ToIntFunction In-Reply-To: <569551612.540516.1575940800028.JavaMail.zimbra@u-pem.fr> References: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> <569551612.540516.1575940800028.JavaMail.zimbra@u-pem.fr> Message-ID: R?mi, While I understand the use of wildcards for parameters and return types, I don't think it makes sense to allow/use "? super Symbol" in this situation. I'd prefer to keep it simple and just use ToIntFunction. -- Jon On 12/09/2019 05:20 PM, Remi Forax wrote: > Hi Jonathan, > for addExtraAttributes, the method should be > > public void addExtraAttributes(ToIntFunction addExtraAttributes) { > > for the same reason a public method should take a List and not an ArrayList, so you can call it with > addExtraAttributes((Object o) -> 12); > if the attribute is constant. > > If addExtraAttributes takes a ToIntFunction, you will have to use ToIntFunction everywhere. > > I should propose a new JEP to lock Dan Smith into a prison until JEP 300 [1] is delivered, because we will be able to get ride of most of those pesky wildcards (at least all the ones on functional interfaces) if that JEP is delivered. > > regards, > R?mi > > [1] https://openjdk.java.net/jeps/300 > > ----- Mail original ----- >> De: "jonathan gibbons" >> ?: "compiler-dev" >> Envoy?: Mardi 10 D?cembre 2019 01:38:44 >> Objet: RFR: JDK-8235621: Replace use of Function with ToIntFunction >> Following R?mi's suggestion[1], please review a trivial change to javac >> to have it use ToIntFunction >> instead of Function<..., Integer> in the recent patch for JDK-8234689 [2]. >> >> Patch inline below. No change to the original test is necessary. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235621 >> [1] >> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014043.html >> [2] https://hg.openjdk.java.net/jdk/jdk/rev/17b0f051280f >> >> -- Jon >> >> diff -r 2aaa8bcb90a9 -r 1e000f399f3a >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >> >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >> Mon Dec 09 15:28:46 2019 +0100 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >> Mon Dec 09 16:12:42 2019 -0800 >> @@ -30,7 +30,7 @@ >> ?import java.util.Map; >> ?import java.util.Set; >> ?import java.util.LinkedHashSet; >> -import java.util.function.Function; >> +import java.util.function.ToIntFunction; >> >> ?import javax.tools.JavaFileManager; >> ?import javax.tools.FileObject; >> @@ -114,7 +114,7 @@ >> ????? */ >> ???? public boolean multiModuleMode; >> >> -??? private List> extraAttributeHooks = >> List.nil(); >> +??? private List> extraAttributeHooks = List.nil(); >> >> ???? /** The initial sizes of the data and constant pool buffers. >> ????? *? Sizes are increased when buffers get full. >> @@ -191,7 +191,7 @@ >> ???????? } >> ???? } >> >> -??? public void addExtraAttributes(Function >> addExtraAttributes) { >> +??? public void addExtraAttributes(ToIntFunction >> addExtraAttributes) { >> ???????? extraAttributeHooks = >> extraAttributeHooks.prepend(addExtraAttributes); >> ???? } >> >> @@ -1669,7 +1669,7 @@ >> ????? */ >> ???? protected int writeExtraAttributes(Symbol sym) { >> ???????? int i = 0; >> -??????? for (Function hook : extraAttributeHooks) { >> +??????? for (ToIntFunction hook : extraAttributeHooks) { >> ???????????? i += hook.apply(sym); >> ???????? } >> ???????? return i; From joe.darcy at oracle.com Tue Dec 10 02:13:34 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 9 Dec 2019 18:13:34 -0800 Subject: JDK 15 RFR: JDK-8225361 : Start of release updates for JDK 15, includes JDK-8235497 and JDK-8235528 In-Reply-To: <1b96e156-01c2-0c16-3c73-da4d7850f4df@oracle.com> References: <9c055943-3794-c975-0bd7-2f3f94ea86f3@oracle.com> <1b96e156-01c2-0c16-3c73-da4d7850f4df@oracle.com> Message-ID: <0df375fe-f318-7848-dd79-adf16b4bfc61@oracle.com> Thanks for the review. On 12/9/2019 5:20 PM, Jonathan Gibbons wrote: > The comment for 14 could be updated, in > http://cr.openjdk.java.net/~darcy/8225361.5/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java.sdiff.html > > or else (later) we should just simplify/drop these comments and rely > on Source.Feature which is inherently more accurate. I'll update that enum constant to use similar wording as SourceVersion: ? 63????? *? 14: switch expressions (pattern matching and records in ? 64????? *????? preview, text blocks in preview again) ? 65????? *? 15: TBD http://cr.openjdk.java.net/~darcy/8225361.5/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java.frames.html The descriptions in the javax.lang.model.SourceVersion and javac Source enums are not always consistently updated when new language features go back. > > Changes in this file do not seem to be directly version related: > test/langtools/tools/javac/records/RecordMemberTests.java I added the second string argument to the assert methods to provide some additional debugging information; the tests were failing in earlier iterations before some corrections were made to the records support under 15 vs 14. I think these changes give better information in the case of test failures so I'd prefer to leave them in. > > I've not looked in detail at the contents of the make/data/symbols files. Acknowledged; those files will need to be updated at least once to accommodate API changes subsequent to JDK 14 b26, including records and the removal of pack200 which are both post-b26. Cheers, -Joe > > -- Jon > > On 12/6/19 10:32 PM, Joe Darcy wrote: >> Hello, >> >> The time approaches to being JDK 15! Please review the general >> langtools API and spec updates for this: >> >> ??? http://cr.openjdk.java.net/~darcy/8225361.5/ >> >> The langtools portion includes two bugs with corresponding CSRs that >> also need review: >> >> ??? JDK-8235497: Add SourceVersion.RELEASE_15 >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235498 >> >> ??? JDK-8235528: Add source 15 and target 15 to javac >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235529 >> >> It might be time to retire the notion of profiles for new releases, >> but that can be decided another day. >> >> Thanks, >> >> -Joe >> From jonathan.gibbons at oracle.com Tue Dec 10 02:30:43 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 18:30:43 -0800 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module In-Reply-To: References: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> Message-ID: <2e2fe310-5a0e-94f5-1655-7c3421b67b14@oracle.com> Jeremy, Thank you for your updated patches. I've taken your patches and posted them in a single webrev, with the intent to eventually push them as a single changeset. http://cr.openjdk.java.net/~jjg/8235457-8235458/webrev.00/ While it is not common to post a single changeset for multiple issues, I think it is warranted in this case because the bug fixes are small and the one test covers both fixes. (And, I don't think it is worth splitting the test in two, one for each fix.)? There's a somewhat stronger rule that says that fixes should have associated tests, and so it would be inappropriate to push disjoint fixes and tests. I've taken the liberty of applying some trivial cleanup: * I moved the test into test/langtools/tools/javac/processing instead of test/langtools/tools/javac/modules. The primary reason for this is that the fixes themselves are in code that is more strongly associated with annotation processing.? Moving the test does not need any corresponding code changes. * I fixed the use of /nodynamiccopyright/. I'm sorry I didn't explain it better. It should appear in a comment in files that appear as messages with line numbers in a golden file, and so which should not have a legal header. In this case, it is mods-src2/mod/module-info.java that appears in the golden file, and so that is the file that should have /nodynamiccopyright/ instead of the legal header.?? Making this change meant that I had to make a corresponding update in the line number in the golden file.? By the same reasoning, I removed /nodynamiccopyright/ from the test file, since that file is not mentioned in the golden file. -- I'm not sure quite what you're trying to do with those regular expressions trying to normalize newlines. On Unix, they'll be no-ops, but on Windows, they will completely remove newlines. Not wrong, but sorta weirdly inconsistent.? I'd suggest to avoid regexes here and just doing a literal replace of System.getProperty("line.separator") with "\n", as in 68 String actualOutput = outputWriter.toString(); 69 String expectedOutput = Files.readString(testBasePath.resolve("ReportOnImportedModuleAnnotation.out"))); 70 String lineSep = System.getProperty("line.separator"); 71 if(!actualOutput.replace(lineSep, "\n").equals(expectedOutput.replace(lineSep, "\n"))) { There are other ways you can write this, but that is the simplest adjustment to what you have here, and without getting into using test library code. If you're OK, I can make this change before running the patch through our internal build-and-test system. -- Jon On 12/09/2019 03:12 PM, Jeremy Kuhn wrote: > Hi Jon, > > Following my previous mail, please find enclosed updated patches: > - JDK-8235457.patch provides fix for 8235457 bug > - JDK-8235458.pathc provides fix for 8235458 bug > - JDK-8235457-8235458.patch provides a test to validate both fixes: a > processor reporting a message on an imported module annotation. > > JCheck doesn't complain, code is more consistent and legal header has > been added. > > Please let me know if you need anything else. > > Jeremy > > On Sat, Dec 7, 2019 at 7:47 AM Jeremy Kuhn > wrote: > > Hi Jon, > > I take good note of your comments and get back to you with updated > patches asap. > > As for the other bug 8235458, you're actually right to say that > both tests are quite similar: annotation module is the same, > processor module is almost the same except that the processor > doesn't report a message on the annotation to avoid the first > issue and the mod module uses import. > > I did that to clearly separate the two tests, there's different > approaches to testing, either we test one particular issue at a > time (following a bug) or we test a wider functionality and > potentially other things at the same time. Since I saw many > directories named after a bug number I assumed the first approach > was expected but clearly I would prefer to test functionalities > (and reduce code) > > Following your comment on names I think I'll create one folder for > both tests in test/langtools/tools/javac/modules or > test/langtools/tools/javac/annotations defining annotation and > processor modules once. Now I can either test both issues > altogether with one annotated module with import statements or > create separate tests to test the import issue separately, I think > that one test here would be ok because if the first test fails the > other would inevitably fail as well (since the processor report > message on annotation), there's no need to report twice the same > error and in case of error the issue would be quite clear: either > assertion error or the annotation processor doesn't process the > annotation, in any case you'll know what to do. > > So I propose to create three patches: one for each bug fix and one > for the test if that's ok for you. > > Regarding annotation processor module path, what can I say I like > modules :-P > > Jeremy > > On Sat, Dec 7, 2019 at 1:39 AM Jonathan Gibbons > > > wrote: > > > > On 12/06/2019 03:36 PM, Jeremy Kuhn wrote: >> Hi, >> >> Following previous discussions please find enclosed a patch >> for the issue referenced in JDK-8235457. >> >> The com.sun.tools.javac.model.JavacElements#matchAnnoToTree() >> method (line 275) is invoked when reporting a message on an >> annotation on an element to return the tree for an annotation >> given the annotated element, this allows the compiler to >> output the correct line where the message should be >> displayed, however in the "Vis" class within the method the >> JCModuleDecl has probably been forgotten when modules were >> introduced in JDK-9 leading to an AssertionError crashing the >> compiler when an annotation processor tries to report a >> message on a module's annotation. >> >> In order to fix the issue, I've simply implemented the >> missing method visitModuleDef() in the Vis class so that >> modules' annotations are properly returned. >> >> You'll find a jtreg test in the patch as well, I've actually >> created three modules for the test: >> - annotation: which defines a simple module annotation >> - processor: which provides the annotation processor >> reporting a message on the module's annotation >> - mod: which contains a module annotated with the previous >> annotation >> >> The test is successful when the test run without error and >> the message is properly displayed by the compiler. >> >> I didn't find a way to use jtreg tags to compile modules, so >> I've decided to compile everything programmatically in the >> test main() method. >> >> Please let me know if I can be of any further assistance. > > Hi Jeremy, > > Thanks for providing the patch for the first of your issues. > I've uploaded the patch as a webrev: > http://cr.openjdk.java.net/~jjg/8235457/webrev/index.html > > > Some comments ... > > Some of the files contain tab characters. Code in OpenJDK > should always use spaces instead of tabs. > This and other white-space rules (no trailing spaces; source > files end with newline, etc) are enforced > by a Mercurial extension called jcheck, available here: > http://openjdk.java.net/projects/code-tools/jcheck/ > > Although I acknowledge you'll see a lot of instances in > test/langtools/tools/javac, we now regard the > use of a directory named after a bug number as something of an > anti-pattern. The same for source > files and other related files. The preferred style these days > is to use a "human-understandable" name, > perhaps as a subdirectory in a directory of functionally > related tests. > > Source files, including test source files, should generally > have the "standard" legal header. > For test files, the standard is to use GPL2 without the > ClassPath Exception. In most cases, you > can copy the header from a nearby file and just update the > date to be the current year,? as in > > * Copyright (c) 2019, Oracle and/or its affiliates. All rights > reserved. > > I note you used /nodynamiccopyright/. This is just for use in > files that will be compiled, and the > compilation generates output (containing line-numbers) that > will be compared against a "golden-file". > The purpose of the comment is to mark the file to indicate it > should not have a comment, on the > grounds that if it had a comment and at some point in the > future the header were to be changed, > the test might break (i.e. if the number of lines in the > header were changed, affecting line numbers in > the source file. > > Because source files to be compiled in javac tests are often > small, and because they are often > dominated in size by the legal header, it is sometimes more > convenient (but not required) to embed > these files in strings in the main test program. > > Be careful when comparing javac output against golden files. > Your test will almost certainly fail on > Windows, because the output written by java will contain > Windows-style line-terminators (\r\n), but > the golden file will contain Unix-style line terminators (\n). > The recommend solutions are to either > convert one of the strings to be compared to be compatible > with the other, or to compare them > as a "list of lines". > > In addition, javac provides a hidden option -XDrawDiagnostics > for use in cases like this, which causes > it to use just the simple name of the file, and to use > resource keys instead of localized strings. > This helps avoid what you had to do in lines 47,48 of > T8235457.java. > > You may have intended an additional line break in the middle > of line 34. > > The code would be more concise if you just accessed the system > properties for test.src and test.classes > once and stored the results in variables to use later. Even > better is to store them in type-safe variables > of type File or Path instead of plain old String. > Stylistically, it is nicer to use either File or Path, but not > a mixture unless absolutely necessary. In general, Path (as > the newer API) is the better overall choice. > > Also regarding consistency, you use a mixture of Arrays.asList > and List.of. That's not wrong, but > consistent use of List.of would be better. > > Cool for using > StandardLocation.ANNOTATION_PROCESSOR_MODULE_PATH. I don't > think your anno > processor needed to be a module, but it is nice to see that > you chose to make it one. > (You could have just put the processor class on the classpath > and used the -processor option to > specify it by name ;-) ) > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Dec 10 02:32:07 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 18:32:07 -0800 Subject: JDK 15 RFR: JDK-8225361 : Start of release updates for JDK 15, includes JDK-8235497 and JDK-8235528 In-Reply-To: <0df375fe-f318-7848-dd79-adf16b4bfc61@oracle.com> References: <9c055943-3794-c975-0bd7-2f3f94ea86f3@oracle.com> <1b96e156-01c2-0c16-3c73-da4d7850f4df@oracle.com> <0df375fe-f318-7848-dd79-adf16b4bfc61@oracle.com> Message-ID: All OK, including improved tests ;-) -- Jon On 12/09/2019 06:13 PM, Joe Darcy wrote: > Thanks for the review. > > On 12/9/2019 5:20 PM, Jonathan Gibbons wrote: >> The comment for 14 could be updated, in >> http://cr.openjdk.java.net/~darcy/8225361.5/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java.sdiff.html >> >> or else (later) we should just simplify/drop these comments and rely >> on Source.Feature which is inherently more accurate. > > > I'll update that enum constant to use similar wording as SourceVersion: > > > ? 63????? *? 14: switch expressions (pattern matching and records in > ? 64????? *????? preview, text blocks in preview again) > ? 65????? *? 15: TBD > > http://cr.openjdk.java.net/~darcy/8225361.5/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java.frames.html > > > The descriptions in the javax.lang.model.SourceVersion and javac > Source enums are not always consistently updated when new language > features go back. > > >> >> Changes in this file do not seem to be directly version related: >> test/langtools/tools/javac/records/RecordMemberTests.java > > > I added the second string argument to the assert methods to provide > some additional debugging information; the tests were failing in > earlier iterations before some corrections were made to the records > support under 15 vs 14. I think these changes give better information > in the case of test failures so I'd prefer to leave them in. > > >> >> I've not looked in detail at the contents of the make/data/symbols >> files. > > Acknowledged; those files will need to be updated at least once to > accommodate API changes subsequent to JDK 14 b26, including records > and the removal of pack200 which are both post-b26. > > Cheers, > > -Joe > > > >> >> -- Jon >> >> On 12/6/19 10:32 PM, Joe Darcy wrote: >>> Hello, >>> >>> The time approaches to being JDK 15! Please review the general >>> langtools API and spec updates for this: >>> >>> ??? http://cr.openjdk.java.net/~darcy/8225361.5/ >>> >>> The langtools portion includes two bugs with corresponding CSRs that >>> also need review: >>> >>> ??? JDK-8235497: Add SourceVersion.RELEASE_15 >>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235498 >>> >>> ??? JDK-8235528: Add source 15 and target 15 to javac >>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235529 >>> >>> It might be time to retire the notion of profiles for new releases, >>> but that can be decided another day. >>> >>> Thanks, >>> >>> -Joe >>> From forax at univ-mlv.fr Tue Dec 10 07:39:14 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 10 Dec 2019 08:39:14 +0100 (CET) Subject: RFR: JDK-8235621: Replace use of Function with ToIntFunction In-Reply-To: References: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> <569551612.540516.1575940800028.JavaMail.zimbra@u-pem.fr> Message-ID: <332152246.573091.1575963554687.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "jonathan gibbons" > ?: "Remi Forax" > Cc: "compiler-dev" > Envoy?: Mardi 10 D?cembre 2019 02:28:23 > Objet: Re: RFR: JDK-8235621: Replace use of Function with ToIntFunction > R?mi, > > While I understand the use of wildcards for parameters and return types, I don't > think it makes sense to allow/use "? super Symbol" in this situation. I'd > prefer to keep it simple and just use ToIntFunction. but you are forcing people that that already have a ToIntFunction to do a lambda to lambda conversion which is weird ToIntFunction extraAttributes = (Object o) -> 12; addExtraAttributes(extraAttributes::applyAsInt); // WTF ? instead of ToIntFunction extraAttributes = (Object o) -> 12; addExtraAttributes(extraAttributes); > > -- Jon R?mi > > > On 12/09/2019 05:20 PM, Remi Forax wrote: >> Hi Jonathan, >> for addExtraAttributes, the method should be >> >> public void addExtraAttributes(ToIntFunction addExtraAttributes) >> { >> >> for the same reason a public method should take a List and not an ArrayList, so >> you can call it with >> addExtraAttributes((Object o) -> 12); >> if the attribute is constant. >> >> If addExtraAttributes takes a ToIntFunction, you will have to >> use ToIntFunction everywhere. >> >> I should propose a new JEP to lock Dan Smith into a prison until JEP 300 [1] is >> delivered, because we will be able to get ride of most of those pesky wildcards >> (at least all the ones on functional interfaces) if that JEP is delivered. >> >> regards, >> R?mi >> >> [1] https://openjdk.java.net/jeps/300 >> >> ----- Mail original ----- >>> De: "jonathan gibbons" >>> ?: "compiler-dev" >>> Envoy?: Mardi 10 D?cembre 2019 01:38:44 >>> Objet: RFR: JDK-8235621: Replace use of Function with ToIntFunction >>> Following R?mi's suggestion[1], please review a trivial change to javac >>> to have it use ToIntFunction >>> instead of Function<..., Integer> in the recent patch for JDK-8234689 [2]. >>> >>> Patch inline below. No change to the original test is necessary. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235621 >>> [1] >>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014043.html >>> [2] https://hg.openjdk.java.net/jdk/jdk/rev/17b0f051280f >>> >>> -- Jon >>> >>> diff -r 2aaa8bcb90a9 -r 1e000f399f3a >>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >>> >>> --- >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >>> Mon Dec 09 15:28:46 2019 +0100 >>> +++ >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >>> Mon Dec 09 16:12:42 2019 -0800 >>> @@ -30,7 +30,7 @@ >>> ?import java.util.Map; >>> ?import java.util.Set; >>> ?import java.util.LinkedHashSet; >>> -import java.util.function.Function; >>> +import java.util.function.ToIntFunction; >>> >>> ?import javax.tools.JavaFileManager; >>> ?import javax.tools.FileObject; >>> @@ -114,7 +114,7 @@ >>> ????? */ >>> ???? public boolean multiModuleMode; >>> >>> -??? private List> extraAttributeHooks = >>> List.nil(); >>> +??? private List> extraAttributeHooks = List.nil(); >>> >>> ???? /** The initial sizes of the data and constant pool buffers. >>> ????? *? Sizes are increased when buffers get full. >>> @@ -191,7 +191,7 @@ >>> ???????? } >>> ???? } >>> >>> -??? public void addExtraAttributes(Function >>> addExtraAttributes) { >>> +??? public void addExtraAttributes(ToIntFunction >>> addExtraAttributes) { >>> ???????? extraAttributeHooks = >>> extraAttributeHooks.prepend(addExtraAttributes); >>> ???? } >>> >>> @@ -1669,7 +1669,7 @@ >>> ????? */ >>> ???? protected int writeExtraAttributes(Symbol sym) { >>> ???????? int i = 0; >>> -??????? for (Function hook : extraAttributeHooks) { >>> +??????? for (ToIntFunction hook : extraAttributeHooks) { >>> ???????????? i += hook.apply(sym); >>> ???????? } > >> ???????? return i; From jeremy.kuhn.java at gmail.com Tue Dec 10 09:10:52 2019 From: jeremy.kuhn.java at gmail.com (Jeremy Kuhn) Date: Tue, 10 Dec 2019 10:10:52 +0100 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module In-Reply-To: <2e2fe310-5a0e-94f5-1655-7c3421b67b14@oracle.com> References: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> <2e2fe310-5a0e-94f5-1655-7c3421b67b14@oracle.com> Message-ID: Hi, I'm Ok with the changes you suggest, it makes sense. I googled a bit to find the regexp solution but using line.separator property is cleaner indeed. Thanks! On Tue, Dec 10, 2019 at 3:30 AM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Jeremy, > > Thank you for your updated patches. > > I've taken your patches and posted them in a single webrev, with the > intent to eventually push them as a single changeset. > > http://cr.openjdk.java.net/~jjg/8235457-8235458/webrev.00/ > > While it is not common to post a single changeset for multiple issues, I > think it is warranted in this case because the bug fixes are small and the > one test covers both fixes. (And, I don't think it is worth splitting the > test in two, one for each fix.) There's a somewhat stronger rule that says > that fixes should have associated tests, and so it would be inappropriate > to push disjoint fixes and tests. > > I've taken the liberty of applying some trivial cleanup: > > * I moved the test into test/langtools/tools/javac/processing instead of > test/langtools/tools/javac/modules. The primary reason for this is that the > fixes themselves are in code that is more strongly associated with > annotation processing. Moving the test does not need any corresponding > code changes. > > * I fixed the use of /nodynamiccopyright/. I'm sorry I didn't explain it > better. It should appear in a comment in files that appear as messages with > line numbers in a golden file, and so which should not have a legal header. > In this case, it is mods-src2/mod/module-info.java that appears in the > golden file, and so that is the file that should have /nodynamiccopyright/ > instead of the legal header. Making this change meant that I had to make > a corresponding update in the line number in the golden file. By the same > reasoning, I removed /nodynamiccopyright/ from the test file, since that > file is not mentioned in the golden file. > > -- > > I'm not sure quite what you're trying to do with those regular expressions > trying to normalize newlines. On Unix, they'll be no-ops, but on Windows, > they will completely remove newlines. Not wrong, but sorta weirdly > inconsistent. I'd suggest to avoid regexes here and just doing a literal > replace of System.getProperty("line.separator") with "\n", as in > > 68 String actualOutput = outputWriter.toString(); > 69 String expectedOutput = Files.readString(testBasePath.resolve("ReportOnImportedModuleAnnotation.out"))); > 70 > String lineSep = System.getProperty("line.separator"); > 71 if(!actualOutput.replace(lineSep, "\n").equals(expectedOutput.replace(lineSep, "\n"))) { > > There are other ways you can write this, but that is the simplest > adjustment to what you have here, and without getting into using test > library code. > > If you're OK, I can make this change before running the patch through our > internal build-and-test system. > > -- Jon > > > On 12/09/2019 03:12 PM, Jeremy Kuhn wrote: > > Hi Jon, > > Following my previous mail, please find enclosed updated patches: > - JDK-8235457.patch provides fix for 8235457 bug > - JDK-8235458.pathc provides fix for 8235458 bug > - JDK-8235457-8235458.patch provides a test to validate both fixes: a > processor reporting a message on an imported module annotation. > > JCheck doesn't complain, code is more consistent and legal header has been > added. > > Please let me know if you need anything else. > > Jeremy > > On Sat, Dec 7, 2019 at 7:47 AM Jeremy Kuhn > wrote: > >> Hi Jon, >> >> I take good note of your comments and get back to you with updated >> patches asap. >> >> As for the other bug 8235458, you're actually right to say that both >> tests are quite similar: annotation module is the same, processor module is >> almost the same except that the processor doesn't report a message on the >> annotation to avoid the first issue and the mod module uses import. >> >> I did that to clearly separate the two tests, there's different >> approaches to testing, either we test one particular issue at a time >> (following a bug) or we test a wider functionality and potentially other >> things at the same time. Since I saw many directories named after a bug >> number I assumed the first approach was expected but clearly I would prefer >> to test functionalities (and reduce code) >> >> Following your comment on names I think I'll create one folder for both >> tests in test/langtools/tools/javac/modules or >> test/langtools/tools/javac/annotations defining annotation and processor >> modules once. Now I can either test both issues altogether with one >> annotated module with import statements or create separate tests to test >> the import issue separately, I think that one test here would be ok because >> if the first test fails the other would inevitably fail as well (since the >> processor report message on annotation), there's no need to report twice >> the same error and in case of error the issue would be quite clear: either >> assertion error or the annotation processor doesn't process the annotation, >> in any case you'll know what to do. >> >> So I propose to create three patches: one for each bug fix and one for >> the test if that's ok for you. >> >> Regarding annotation processor module path, what can I say I like modules >> :-P >> >> Jeremy >> >> On Sat, Dec 7, 2019 at 1:39 AM Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >>> >>> >>> On 12/06/2019 03:36 PM, Jeremy Kuhn wrote: >>> >>> Hi, >>> >>> Following previous discussions please find enclosed a patch for the >>> issue referenced in JDK-8235457. >>> >>> The com.sun.tools.javac.model.JavacElements#matchAnnoToTree() method >>> (line 275) is invoked when reporting a message on an annotation on an >>> element to return the tree for an annotation given the annotated element, >>> this allows the compiler to output the correct line where the message >>> should be displayed, however in the "Vis" class within the method the >>> JCModuleDecl has probably been forgotten when modules were introduced in >>> JDK-9 leading to an AssertionError crashing the compiler when an annotation >>> processor tries to report a message on a module's annotation. >>> >>> In order to fix the issue, I've simply implemented the missing method >>> visitModuleDef() in the Vis class so that modules' annotations are properly >>> returned. >>> >>> You'll find a jtreg test in the patch as well, I've actually created >>> three modules for the test: >>> - annotation: which defines a simple module annotation >>> - processor: which provides the annotation processor reporting a message >>> on the module's annotation >>> - mod: which contains a module annotated with the previous annotation >>> >>> The test is successful when the test run without error and the message >>> is properly displayed by the compiler. >>> >>> I didn't find a way to use jtreg tags to compile modules, so I've >>> decided to compile everything programmatically in the test main() method. >>> >>> Please let me know if I can be of any further assistance. >>> >>> >>> Hi Jeremy, >>> >>> Thanks for providing the patch for the first of your issues. I've >>> uploaded the patch as a webrev: >>> http://cr.openjdk.java.net/~jjg/8235457/webrev/index.html >>> >>> Some comments ... >>> >>> Some of the files contain tab characters. Code in OpenJDK should always >>> use spaces instead of tabs. >>> This and other white-space rules (no trailing spaces; source files end >>> with newline, etc) are enforced >>> by a Mercurial extension called jcheck, available here: >>> http://openjdk.java.net/projects/code-tools/jcheck/ >>> >>> Although I acknowledge you'll see a lot of instances in >>> test/langtools/tools/javac, we now regard the >>> use of a directory named after a bug number as something of an >>> anti-pattern. The same for source >>> files and other related files. The preferred style these days is to use >>> a "human-understandable" name, >>> perhaps as a subdirectory in a directory of functionally related tests. >>> >>> Source files, including test source files, should generally have the >>> "standard" legal header. >>> For test files, the standard is to use GPL2 without the ClassPath >>> Exception. In most cases, you >>> can copy the header from a nearby file and just update the date to be >>> the current year, as in >>> >>> * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. >>> >>> I note you used /nodynamiccopyright/. This is just for use in files that >>> will be compiled, and the >>> compilation generates output (containing line-numbers) that will be >>> compared against a "golden-file". >>> The purpose of the comment is to mark the file to indicate it should not >>> have a comment, on the >>> grounds that if it had a comment and at some point in the future the >>> header were to be changed, >>> the test might break (i.e. if the number of lines in the header were >>> changed, affecting line numbers in >>> the source file. >>> >>> Because source files to be compiled in javac tests are often small, and >>> because they are often >>> dominated in size by the legal header, it is sometimes more convenient >>> (but not required) to embed >>> these files in strings in the main test program. >>> >>> Be careful when comparing javac output against golden files. Your test >>> will almost certainly fail on >>> Windows, because the output written by java will contain Windows-style >>> line-terminators (\r\n), but >>> the golden file will contain Unix-style line terminators (\n). The >>> recommend solutions are to either >>> convert one of the strings to be compared to be compatible with the >>> other, or to compare them >>> as a "list of lines". >>> >>> In addition, javac provides a hidden option -XDrawDiagnostics for use in >>> cases like this, which causes >>> it to use just the simple name of the file, and to use resource keys >>> instead of localized strings. >>> This helps avoid what you had to do in lines 47,48 of T8235457.java. >>> >>> You may have intended an additional line break in the middle of line 34. >>> >>> The code would be more concise if you just accessed the system >>> properties for test.src and test.classes >>> once and stored the results in variables to use later. Even better is to >>> store them in type-safe variables >>> of type File or Path instead of plain old String. Stylistically, it is >>> nicer to use either File or Path, but not >>> a mixture unless absolutely necessary. In general, Path (as the newer >>> API) is the better overall choice. >>> >>> Also regarding consistency, you use a mixture of Arrays.asList and >>> List.of. That's not wrong, but >>> consistent use of List.of would be better. >>> >>> Cool for using StandardLocation.ANNOTATION_PROCESSOR_MODULE_PATH. I >>> don't think your anno >>> processor needed to be a module, but it is nice to see that you chose to >>> make it one. >>> (You could have just put the processor class on the classpath and used >>> the -processor option to >>> specify it by name ;-) ) >>> >>> -- Jon >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Tue Dec 10 16:04:46 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 10 Dec 2019 17:04:46 +0100 Subject: JDK 15 RFR: JDK-8225361 : Start of release updates for JDK 15, includes JDK-8235497 and JDK-8235528 In-Reply-To: <9c055943-3794-c975-0bd7-2f3f94ea86f3@oracle.com> References: <9c055943-3794-c975-0bd7-2f3f94ea86f3@oracle.com> Message-ID: Hi, The javac changes look OK to me. Jan On 07. 12. 19 7:32, Joe Darcy wrote: > Hello, > > The time approaches to being JDK 15! Please review the general langtools > API and spec updates for this: > > ??? http://cr.openjdk.java.net/~darcy/8225361.5/ > > The langtools portion includes two bugs with corresponding CSRs that > also need review: > > ??? JDK-8235497: Add SourceVersion.RELEASE_15 > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235498 > > ??? JDK-8235528: Add source 15 and target 15 to javac > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235529 > > It might be time to retire the notion of profiles for new releases, but > that can be decided another day. > > Thanks, > > -Joe > From jan.lahoda at oracle.com Tue Dec 10 16:15:42 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 10 Dec 2019 17:15:42 +0100 Subject: RFR: JDK-8235541: Extend javax.lang.model to cover binding variables Message-ID: <64dfb7fa-6483-7dfb-12c2-38abaa856478@oracle.com> Hi, The bindings variables might get their own ElementKind constant (as e.g. resource variables and exception parameters get). The proposed addition is here: http://cr.openjdk.java.net/~jlahoda/8235541/webrev.00/ I've started with the CSR here: https://bugs.openjdk.java.net/browse/JDK-8235590 JBS: https://bugs.openjdk.java.net/browse/JDK-8235541 How does this look? Thanks, Jan From jonathan.gibbons at oracle.com Tue Dec 10 19:45:27 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Dec 2019 11:45:27 -0800 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module In-Reply-To: References: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> <2e2fe310-5a0e-94f5-1655-7c3421b67b14@oracle.com> Message-ID: FYI ... * For a regexp solution, you can use just "\R"? ... replaceAll("\\R", "\n") * For a list-of-lines solution you can do the following: 68 List actualOutput = outputWriter.toString().lines().collect(Collectors.toList()); 69 List expectedOutput = Files.readLines(testBasePath.resolve("ReportOnImportedModuleAnnotation.out"))); 70 71 if(!actualOutput.equals(expectedOutput)) { ?72 System.err.println("Expected: ["); expectedOutput.forEach(System.err::println); System.err.println("]"); 73 System.err.println("Received: ["); actualOutput.forEach(System.err::println); System.err.println("]"); * For a test-library solution, use toolbox.* to run javac, collect the results as lines, and compare the resulting lists. See the package in test/langtools/tools/lib/toolbox. But, for now, the lineSeparator solution is good enough. -- Jon On 12/10/2019 01:10 AM, Jeremy Kuhn wrote: > Hi, > > I'm Ok with the changes you suggest, it makes sense. I googled a bit > to find the regexp solution but using line.separator property is > cleaner indeed. > > Thanks! > > On Tue, Dec 10, 2019 at 3:30 AM Jonathan Gibbons > > wrote: > > Jeremy, > > Thank you for your updated patches. > > I've taken your patches and posted them in a single webrev, with > the intent to eventually push them as a single changeset. > > http://cr.openjdk.java.net/~jjg/8235457-8235458/webrev.00/ > > > While it is not common to post a single changeset for multiple > issues, I think it is warranted in this case because the bug fixes > are small and the one test covers both fixes. (And, I don't think > it is worth splitting the test in two, one for each fix.)? There's > a somewhat stronger rule that says that fixes should have > associated tests, and so it would be inappropriate to push > disjoint fixes and tests. > > I've taken the liberty of applying some trivial cleanup: > > * I moved the test into test/langtools/tools/javac/processing > instead of test/langtools/tools/javac/modules. The primary reason > for this is that the fixes themselves are in code that is more > strongly associated with annotation processing.? Moving the test > does not need any corresponding code changes. > > * I fixed the use of /nodynamiccopyright/. I'm sorry I didn't > explain it better. It should appear in a comment in files that > appear as messages with line numbers in a golden file, and so > which should not have a legal header. In this case, it is > mods-src2/mod/module-info.java that appears in the golden file, > and so that is the file that should have /nodynamiccopyright/ > instead of the legal header.?? Making this change meant that I had > to make a corresponding update in the line number in the golden > file.? By the same reasoning, I removed /nodynamiccopyright/ from > the test file, since that file is not mentioned in the golden file. > > -- > > I'm not sure quite what you're trying to do with those regular > expressions trying to normalize newlines. On Unix, they'll be > no-ops, but on Windows, they will completely remove newlines. Not > wrong, but sorta weirdly inconsistent.? I'd suggest to avoid > regexes here and just doing a literal replace of > System.getProperty("line.separator") with "\n", as in > > 68 String actualOutput = outputWriter.toString(); > 69 String expectedOutput = Files.readString(testBasePath.resolve("ReportOnImportedModuleAnnotation.out"))); > 70 > String lineSep = System.getProperty("line.separator"); > 71 if(!actualOutput.replace(lineSep, "\n").equals(expectedOutput.replace(lineSep, "\n"))) { > > There are other ways you can write this, but that is the simplest > adjustment to what you have here, and without getting into using > test library code. > > If you're OK, I can make this change before running the patch > through our internal build-and-test system. > > -- Jon > > > On 12/09/2019 03:12 PM, Jeremy Kuhn wrote: >> Hi Jon, >> >> Following my previous mail, please find enclosed updated patches: >> - JDK-8235457.patch provides fix for 8235457 bug >> - JDK-8235458.pathc provides fix for 8235458 bug >> - JDK-8235457-8235458.patch provides a test to validate both >> fixes: a processor reporting a message on an imported module >> annotation. >> >> JCheck doesn't complain, code is more consistent and legal header >> has been added. >> >> Please let me know if you need anything else. >> >> Jeremy >> >> On Sat, Dec 7, 2019 at 7:47 AM Jeremy Kuhn >> > >> wrote: >> >> Hi Jon, >> >> I take good note of your comments and get back to you with >> updated patches asap. >> >> As for the other bug 8235458, you're actually right to say >> that both tests are quite similar: annotation module is the >> same, processor module is almost the same except that the >> processor doesn't report a message on the annotation to avoid >> the first issue and the mod module uses import. >> >> I did that to clearly separate the two tests, there's >> different approaches to testing, either we test one >> particular issue at a time (following a bug) or we test a >> wider functionality and potentially other things at the same >> time. Since I saw many directories named after a bug number I >> assumed the first approach was expected but clearly I would >> prefer to test functionalities (and reduce code) >> >> Following your comment on names I think I'll create one >> folder for both tests in test/langtools/tools/javac/modules >> or test/langtools/tools/javac/annotations defining annotation >> and processor modules once. Now I can either test both issues >> altogether with one annotated module with import statements >> or create separate tests to test the import issue separately, >> I think that one test here would be ok because if the first >> test fails the other would inevitably fail as well (since the >> processor report message on annotation), there's no need to >> report twice the same error and in case of error the issue >> would be quite clear: either assertion error or the >> annotation processor doesn't process the annotation, in any >> case you'll know what to do. >> >> So I propose to create three patches: one for each bug fix >> and one for the test if that's ok for you. >> >> Regarding annotation processor module path, what can I say I >> like modules :-P >> >> Jeremy >> >> On Sat, Dec 7, 2019 at 1:39 AM Jonathan Gibbons >> > > wrote: >> >> >> >> On 12/06/2019 03:36 PM, Jeremy Kuhn wrote: >>> Hi, >>> >>> Following previous discussions please find enclosed a >>> patch for the issue referenced in JDK-8235457. >>> >>> The >>> com.sun.tools.javac.model.JavacElements#matchAnnoToTree() >>> method (line 275) is invoked when reporting a message on >>> an annotation on an element to return the tree for an >>> annotation given the annotated element, this allows the >>> compiler to output the correct line where the message >>> should be displayed, however in the "Vis" class within >>> the method the JCModuleDecl has probably been forgotten >>> when modules were introduced in JDK-9 leading to an >>> AssertionError crashing the compiler when an annotation >>> processor tries to report a message on a module's >>> annotation. >>> >>> In order to fix the issue, I've simply implemented the >>> missing method visitModuleDef() in the Vis class so that >>> modules' annotations are properly returned. >>> >>> You'll find a jtreg test in the patch as well, I've >>> actually created three modules for the test: >>> - annotation: which defines a simple module annotation >>> - processor: which provides the annotation processor >>> reporting a message on the module's annotation >>> - mod: which contains a module annotated with the >>> previous annotation >>> >>> The test is successful when the test run without error >>> and the message is properly displayed by the compiler. >>> >>> I didn't find a way to use jtreg tags to compile >>> modules, so I've decided to compile everything >>> programmatically in the test main() method. >>> >>> Please let me know if I can be of any further assistance. >> >> Hi Jeremy, >> >> Thanks for providing the patch for the first of your >> issues. I've uploaded the patch as a webrev: >> http://cr.openjdk.java.net/~jjg/8235457/webrev/index.html >> >> >> Some comments ... >> >> Some of the files contain tab characters. Code in OpenJDK >> should always use spaces instead of tabs. >> This and other white-space rules (no trailing spaces;? >> source files end with newline, etc) are enforced >> by a Mercurial extension called jcheck, available here: >> http://openjdk.java.net/projects/code-tools/jcheck/ >> >> Although I acknowledge you'll see a lot of instances in >> test/langtools/tools/javac, we now regard the >> use of a directory named after a bug number as something >> of an anti-pattern. The same for source >> files and other related files. The preferred style these >> days is to use a "human-understandable" name, >> perhaps as a subdirectory in a directory of functionally >> related tests. >> >> Source files, including test source files, should >> generally have the "standard" legal header. >> For test files, the standard is to use GPL2 without the >> ClassPath Exception. In most cases, you >> can copy the header from a nearby file and just update >> the date to be the current year,? as in >> >> * Copyright (c) 2019, Oracle and/or its affiliates. All >> rights reserved. >> >> I note you used /nodynamiccopyright/. This is just for >> use in files that will be compiled, and the >> compilation generates output (containing line-numbers) >> that will be compared against a "golden-file". >> The purpose of the comment is to mark the file to >> indicate it should not have a comment, on the >> grounds that if it had a comment and at some point in the >> future the header were to be changed, >> the test might break (i.e. if the number of lines in the >> header were changed, affecting line numbers in >> the source file. >> >> Because source files to be compiled in javac tests are >> often small, and because they are often >> dominated in size by the legal header, it is sometimes >> more convenient (but not required) to embed >> these files in strings in the main test program. >> >> Be careful when comparing javac output against golden >> files. Your test will almost certainly fail on >> Windows, because the output written by java will contain >> Windows-style line-terminators (\r\n), but >> the golden file will contain Unix-style line terminators >> (\n). The recommend solutions are to either >> convert one of the strings to be compared to be >> compatible with the other, or to compare them >> as a "list of lines". >> >> In addition, javac provides a hidden option >> -XDrawDiagnostics for use in cases like this, which causes >> it to use just the simple name of the file, and to use >> resource keys instead of localized strings. >> This helps avoid what you had to do in lines 47,48 of >> T8235457.java. >> >> You may have intended an additional line break in the >> middle of line 34. >> >> The code would be more concise if you just accessed the >> system properties for test.src and test.classes >> once and stored the results in variables to use later. >> Even better is to store them in type-safe variables >> of type File or Path instead of plain old String. >> Stylistically, it is nicer to use either File or Path, >> but not >> a mixture unless absolutely necessary. In general, Path >> (as the newer API) is the better overall choice. >> >> Also regarding consistency, you use a mixture of >> Arrays.asList and List.of. That's not wrong, but >> consistent use of List.of would be better. >> >> Cool for using >> StandardLocation.ANNOTATION_PROCESSOR_MODULE_PATH. I >> don't think your anno >> processor needed to be a module, but it is nice to see >> that you chose to make it one. >> (You could have just put the processor class on the >> classpath and used the -processor option to >> specify it by name ;-) ) >> >> -- Jon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Dec 11 00:26:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Dec 2019 16:26:31 -0800 Subject: RFR: JDK-8235621: Replace use of Function with ToIntFunction In-Reply-To: <332152246.573091.1575963554687.JavaMail.zimbra@u-pem.fr> References: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> <569551612.540516.1575940800028.JavaMail.zimbra@u-pem.fr> <332152246.573091.1575963554687.JavaMail.zimbra@u-pem.fr> Message-ID: R?mi, I don't believe there are any valid use cases for the scenario you describe, particularly with a lambda as simple as "(Object o) -> 12". Not only are there no existing clients of the proposed API, since it is new API, any realistic clients will want to access the symbol in order to write the contents of the attribute. While there may be reasons in more general contexts to use a super wildcard, I don't believe that applies here, and I think it is better to support the simple non-wildcard case instead of forcing wildcards on clients. This proposed change is *just* about responding to your earlier suggestion to replace Function with ToIntFunction. -- Jon On 12/09/2019 11:39 PM, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "jonathan gibbons" >> ?: "Remi Forax" >> Cc: "compiler-dev" >> Envoy?: Mardi 10 D?cembre 2019 02:28:23 >> Objet: Re: RFR: JDK-8235621: Replace use of Function with ToIntFunction >> R?mi, >> >> While I understand the use of wildcards for parameters and return types, I don't >> think it makes sense to allow/use "? super Symbol" in this situation. I'd >> prefer to keep it simple and just use ToIntFunction. > but you are forcing people that that already have a ToIntFunction to do a lambda to lambda conversion which is weird > > ToIntFunction extraAttributes = (Object o) -> 12; > addExtraAttributes(extraAttributes::applyAsInt); // WTF ? > > instead of > > ToIntFunction extraAttributes = (Object o) -> 12; > addExtraAttributes(extraAttributes); > >> -- Jon > R?mi > >> >> On 12/09/2019 05:20 PM, Remi Forax wrote: >>> Hi Jonathan, >>> for addExtraAttributes, the method should be >>> >>> public void addExtraAttributes(ToIntFunction addExtraAttributes) >>> { >>> >>> for the same reason a public method should take a List and not an ArrayList, so >>> you can call it with >>> addExtraAttributes((Object o) -> 12); >>> if the attribute is constant. >>> >>> If addExtraAttributes takes a ToIntFunction, you will have to >>> use ToIntFunction everywhere. >>> >>> I should propose a new JEP to lock Dan Smith into a prison until JEP 300 [1] is >>> delivered, because we will be able to get ride of most of those pesky wildcards >>> (at least all the ones on functional interfaces) if that JEP is delivered. >>> >>> regards, >>> R?mi >>> >>> [1] https://openjdk.java.net/jeps/300 >>> >>> ----- Mail original ----- >>>> De: "jonathan gibbons" >>>> ?: "compiler-dev" >>>> Envoy?: Mardi 10 D?cembre 2019 01:38:44 >>>> Objet: RFR: JDK-8235621: Replace use of Function with ToIntFunction >>>> Following R?mi's suggestion[1], please review a trivial change to javac >>>> to have it use ToIntFunction >>>> instead of Function<..., Integer> in the recent patch for JDK-8234689 [2]. >>>> >>>> Patch inline below. No change to the original test is necessary. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235621 >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014043.html >>>> [2] https://hg.openjdk.java.net/jdk/jdk/rev/17b0f051280f >>>> >>>> -- Jon >>>> >>>> diff -r 2aaa8bcb90a9 -r 1e000f399f3a >>>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >>>> >>>> --- >>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >>>> Mon Dec 09 15:28:46 2019 +0100 >>>> +++ >>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >>>> Mon Dec 09 16:12:42 2019 -0800 >>>> @@ -30,7 +30,7 @@ >>>> ?import java.util.Map; >>>> ?import java.util.Set; >>>> ?import java.util.LinkedHashSet; >>>> -import java.util.function.Function; >>>> +import java.util.function.ToIntFunction; >>>> >>>> ?import javax.tools.JavaFileManager; >>>> ?import javax.tools.FileObject; >>>> @@ -114,7 +114,7 @@ >>>> ????? */ >>>> ???? public boolean multiModuleMode; >>>> >>>> -??? private List> extraAttributeHooks = >>>> List.nil(); >>>> +??? private List> extraAttributeHooks = List.nil(); >>>> >>>> ???? /** The initial sizes of the data and constant pool buffers. >>>> ????? *? Sizes are increased when buffers get full. >>>> @@ -191,7 +191,7 @@ >>>> ???????? } >>>> ???? } >>>> >>>> -??? public void addExtraAttributes(Function >>>> addExtraAttributes) { >>>> +??? public void addExtraAttributes(ToIntFunction >>>> addExtraAttributes) { >>>> ???????? extraAttributeHooks = >>>> extraAttributeHooks.prepend(addExtraAttributes); >>>> ???? } >>>> >>>> @@ -1669,7 +1669,7 @@ >>>> ????? */ >>>> ???? protected int writeExtraAttributes(Symbol sym) { >>>> ???????? int i = 0; >>>> -??????? for (Function hook : extraAttributeHooks) { >>>> +??????? for (ToIntFunction hook : extraAttributeHooks) { >>>> ???????????? i += hook.apply(sym); >>>> ???????? } >>>> ???????? return i; From joe.darcy at oracle.com Wed Dec 11 01:33:29 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 10 Dec 2019 17:33:29 -0800 Subject: RFR: JDK-8235541: Extend javax.lang.model to cover binding variables In-Reply-To: <64dfb7fa-6483-7dfb-12c2-38abaa856478@oracle.com> References: <64dfb7fa-6483-7dfb-12c2-38abaa856478@oracle.com> Message-ID: <895c7190-223b-9fb4-ea25-582455694f54@oracle.com> Hi Jan, Please fix the try-with-resources typo in the TestBindingVariableData.java test: 42 /** 43 * Using the tree API, retrieve element representations of the 44 * resource of a try-with-resources statement and verify their kind 45 * tags are set appropriately. 46 */ Otherwise, looks okay; thanks, -Joe On 12/10/2019 8:15 AM, Jan Lahoda wrote: > Hi, > > The bindings variables might get their own ElementKind constant (as > e.g. resource variables and exception parameters get). The proposed > addition is here: > http://cr.openjdk.java.net/~jlahoda/8235541/webrev.00/ > > I've started with the CSR here: > https://bugs.openjdk.java.net/browse/JDK-8235590 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235541 > > How does this look? > > Thanks, > ???? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Dec 11 04:40:24 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 10 Dec 2019 23:40:24 -0500 Subject: RFR: JDK-8234101: Compilation error thrown when repeating annotation is used on record component Message-ID: <27c343ab-8616-cf4c-5da7-11d98a465e57@oracle.com> Hi, Please review the fix for [1] at [2]. This patch provides support for repeating annotations on records. It builds on the previous support for annotations for records. Which is that all annotations applied to record components are pushed down to all members generated by the compiler from each record component: field, constructor parameter and accessor. Later at Check::validateAnnotation if we have gone too far and had applied an annotation to a non-applicable location, it is removed. The idea of this patch is that when a repeated annotations are being processed at Annotate::processRepeatedAnnotations, if the annotated element is a record or a record member and the annotation is not applicable to it, we bail out instead of issuing an error. Later on at Check::validateAnnotation when we have all the information about the annotations we can remove non-applicable annotations as before. But there is an important detail Check::validateAnnotation, validates annotations one by one, so if an annotation has been repeated kind of: record R(@A @A int i) {} then the method will be invoked twice for each appearance of @A, currently Check::validateAnnotation can remove each instance, but we also want to remove the container annotation which is synthetically generated by javac. For this reason I have modified SymbolMetadata::remove to remove a container annotation if at least one of the contained annotations is removed. How does it looks? Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8234101 [2] http://cr.openjdk.java.net/~vromero/8234101/webrev.00/ From jan.lahoda at oracle.com Wed Dec 11 17:54:59 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 11 Dec 2019 18:54:59 +0100 Subject: RFR: JDK-8234101: Compilation error thrown when repeating annotation is used on record component In-Reply-To: <27c343ab-8616-cf4c-5da7-11d98a465e57@oracle.com> References: <27c343ab-8616-cf4c-5da7-11d98a465e57@oracle.com> Message-ID: <6cb9dabc-34c6-86c4-a6d5-3dde828778b1@oracle.com> Looks OK to me for now. But I wonder if we eventually shouldn't find a better place for the side-effects made in Check.validateAnnotation (i.e. tat "validate" would not have side-effects except for reporting errors). Jan On 11. 12. 19 5:40, Vicente Romero wrote: > Hi, > > Please review the fix for [1] at [2]. This patch provides support for > repeating annotations on records. It builds on the previous support for > annotations for records. Which is that all annotations applied to record > components are pushed down to all members generated by the compiler from > each record component: field, constructor parameter and accessor. Later > at Check::validateAnnotation if we have gone too far and had applied an > annotation to a non-applicable location, it is removed. > > The idea of this patch is that when a repeated annotations are being > processed at Annotate::processRepeatedAnnotations, if the annotated > element is a record or a record member and the annotation is not > applicable to it, we bail out instead of issuing an error. Later on at > Check::validateAnnotation when we have all the information about the > annotations we can remove non-applicable annotations as before. But > there is an important detail Check::validateAnnotation, validates > annotations one by one, so if an annotation has been repeated kind of: > > record R(@A @A int i) {} > > then the method will be invoked twice for each appearance of @A, > currently Check::validateAnnotation can remove each instance, but we > also want to remove the container annotation which is synthetically > generated by javac. For this reason I have modified > SymbolMetadata::remove to remove a container annotation if at least one > of the contained annotations is removed. How does it looks? > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8234101 > [2] http://cr.openjdk.java.net/~vromero/8234101/webrev.00/ From vicente.romero at oracle.com Wed Dec 11 18:20:34 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 11 Dec 2019 13:20:34 -0500 Subject: RFR: JDK-8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference Message-ID: <3e6c2e3e-eed1-3b18-0b3c-3e1cff911234@oracle.com> Hi, Please review this P4 targeted to 14. Javac is failing to check the staticness of the most specific candidate, instead it is checking the staticness of all the possible candidates. This patch fixes that issue. Thanks, Vicente PS, the fix was originally developed by Maurizio http://cr.openjdk.java.net/~vromero/8231461/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8231461 From jonathan.gibbons at oracle.com Wed Dec 11 18:49:09 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Dec 2019 10:49:09 -0800 Subject: RFR: JDK-8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference In-Reply-To: <3e6c2e3e-eed1-3b18-0b3c-3e1cff911234@oracle.com> References: <3e6c2e3e-eed1-3b18-0b3c-3e1cff911234@oracle.com> Message-ID: <1b233d56-705c-4045-d7b2-9aaed4787d0b@oracle.com> The basic fix is OK. The test is a little light and may be a candidate for a follow-up fix to provide a small combo test covering static/non-static bound/unbound, and maybe verifying error messages. -- Jon On 12/11/2019 10:20 AM, Vicente Romero wrote: > Hi, > > Please review this P4 targeted to 14. Javac is failing to check the > staticness of the most specific candidate, instead it is checking the > staticness of all the possible candidates. This patch fixes that issue. > > Thanks, > Vicente > > PS, the fix was originally developed by Maurizio > > http://cr.openjdk.java.net/~vromero/8231461/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8231461 From vicente.romero at oracle.com Wed Dec 11 19:16:12 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 11 Dec 2019 14:16:12 -0500 Subject: RFR: JDK-8234101: Compilation error thrown when repeating annotation is used on record component In-Reply-To: <6cb9dabc-34c6-86c4-a6d5-3dde828778b1@oracle.com> References: <27c343ab-8616-cf4c-5da7-11d98a465e57@oracle.com> <6cb9dabc-34c6-86c4-a6d5-3dde828778b1@oracle.com> Message-ID: right I agree with that, we can also split the method into two one that does validation and one that do the special job for records Vicente On 12/11/19 12:54 PM, Jan Lahoda wrote: > Looks OK to me for now. > > But I wonder if we eventually shouldn't find a better place for the > side-effects made in Check.validateAnnotation (i.e. tat "validate" > would not have side-effects except for reporting errors). > > Jan > > On 11. 12. 19 5:40, Vicente Romero wrote: >> Hi, >> >> Please review the fix for [1] at [2]. This patch provides support for >> repeating annotations on records. It builds on the previous support >> for annotations for records. Which is that all annotations applied to >> record components are pushed down to all members generated by the >> compiler from each record component: field, constructor parameter and >> accessor. Later at Check::validateAnnotation if we have gone too far >> and had applied an annotation to a non-applicable location, it is >> removed. >> >> The idea of this patch is that when a repeated annotations are being >> processed at Annotate::processRepeatedAnnotations, if the annotated >> element is a record or a record member and the annotation is not >> applicable to it, we bail out instead of issuing an error. Later on >> at Check::validateAnnotation when we have all the information about >> the annotations we can remove non-applicable annotations as before. >> But there is an important detail Check::validateAnnotation, validates >> annotations one by one, so if an annotation has been repeated kind of: >> >> record R(@A @A int i) {} >> >> then the method will be invoked twice for each appearance of @A, >> currently Check::validateAnnotation can remove each instance, but we >> also want to remove the container annotation which is synthetically >> generated by javac. For this reason I have modified >> SymbolMetadata::remove to remove a container annotation if at least >> one of the contained annotations is removed. How does it looks? >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8234101 >> [2] http://cr.openjdk.java.net/~vromero/8234101/webrev.00/ From jonathan.gibbons at oracle.com Wed Dec 11 21:09:44 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Dec 2019 13:09:44 -0800 Subject: [PATCH] JDK-8235457: Crash when reporting a message about an annotation on a module In-Reply-To: References: <3146b72e-c7f7-001a-7133-e4fc78f755c3@oracle.com> <2e2fe310-5a0e-94f5-1655-7c3421b67b14@oracle.com> Message-ID: <1d193409-adfd-5f9a-2cd4-efcc4ffbac57@oracle.com> To close out this thread, I have pushed the changeset: https://hg.openjdk.java.net/jdk/jdk/rev/8086ccbe445d Jeremy, thanks again for your contribution. -- Jon On 12/10/2019 11:45 AM, Jonathan Gibbons wrote: > > FYI ... > > * For a regexp solution, you can use just "\R"? ... replaceAll("\\R", > "\n") > > * For a list-of-lines solution you can do the following: > > 68 List actualOutput = outputWriter.toString().lines().collect(Collectors.toList()); > 69 List expectedOutput = Files.readLines(testBasePath.resolve("ReportOnImportedModuleAnnotation.out"))); > 70 > 71 if(!actualOutput.equals(expectedOutput)) { > ?72 System.err.println("Expected: ["); expectedOutput.forEach(System.err::println); System.err.println("]"); > 73 System.err.println("Received: ["); actualOutput.forEach(System.err::println); System.err.println("]"); > > * For a test-library solution, use toolbox.* to run javac, collect the > results as lines, and compare the resulting lists. See the package in > test/langtools/tools/lib/toolbox. > > But, for now, the lineSeparator solution is good enough. > > -- Jon > > > On 12/10/2019 01:10 AM, Jeremy Kuhn wrote: >> Hi, >> >> I'm Ok with the changes you suggest, it makes sense. I googled a bit >> to find the regexp solution but using line.separator property is >> cleaner indeed. >> >> Thanks! >> >> On Tue, Dec 10, 2019 at 3:30 AM Jonathan Gibbons >> > wrote: >> >> Jeremy, >> >> Thank you for your updated patches. >> >> I've taken your patches and posted them in a single webrev, with >> the intent to eventually push them as a single changeset. >> >> http://cr.openjdk.java.net/~jjg/8235457-8235458/webrev.00/ >> >> >> While it is not common to post a single changeset for multiple >> issues, I think it is warranted in this case because the bug >> fixes are small and the one test covers both fixes. (And, I don't >> think it is worth splitting the test in two, one for each fix.)? >> There's a somewhat stronger rule that says that fixes should have >> associated tests, and so it would be inappropriate to push >> disjoint fixes and tests. >> >> I've taken the liberty of applying some trivial cleanup: >> >> * I moved the test into test/langtools/tools/javac/processing >> instead of test/langtools/tools/javac/modules. The primary reason >> for this is that the fixes themselves are in code that is more >> strongly associated with annotation processing. Moving the test >> does not need any corresponding code changes. >> >> * I fixed the use of /nodynamiccopyright/. I'm sorry I didn't >> explain it better. It should appear in a comment in files that >> appear as messages with line numbers in a golden file, and so >> which should not have a legal header. In this case, it is >> mods-src2/mod/module-info.java that appears in the golden file, >> and so that is the file that should have /nodynamiccopyright/ >> instead of the legal header. Making this change meant that I had >> to make a corresponding update in the line number in the golden >> file.? By the same reasoning, I removed /nodynamiccopyright/ from >> the test file, since that file is not mentioned in the golden file. >> >> -- >> >> I'm not sure quite what you're trying to do with those regular >> expressions trying to normalize newlines. On Unix, they'll be >> no-ops, but on Windows, they will completely remove newlines. Not >> wrong, but sorta weirdly inconsistent.? I'd suggest to avoid >> regexes here and just doing a literal replace of >> System.getProperty("line.separator") with "\n", as in >> >> 68 String actualOutput = outputWriter.toString(); >> 69 String expectedOutput = Files.readString(testBasePath.resolve("ReportOnImportedModuleAnnotation.out"))); >> 70 >> String lineSep = System.getProperty("line.separator"); >> 71 if(!actualOutput.replace(lineSep, "\n").equals(expectedOutput.replace(lineSep, "\n"))) { >> >> There are other ways you can write this, but that is the simplest >> adjustment to what you have here, and without getting into using >> test library code. >> >> If you're OK, I can make this change before running the patch >> through our internal build-and-test system. >> >> -- Jon >> >> >> On 12/09/2019 03:12 PM, Jeremy Kuhn wrote: >>> Hi Jon, >>> >>> Following my previous mail, please find enclosed updated patches: >>> - JDK-8235457.patch provides fix for 8235457 bug >>> - JDK-8235458.pathc provides fix for 8235458 bug >>> - JDK-8235457-8235458.patch provides a test to validate both >>> fixes: a processor reporting a message on an imported module >>> annotation. >>> >>> JCheck doesn't complain, code is more consistent and legal >>> header has been added. >>> >>> Please let me know if you need anything else. >>> >>> Jeremy >>> >>> On Sat, Dec 7, 2019 at 7:47 AM Jeremy Kuhn >>> > >>> wrote: >>> >>> Hi Jon, >>> >>> I take good note of your comments and get back to you with >>> updated patches asap. >>> >>> As for the other bug 8235458, you're actually right to say >>> that both tests are quite similar: annotation module is the >>> same, processor module is almost the same except that the >>> processor doesn't report a message on the annotation to >>> avoid the first issue and the mod module uses import. >>> >>> I did that to clearly separate the two tests, there's >>> different approaches to testing, either we test one >>> particular issue at a time (following a bug) or we test a >>> wider functionality and potentially other things at the same >>> time. Since I saw many directories named after a bug number >>> I assumed the first approach was expected but clearly I >>> would prefer to test functionalities (and reduce code) >>> >>> Following your comment on names I think I'll create one >>> folder for both tests in test/langtools/tools/javac/modules >>> or test/langtools/tools/javac/annotations defining >>> annotation and processor modules once. Now I can either test >>> both issues altogether with one annotated module with import >>> statements or create separate tests to test the import issue >>> separately, I think that one test here would be ok because >>> if the first test fails the other would inevitably fail as >>> well (since the processor report message on annotation), >>> there's no need to report twice the same error and in case >>> of error the issue would be quite clear: either assertion >>> error or the annotation processor doesn't process the >>> annotation, in any case you'll know what to do. >>> >>> So I propose to create three patches: one for each bug fix >>> and one for the test if that's ok for you. >>> >>> Regarding annotation processor module path, what can I say I >>> like modules :-P >>> >>> Jeremy >>> >>> On Sat, Dec 7, 2019 at 1:39 AM Jonathan Gibbons >>> >> > wrote: >>> >>> >>> >>> On 12/06/2019 03:36 PM, Jeremy Kuhn wrote: >>>> Hi, >>>> >>>> Following previous discussions please find enclosed a >>>> patch for the issue referenced in JDK-8235457. >>>> >>>> The >>>> com.sun.tools.javac.model.JavacElements#matchAnnoToTree() >>>> method (line 275) is invoked when reporting a message >>>> on an annotation on an element to return the tree for >>>> an annotation given the annotated element, this allows >>>> the compiler to output the correct line where the >>>> message should be displayed, however in the "Vis" class >>>> within the method the JCModuleDecl has probably been >>>> forgotten when modules were introduced in JDK-9 leading >>>> to an AssertionError crashing the compiler when an >>>> annotation processor tries to report a message on a >>>> module's annotation. >>>> >>>> In order to fix the issue, I've simply implemented the >>>> missing method visitModuleDef() in the Vis class so >>>> that modules' annotations are properly returned. >>>> >>>> You'll find a jtreg test in the patch as well, I've >>>> actually created three modules for the test: >>>> - annotation: which defines a simple module annotation >>>> - processor: which provides the annotation processor >>>> reporting a message on the module's annotation >>>> - mod: which contains a module annotated with the >>>> previous annotation >>>> >>>> The test is successful when the test run without error >>>> and the message is properly displayed by the compiler. >>>> >>>> I didn't find a way to use jtreg tags to compile >>>> modules, so I've decided to compile everything >>>> programmatically in the test main() method. >>>> >>>> Please let me know if I can be of any further assistance. >>> >>> Hi Jeremy, >>> >>> Thanks for providing the patch for the first of your >>> issues. I've uploaded the patch as a webrev: >>> http://cr.openjdk.java.net/~jjg/8235457/webrev/index.html >>> >>> >>> Some comments ... >>> >>> Some of the files contain tab characters. Code in >>> OpenJDK should always use spaces instead of tabs. >>> This and other white-space rules (no trailing spaces;? >>> source files end with newline, etc) are enforced >>> by a Mercurial extension called jcheck, available here: >>> http://openjdk.java.net/projects/code-tools/jcheck/ >>> >>> Although I acknowledge you'll see a lot of instances in >>> test/langtools/tools/javac, we now regard the >>> use of a directory named after a bug number as something >>> of an anti-pattern. The same for source >>> files and other related files. The preferred style these >>> days is to use a "human-understandable" name, >>> perhaps as a subdirectory in a directory of functionally >>> related tests. >>> >>> Source files, including test source files, should >>> generally have the "standard" legal header. >>> For test files, the standard is to use GPL2 without the >>> ClassPath Exception. In most cases, you >>> can copy the header from a nearby file and just update >>> the date to be the current year, as in >>> >>> * Copyright (c) 2019, Oracle and/or its affiliates. All >>> rights reserved. >>> >>> I note you used /nodynamiccopyright/. This is just for >>> use in files that will be compiled, and the >>> compilation generates output (containing line-numbers) >>> that will be compared against a "golden-file". >>> The purpose of the comment is to mark the file to >>> indicate it should not have a comment, on the >>> grounds that if it had a comment and at some point in >>> the future the header were to be changed, >>> the test might break (i.e. if the number of lines in the >>> header were changed, affecting line numbers in >>> the source file. >>> >>> Because source files to be compiled in javac tests are >>> often small, and because they are often >>> dominated in size by the legal header, it is sometimes >>> more convenient (but not required) to embed >>> these files in strings in the main test program. >>> >>> Be careful when comparing javac output against golden >>> files. Your test will almost certainly fail on >>> Windows, because the output written by java will contain >>> Windows-style line-terminators (\r\n), but >>> the golden file will contain Unix-style line terminators >>> (\n). The recommend solutions are to either >>> convert one of the strings to be compared to be >>> compatible with the other, or to compare them >>> as a "list of lines". >>> >>> In addition, javac provides a hidden option >>> -XDrawDiagnostics for use in cases like this, which causes >>> it to use just the simple name of the file, and to use >>> resource keys instead of localized strings. >>> This helps avoid what you had to do in lines 47,48 of >>> T8235457.java. >>> >>> You may have intended an additional line break in the >>> middle of line 34. >>> >>> The code would be more concise if you just accessed the >>> system properties for test.src and test.classes >>> once and stored the results in variables to use later. >>> Even better is to store them in type-safe variables >>> of type File or Path instead of plain old String. >>> Stylistically, it is nicer to use either File or Path, >>> but not >>> a mixture unless absolutely necessary. In general, Path >>> (as the newer API) is the better overall choice. >>> >>> Also regarding consistency, you use a mixture of >>> Arrays.asList and List.of. That's not wrong, but >>> consistent use of List.of would be better. >>> >>> Cool for using >>> StandardLocation.ANNOTATION_PROCESSOR_MODULE_PATH. I >>> don't think your anno >>> processor needed to be a module, but it is nice to see >>> that you chose to make it one. >>> (You could have just put the processor class on the >>> classpath and used the -processor option to >>> specify it by name ;-) ) >>> >>> -- Jon >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Dec 11 21:18:21 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 11 Dec 2019 21:18:21 +0000 Subject: RFR: JDK-8235621: Replace use of Function with ToIntFunction In-Reply-To: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> References: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> Message-ID: <4b4178fd-b986-0e00-4c65-7e298753ee59@oracle.com> Looks good - while I understand the general point around contravariance, I think it's always a trade off between simplicity and completeness. In this case, using ? super buys you nothing (since there's no interesting Symbol supertype). Yes Remi, we can write examples where that bites, but I don't think that's important - and we can change if (and when) that becomes an issue. Maurizio On 10/12/2019 00:38, Jonathan Gibbons wrote: > Following R?mi's suggestion[1], please review a trivial change to > javac to have it use ToIntFunction > instead of Function<..., Integer> in the recent patch for JDK-8234689 > [2]. > > Patch inline below. No change to the original test is necessary. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235621 > [1] > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014043.html > [2] https://hg.openjdk.java.net/jdk/jdk/rev/17b0f051280f > > -- Jon > > diff -r 2aaa8bcb90a9 -r 1e000f399f3a > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > Mon Dec 09 15:28:46 2019 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > Mon Dec 09 16:12:42 2019 -0800 > @@ -30,7 +30,7 @@ > ?import java.util.Map; > ?import java.util.Set; > ?import java.util.LinkedHashSet; > -import java.util.function.Function; > +import java.util.function.ToIntFunction; > > ?import javax.tools.JavaFileManager; > ?import javax.tools.FileObject; > @@ -114,7 +114,7 @@ > ????? */ > ???? public boolean multiModuleMode; > > -??? private List> extraAttributeHooks = > List.nil(); > +??? private List> extraAttributeHooks = > List.nil(); > > ???? /** The initial sizes of the data and constant pool buffers. > ????? *? Sizes are increased when buffers get full. > @@ -191,7 +191,7 @@ > ???????? } > ???? } > > -??? public void addExtraAttributes(Function > addExtraAttributes) { > +??? public void addExtraAttributes(ToIntFunction > addExtraAttributes) { > ???????? extraAttributeHooks = > extraAttributeHooks.prepend(addExtraAttributes); > ???? } > > @@ -1669,7 +1669,7 @@ > ????? */ > ???? protected int writeExtraAttributes(Symbol sym) { > ???????? int i = 0; > -??????? for (Function hook : extraAttributeHooks) { > +??????? for (ToIntFunction hook : extraAttributeHooks) { > ???????????? i += hook.apply(sym); > ???????? } > ???????? return i; > From maurizio.cimadamore at oracle.com Wed Dec 11 21:24:57 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 11 Dec 2019 21:24:57 +0000 Subject: RFR: JDK-8235597: Extend support for -XDaccessInternalAPI to plugin modules In-Reply-To: <3f2b4afb-ac83-c769-0013-2b1c0115babf@oracle.com> References: <3f2b4afb-ac83-c769-0013-2b1c0115babf@oracle.com> Message-ID: <5b14ea78-45ed-2312-eff0-c0ba2d9b33c5@oracle.com> Looks good. Wish we could (easily) use new features in tests (e.g. text blocks) :-) One small typo: 143 // negative control test: access fails without tyhe new option Cheers Maurizio On 09/12/2019 22:07, Jonathan Gibbons wrote: > Please review a small localized change to javac, to extend the support > for the existing hidden -XDaccessInternalAPI option to plugins > provided as modules. > > The change utilizes the existing ModuleHelper.addExports method. > > The test is derived from the recent new test AutostartPlugins.java.? > It creates a plugin in a jar file, in a module on the module path, and > in a module that is linked in to the image.? The test case for the > classpath is not new and is just provided for completeness. A negative > test case for plugin-as-module is provided, to demonstrate that access > fails without the option, and there are test cases for modules on the > module path and jlinked into an image. > > The positive test cases just verify that non-null elements in task > events can be downcast to ClassSymbol, and an internal field (the > kind) accessed. > > No CSR, since the option is undocumented, unsupported and subject to > change at any time. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235597 > Webrev: http://cr.openjdk.java.net/~jjg/8235597/webrev.00/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Dec 11 21:28:23 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Dec 2019 13:28:23 -0800 Subject: RFR: JDK-8235597: Extend support for -XDaccessInternalAPI to plugin modules In-Reply-To: <5b14ea78-45ed-2312-eff0-c0ba2d9b33c5@oracle.com> References: <3f2b4afb-ac83-c769-0013-2b1c0115babf@oracle.com> <5b14ea78-45ed-2312-eff0-c0ba2d9b33c5@oracle.com> Message-ID: Text blocks are coming ;-)? I hope we have good IDE integration coming as well ;-) -- Jon On 12/11/2019 01:24 PM, Maurizio Cimadamore wrote: > > Looks good. > > Wish we could (easily) use new features in tests (e.g. text blocks) :-) > > One small typo: > > 143 // negative control test: access fails without tyhe new option > > > Cheers > Maurizio > > On 09/12/2019 22:07, Jonathan Gibbons wrote: >> Please review a small localized change to javac, to extend the >> support for the existing hidden -XDaccessInternalAPI option to >> plugins provided as modules. >> >> The change utilizes the existing ModuleHelper.addExports method. >> >> The test is derived from the recent new test AutostartPlugins.java.? >> It creates a plugin in a jar file, in a module on the module path, >> and in a module that is linked in to the image.? The test case for >> the classpath is not new and is just provided for completeness. A >> negative test case for plugin-as-module is provided, to demonstrate >> that access fails without the option, and there are test cases for >> modules on the module path and jlinked into an image. >> >> The positive test cases just verify that non-null elements in task >> events can be downcast to ClassSymbol, and an internal field (the >> kind) accessed. >> >> No CSR, since the option is undocumented, unsupported and subject to >> change at any time. >> >> -- Jon >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235597 >> Webrev: http://cr.openjdk.java.net/~jjg/8235597/webrev.00/ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Dec 11 21:55:20 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 11 Dec 2019 22:55:20 +0100 Subject: RFR: JDK-8235621: Replace use of Function with ToIntFunction In-Reply-To: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> References: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> Message-ID: <9ac1ee91-c2ed-e1f0-a3b2-855cc5c99fd5@oracle.com> Looks OK to me. Jan On 10. 12. 19 1:38, Jonathan Gibbons wrote: > Following R?mi's suggestion[1], please review a trivial change to javac > to have it use ToIntFunction > instead of Function<..., Integer> in the recent patch for JDK-8234689 [2]. > > Patch inline below. No change to the original test is necessary. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235621 > [1] > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014043.html > > [2] https://hg.openjdk.java.net/jdk/jdk/rev/17b0f051280f > > -- Jon > > diff -r 2aaa8bcb90a9 -r 1e000f399f3a > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Mon > Dec 09 15:28:46 2019 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Mon > Dec 09 16:12:42 2019 -0800 > @@ -30,7 +30,7 @@ > ?import java.util.Map; > ?import java.util.Set; > ?import java.util.LinkedHashSet; > -import java.util.function.Function; > +import java.util.function.ToIntFunction; > > ?import javax.tools.JavaFileManager; > ?import javax.tools.FileObject; > @@ -114,7 +114,7 @@ > ????? */ > ???? public boolean multiModuleMode; > > -??? private List> extraAttributeHooks = > List.nil(); > +??? private List> extraAttributeHooks = List.nil(); > > ???? /** The initial sizes of the data and constant pool buffers. > ????? *? Sizes are increased when buffers get full. > @@ -191,7 +191,7 @@ > ???????? } > ???? } > > -??? public void addExtraAttributes(Function > addExtraAttributes) { > +??? public void addExtraAttributes(ToIntFunction > addExtraAttributes) { > ???????? extraAttributeHooks = > extraAttributeHooks.prepend(addExtraAttributes); > ???? } > > @@ -1669,7 +1669,7 @@ > ????? */ > ???? protected int writeExtraAttributes(Symbol sym) { > ???????? int i = 0; > -??????? for (Function hook : extraAttributeHooks) { > +??????? for (ToIntFunction hook : extraAttributeHooks) { > ???????????? i += hook.apply(sym); > ???????? } > ???????? return i; > From forax at univ-mlv.fr Wed Dec 11 22:07:30 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 11 Dec 2019 23:07:30 +0100 (CET) Subject: RFR: JDK-8235621: Replace use of Function with ToIntFunction In-Reply-To: <4b4178fd-b986-0e00-4c65-7e298753ee59@oracle.com> References: <50a68d71-ac34-f1e8-6ec8-dde7882b7ecd@oracle.com> <4b4178fd-b986-0e00-4c65-7e298753ee59@oracle.com> Message-ID: <75394473.24505.1576102050657.JavaMail.zimbra@u-pem.fr> Maurizio, Jon, It's not always a trade off between simplicity and completeness, you have other factors: - code inspector of IDEs that will warn you, and because you have now too many warnings, you just de-activate the code inspector, creating a vicious circle. - types that come from type inference, so a user doesn't fully control the type sent as argument. From my experience, it's a common way to get Object instead of a subtype. - teachers do not scale. As a teacher, you have to explain how wildcard works and then to explain why some random APIs of the JDK will not follow the rule. My answer is usually "ahhh, humans". You're right that thanks to erasure you can always add the wildcard later. And the right way(TM) to fix that issue if to introduce declaration site variance because use site annotations is not user friendly. Anyway, as you say it's not important, it does not worth to spend more time on that. So not introducing "? super" is fine for me. ahhh, humans :) regards, R?mi ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "jonathan gibbons" , "compiler-dev" > Envoy?: Mercredi 11 D?cembre 2019 22:18:21 > Objet: Re: RFR: JDK-8235621: Replace use of Function with ToIntFunction > Looks good - while I understand the general point around contravariance, > I think it's always a trade off between simplicity and completeness. In > this case, using ? super buys you nothing (since there's no interesting > Symbol supertype). Yes Remi, we can write examples where that bites, but > I don't think that's important - and we can change if (and when) that > becomes an issue. > > Maurizio > > On 10/12/2019 00:38, Jonathan Gibbons wrote: >> Following R?mi's suggestion[1], please review a trivial change to >> javac to have it use ToIntFunction >> instead of Function<..., Integer> in the recent patch for JDK-8234689 >> [2]. >> >> Patch inline below. No change to the original test is necessary. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235621 >> [1] >> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014043.html >> [2] https://hg.openjdk.java.net/jdk/jdk/rev/17b0f051280f >> >> -- Jon >> >> diff -r 2aaa8bcb90a9 -r 1e000f399f3a >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >> >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >> Mon Dec 09 15:28:46 2019 +0100 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >> Mon Dec 09 16:12:42 2019 -0800 >> @@ -30,7 +30,7 @@ >> ?import java.util.Map; >> ?import java.util.Set; >> ?import java.util.LinkedHashSet; >> -import java.util.function.Function; >> +import java.util.function.ToIntFunction; >> >> ?import javax.tools.JavaFileManager; >> ?import javax.tools.FileObject; >> @@ -114,7 +114,7 @@ >> ????? */ >> ???? public boolean multiModuleMode; >> >> -??? private List> extraAttributeHooks = >> List.nil(); >> +??? private List> extraAttributeHooks = >> List.nil(); >> >> ???? /** The initial sizes of the data and constant pool buffers. >> ????? *? Sizes are increased when buffers get full. >> @@ -191,7 +191,7 @@ >> ???????? } >> ???? } >> >> -??? public void addExtraAttributes(Function >> addExtraAttributes) { >> +??? public void addExtraAttributes(ToIntFunction >> addExtraAttributes) { >> ???????? extraAttributeHooks = >> extraAttributeHooks.prepend(addExtraAttributes); >> ???? } >> >> @@ -1669,7 +1669,7 @@ >> ????? */ >> ???? protected int writeExtraAttributes(Symbol sym) { >> ???????? int i = 0; >> -??????? for (Function hook : extraAttributeHooks) { >> +??????? for (ToIntFunction hook : extraAttributeHooks) { >> ???????????? i += hook.apply(sym); >> ???????? } >> ???????? return i; From jonathan.gibbons at oracle.com Wed Dec 11 23:15:46 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Dec 2019 15:15:46 -0800 Subject: RFR: JDK-8214916: SourceLauncherTest fails on exploded image Message-ID: It is sometimes convenient during JDK development to use an "exploded image" instead of a linked image. But, a couple of javac tests contain a couple of test cases that don't work in this configuration. The fix is simply to detect the situation and skip these test cases. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8214916 Webrev: http://cr.openjdk.java.net/~jjg/8214916/webrev/index.html From kusrinivasan at vmware.com Wed Dec 11 23:26:42 2019 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Wed, 11 Dec 2019 23:26:42 +0000 Subject: RFR: JDK-8214916: SourceLauncherTest fails on exploded image In-Reply-To: References: Message-ID: <88480E95-4968-49DD-87E1-65CF0928366A@vmware.com> Hi Jon, Looks ok to me. Kumar Srinivasan > On Dec 11, 2019, at 3:15 PM, Jonathan Gibbons wrote: > > It is sometimes convenient during JDK development to use an "exploded image" instead of a linked image. But, a couple of javac tests contain a couple of test cases that don't work in this configuration. > > The fix is simply to detect the situation and skip these test cases. > > -- Jon > > JBS: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8214916&data=02%7C01%7Ckusrinivasan%40vmware.com%7Cfecb9951809a4da74e3808d77e9021cd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637117029830557298&sdata=XKM%2F6%2BrRreBwyLHGi%2BKeb11gWE602wvRpWwZPuri5x4%3D&reserved=0 > Webrev: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~jjg%2F8214916%2Fwebrev%2Findex.html&data=02%7C01%7Ckusrinivasan%40vmware.com%7Cfecb9951809a4da74e3808d77e9021cd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637117029830557298&sdata=2X2dqQH2DsvVIcd8nlkqzDcWjEj%2BIuAQnJzCEqWa3Yw%3D&reserved=0 > From jan.lahoda at oracle.com Wed Dec 11 23:31:34 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 Dec 2019 00:31:34 +0100 Subject: RFR: JDK-8235541: Extend javax.lang.model to cover binding variables In-Reply-To: <895c7190-223b-9fb4-ea25-582455694f54@oracle.com> References: <64dfb7fa-6483-7dfb-12c2-38abaa856478@oracle.com> <895c7190-223b-9fb4-ea25-582455694f54@oracle.com> Message-ID: <6d5cdc5c-858a-2115-3f58-89bee76e9c01@oracle.com> Thanks Joe! I've changed the comment to: 42 /** 43 * Using the tree API, retrieve element representations of the 44 * binding variables of the type test pattern, and verify their kind 45 * tags are set appropriately. 46 */ Full webrev: http://cr.openjdk.java.net/~jlahoda/8235541/webrev.01/ I'll push this, unless there are objections. Thanks! Jan On 11. 12. 19 2:33, Joe Darcy wrote: > Hi Jan, > > Please fix the try-with-resources typo in the > TestBindingVariableData.java test: > > 42 /** > 43 * Using the tree API, retrieve element representations of the > 44 * resource of a try-with-resources statement and verify their kind > 45 * tags are set appropriately. > 46 */ > > Otherwise, looks okay; thanks, > > -Joe > > On 12/10/2019 8:15 AM, Jan Lahoda wrote: >> Hi, >> >> The bindings variables might get their own ElementKind constant (as >> e.g. resource variables and exception parameters get). The proposed >> addition is here: >> http://cr.openjdk.java.net/~jlahoda/8235541/webrev.00/ >> >> I've started with the CSR here: >> https://bugs.openjdk.java.net/browse/JDK-8235590 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235541 >> >> How does this look? >> >> Thanks, >> ???? Jan From vicente.romero at oracle.com Wed Dec 11 23:39:37 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 11 Dec 2019 18:39:37 -0500 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class Message-ID: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> Hi, Please review the fix for [1] at [2]. Records are not allowed to be defined inside inner classes. This patch extends the check to local inner classes which was missing. Thanks, Vicente https://bugs.openjdk.java.net/browse/JDK-8235778 http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ From maurizio.cimadamore at oracle.com Wed Dec 11 23:53:32 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 11 Dec 2019 23:53:32 +0000 Subject: RFR: JDK-8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference In-Reply-To: <1b233d56-705c-4045-d7b2-9aaed4787d0b@oracle.com> References: <3e6c2e3e-eed1-3b18-0b3c-3e1cff911234@oracle.com> <1b233d56-705c-4045-d7b2-9aaed4787d0b@oracle.com> Message-ID: I was thinking the same as Jon - this is tricky area - there are two separate lookup steps, each of which can have different results and then the method reference is selected according to some criteria between the two results. We had an history of issues in this area and, while the code is much more in sync with the spec than it used to be (which allowed for a relatively speedy fix), I think that the fact that we're still finding issues with it points at the fact that some better testing methodology is required. Generating combination automatically might not be the best way to approach this either - given that we would then need somehow to replicate all the complex machinery to decide which method reference gets resolved in the test itself, and that machinery can in itself be buggy. This is probably a case of spending a week or two combing through the spec, and maybe putting together a 'light' framework, like the one for records [1] or for 'var' [2] which allows to add new tests in relatively little time, so that we can add many variants by hand, testing the various corners of the spec logic. Maurizio [1] - https://hg.openjdk.java.net/jdk/jdk/file/8e76f81d057a/test/langtools/tools/javac/records/RecordCompilationTests.java [2] - http://hg.openjdk.java.net/jdk/jdk/file/tip/test/langtools/tools/javac/lvti/harness/NonDenotableTest.java On 11/12/2019 18:49, Jonathan Gibbons wrote: > The basic fix is OK. > > The test is a little light and may be a candidate for a follow-up fix > to provide a small combo test covering static/non-static > bound/unbound, and maybe verifying error messages. > > -- Jon > > > > On 12/11/2019 10:20 AM, Vicente Romero wrote: >> Hi, >> >> Please review this P4 targeted to 14. Javac is failing to check the >> staticness of the most specific candidate, instead it is checking the >> staticness of all the possible candidates. This patch fixes that issue. >> >> Thanks, >> Vicente >> >> PS, the fix was originally developed by Maurizio >> >> http://cr.openjdk.java.net/~vromero/8231461/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8231461 > From maurizio.cimadamore at oracle.com Thu Dec 12 00:08:34 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 12 Dec 2019 00:08:34 +0000 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> Message-ID: If sym.isLocal() returns true, is this check && (sym.owner.flags_field & STATIC) == 0) Needed? Aren't we inside a record declaration that is contained in some local context (e.g. within a method body), whose immediate enclosing type is a type T? If so, isn't T always non-static? I guess yes, unless T is a record itself, like: void m() { ?? record A() { ??????? record B() { } ?? } } The patch seems to be biased in favor of this - is it deliberate? (also there's no test around that). Should the spec say something? Maurizio On 11/12/2019 23:39, Vicente Romero wrote: > Hi, > > Please review the fix for [1] at [2]. Records are not allowed to be > defined inside inner classes. This patch extends the check to local > inner classes which was missing. > > Thanks, > Vicente > > https://bugs.openjdk.java.net/browse/JDK-8235778 > http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Dec 12 00:36:18 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 11 Dec 2019 19:36:18 -0500 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> Message-ID: <96841a4b-8284-d2c0-456c-e81142adab59@oracle.com> On 12/11/19 7:08 PM, Maurizio Cimadamore wrote: > > If sym.isLocal() returns true, is this check > > && (sym.owner.flags_field & STATIC) == 0) you are right there is no need for this check > Needed? Aren't we inside a record declaration that is contained in > some local context (e.g. within a method body), whose immediate > enclosing type is a type T? If so, isn't T always non-static? I guess > yes, unless T is a record itself, like: > > void m() { > ?? record A() { > ??????? record B() { } > ?? } > } > > The patch seems to be biased in favor of this - is it deliberate? > (also there's no test around that). Should the spec say something? this could be a good example to add to the spec. I will also add a test case covering this case > > Maurizio Thanks, Vicente > > On 11/12/2019 23:39, Vicente Romero wrote: >> Hi, >> >> Please review the fix for [1] at [2]. Records are not allowed to be >> defined inside inner classes. This patch extends the check to local >> inner classes which was missing. >> >> Thanks, >> Vicente >> >> https://bugs.openjdk.java.net/browse/JDK-8235778 >> http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Dec 12 00:40:01 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 11 Dec 2019 19:40:01 -0500 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> Message-ID: <671447a4-d93f-05a5-d26e-d538115b28a9@oracle.com> I have uploaded a new iteration at [1], Thanks for your comments, Vicente [1] http://cr.openjdk.java.net/~vromero/8235778/webrev.01/ On 12/11/19 7:08 PM, Maurizio Cimadamore wrote: > > If sym.isLocal() returns true, is this check > > && (sym.owner.flags_field & STATIC) == 0) > Needed? Aren't we inside a record declaration that is contained in > some local context (e.g. within a method body), whose immediate > enclosing type is a type T? If so, isn't T always non-static? I guess > yes, unless T is a record itself, like: > > void m() { > ?? record A() { > ??????? record B() { } > ?? } > } > > The patch seems to be biased in favor of this - is it deliberate? > (also there's no test around that). Should the spec say something? > > Maurizio > > On 11/12/2019 23:39, Vicente Romero wrote: >> Hi, >> >> Please review the fix for [1] at [2]. Records are not allowed to be >> defined inside inner classes. This patch extends the check to local >> inner classes which was missing. >> >> Thanks, >> Vicente >> >> https://bugs.openjdk.java.net/browse/JDK-8235778 >> http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Dec 12 12:34:38 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 12 Dec 2019 12:34:38 +0000 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <671447a4-d93f-05a5-d26e-d538115b28a9@oracle.com> References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> <671447a4-d93f-05a5-d26e-d538115b28a9@oracle.com> Message-ID: <8fc89684-e06f-a0b9-1b5e-6fa49ed81963@oracle.com> The patch is ok, but I'm still not super convinced about treatment of local records; example: $ cat TestLocalRecord.java class TestLocalRecord { void m() { ?? String s = "Hello!"; ?? record A() { ?????? void m() { System.out.println(s); } ?? } ?? new A().m(); } } $ javap -s TestLocalRecord\$1A.class Compiled from "TestLocalRecord.java" final class TestLocalRecord$1A extends java.lang.Record { ? final java.lang.String val$s; ??? descriptor: Ljava/lang/String; ? public TestLocalRecord$1A(); ??? descriptor: (Ljava/lang/String;)V ? void m(); ??? descriptor: ()V ? public java.lang.String toString(); ??? descriptor: ()Ljava/lang/String; ? public final int hashCode(); ??? descriptor: ()I ? public final boolean equals(java.lang.Object); ??? descriptor: (Ljava/lang/Object;)Z } Note the mismatch between the descriptor of the canonical constructor and the source signature of the same. This record seems not to be "the whole state and nothing but the state" because of the presence of captured fields in there. Maurizio On 12/12/2019 00:40, Vicente Romero wrote: > I have uploaded a new iteration at [1], > > Thanks for your comments, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8235778/webrev.01/ > > On 12/11/19 7:08 PM, Maurizio Cimadamore wrote: >> >> If sym.isLocal() returns true, is this check >> >> && (sym.owner.flags_field & STATIC) == 0) >> Needed? Aren't we inside a record declaration that is contained in >> some local context (e.g. within a method body), whose immediate >> enclosing type is a type T? If so, isn't T always non-static? I guess >> yes, unless T is a record itself, like: >> >> void m() { >> ?? record A() { >> ??????? record B() { } >> ?? } >> } >> >> The patch seems to be biased in favor of this - is it deliberate? >> (also there's no test around that). Should the spec say something? >> >> Maurizio >> >> On 11/12/2019 23:39, Vicente Romero wrote: >>> Hi, >>> >>> Please review the fix for [1] at [2]. Records are not allowed to be >>> defined inside inner classes. This patch extends the check to local >>> inner classes which was missing. >>> >>> Thanks, >>> Vicente >>> >>> https://bugs.openjdk.java.net/browse/JDK-8235778 >>> http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Thu Dec 12 14:04:27 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 12 Dec 2019 15:04:27 +0100 (CET) Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <8fc89684-e06f-a0b9-1b5e-6fa49ed81963@oracle.com> References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> <671447a4-d93f-05a5-d26e-d538115b28a9@oracle.com> <8fc89684-e06f-a0b9-1b5e-6fa49ed81963@oracle.com> Message-ID: <2060264764.306934.1576159467692.JavaMail.zimbra@u-pem.fr> yes, this code should not compile, a local record should not be able to capture local variables. An "inner" record is implicitly static for the same reason. R?mi > De: "Maurizio Cimadamore" > ?: "Vicente Romero" , "compiler-dev" > > Envoy?: Jeudi 12 D?cembre 2019 13:34:38 > Objet: Re: RFR: JDK-8235778: No compilation error reported when a record is > declared in a local class > The patch is ok, but I'm still not super convinced about treatment of local > records; example: > $ cat TestLocalRecord.java > class TestLocalRecord { > void m() { > String s = "Hello!"; > record A() { > void m() { System.out.println(s); } > } > new A().m(); > } > } > $ javap -s TestLocalRecord\$1A.class Compiled from "TestLocalRecord.java" > final class TestLocalRecord$1A extends java.lang.Record { > final java.lang.String val$s; > descriptor: Ljava/lang/String; > public TestLocalRecord$1A(); > descriptor: (Ljava/lang/String;)V > void m(); > descriptor: ()V > public java.lang.String toString(); > descriptor: ()Ljava/lang/String; > public final int hashCode(); > descriptor: ()I > public final boolean equals(java.lang.Object); > descriptor: (Ljava/lang/Object;)Z > } > Note the mismatch between the descriptor of the canonical constructor and the > source signature of the same. This record seems not to be "the whole state and > nothing but the state" because of the presence of captured fields in there. > Maurizio > On 12/12/2019 00:40, Vicente Romero wrote: >> I have uploaded a new iteration at [1], >> Thanks for your comments, >> Vicente >> [1] [ http://cr.openjdk.java.net/~vromero/8235778/webrev.01/ | >> http://cr.openjdk.java.net/~vromero/8235778/webrev.01/ ] >> On 12/11/19 7:08 PM, Maurizio Cimadamore wrote: >>> If sym.isLocal() returns true, is this check >>> && (sym.owner.flags_field & STATIC) == 0) >>> Needed? Aren't we inside a record declaration that is contained in some local >>> context (e.g. within a method body), whose immediate enclosing type is a type >>> T? If so, isn't T always non-static? I guess yes, unless T is a record itself, >>> like: >>> void m() { >>> record A() { >>> record B() { } >>> } >>> } >>> The patch seems to be biased in favor of this - is it deliberate? (also there's >>> no test around that). Should the spec say something? >>> Maurizio >>> On 11/12/2019 23:39, Vicente Romero wrote: >>>> Hi, >>>> Please review the fix for [1] at [2]. Records are not allowed to be defined >>>> inside inner classes. This patch extends the check to local inner classes which >>>> was missing. >>>> Thanks, >>>> Vicente >>>> [ https://bugs.openjdk.java.net/browse/JDK-8235778 | >>>> https://bugs.openjdk.java.net/browse/JDK-8235778 ] >>>> [ http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ | >>>> http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Dec 12 17:49:09 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 12 Dec 2019 12:49:09 -0500 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <8fc89684-e06f-a0b9-1b5e-6fa49ed81963@oracle.com> References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> <671447a4-d93f-05a5-d26e-d538115b28a9@oracle.com> <8fc89684-e06f-a0b9-1b5e-6fa49ed81963@oracle.com> Message-ID: <24e14156-0499-a694-6361-28a87bc95513@oracle.com> should the spec be more specific about local records, like mentioning that they can't capture state? Vicente On 12/12/19 7:34 AM, Maurizio Cimadamore wrote: > > The patch is ok, but I'm still not super convinced about treatment of > local records; example: > > $ cat TestLocalRecord.java > > class TestLocalRecord { > void m() { > ?? String s = "Hello!"; > ?? record A() { > ?????? void m() { System.out.println(s); } > ?? } > ?? new A().m(); > } > } > > $ javap -s TestLocalRecord\$1A.class Compiled from "TestLocalRecord.java" > > final class TestLocalRecord$1A extends java.lang.Record { > ? final java.lang.String val$s; > ??? descriptor: Ljava/lang/String; > ? public TestLocalRecord$1A(); > ??? descriptor: (Ljava/lang/String;)V > > ? void m(); > ??? descriptor: ()V > > ? public java.lang.String toString(); > ??? descriptor: ()Ljava/lang/String; > > ? public final int hashCode(); > ??? descriptor: ()I > > ? public final boolean equals(java.lang.Object); > ??? descriptor: (Ljava/lang/Object;)Z > } > > Note the mismatch between the descriptor of the canonical constructor > and the source signature of the same. This record seems not to be "the > whole state and nothing but the state" because of the presence of > captured fields in there. > > Maurizio > > > On 12/12/2019 00:40, Vicente Romero wrote: >> I have uploaded a new iteration at [1], >> >> Thanks for your comments, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8235778/webrev.01/ >> >> On 12/11/19 7:08 PM, Maurizio Cimadamore wrote: >>> >>> If sym.isLocal() returns true, is this check >>> >>> && (sym.owner.flags_field & STATIC) == 0) >>> Needed? Aren't we inside a record declaration that is contained in >>> some local context (e.g. within a method body), whose immediate >>> enclosing type is a type T? If so, isn't T always non-static? I >>> guess yes, unless T is a record itself, like: >>> >>> void m() { >>> ?? record A() { >>> ??????? record B() { } >>> ?? } >>> } >>> >>> The patch seems to be biased in favor of this - is it deliberate? >>> (also there's no test around that). Should the spec say something? >>> >>> Maurizio >>> >>> On 11/12/2019 23:39, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review the fix for [1] at [2]. Records are not allowed to be >>>> defined inside inner classes. This patch extends the check to local >>>> inner classes which was missing. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8235778 >>>> http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Dec 12 18:38:54 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 12 Dec 2019 18:38:54 +0000 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <24e14156-0499-a694-6361-28a87bc95513@oracle.com> References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> <671447a4-d93f-05a5-d26e-d538115b28a9@oracle.com> <8fc89684-e06f-a0b9-1b5e-6fa49ed81963@oracle.com> <24e14156-0499-a694-6361-28a87bc95513@oracle.com> Message-ID: <289634c3-2ac8-ef7e-f1c5-2632ce172a2f@oracle.com> I believe so - Remi started a thread on this topic on amber-spec-experts Maurizio On 12/12/2019 17:49, Vicente Romero wrote: > should the spec be more specific about local records, like mentioning > that they can't capture state? > > Vicente > > On 12/12/19 7:34 AM, Maurizio Cimadamore wrote: >> >> The patch is ok, but I'm still not super convinced about treatment of >> local records; example: >> >> $ cat TestLocalRecord.java >> >> class TestLocalRecord { >> void m() { >> ?? String s = "Hello!"; >> ?? record A() { >> ?????? void m() { System.out.println(s); } >> ?? } >> ?? new A().m(); >> } >> } >> >> $ javap -s TestLocalRecord\$1A.class Compiled from "TestLocalRecord.java" >> >> final class TestLocalRecord$1A extends java.lang.Record { >> ? final java.lang.String val$s; >> ??? descriptor: Ljava/lang/String; >> ? public TestLocalRecord$1A(); >> ??? descriptor: (Ljava/lang/String;)V >> >> ? void m(); >> ??? descriptor: ()V >> >> ? public java.lang.String toString(); >> ??? descriptor: ()Ljava/lang/String; >> >> ? public final int hashCode(); >> ??? descriptor: ()I >> >> ? public final boolean equals(java.lang.Object); >> ??? descriptor: (Ljava/lang/Object;)Z >> } >> >> Note the mismatch between the descriptor of the canonical constructor >> and the source signature of the same. This record seems not to be >> "the whole state and nothing but the state" because of the presence >> of captured fields in there. >> >> Maurizio >> >> >> On 12/12/2019 00:40, Vicente Romero wrote: >>> I have uploaded a new iteration at [1], >>> >>> Thanks for your comments, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8235778/webrev.01/ >>> >>> On 12/11/19 7:08 PM, Maurizio Cimadamore wrote: >>>> >>>> If sym.isLocal() returns true, is this check >>>> >>>> && (sym.owner.flags_field & STATIC) == 0) >>>> Needed? Aren't we inside a record declaration that is contained in >>>> some local context (e.g. within a method body), whose immediate >>>> enclosing type is a type T? If so, isn't T always non-static? I >>>> guess yes, unless T is a record itself, like: >>>> >>>> void m() { >>>> ?? record A() { >>>> ??????? record B() { } >>>> ?? } >>>> } >>>> >>>> The patch seems to be biased in favor of this - is it deliberate? >>>> (also there's no test around that). Should the spec say something? >>>> >>>> Maurizio >>>> >>>> On 11/12/2019 23:39, Vicente Romero wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for [1] at [2]. Records are not allowed to >>>>> be defined inside inner classes. This patch extends the check to >>>>> local inner classes which was missing. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8235778 >>>>> http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Fri Dec 13 19:46:44 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 13 Dec 2019 20:46:44 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap Message-ID: Hi, I looked at the following interesting issue [1]: public static void main(String... args) { Map destination = null; Map source = null; destination.putAll( source.entrySet().stream().collect( Collectors.toMap( e -> 0, e -> 0, ( e1, e2 ) -> 0, HashMap::new ) ) ); } Javac fails to infer the above expression during overload resolution of 'putAll()' when checking the return type of the partially inferred method 'collect()' whereas avoiding it succeeds: Map broker = source.entrySet().stream().collect( Collectors.toMap( e -> 0, e -> 0, ( e1, e2 ) -> 0, HashMap::new ) ); It seems that the inference context is missing constraints from 'HashMap::new' when checking the partially inferred method return type because of [2]. Removing the line 'stuck = true' as here under makes the above example succeed but a couple of tests like [3] are then failing as statements like 'g4(MethodReference46::m)' are no more ambiguous which would be, at my mind, a good thing. What do you think, is the current behavior correct or should we fix this issue with something like below? Thanks, Bernard [1] https://bugs.openjdk.java.net/browse/JDK-8219318 [2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1280 [3] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/test/langtools/tools/javac/lambda/MethodReference46.java#l43 diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java @@ -1276,9 +1276,9 @@ @Override public void visitReference(JCMemberReference tree) { super.visitReference(tree); - if (tree.getOverloadKind() != JCMemberReference.OverloadKind.UNOVERLOADED) { - stuck = true; - } +// if (tree.getOverloadKind() != JCMemberReference.OverloadKind.UNOVERLOADED) { +// stuck = true; +// } } } From maurizio.cimadamore at oracle.com Fri Dec 13 21:52:52 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Dec 2019 21:52:52 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: Message-ID: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> I'll need to think more about this - but I think the proposed fix doesn't seem conform with the JLS. Note that, during overload resolution, certain arguments are 'left behind', see JLS section 15.12.2.2: "An argument expression is considered pertinent to applicability for a potentially applicable method m unless it has one of the following forms: ... An inexact method reference expression (?15.13.1). " 'stuck' is javac's way to call an argument that is not pertinent to applicability. So, to me, the fact that we get no constraints from HashMap::new during overload seems normal. At the same time, the target type (Map) is _not_ considered during overload inference - which means that the M type-variable of the Collectors.toMap method is underconstrained (and will be inferred as Map). As I said before, I'd need to think more about it (as this is a tricky issue), but it is possible that this is not an issue (for what it's worth, pasting the code with IntelliJ reveals the same issue). Maurizio On 13/12/2019 19:46, B. Blaser wrote: > Hi, > > I looked at the following interesting issue [1]: > > public static void main(String... args) { > Map destination = null; > Map source = null; > > destination.putAll( source.entrySet().stream().collect( > Collectors.toMap( e -> 0, e -> 0, ( e1, e2 ) -> 0, HashMap::new ) ) ); > } > > Javac fails to infer the above expression during overload resolution > of 'putAll()' when checking the return type of the partially inferred > method 'collect()' whereas avoiding it succeeds: > > Map broker = > source.entrySet().stream().collect( Collectors.toMap( e -> 0, e -> 0, > ( e1, e2 ) -> 0, HashMap::new ) ); > > It seems that the inference context is missing constraints from > 'HashMap::new' when checking the partially inferred method return type > because of [2]. > > Removing the line 'stuck = true' as here under makes the above example > succeed but a couple of tests like [3] are then failing as statements > like 'g4(MethodReference46::m)' are no more ambiguous which would be, > at my mind, a good thing. > > What do you think, is the current behavior correct or should we fix > this issue with something like below? > > Thanks, > Bernard > > [1] https://bugs.openjdk.java.net/browse/JDK-8219318 > [2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1280 > [3] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/test/langtools/tools/javac/lambda/MethodReference46.java#l43 > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > @@ -1276,9 +1276,9 @@ > @Override > public void visitReference(JCMemberReference tree) { > super.visitReference(tree); > - if (tree.getOverloadKind() != > JCMemberReference.OverloadKind.UNOVERLOADED) { > - stuck = true; > - } > +// if (tree.getOverloadKind() != > JCMemberReference.OverloadKind.UNOVERLOADED) { > +// stuck = true; > +// } > } > } From bsrbnd at gmail.com Sat Dec 14 14:14:50 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 14 Dec 2019 15:14:50 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> Message-ID: Thanks for your feedback, Maurizio. Using a lacunal inference mechanism during overload resolution would definitely lead to inconsistencies like this. Moreover, JLS ?15.12.2.2 [1] is about applicability by strict invocation and our example refers to applicability by loose invocation (?15.12.2.3 [2]): "If m is a generic method and the method invocation does not provide explicit type arguments, then the applicability of the method is inferred as specified in ?18.5.1." At my mind, the suggested fix conforms to the JLS and brings the missing orthogonality revealed here. You're right that 'toMap()' is under-constrained during overload resolution in both cases but the problem only appears when adding the target type constraint during the overload inference of 'putAll()' and _not_ during the assignment inference of 'broker' which is truly inconsistent. But if you stay on your position considering this isn't an issue, I'll close it as "won't fix"? Cheers, Bernard [1] https://docs.oracle.com/javase/specs/jls/se13/html/jls-15.html#jls-15.12.2.2 [2] https://docs.oracle.com/javase/specs/jls/se13/html/jls-15.html#jls-15.12.2.3 On Fri, 13 Dec 2019 at 22:52, Maurizio Cimadamore wrote: > > I'll need to think more about this - but I think the proposed fix > doesn't seem conform with the JLS. Note that, during overload > resolution, certain arguments are 'left behind', see JLS section 15.12.2.2: > > "An argument expression is considered pertinent to applicability for a > potentially applicable method m unless it has one of the following forms: > ... > > An inexact method reference expression (?15.13.1). > > " > > 'stuck' is javac's way to call an argument that is not pertinent to > applicability. So, to me, the fact that we get no constraints from > HashMap::new during overload seems normal. > > At the same time, the target type (Map Integer>) is _not_ considered during overload inference - which means > that the M type-variable of the Collectors.toMap method is > underconstrained (and will be inferred as Map). As I > said before, I'd need to think more about it (as this is a tricky > issue), but it is possible that this is not an issue (for what it's > worth, pasting the code with IntelliJ reveals the same issue). > > Maurizio > > On 13/12/2019 19:46, B. Blaser wrote: > > Hi, > > > > I looked at the following interesting issue [1]: > > > > public static void main(String... args) { > > Map destination = null; > > Map source = null; > > > > destination.putAll( source.entrySet().stream().collect( > > Collectors.toMap( e -> 0, e -> 0, ( e1, e2 ) -> 0, HashMap::new ) ) ); > > } > > > > Javac fails to infer the above expression during overload resolution > > of 'putAll()' when checking the return type of the partially inferred > > method 'collect()' whereas avoiding it succeeds: > > > > Map broker = > > source.entrySet().stream().collect( Collectors.toMap( e -> 0, e -> 0, > > ( e1, e2 ) -> 0, HashMap::new ) ); > > > > It seems that the inference context is missing constraints from > > 'HashMap::new' when checking the partially inferred method return type > > because of [2]. > > > > Removing the line 'stuck = true' as here under makes the above example > > succeed but a couple of tests like [3] are then failing as statements > > like 'g4(MethodReference46::m)' are no more ambiguous which would be, > > at my mind, a good thing. > > > > What do you think, is the current behavior correct or should we fix > > this issue with something like below? > > > > Thanks, > > Bernard > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8219318 > > [2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1280 > > [3] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/test/langtools/tools/javac/lambda/MethodReference46.java#l43 > > > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > > @@ -1276,9 +1276,9 @@ > > @Override > > public void visitReference(JCMemberReference tree) { > > super.visitReference(tree); > > - if (tree.getOverloadKind() != > > JCMemberReference.OverloadKind.UNOVERLOADED) { > > - stuck = true; > > - } > > +// if (tree.getOverloadKind() != > > JCMemberReference.OverloadKind.UNOVERLOADED) { > > +// stuck = true; > > +// } > > } > > } From maurizio.cimadamore at oracle.com Mon Dec 16 14:00:42 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Dec 2019 14:00:42 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> Message-ID: <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> On 14/12/2019 14:14, B. Blaser wrote: > Thanks for your feedback, Maurizio. > > Using a lacunal inference mechanism during overload resolution would > definitely lead to inconsistencies like this. > > Moreover, JLS ?15.12.2.2 [1] is about applicability by strict > invocation and our example refers to applicability by loose invocation > (?15.12.2.3 [2]): > > "If m is a generic method and the method invocation does not provide > explicit type arguments, then the applicability of the method is > inferred as specified in ?18.5.1." Same process applies - the subsequent sections e.g. 15.12.2.3 are only applied when previous steps have failed: "If no method applicable by strict invocation is found, the search for applicable methods continues with phase 2 (?15.12.2.3 )." - so the pertinent to applicability analysis is really the same for all steps. > > At my mind, the suggested fix conforms to the JLS and brings the > missing orthogonality revealed here. No. I don't think it does. I think the problems in your examples are very similars to the (more common) ones that occur when the Comarator 'combinator' methods e.g. https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/Comparator.html#thenComparing(java.util.Comparator) In a method context; in such cases it's easy to see inference running out of gas, because, again, if the only argument to the method is a 'stuck' lambda/method reference, there's not much overload inference can do (since it can't look at target type info) other than inferring Object. Some examples of this can be found e.g. here: https://stackoverflow.com/questions/40500280/comparing-and-thencomparing-gives-compile-error Maurizio > > You're right that 'toMap()' is under-constrained during overload > resolution in both cases but the problem only appears when adding the > target type constraint during the overload inference of 'putAll()' and > _not_ during the assignment inference of 'broker' which is truly > inconsistent. > > But if you stay on your position considering this isn't an issue, I'll > close it as "won't fix"? > > Cheers, > Bernard > > [1] https://docs.oracle.com/javase/specs/jls/se13/html/jls-15.html#jls-15.12.2.2 > [2] https://docs.oracle.com/javase/specs/jls/se13/html/jls-15.html#jls-15.12.2.3 > > On Fri, 13 Dec 2019 at 22:52, Maurizio Cimadamore > wrote: >> I'll need to think more about this - but I think the proposed fix >> doesn't seem conform with the JLS. Note that, during overload >> resolution, certain arguments are 'left behind', see JLS section 15.12.2.2: >> >> "An argument expression is considered pertinent to applicability for a >> potentially applicable method m unless it has one of the following forms: >> ... >> >> An inexact method reference expression (?15.13.1). >> >> " >> >> 'stuck' is javac's way to call an argument that is not pertinent to >> applicability. So, to me, the fact that we get no constraints from >> HashMap::new during overload seems normal. >> >> At the same time, the target type (Map> Integer>) is _not_ considered during overload inference - which means >> that the M type-variable of the Collectors.toMap method is >> underconstrained (and will be inferred as Map). As I >> said before, I'd need to think more about it (as this is a tricky >> issue), but it is possible that this is not an issue (for what it's >> worth, pasting the code with IntelliJ reveals the same issue). >> >> Maurizio >> >> On 13/12/2019 19:46, B. Blaser wrote: >>> Hi, >>> >>> I looked at the following interesting issue [1]: >>> >>> public static void main(String... args) { >>> Map destination = null; >>> Map source = null; >>> >>> destination.putAll( source.entrySet().stream().collect( >>> Collectors.toMap( e -> 0, e -> 0, ( e1, e2 ) -> 0, HashMap::new ) ) ); >>> } >>> >>> Javac fails to infer the above expression during overload resolution >>> of 'putAll()' when checking the return type of the partially inferred >>> method 'collect()' whereas avoiding it succeeds: >>> >>> Map broker = >>> source.entrySet().stream().collect( Collectors.toMap( e -> 0, e -> 0, >>> ( e1, e2 ) -> 0, HashMap::new ) ); >>> >>> It seems that the inference context is missing constraints from >>> 'HashMap::new' when checking the partially inferred method return type >>> because of [2]. >>> >>> Removing the line 'stuck = true' as here under makes the above example >>> succeed but a couple of tests like [3] are then failing as statements >>> like 'g4(MethodReference46::m)' are no more ambiguous which would be, >>> at my mind, a good thing. >>> >>> What do you think, is the current behavior correct or should we fix >>> this issue with something like below? >>> >>> Thanks, >>> Bernard >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8219318 >>> [2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1280 >>> [3] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/test/langtools/tools/javac/lambda/MethodReference46.java#l43 >>> >>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java >>> @@ -1276,9 +1276,9 @@ >>> @Override >>> public void visitReference(JCMemberReference tree) { >>> super.visitReference(tree); >>> - if (tree.getOverloadKind() != >>> JCMemberReference.OverloadKind.UNOVERLOADED) { >>> - stuck = true; >>> - } >>> +// if (tree.getOverloadKind() != >>> JCMemberReference.OverloadKind.UNOVERLOADED) { >>> +// stuck = true; >>> +// } >>> } >>> } -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Mon Dec 16 15:09:23 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Dec 2019 16:09:23 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> Message-ID: On Mon, 16 Dec 2019 at 15:00, Maurizio Cimadamore wrote: > > > On 14/12/2019 14:14, B. Blaser wrote: >> >> Thanks for your feedback, Maurizio. >> >> Using a lacunal inference mechanism during overload resolution would >> definitely lead to inconsistencies like this. >> >> Moreover, JLS ?15.12.2.2 [1] is about applicability by strict >> invocation and our example refers to applicability by loose invocation >> (?15.12.2.3 [2]): >> >> "If m is a generic method and the method invocation does not provide >> explicit type arguments, then the applicability of the method is >> inferred as specified in ?18.5.1." > > Same process applies - the subsequent sections e.g. 15.12.2.3 are only applied when previous steps have failed: > > "If no method applicable by strict invocation is found, the search for applicable methods continues with phase 2 (?15.12.2.3)." - so the pertinent to applicability analysis is really the same for all steps. Well, if I apply these rules to our example, javac shouldn't find any applicable method by strict invocation (?15.12.2.2) but it should then find one by loose invocation (?15.12.2.3) inferring it correctly. The current behavior is a dubious mixture of these two steps; instead of performing a clear strict invocation applicability check, javac simply truncate the inference process concluding to the non-applicability of the candidate. Of course, this is only my modest interpretation of the JLS. So, would you like me to close it as "not an issue"? Thanks, Bernard From vicente.romero at oracle.com Mon Dec 16 15:28:32 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 16 Dec 2019 10:28:32 -0500 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <289634c3-2ac8-ef7e-f1c5-2632ce172a2f@oracle.com> References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> <671447a4-d93f-05a5-d26e-d538115b28a9@oracle.com> <8fc89684-e06f-a0b9-1b5e-6fa49ed81963@oracle.com> <24e14156-0499-a694-6361-28a87bc95513@oracle.com> <289634c3-2ac8-ef7e-f1c5-2632ce172a2f@oracle.com> Message-ID: <21800d67-3516-e0e8-44ea-99b1c2883cda@oracle.com> Ok can we then push this issue, if acceptable in its current state, an deal with the state capturing problem in a separate issue? Thanks, Vicente On 12/12/19 1:38 PM, Maurizio Cimadamore wrote: > > I believe so - Remi started a thread on this topic on amber-spec-experts > > Maurizio > > On 12/12/2019 17:49, Vicente Romero wrote: >> should the spec be more specific about local records, like mentioning >> that they can't capture state? >> >> Vicente >> >> On 12/12/19 7:34 AM, Maurizio Cimadamore wrote: >>> >>> The patch is ok, but I'm still not super convinced about treatment >>> of local records; example: >>> >>> $ cat TestLocalRecord.java >>> >>> class TestLocalRecord { >>> void m() { >>> ?? String s = "Hello!"; >>> ?? record A() { >>> ?????? void m() { System.out.println(s); } >>> ?? } >>> ?? new A().m(); >>> } >>> } >>> >>> $ javap -s TestLocalRecord\$1A.class Compiled from >>> "TestLocalRecord.java" >>> >>> final class TestLocalRecord$1A extends java.lang.Record { >>> ? final java.lang.String val$s; >>> ??? descriptor: Ljava/lang/String; >>> ? public TestLocalRecord$1A(); >>> ??? descriptor: (Ljava/lang/String;)V >>> >>> ? void m(); >>> ??? descriptor: ()V >>> >>> ? public java.lang.String toString(); >>> ??? descriptor: ()Ljava/lang/String; >>> >>> ? public final int hashCode(); >>> ??? descriptor: ()I >>> >>> ? public final boolean equals(java.lang.Object); >>> ??? descriptor: (Ljava/lang/Object;)Z >>> } >>> >>> Note the mismatch between the descriptor of the canonical >>> constructor and the source signature of the same. This record seems >>> not to be "the whole state and nothing but the state" because of the >>> presence of captured fields in there. >>> >>> Maurizio >>> >>> >>> On 12/12/2019 00:40, Vicente Romero wrote: >>>> I have uploaded a new iteration at [1], >>>> >>>> Thanks for your comments, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8235778/webrev.01/ >>>> >>>> On 12/11/19 7:08 PM, Maurizio Cimadamore wrote: >>>>> >>>>> If sym.isLocal() returns true, is this check >>>>> >>>>> && (sym.owner.flags_field & STATIC) == 0) >>>>> Needed? Aren't we inside a record declaration that is contained in >>>>> some local context (e.g. within a method body), whose immediate >>>>> enclosing type is a type T? If so, isn't T always non-static? I >>>>> guess yes, unless T is a record itself, like: >>>>> >>>>> void m() { >>>>> ?? record A() { >>>>> ??????? record B() { } >>>>> ?? } >>>>> } >>>>> >>>>> The patch seems to be biased in favor of this - is it deliberate? >>>>> (also there's no test around that). Should the spec say something? >>>>> >>>>> Maurizio >>>>> >>>>> On 11/12/2019 23:39, Vicente Romero wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix for [1] at [2]. Records are not allowed to >>>>>> be defined inside inner classes. This patch extends the check to >>>>>> local inner classes which was missing. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8235778 >>>>>> http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Dec 16 15:29:36 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Dec 2019 15:29:36 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> Message-ID: <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> On 16/12/2019 15:09, B. Blaser wrote: > On Mon, 16 Dec 2019 at 15:00, Maurizio Cimadamore > wrote: >> >> On 14/12/2019 14:14, B. Blaser wrote: >>> Thanks for your feedback, Maurizio. >>> >>> Using a lacunal inference mechanism during overload resolution would >>> definitely lead to inconsistencies like this. >>> >>> Moreover, JLS ?15.12.2.2 [1] is about applicability by strict >>> invocation and our example refers to applicability by loose invocation >>> (?15.12.2.3 [2]): >>> >>> "If m is a generic method and the method invocation does not provide >>> explicit type arguments, then the applicability of the method is >>> inferred as specified in ?18.5.1." >> Same process applies - the subsequent sections e.g. 15.12.2.3 are only applied when previous steps have failed: >> >> "If no method applicable by strict invocation is found, the search for applicable methods continues with phase 2 (?15.12.2.3)." - so the pertinent to applicability analysis is really the same for all steps. > Well, if I apply these rules to our example, javac shouldn't find any > applicable method by strict invocation (?15.12.2.2) but it should then > find one by loose invocation (?15.12.2.3) inferring it correctly. How can it infer it correctly in 15.12.2.3? The arguments are still not pertinent to applicability - hence, you will end up with same result (lack of constraints). > The current behavior is a dubious mixture of these two steps; instead > of performing a clear strict invocation applicability check, javac > simply truncate the inference process concluding to the > non-applicability of the candidate. > > Of course, this is only my modest interpretation of the JLS. > So, would you like me to close it as "not an issue"? Sure, unless I'm missing something of what you are trying to say above. Maurizio > Thanks, > Bernard From maurizio.cimadamore at oracle.com Mon Dec 16 15:34:25 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Dec 2019 15:34:25 +0000 Subject: RFR: JDK-8235778: No compilation error reported when a record is declared in a local class In-Reply-To: <21800d67-3516-e0e8-44ea-99b1c2883cda@oracle.com> References: <7f09a74c-cce5-21db-485f-de75a6ee8ed2@oracle.com> <671447a4-d93f-05a5-d26e-d538115b28a9@oracle.com> <8fc89684-e06f-a0b9-1b5e-6fa49ed81963@oracle.com> <24e14156-0499-a694-6361-28a87bc95513@oracle.com> <289634c3-2ac8-ef7e-f1c5-2632ce172a2f@oracle.com> <21800d67-3516-e0e8-44ea-99b1c2883cda@oracle.com> Message-ID: <7265e7b5-61c9-8c78-0443-19735bff3b87@oracle.com> On 16/12/2019 15:28, Vicente Romero wrote: > Ok can we then push this issue, if acceptable in its current state, an > deal with the state capturing problem in a separate issue? That's fine by me Cheers Maurizio > > Thanks, > Vicente > > On 12/12/19 1:38 PM, Maurizio Cimadamore wrote: >> >> I believe so - Remi started a thread on this topic on amber-spec-experts >> >> Maurizio >> >> On 12/12/2019 17:49, Vicente Romero wrote: >>> should the spec be more specific about local records, like >>> mentioning that they can't capture state? >>> >>> Vicente >>> >>> On 12/12/19 7:34 AM, Maurizio Cimadamore wrote: >>>> >>>> The patch is ok, but I'm still not super convinced about treatment >>>> of local records; example: >>>> >>>> $ cat TestLocalRecord.java >>>> >>>> class TestLocalRecord { >>>> void m() { >>>> ?? String s = "Hello!"; >>>> ?? record A() { >>>> ?????? void m() { System.out.println(s); } >>>> ?? } >>>> ?? new A().m(); >>>> } >>>> } >>>> >>>> $ javap -s TestLocalRecord\$1A.class Compiled from >>>> "TestLocalRecord.java" >>>> >>>> final class TestLocalRecord$1A extends java.lang.Record { >>>> ? final java.lang.String val$s; >>>> ??? descriptor: Ljava/lang/String; >>>> ? public TestLocalRecord$1A(); >>>> ??? descriptor: (Ljava/lang/String;)V >>>> >>>> ? void m(); >>>> ??? descriptor: ()V >>>> >>>> ? public java.lang.String toString(); >>>> ??? descriptor: ()Ljava/lang/String; >>>> >>>> ? public final int hashCode(); >>>> ??? descriptor: ()I >>>> >>>> ? public final boolean equals(java.lang.Object); >>>> ??? descriptor: (Ljava/lang/Object;)Z >>>> } >>>> >>>> Note the mismatch between the descriptor of the canonical >>>> constructor and the source signature of the same. This record seems >>>> not to be "the whole state and nothing but the state" because of >>>> the presence of captured fields in there. >>>> >>>> Maurizio >>>> >>>> >>>> On 12/12/2019 00:40, Vicente Romero wrote: >>>>> I have uploaded a new iteration at [1], >>>>> >>>>> Thanks for your comments, >>>>> Vicente >>>>> >>>>> [1] http://cr.openjdk.java.net/~vromero/8235778/webrev.01/ >>>>> >>>>> On 12/11/19 7:08 PM, Maurizio Cimadamore wrote: >>>>>> >>>>>> If sym.isLocal() returns true, is this check >>>>>> >>>>>> && (sym.owner.flags_field & STATIC) == 0) >>>>>> Needed? Aren't we inside a record declaration that is contained >>>>>> in some local context (e.g. within a method body), whose >>>>>> immediate enclosing type is a type T? If so, isn't T always >>>>>> non-static? I guess yes, unless T is a record itself, like: >>>>>> >>>>>> void m() { >>>>>> ?? record A() { >>>>>> ??????? record B() { } >>>>>> ?? } >>>>>> } >>>>>> >>>>>> The patch seems to be biased in favor of this - is it deliberate? >>>>>> (also there's no test around that). Should the spec say something? >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 11/12/2019 23:39, Vicente Romero wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the fix for [1] at [2]. Records are not allowed to >>>>>>> be defined inside inner classes. This patch extends the check to >>>>>>> local inner classes which was missing. >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235778 >>>>>>> http://cr.openjdk.java.net/~vromero/8235778/webrev.00/ >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Mon Dec 16 16:30:04 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Dec 2019 17:30:04 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> Message-ID: On Mon, 16 Dec 2019 at 16:29, Maurizio Cimadamore wrote: > > > On 16/12/2019 15:09, B. Blaser wrote: > > On Mon, 16 Dec 2019 at 15:00, Maurizio Cimadamore > > wrote: > >> > >> On 14/12/2019 14:14, B. Blaser wrote: > >>> Thanks for your feedback, Maurizio. > >>> > >>> Using a lacunal inference mechanism during overload resolution would > >>> definitely lead to inconsistencies like this. > >>> > >>> Moreover, JLS ?15.12.2.2 [1] is about applicability by strict > >>> invocation and our example refers to applicability by loose invocation > >>> (?15.12.2.3 [2]): > >>> > >>> "If m is a generic method and the method invocation does not provide > >>> explicit type arguments, then the applicability of the method is > >>> inferred as specified in ?18.5.1." > >> Same process applies - the subsequent sections e.g. 15.12.2.3 are only applied when previous steps have failed: > >> > >> "If no method applicable by strict invocation is found, the search for applicable methods continues with phase 2 (?15.12.2.3)." - so the pertinent to applicability analysis is really the same for all steps. > > Well, if I apply these rules to our example, javac shouldn't find any > > applicable method by strict invocation (?15.12.2.2) but it should then > > find one by loose invocation (?15.12.2.3) inferring it correctly. > > How can it infer it correctly in 15.12.2.3? The arguments are still not > pertinent to applicability - hence, you will end up with same result > (lack of constraints). So, let's go step by step following the JLS: 1) "15.12.2.2. Phase 1: Identify Matching Arity Methods Applicable by Strict Invocation" 2) "An argument expression is considered pertinent to applicability for a potentially applicable method m unless it has one of the following forms:" 3) "An inexact method reference expression (?15.13.1)." => 'HashMap::new' isn't pertinent to applicability by strict invocation. 4) "If no method applicable by strict invocation is found, the search for applicable methods continues with phase 2 (?15.12.2.3)." 5) "15.12.2.3. Phase 2: Identify Matching Arity Methods Applicable by Loose Invocation" 6) "If m is a generic method and the method invocation does not provide explicit type arguments, then the applicability of the method is inferred as specified in ?18.5.1." => if the overload inference includes constraints from 'HashMap::new' as suggested in the fix, the method would be pertinent to applicability. Did I miss anything? > > The current behavior is a dubious mixture of these two steps; instead > > of performing a clear strict invocation applicability check, javac > > simply truncate the inference process concluding to the > > non-applicability of the candidate. > > > > Of course, this is only my modest interpretation of the JLS. > > So, would you like me to close it as "not an issue"? > > Sure, unless I'm missing something of what you are trying to say above. Up to you to conclude, should I close it? Thanks, Bernard From maurizio.cimadamore at oracle.com Mon Dec 16 16:40:33 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Dec 2019 16:40:33 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> Message-ID: <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> On 16/12/2019 16:30, B. Blaser wrote: > On Mon, 16 Dec 2019 at 16:29, Maurizio Cimadamore > wrote: >> >> On 16/12/2019 15:09, B. Blaser wrote: >>> On Mon, 16 Dec 2019 at 15:00, Maurizio Cimadamore >>> wrote: >>>> On 14/12/2019 14:14, B. Blaser wrote: >>>>> Thanks for your feedback, Maurizio. >>>>> >>>>> Using a lacunal inference mechanism during overload resolution would >>>>> definitely lead to inconsistencies like this. >>>>> >>>>> Moreover, JLS ?15.12.2.2 [1] is about applicability by strict >>>>> invocation and our example refers to applicability by loose invocation >>>>> (?15.12.2.3 [2]): >>>>> >>>>> "If m is a generic method and the method invocation does not provide >>>>> explicit type arguments, then the applicability of the method is >>>>> inferred as specified in ?18.5.1." >>>> Same process applies - the subsequent sections e.g. 15.12.2.3 are only applied when previous steps have failed: >>>> >>>> "If no method applicable by strict invocation is found, the search for applicable methods continues with phase 2 (?15.12.2.3)." - so the pertinent to applicability analysis is really the same for all steps. >>> Well, if I apply these rules to our example, javac shouldn't find any >>> applicable method by strict invocation (?15.12.2.2) but it should then >>> find one by loose invocation (?15.12.2.3) inferring it correctly. >> How can it infer it correctly in 15.12.2.3? The arguments are still not >> pertinent to applicability - hence, you will end up with same result >> (lack of constraints). > So, let's go step by step following the JLS: > > 1) "15.12.2.2. Phase 1: Identify Matching Arity Methods Applicable by > Strict Invocation" > > 2) "An argument expression is considered pertinent to applicability > for a potentially applicable method m unless it has one of the > following forms:" > > 3) "An inexact method reference expression (?15.13.1)." > > => 'HashMap::new' isn't pertinent to applicability by strict invocation. > > 4) "If no method applicable by strict invocation is found, the search > for applicable methods continues with phase 2 (?15.12.2.3)." > > 5) "15.12.2.3. Phase 2: Identify Matching Arity Methods Applicable by > Loose Invocation" > > 6) "If m is a generic method and the method invocation does not > provide explicit type arguments, then the applicability of the method > is inferred as specified in ?18.5.1." Note that this applied also to 15.12.2.2 - all the paragraphs 15.12.2.2/3/4 - are meant to be applied in sequence - they are literally the same logic (esp. the first two), just with a different check context (strict vs. loose vs. varargs). So I don't get why you believe that 'pertinent to applicability' applies to 15.12.2.2 but not to 15.12.2.3 ? In any case, inside 18.5.1 you will find that constraints are only set up for arguments that are pertinent to applicability: "A? set of constraint formulas, C, is generated as follows. Let F1, ..., Fn be the formal parameter types of m, and let e1, ..., ek be the actual argument expressions of the invocation. Then: ??? To test for applicability by strict invocation: ??? If k ? n, or if there exists an i (1 ? i ? n) such that ei is pertinent to applicability (?15.12.2.2) and either (i) ei is a standalone expression of a primitive type but Fi is a reference type, or (ii) Fi is a primitive type but ei is not a standalone expression of a primitive type; then the method is not applicable and there is no need to proceed with inference. ??? Otherwise, C includes, for all i (1 ? i ? k) where ei is pertinent to applicability, ?ei ? Fi ??. ??? To test for applicability by loose invocation: ??? If k ? n, the method is not applicable and there is no need to proceed with inference. ??? Otherwise, C includes, for all i (1 ? i ? k) where ei is pertinent to applicability, ?ei ? Fi ??. ??? To test for applicability by variable arity invocation: ??? Let F'1, ..., F'k be the first k variable arity parameter types of m (?15.12.2.4). C includes, for all i (1 ? i ? k) where ei is pertinent to applicability, ?ei ? F'i ??. " Which again leaves us in a position where no useful constraint can be derived from HashMap::new Maurizio > > => if the overload inference includes constraints from 'HashMap::new' > as suggested in the fix, the method would be pertinent to > applicability. > > Did I miss anything? > >>> The current behavior is a dubious mixture of these two steps; instead >>> of performing a clear strict invocation applicability check, javac >>> simply truncate the inference process concluding to the >>> non-applicability of the candidate. >>> >>> Of course, this is only my modest interpretation of the JLS. >>> So, would you like me to close it as "not an issue"? >> Sure, unless I'm missing something of what you are trying to say above. > Up to you to conclude, should I close it? > > Thanks, > Bernard From maurizio.cimadamore at oracle.com Mon Dec 16 16:59:32 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Dec 2019 16:59:32 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> Message-ID: <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> On 16/12/2019 16:40, Maurizio Cimadamore wrote: > Which again leaves us in a position where no useful constraint can be > derived from HashMap::new I think that the key in unlocking this lies deeper in the spec. If we look at 18.5.1 we will see sentences such as: " Otherwise, C includes, for all i (1 ? i ? k) where ei is pertinent to applicability, ?ei ? Fi ??. " In the case of your example, the outermost call is putAll and the argument in question is call to Stream::collect. So that one is pertinent to applicability. But what does the constraint above reduces to? If we follow 18.2.1 we find the answer: "If the expression is a class instance creation expression or a method invocation expression, the constraint reduces to the bound set B3 which would be used to determine the expression's compatibility with target type T, as defined in ?18.5.2.1. (For a class instance creation expression, the corresponding "method" used for inference is defined in ?15.9.3.) " So, it seems like we should compute a new bound set using the rules in 18.5.2.1 - using the target type which is the argument type of putAll - hence Map. Now, this *should* work (despite we get no constraints from HashMap::new), but it seems like it doesn't. Of these there could be two possible scenario: (1) there's a subtle javac bug or (2) under some situations the spec forces eager instantiation for some of its arguments. Now, let's examine (2) - 18.5.2.1 says the following: "Otherwise, if R ? is an inference variable ?, and one of the following is true: ??? T is a reference type, but is not a wildcard-parameterized type, and either (i) B2 contains a bound of one of the forms ? = S or S <: ?, where S is a wildcard-parameterized type, or (ii) B2 contains two bounds of the forms S1 <: ? and S2 <: ?, where S1 and S2 have supertypes that are two different parameterizations of the same generic class or interface. ??? T is a parameterization of a generic class or interface, G, and B2 contains a bound of one of the forms ? = S or S <: ?, where there exists no type of the form G<...> that is a supertype of S, but the raw type |G<...>| is a supertype of S. ??? T is a primitive type, and one of the primitive wrapper classes mentioned in ?5.1.7 is an instantiation, upper bound, or lower bound for ? in B2. ?then ? is resolved in B2, and where the capture of the resulting instantiation of ? is U, the constraint formula ?U ? T? is reduced and incorporated with B2. " Now, this does ring some bells - if you look, Stream::collect does return a type variable: https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#collect-java.util.stream.Collector- Now, the target type here is a wildcard-parameterized type (first bullet), so eager instantiation should not happen - but I wonder what happens inside javac. Maurizio From maurizio.cimadamore at oracle.com Mon Dec 16 18:42:02 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Dec 2019 18:42:02 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> Message-ID: <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> I did some more investigation and I think javac behaves as expected. No eager instantiation occurs (which was my fear). In reality, since _all_ the lambda expression being passed as argument are implicit, all arguments to the toMap() call are not pertinent to applicability. So you have this configuration of the inference variable: M <: Map M <: Map K <: Object U <: Object Where K, U, M are defined in Collectors::toMap Now,when we go ahead and resolve this, since M 'depends' on K, U, we must instantiate those first (to Object, given we have no other meaningful bounds). Which then leads to the error javac reports, as now M has two incompatible bounds: Map and Map. Note that incorporation fails to set constraints here - the only rule that would help is this (18.3.1): "When a bound set contains a pair of bounds ? <: S and ? <: T, and there exists a supertype of S of the form G and a supertype of T of the form G (for some generic class or interface, G), then for all i (1 ? i ? n), if Si and Ti are types (not wildcards), the constraint formula ?Si = Ti? is implied." But the "not wildcards" restriction prevent any extra constraint to be generated here. In fact, if you define a method like this: static void myPutAll(Map mii) { } And try to call it with the collect(toMap) chain, everything works as expected. In other words, this is a limitation that is caused by an interaction of the putAll signature, plus arguments being not pertinent to applicability (leading to missing constraints), plus limitation in the incorporation logic which fails to keep track of relationship between type variables (if their bounds contain wildcards). So, this is not an issue, in the compiler sense (and should be closed). Whether there's room to do better in the spec (esp. in terms of incorporation) I'll leave that to Dan. Cheers Maurizio On 16/12/2019 16:59, Maurizio Cimadamore wrote: > > On 16/12/2019 16:40, Maurizio Cimadamore wrote: >> Which again leaves us in a position where no useful constraint can be >> derived from HashMap::new > > I think that the key in unlocking this lies deeper in the spec. If we > look at 18.5.1 we will see sentences such as: > > " Otherwise, C includes, for all i (1 ? i ? k) where ei is pertinent > to applicability, ?ei ? Fi ??. " > > In the case of your example, the outermost call is putAll and the > argument in question is call to Stream::collect. So that one is > pertinent to applicability. But what does the constraint above reduces > to? > > If we follow 18.2.1 we find the answer: > > "If the expression is a class instance creation expression or a method > invocation expression, the constraint reduces to the bound set B3 > which would be used to determine the expression's compatibility with > target type T, as defined in ?18.5.2.1. (For a class instance creation > expression, the corresponding "method" used for inference is defined > in ?15.9.3.) " > > So, it seems like we should compute a new bound set using the rules in > 18.5.2.1 - using the target type which is the argument type of putAll > - hence Map. > > Now, this *should* work (despite we get no constraints from > HashMap::new), but it seems like it doesn't. Of these there could be > two possible scenario: (1) there's a subtle javac bug or (2) under > some situations the spec forces eager instantiation for some of its > arguments. Now, let's examine (2) - 18.5.2.1 says the following: > > "Otherwise, if R ? is an inference variable ?, and one of the > following is true: > > ??? T is a reference type, but is not a wildcard-parameterized type, > and either (i) B2 contains a bound of one of the forms ? = S or S <: > ?, where S is a wildcard-parameterized type, or (ii) B2 contains two > bounds of the forms S1 <: ? and S2 <: ?, where S1 and S2 have > supertypes that are two different parameterizations of the same > generic class or interface. > > ??? T is a parameterization of a generic class or interface, G, and B2 > contains a bound of one of the forms ? = S or S <: ?, where there > exists no type of the form G<...> that is a supertype of S, but the > raw type |G<...>| is a supertype of S. > > ??? T is a primitive type, and one of the primitive wrapper classes > mentioned in ?5.1.7 is an instantiation, upper bound, or lower bound > for ? in B2. > > ?then ? is resolved in B2, and where the capture of the resulting > instantiation of ? is U, the constraint formula ?U ? T? is reduced and > incorporated with B2. " > > Now, this does ring some bells - if you look, Stream::collect does > return a type variable: > > https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#collect-java.util.stream.Collector- > > > Now, the target type here is a wildcard-parameterized type (first > bullet), so eager instantiation should not happen - but I wonder what > happens inside javac. > > Maurizio > From bsrbnd at gmail.com Mon Dec 16 19:36:18 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Dec 2019 20:36:18 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> Message-ID: On 16/12/2019 16:40, Maurizio Cimadamore wrote: >> 6) "If m is a generic method and the method invocation does not >> provide explicit type arguments, then the applicability of the method >> is inferred as specified in ?18.5.1." > > Note that this applied also to 15.12.2.2 - all the paragraphs > 15.12.2.2/3/4 - are meant to be applied in sequence - they are literally > the same logic (esp. the first two), just with a different check context > (strict vs. loose vs. varargs). So I don't get why you believe that > 'pertinent to applicability' applies to 15.12.2.2 but not to 15.12.2.3 ? 'pertinent to applicability' applies to both, of course, but in different ways for method references; 'exact' is the condition expressed in ?15.12.2.2 and 'inferrable' is the requirement for ?15.12.2.3. Interpreting the JLS otherwise would mean that the inexact method reference 'HashMap::new' is never pertinent to applicability and thus the assignment inference of 'broker' should fail too... but currently 'putAll()' is rejected while 'broker=' is still accepted. The difference between them is that the target type constraint from 'Map' is added during the overload inference of 'putAll()' in which [1] applies whereas the same constraint is added during the assignment inference of 'broker=' for which [2] applies. On 16/12/2019 16:59, Maurizio Cimadamore wrote: > Now, the target type here is a wildcard-parameterized type (first > bullet), so eager instantiation should not happen - but I wonder what > happens inside javac. I'm not sure you're looking at the right place, recall that 'putAll()' works and 'broker=' doesn't with exactly the same argument 'HashMap::new' and the same target type 'Map'; the only difference being the overload [1] vs assignment inference [2] which don't seem to be distinct cases in the JLS, isn't it? On Mon, 16 Dec 2019 at 19:42, Maurizio Cimadamore wrote: > So, this is not an issue, in the compiler sense (and should be closed). > Whether there's room to do better in the spec (esp. in terms of > incorporation) I'll leave that to Dan. I'm still not sure whether this is a spec or compiler issue (or nothing), so let's wait for Dan's feedback before closing it. Cheers, Bernard [1] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1255 [2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1145 From maurizio.cimadamore at oracle.com Mon Dec 16 21:05:48 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Dec 2019 21:05:48 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> Message-ID: <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> On 16/12/2019 19:36, B. Blaser wrote: > On 16/12/2019 16:40, Maurizio Cimadamore wrote: >>> 6) "If m is a generic method and the method invocation does not >>> provide explicit type arguments, then the applicability of the method >>> is inferred as specified in ?18.5.1." >> Note that this applied also to 15.12.2.2 - all the paragraphs >> 15.12.2.2/3/4 - are meant to be applied in sequence - they are literally >> the same logic (esp. the first two), just with a different check context >> (strict vs. loose vs. varargs). So I don't get why you believe that >> 'pertinent to applicability' applies to 15.12.2.2 but not to 15.12.2.3 ? > 'pertinent to applicability' applies to both, of course, but in > different ways for method references; 'exact' is the condition > expressed in ?15.12.2.2 and 'inferrable' is the requirement for > ?15.12.2.3. I really don't get where you get this interpretation for - where is it written that pertinent to applicability has a different definition in 15.12.2.3? > > Interpreting the JLS otherwise would mean that the inexact method > reference 'HashMap::new' is never pertinent to applicability and thus > the assignment inference of 'broker' should fail too... but currently > 'putAll()' is rejected while 'broker=' is still accepted. The two processes are completely different. When you evaluate an assignment, you start by typing the LHS. In the case of broker= the LHS has type Map. But, and this is the crucial difference, this type is *not* used during overload selection. You basically perform selection _as if this type did not exist_. Which means that the inference variables are configured in this way: M <: Map K <: Object U <: Object So, here, inferring Map is fine, _for the purpose of overload resolution_. You might ask , but Map is not the type that comes out in the end - and that's true - the type computed at overload selection is _thrown away_ and a new process (invocation type inference, 18.5.2) kicks in. This process differs from overload inference in two main ways: * it also throws the target type into the picture (Map) * it keeps trying to 'unstuck' arguments that are stuck - that is, not only it evaluates constraints coming from arguments pertinent to applicability, but it used information from such constraint to unblock attribution of arguments that are _not_ pertinent to applicability. By doing this, we can finally take full advantage of inference propagation - first the (implicit) parameter type of the first two lambdas is inferred to Map.Entry. From there, both lambdas can finally be type checked, which produces constraints for both K and U - e.g. Integer <: K Integer <: U At which point we no longer infer K=Object and U=Object like before, but we infer Integer instead, which makes the whole inference process to converge on the right solution. So, this is the JLS explanation as to why things work in one case, but not in the other. Maurizio > > The difference between them is that the target type constraint from > 'Map' is added during the > overload inference of 'putAll()' in which [1] applies whereas the same > constraint is added during the assignment inference of 'broker=' for > which [2] applies. > > On 16/12/2019 16:59, Maurizio Cimadamore wrote: >> Now, the target type here is a wildcard-parameterized type (first >> bullet), so eager instantiation should not happen - but I wonder what >> happens inside javac. > I'm not sure you're looking at the right place, recall that 'putAll()' > works and 'broker=' doesn't with exactly the same argument > 'HashMap::new' and the same target type 'Map extends Integer>'; the only difference being the overload [1] vs > assignment inference [2] which don't seem to be distinct cases in the > JLS, isn't it? > > On Mon, 16 Dec 2019 at 19:42, Maurizio Cimadamore > wrote: >> So, this is not an issue, in the compiler sense (and should be closed). >> Whether there's room to do better in the spec (esp. in terms of >> incorporation) I'll leave that to Dan. > I'm still not sure whether this is a spec or compiler issue (or > nothing), so let's wait for Dan's feedback before closing it. > > Cheers, > Bernard > > [1] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1255 > [2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1145 From bsrbnd at gmail.com Tue Dec 17 12:32:28 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 17 Dec 2019 13:32:28 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> Message-ID: Thanks for this explanation, Maurizio. I understand that your main concern is to make sure that javac conforms to the JLS and it probably does but I still remain perplexed about this inference inconsistency. I've no problem with putting aside stuck arguments during overload resolution but the notion of pertinence to applicability is really misleading. I had trouble understanding that 'toMap()' could be a potentially applicable method if 'HashMap::new' isn't pertinent to applicability in the sense of the JLS. But, as you explained, this argument is left over during overload resolution and reinstated after causing the inconsistency between 'putAll()' and 'broker='. Which is still confusing to me is that javac gives another definition of stuck arguments between overload resolution [1] and invocation type inference [2] relating this to their pertinence to applicability. The motivation of my fix was therefore to unify these definitions to also consider arguments that aren't "really" stuck during overload resolution which may conform to the JLS (or not?). But as I don't see much enthusiasm in going in this direction, I'll close this issue as you suggested. Thanks, Bernard [1] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1255 [2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1145 On Mon, 16 Dec 2019 at 22:06, Maurizio Cimadamore wrote: > [...] > So, this is the JLS explanation as to why things work in one case, but > not in the other. > > Maurizio From maurizio.cimadamore at oracle.com Tue Dec 17 14:09:24 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 17 Dec 2019 14:09:24 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> Message-ID: <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> On 17/12/2019 12:32, B. Blaser wrote: > Thanks for this explanation, Maurizio. > > I understand that your main concern is to make sure that javac > conforms to the JLS and it probably does but I still remain perplexed > about this inference inconsistency. Yes, the inconsistency is bad - but it seems like a specification issue, not a javac issue. That's what I'm trying to say (and why I was proposing to close the bug). Perhaps instead of closing we can move to the specification category, and attach my explanation? > > I've no problem with putting aside stuck arguments during overload > resolution but the notion of pertinence to applicability is really > misleading. > I had trouble understanding that 'toMap()' could be a potentially > applicable method if 'HashMap::new' isn't pertinent to applicability > in the sense of the JLS. > But, as you explained, this argument is left over during overload > resolution and reinstated after causing the inconsistency between > 'putAll()' and 'broker='. > > Which is still confusing to me is that javac gives another definition > of stuck arguments between overload resolution [1] and invocation type > inference [2] relating this to their pertinence to applicability. That's because during overload resolution, argument non-pertinent are simply stuck and should never ever be touched. But during invocation type inference, even arguments non-pertinent can be made available for further type-checking (depending on whether their 'input' set of stuck variables have been solved or not). The compiler implementation here is using the 'stuck' argument notion to model both pertinent-to-applicability _and_ dealing with the selection of argument in section 18.5.2.2. > > The motivation of my fix was therefore to unify these definitions to > also consider arguments that aren't "really" stuck during overload > resolution which may conform to the JLS (or not?). That was the behavior we had for some time before Java 8 was finalized, where two symmetric processes were indeed happening, and 'unsticking' was also allowed to happen during overload; this led to issues, such as overload resolution being sensitive to errors triggered in the body of an unstuck lambda - which is why we moved to a saner (but asymmetric) model. > > But as I don't see much enthusiasm in going in this direction, I'll > close this issue as you suggested. As I said above, I think the fact that we have a discrepancy between assignment context and invocation context, and one that is probably caused by incorporation rules not being strong enough when the overload target contains wildcards, is something that can be submitted for evaluation to the spec team. While we're not willing to make the overload and invocation inference process fully symmetric (for the reasons above), adding extra incorporation rules to help in cases like these doesn't seem (too) bad. Maurizio > > Thanks, > Bernard > > [1] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1255 > [2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1145 > > On Mon, 16 Dec 2019 at 22:06, Maurizio Cimadamore > wrote: >> [...] >> So, this is the JLS explanation as to why things work in one case, but >> not in the other. >> >> Maurizio From vicente.romero at oracle.com Tue Dec 17 17:43:48 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 17 Dec 2019 12:43:48 -0500 Subject: RFR: JDK-8234971: Incorrect example in j.l.reflect.RecordComponent::toString Message-ID: <4449f3de-5d8a-0548-2ab2-edabb244cb33@oracle.com> Please review this very simple change to an example shown in the API for j.l.r.RecordComponent::toString. There are tests checking the correct behavior, it was just the example that was incorrect. I double checked that there is no need for a CSR for this simple change, Thanks, Vicente http://cr.openjdk.java.net/~vromero/8234971/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8234971 From bsrbnd at gmail.com Tue Dec 17 18:22:36 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 17 Dec 2019 19:22:36 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> Message-ID: On Tue, 17 Dec 2019 at 15:09, Maurizio Cimadamore wrote: > > On 17/12/2019 12:32, B. Blaser wrote: > > > > But as I don't see much enthusiasm in going in this direction, I'll > > close this issue as you suggested. > > As I said above, I think the fact that we have a discrepancy between > assignment context and invocation context, and one that is probably > caused by incorporation rules not being strong enough when the overload > target contains wildcards, is something that can be submitted for > evaluation to the spec team. While we're not willing to make the > overload and invocation inference process fully symmetric (for the > reasons above), adding extra incorporation rules to help in cases like > these doesn't seem (too) bad. So, I moved it the specification component and assigned it to Dan. Note that the fix I suggested isn't fully symmetric neither; the overload inference would only includes method references that don't have stuck variables, see [1]. The only thing that would have to change in the JLS is that inexact method references with no stuck variables would be pertinent to applicability. All the rest would remain unchanged (all lambda expressions and method references with stuck variables). Cheers, Bernard [1] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1145 From jonathan.gibbons at oracle.com Tue Dec 17 19:04:43 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 17 Dec 2019 11:04:43 -0800 Subject: RFR: JDK-8234971: Incorrect example in j.l.reflect.RecordComponent::toString In-Reply-To: <4449f3de-5d8a-0548-2ab2-edabb244cb33@oracle.com> References: <4449f3de-5d8a-0548-2ab2-edabb244cb33@oracle.com> Message-ID: <3288c870-c26a-b7d9-3f84-98ef510a0b3c@oracle.com> +1 On 12/17/19 9:43 AM, Vicente Romero wrote: > Please review this very simple change to an example shown in the API > for j.l.r.RecordComponent::toString. There are tests checking the > correct behavior, it was just the example that was incorrect. I double > checked that there is no need for a CSR for this simple change, > > Thanks, > Vicente > > http://cr.openjdk.java.net/~vromero/8234971/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8234971 From maurizio.cimadamore at oracle.com Tue Dec 17 21:21:14 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 17 Dec 2019 21:21:14 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> Message-ID: <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> On 17/12/2019 18:22, B. Blaser wrote: > So, I moved it the specification component and assigned it to Dan. Thanks! > > Note that the fix I suggested isn't fully symmetric neither; the > overload inference would only includes method references that don't > have stuck variables, see [1]. The only thing that would have to > change in the JLS is that inexact method references with no stuck > variables would be pertinent to applicability. I'm afraid it can't be that simple - if you have multiple, non-generic methods which can be potential target of a method reference expression, which one would you use in order to type-check against the functional interface target? Maurizio > All the rest would > remain unchanged (all lambda expressions and method references with > stuck variables). From bsrbnd at gmail.com Wed Dec 18 12:24:36 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 18 Dec 2019 13:24:36 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> References: <424cf660-3e00-2cb9-415d-5942f9209a70@oracle.com> <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> Message-ID: On Tue, 17 Dec 2019 at 22:21, Maurizio Cimadamore wrote: > > On 17/12/2019 18:22, B. Blaser wrote: > > Note that the fix I suggested isn't fully symmetric neither; the > > overload inference would only includes method references that don't > > have stuck variables, see [1]. The only thing that would have to > > change in the JLS is that inexact method references with no stuck > > variables would be pertinent to applicability. > > I'm afraid it can't be that simple - if you have multiple, non-generic > methods which can be potential target of a method reference expression, > which one would you use in order to type-check against the functional > interface target? On spec side, grosso modo the most specific one or do you mean on javac side? Bernard From maurizio.cimadamore at oracle.com Wed Dec 18 13:59:30 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 18 Dec 2019 13:59:30 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> Message-ID: On 18/12/2019 12:24, B. Blaser wrote: > On Tue, 17 Dec 2019 at 22:21, Maurizio Cimadamore > wrote: >> On 17/12/2019 18:22, B. Blaser wrote: >>> Note that the fix I suggested isn't fully symmetric neither; the >>> overload inference would only includes method references that don't >>> have stuck variables, see [1]. The only thing that would have to >>> change in the JLS is that inexact method references with no stuck >>> variables would be pertinent to applicability. >> I'm afraid it can't be that simple - if you have multiple, non-generic >> methods which can be potential target of a method reference expression, >> which one would you use in order to type-check against the functional >> interface target? > On spec side, grosso modo the most specific one or do you mean on javac side? I meant spec side. What if there's no most specific? e.g. m(int) m(String) Maurizio > Bernard From bsrbnd at gmail.com Wed Dec 18 15:35:17 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 18 Dec 2019 16:35:17 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <65b65e18-3dc7-7fbe-1a95-88184dc335f0@oracle.com> <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> Message-ID: On Wed, 18 Dec 2019 at 14:59, Maurizio Cimadamore wrote: > > > On 18/12/2019 12:24, B. Blaser wrote: > > On Tue, 17 Dec 2019 at 22:21, Maurizio Cimadamore > > wrote: > >> On 17/12/2019 18:22, B. Blaser wrote: > >>> Note that the fix I suggested isn't fully symmetric neither; the > >>> overload inference would only includes method references that don't > >>> have stuck variables, see [1]. The only thing that would have to > >>> change in the JLS is that inexact method references with no stuck > >>> variables would be pertinent to applicability. > >> I'm afraid it can't be that simple - if you have multiple, non-generic > >> methods which can be potential target of a method reference expression, > >> which one would you use in order to type-check against the functional > >> interface target? > > On spec side, grosso modo the most specific one or do you mean on javac side? > > I meant spec side. > > What if there's no most specific? > > e.g. > > m(int) > > m(String) In this case, only one of them can be a potential target (not both), isn't it? Another possibility would be to reduce the fix to 'inexact method references with *a unique potential target* and no stuck variables would be pertinent to applicability'? Bernard From christoph.langer at sap.com Wed Dec 18 15:42:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Dec 2019 15:42:01 +0000 Subject: RFR: JDK-8234971: Incorrect example in j.l.reflect.RecordComponent::toString In-Reply-To: <3288c870-c26a-b7d9-3f84-98ef510a0b3c@oracle.com> References: <4449f3de-5d8a-0548-2ab2-edabb244cb33@oracle.com> <3288c870-c26a-b7d9-3f84-98ef510a0b3c@oracle.com> Message-ID: Hi, we just discovered that the bug (https://bugs.openjdk.java.net/browse/JDK-8234971) is not visible. Is there any chance that you could open it up? Thanks Christoph > -----Original Message----- > From: compiler-dev On Behalf > Of Jonathan Gibbons > Sent: Dienstag, 17. Dezember 2019 20:05 > To: compiler-dev at openjdk.java.net > Subject: Re: RFR: JDK-8234971: Incorrect example in > j.l.reflect.RecordComponent::toString > > +1 > > On 12/17/19 9:43 AM, Vicente Romero wrote: > > Please review this very simple change to an example shown in the API > > for j.l.r.RecordComponent::toString. There are tests checking the > > correct behavior, it was just the example that was incorrect. I double > > checked that there is no need for a CSR for this simple change, > > > > Thanks, > > Vicente > > > > http://cr.openjdk.java.net/~vromero/8234971/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8234971 From maurizio.cimadamore at oracle.com Wed Dec 18 15:46:34 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 18 Dec 2019 15:46:34 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> Message-ID: <70634e83-a9da-9138-2c96-807a885479f8@oracle.com> On 18/12/2019 15:35, B. Blaser wrote: > On Wed, 18 Dec 2019 at 14:59, Maurizio Cimadamore > wrote: >> >> On 18/12/2019 12:24, B. Blaser wrote: >>> On Tue, 17 Dec 2019 at 22:21, Maurizio Cimadamore >>> wrote: >>>> On 17/12/2019 18:22, B. Blaser wrote: >>>>> Note that the fix I suggested isn't fully symmetric neither; the >>>>> overload inference would only includes method references that don't >>>>> have stuck variables, see [1]. The only thing that would have to >>>>> change in the JLS is that inexact method references with no stuck >>>>> variables would be pertinent to applicability. >>>> I'm afraid it can't be that simple - if you have multiple, non-generic >>>> methods which can be potential target of a method reference expression, >>>> which one would you use in order to type-check against the functional >>>> interface target? >>> On spec side, grosso modo the most specific one or do you mean on javac side? >> I meant spec side. >> >> What if there's no most specific? >> >> e.g. >> >> m(int) >> >> m(String) > In this case, only one of them can be a potential target (not both), isn't it? Sure - but if it's pertinent to applicability, you need to chose one to rule out some outer overload candidate - e.g. g(this::m) Which 'g' gets selected depends on which 'm' you believe the inexact reference should resolve to. It's a chicken and egg problem :-) > Another possibility would be to reduce the fix to 'inexact method > references with *a unique potential target* and no stuck variables > would be pertinent to applicability'? I honestly believe you are looking in the wrong place. I think there's a reason (as I explained) as to why pertinent to applicability was defined the way it was. If there's a spec problem here, it seems like it lies in how incorporation fails to generate constraints for the underconstrained vars because of the presence of wildcards. That's a much more direct problem to fix, which doesn't involve re-architecting how overload selection is structured (which is not gonna happen). Maurizio > Bernard From vicente.romero at oracle.com Wed Dec 18 17:38:43 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Dec 2019 12:38:43 -0500 Subject: RFR: JDK-8234971: Incorrect example in j.l.reflect.RecordComponent::toString In-Reply-To: References: <4449f3de-5d8a-0548-2ab2-edabb244cb33@oracle.com> <3288c870-c26a-b7d9-3f84-98ef510a0b3c@oracle.com> Message-ID: <0784de2a-4bc2-5fd0-4b28-23f2ca50265b@oracle.com> done, Vicente On 12/18/19 10:42 AM, Langer, Christoph wrote: > Hi, > > we just discovered that the bug (https://bugs.openjdk.java.net/browse/JDK-8234971) is not visible. Is there any chance that you could open it up? > > Thanks > Christoph > >> -----Original Message----- >> From: compiler-dev On Behalf >> Of Jonathan Gibbons >> Sent: Dienstag, 17. Dezember 2019 20:05 >> To: compiler-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8234971: Incorrect example in >> j.l.reflect.RecordComponent::toString >> >> +1 >> >> On 12/17/19 9:43 AM, Vicente Romero wrote: >>> Please review this very simple change to an example shown in the API >>> for j.l.r.RecordComponent::toString. There are tests checking the >>> correct behavior, it was just the example that was incorrect. I double >>> checked that there is no need for a CSR for this simple change, >>> >>> Thanks, >>> Vicente >>> >>> http://cr.openjdk.java.net/~vromero/8234971/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8234971 From vicente.romero at oracle.com Wed Dec 18 18:24:59 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Dec 2019 13:24:59 -0500 Subject: RFR: JDK-8234445: spurious error message for record constructors with receiver parameters Message-ID: <4ad0d7d4-ce17-5403-7b8e-82b48a420c8c@oracle.com> Please review the fix for [1] at [2]. What happens here is that basically for records we are altering the order in which members are entered, this is because the compiler needs to check if a user provided constructor has the same erasure as the canonical constructor or not and depending on this generate one or not, or even issue an error. The only way to have access to this information is to enter all the constructors before the compiler gets to the point where it needs to decide if a canonical should be generated or not. The current implementation 'forgot' to add `this` and `super` to the scope before entering all the constructors. This is the reason for the spurious error message: because `this` was not entered before the user defined constructors were entered by the compiler Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8234445 [2] http://cr.openjdk.java.net/~vromero/8234445/webrev.00/ From christoph.langer at sap.com Wed Dec 18 22:32:24 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Dec 2019 22:32:24 +0000 Subject: RFR: JDK-8234971: Incorrect example in j.l.reflect.RecordComponent::toString In-Reply-To: <0784de2a-4bc2-5fd0-4b28-23f2ca50265b@oracle.com> References: <4449f3de-5d8a-0548-2ab2-edabb244cb33@oracle.com> <3288c870-c26a-b7d9-3f84-98ef510a0b3c@oracle.com> <0784de2a-4bc2-5fd0-4b28-23f2ca50265b@oracle.com> Message-ID: Thank you, Vicente. > -----Original Message----- > From: Vicente Romero > Sent: Mittwoch, 18. Dezember 2019 18:39 > To: Langer, Christoph ; Jonathan Gibbons > > Cc: compiler-dev at openjdk.java.net; Lindenmaier, Goetz > ; Zeller, Arno > Subject: Re: RFR: JDK-8234971: Incorrect example in > j.l.reflect.RecordComponent::toString > > done, > > Vicente > > On 12/18/19 10:42 AM, Langer, Christoph wrote: > > Hi, > > > > we just discovered that the bug > (https://bugs.openjdk.java.net/browse/JDK-8234971) is not visible. Is there > any chance that you could open it up? > > > > Thanks > > Christoph > > > >> -----Original Message----- > >> From: compiler-dev On > Behalf > >> Of Jonathan Gibbons > >> Sent: Dienstag, 17. Dezember 2019 20:05 > >> To: compiler-dev at openjdk.java.net > >> Subject: Re: RFR: JDK-8234971: Incorrect example in > >> j.l.reflect.RecordComponent::toString > >> > >> +1 > >> > >> On 12/17/19 9:43 AM, Vicente Romero wrote: > >>> Please review this very simple change to an example shown in the API > >>> for j.l.r.RecordComponent::toString. There are tests checking the > >>> correct behavior, it was just the example that was incorrect. I double > >>> checked that there is no need for a CSR for this simple change, > >>> > >>> Thanks, > >>> Vicente > >>> > >>> http://cr.openjdk.java.net/~vromero/8234971/webrev.00/ > >>> https://bugs.openjdk.java.net/browse/JDK-8234971 From bsrbnd at gmail.com Thu Dec 19 15:23:23 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 19 Dec 2019 16:23:23 +0100 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: <70634e83-a9da-9138-2c96-807a885479f8@oracle.com> References: <201032b2-e91c-6dd9-1203-1c2c19b65a84@oracle.com> <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> <70634e83-a9da-9138-2c96-807a885479f8@oracle.com> Message-ID: On Wed, 18 Dec 2019 at 16:46, Maurizio Cimadamore wrote: > > On 18/12/2019 15:35, B. Blaser wrote: > > Another possibility would be to reduce the fix to 'inexact method > > references with *a unique potential target* and no stuck variables > > would be pertinent to applicability'? > > I honestly believe you are looking in the wrong place. I think there's a > reason (as I explained) as to why pertinent to applicability was defined > the way it was. If there's a spec problem here, it seems like it lies in > how incorporation fails to generate constraints for the underconstrained > vars because of the presence of wildcards. That's a much more direct > problem to fix, which doesn't involve re-architecting how overload > selection is structured (which is not gonna happen). I guess you're right, the method reference is probably shadowing the problem. Take the following simpler example: class Test3 { interface I {} > X m() { return null; } void n(I p) {} void o(I p) {} void run() { n(m()); o(this.>m()); o(m()); // KO! } } $ javac Test3.java Test3.java:12: error: incompatible types: inferred type does not conform to upper bound(s) o(m()); // KO! ^ inferred: I upper bound(s): I,I Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 1 error The problem is that when inferring 'n(m())' the bounds 'X <: I(W), I(Integer)' implies 'W=Integer' per ?18.3.1 but with 'o(m())' the bounds 'X <: I(W), I(? extends Integer)' should probably imply 'W <: Integer' instead of inferring 'W=Object'. So, I did a voodoo cult devoted to inference which ended up with some black magic on our good old friend 'Types::isSameType', see below. While this experiment is somewhat incomplete, both examples 'putAll()' and 'o(m())' are now working without any 'langtools:tier1' failure. What do you think? Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java @@ -1376,6 +1376,10 @@ @Override public Boolean visitWildcardType(WildcardType t, Type s) { if (!s.hasTag(WILDCARD)) { + if (!t.isUnbound() && t.isExtendsBound() && s.hasTag(UNDETVAR)) { + ((UndetVar)s).addBound(InferenceBound.UPPER, t.type, Types.this); + return true; + } return false; } else { WildcardType t2 = (WildcardType)s; diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java @@ -944,6 +944,10 @@ List allParamsSuperBound1 = commonSupers.fst.allparams(); List allParamsSuperBound2 = commonSupers.snd.allparams(); while (allParamsSuperBound1.nonEmpty() && allParamsSuperBound2.nonEmpty()) { + if (allParamsSuperBound1.head.hasTag(WILDCARD) && !allParamsSuperBound2.head.hasTag(WILDCARD)) { + //try to match wildcard and undet var bounds + isSameType(allParamsSuperBound1.head, inferenceContext.asUndetVar(allParamsSuperBound2.head)); + } //traverse the list of all params comparing them if (!allParamsSuperBound1.head.hasTag(WILDCARD) && !allParamsSuperBound2.head.hasTag(WILDCARD)) { From maurizio.cimadamore at oracle.com Thu Dec 19 15:37:28 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 19 Dec 2019 15:37:28 +0000 Subject: JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap In-Reply-To: References: <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> <70634e83-a9da-9138-2c96-807a885479f8@oracle.com> Message-ID: > The problem is that when inferring 'n(m())' the bounds 'X <: I(W), > I(Integer)' implies 'W=Integer' per ?18.3.1 but with 'o(m())' the > bounds 'X <: I(W), I(? extends Integer)' should probably imply 'W <: > Integer' instead of inferring 'W=Object'. > > So, I did a voodoo cult devoted to inference which ended up with some > black magic on our good old friend 'Types::isSameType', see below. > > While this experiment is somewhat incomplete, both examples 'putAll()' > and 'o(m())' are now working without any 'langtools:tier1' failure. > > What do you think? This extension is, more or less, what I was expecting/suggesting - but I think this is more of a question for our spec experts (there might be subtle reasons as to why this wasn't done already). Maurizio > Bernard > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > @@ -1376,6 +1376,10 @@ > @Override > public Boolean visitWildcardType(WildcardType t, Type s) { > if (!s.hasTag(WILDCARD)) { > + if (!t.isUnbound() && t.isExtendsBound() && > s.hasTag(UNDETVAR)) { > + ((UndetVar)s).addBound(InferenceBound.UPPER, > t.type, Types.this); > + return true; > + } > return false; > } else { > WildcardType t2 = (WildcardType)s; > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > @@ -944,6 +944,10 @@ > List allParamsSuperBound1 = > commonSupers.fst.allparams(); > List allParamsSuperBound2 = > commonSupers.snd.allparams(); > while (allParamsSuperBound1.nonEmpty() && > allParamsSuperBound2.nonEmpty()) { > + if > (allParamsSuperBound1.head.hasTag(WILDCARD) && > !allParamsSuperBound2.head.hasTag(WILDCARD)) { > + //try to match wildcard and undet var bounds > + isSameType(allParamsSuperBound1.head, > inferenceContext.asUndetVar(allParamsSuperBound2.head)); > + } > //traverse the list of all params comparing them > if (!allParamsSuperBound1.head.hasTag(WILDCARD) && > > !allParamsSuperBound2.head.hasTag(WILDCARD)) { From vicente.romero at oracle.com Thu Dec 19 16:03:22 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Dec 2019 11:03:22 -0500 Subject: RFR: JDK-8234445: spurious error message for record constructors with receiver parameters In-Reply-To: <4ad0d7d4-ce17-5403-7b8e-82b48a420c8c@oracle.com> References: <4ad0d7d4-ce17-5403-7b8e-82b48a420c8c@oracle.com> Message-ID: ping On 12/18/19 1:24 PM, Vicente Romero wrote: > Please review the fix for [1] at [2]. What happens here is that > basically for records we are altering the order in which members are > entered, this is because the compiler needs to check if a user > provided constructor has the same erasure as the canonical constructor > or not and depending on this generate one or not, or even issue an > error. The only way to have access to this information is to enter all > the constructors before the compiler gets to the point where it needs > to decide if a canonical should be generated or not. The current > implementation 'forgot' to add `this` and `super` to the scope before > entering all the constructors. This is the reason for the spurious > error message: because `this` was not entered before the user defined > constructors were entered by the compiler > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8234445 > [2] http://cr.openjdk.java.net/~vromero/8234445/webrev.00/ From maurizio.cimadamore at oracle.com Thu Dec 19 16:09:29 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 19 Dec 2019 16:09:29 +0000 Subject: RFR: JDK-8234445: spurious error message for record constructors with receiver parameters In-Reply-To: <4ad0d7d4-ce17-5403-7b8e-82b48a420c8c@oracle.com> References: <4ad0d7d4-ce17-5403-7b8e-82b48a420c8c@oracle.com> Message-ID: Looks good - two questions: 1) do we really need to add this/super at different times? Perhaps we could also add this/super in RecordsHeaderPhase for all classes (class + records) 2) or, if not, I'd suggest moving the code which adds this/super in a routine, and call the routine from where you need it Maurizio On 18/12/2019 18:24, Vicente Romero wrote: > Please review the fix for [1] at [2]. What happens here is that > basically for records we are altering the order in which members are > entered, this is because the compiler needs to check if a user > provided constructor has the same erasure as the canonical constructor > or not and depending on this generate one or not, or even issue an > error. The only way to have access to this information is to enter all > the constructors before the compiler gets to the point where it needs > to decide if a canonical should be generated or not. The current > implementation 'forgot' to add `this` and `super` to the scope before > entering all the constructors. This is the reason for the spurious > error message: because `this` was not entered before the user defined > constructors were entered by the compiler > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8234445 > [2] http://cr.openjdk.java.net/~vromero/8234445/webrev.00/ From vicente.romero at oracle.com Thu Dec 19 16:41:23 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Dec 2019 11:41:23 -0500 Subject: RFR: JDK-8234445: spurious error message for record constructors with receiver parameters In-Reply-To: References: <4ad0d7d4-ce17-5403-7b8e-82b48a420c8c@oracle.com> Message-ID: <62d3a2a8-bc04-7321-5463-cf3a25c1ee88@oracle.com> Hi, Thanks for the review, On 12/19/19 11:09 AM, Maurizio Cimadamore wrote: > Looks good - two questions: > > 1) do we really need to add this/super at different times? Perhaps we > could also add this/super in RecordsHeaderPhase for all classes (class > + records) > 2) or, if not, I'd suggest moving the code which adds this/super in a > routine, and call the routine from where you need it I think I prefer option 2 even if 1 is doable, I would prefer to let the RecordPhase to record stuff only, also I prefer to let the current flow stable and introduce a change to records only. So I have added a new routine and invoked it from two different places [1]. How does it look? > > Maurizio Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8234445/webrev.01/ > > On 18/12/2019 18:24, Vicente Romero wrote: >> Please review the fix for [1] at [2]. What happens here is that >> basically for records we are altering the order in which members are >> entered, this is because the compiler needs to check if a user >> provided constructor has the same erasure as the canonical >> constructor or not and depending on this generate one or not, or even >> issue an error. The only way to have access to this information is to >> enter all the constructors before the compiler gets to the point >> where it needs to decide if a canonical should be generated or not. >> The current implementation 'forgot' to add `this` and `super` to the >> scope before entering all the constructors. This is the reason for >> the spurious error message: because `this` was not entered before the >> user defined constructors were entered by the compiler >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8234445 >> [2] http://cr.openjdk.java.net/~vromero/8234445/webrev.00/ From maurizio.cimadamore at oracle.com Thu Dec 19 16:43:07 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 19 Dec 2019 16:43:07 +0000 Subject: RFR: JDK-8234445: spurious error message for record constructors with receiver parameters In-Reply-To: <62d3a2a8-bc04-7321-5463-cf3a25c1ee88@oracle.com> References: <4ad0d7d4-ce17-5403-7b8e-82b48a420c8c@oracle.com> <62d3a2a8-bc04-7321-5463-cf3a25c1ee88@oracle.com> Message-ID: <0ae807de-cfee-7d77-2c07-896702c5c672@oracle.com> Looks good Maurizio On 19/12/2019 16:41, Vicente Romero wrote: > Hi, > > Thanks for the review, > > On 12/19/19 11:09 AM, Maurizio Cimadamore wrote: >> Looks good - two questions: >> >> 1) do we really need to add this/super at different times? Perhaps we >> could also add this/super in RecordsHeaderPhase for all classes >> (class + records) >> 2) or, if not, I'd suggest moving the code which adds this/super in a >> routine, and call the routine from where you need it > > I think I prefer option 2 even if 1 is doable, I would prefer to let > the RecordPhase to record stuff only, also I prefer to let the current > flow stable and introduce a change to records only. So I have added a > new routine and invoked it from two different places [1]. How does it > look? > >> >> Maurizio > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8234445/webrev.01/ >> >> On 18/12/2019 18:24, Vicente Romero wrote: >>> Please review the fix for [1] at [2]. What happens here is that >>> basically for records we are altering the order in which members are >>> entered, this is because the compiler needs to check if a user >>> provided constructor has the same erasure as the canonical >>> constructor or not and depending on this generate one or not, or >>> even issue an error. The only way to have access to this information >>> is to enter all the constructors before the compiler gets to the >>> point where it needs to decide if a canonical should be generated or >>> not. The current implementation 'forgot' to add `this` and `super` >>> to the scope before entering all the constructors. This is the >>> reason for the spurious error message: because `this` was not >>> entered before the user defined constructors were entered by the >>> compiler >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8234445 >>> [2] http://cr.openjdk.java.net/~vromero/8234445/webrev.00/ > From vicente.romero at oracle.com Thu Dec 19 16:45:09 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Dec 2019 11:45:09 -0500 Subject: RFR: JDK-8234445: spurious error message for record constructors with receiver parameters In-Reply-To: <0ae807de-cfee-7d77-2c07-896702c5c672@oracle.com> References: <4ad0d7d4-ce17-5403-7b8e-82b48a420c8c@oracle.com> <62d3a2a8-bc04-7321-5463-cf3a25c1ee88@oracle.com> <0ae807de-cfee-7d77-2c07-896702c5c672@oracle.com> Message-ID: <3b7052ec-09f2-d9e9-4fbc-d3fd3aa970b6@oracle.com> thanks, Vicente On 12/19/19 11:43 AM, Maurizio Cimadamore wrote: > Looks good > > Maurizio > > On 19/12/2019 16:41, Vicente Romero wrote: >> Hi, >> >> Thanks for the review, >> >> On 12/19/19 11:09 AM, Maurizio Cimadamore wrote: >>> Looks good - two questions: >>> >>> 1) do we really need to add this/super at different times? Perhaps >>> we could also add this/super in RecordsHeaderPhase for all classes >>> (class + records) >>> 2) or, if not, I'd suggest moving the code which adds this/super in >>> a routine, and call the routine from where you need it >> >> I think I prefer option 2 even if 1 is doable, I would prefer to let >> the RecordPhase to record stuff only, also I prefer to let the >> current flow stable and introduce a change to records only. So I have >> added a new routine and invoked it from two different places [1]. How >> does it look? >> >>> >>> Maurizio >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8234445/webrev.01/ >>> >>> On 18/12/2019 18:24, Vicente Romero wrote: >>>> Please review the fix for [1] at [2]. What happens here is that >>>> basically for records we are altering the order in which members >>>> are entered, this is because the compiler needs to check if a user >>>> provided constructor has the same erasure as the canonical >>>> constructor or not and depending on this generate one or not, or >>>> even issue an error. The only way to have access to this >>>> information is to enter all the constructors before the compiler >>>> gets to the point where it needs to decide if a canonical should be >>>> generated or not. The current implementation 'forgot' to add `this` >>>> and `super` to the scope before entering all the constructors. This >>>> is the reason for the spurious error message: because `this` was >>>> not entered before the user defined constructors were entered by >>>> the compiler >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234445 >>>> [2] http://cr.openjdk.java.net/~vromero/8234445/webrev.00/ >> From vicente.romero at oracle.com Thu Dec 19 17:59:57 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Dec 2019 12:59:57 -0500 Subject: RFR: JDK-8236266: change error message for the case when a class extends j.l.Record Message-ID: <67529bf7-e135-c93e-ac09-1e480669f345@oracle.com> Please review this one liner fix to [1] at [2]. This is just a minor change in an error message.Currently if a class extends class: j.l.Record, javac shows the following error message: ExtendingRecordClass.java:1: error: records cannot directly extend Record class Test extends Record {} ^ when Test is not a record but a class. This fix updates the error message, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8236266 [2] http://cr.openjdk.java.net/~vromero/8236266/webrev.00/ From maurizio.cimadamore at oracle.com Thu Dec 19 18:08:32 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 19 Dec 2019 18:08:32 +0000 Subject: RFR: JDK-8236266: change error message for the case when a class extends j.l.Record In-Reply-To: <67529bf7-e135-c93e-ac09-1e480669f345@oracle.com> References: <67529bf7-e135-c93e-ac09-1e480669f345@oracle.com> Message-ID: Looks good Maurizio On 19/12/2019 17:59, Vicente Romero wrote: > Please review this one liner fix to [1] at [2]. This is just a minor > change in an error message.Currently if a class extends class: > j.l.Record, javac shows the following error message: > > ExtendingRecordClass.java:1: error: records cannot directly extend Record > class Test extends Record {} > ^ > > when Test is not a record but a class. This fix updates the error > message, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236266 > [2] http://cr.openjdk.java.net/~vromero/8236266/webrev.00/ > From jonathan.gibbons at oracle.com Thu Dec 19 22:51:32 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Dec 2019 14:51:32 -0800 Subject: [PATCH] JDK-8233680: JavacFileManager.close() doesn't clear some cache instance variables In-Reply-To: References: Message-ID: dropping: jdk-dev at openjdk.java.net, follow-ups to: compiler-dev at openjdk.java.net Daniel, While I appreciate that you have written a test, these days our policy is to not use shell script for writing compiler tests, unless it is absolutely necessary, which it almost never is. It is also curious that your test depends on the use of javadoc, which is unusual for a compiler test. Is it possible to write the test in Java, and to not depend on javadoc? -- Jon On 12/18/2019 11:35 PM, Daniel Le Duc Khoi Nguyen wrote: > Hi everyone, > > I've already included all relevant information at > https://bugs.openjdk.java.net/browse/JDK-8233680. I'm just going to > attach the patch (with tests) below. > > Since this is my first patch, please help guide me through the > process. Thank you. > From jonathan.gibbons at oracle.com Thu Dec 19 23:49:11 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Dec 2019 15:49:11 -0800 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> Message-ID: On 12/19/19 3:30 PM, David Holmes wrote: >> >> /home/ty/Downloads/jdk-master/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java:30: >> warning: [preview] RecordComponentElement is an API that is part of a >> preview feature >> import javax.lang.model.element.RecordComponentElement; >> ??????????????????????????????? ^ >> /home/ty/Downloads/jdk-master/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java:30: >> warning: [preview] RecordComponentElement is an API that is part of a >> preview feature >> import javax.lang.model.element.RecordComponentElement; >> ??????????????????????????????? ^ >> error: warnings found and -Werror specified > > I think this is more an issue for the language and compiler folk on > compiler-dev. I'm not clear on all the rules around use of preview > features but it seems to me that if we are using them internally and > that generates warnings then we should be suppressing those warnings > (@supressedWarning) at those call sites. Though I don't know whether > you can suppress a warning for an import statement?? > > David > ----- This sounds like a bug.?? In other analogous situations, we decided not to give warnings on imports. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From youngty1997 at gmail.com Thu Dec 19 23:58:05 2019 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 19 Dec 2019 17:58:05 -0600 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> Message-ID: <73306b5b-ef0e-0cc0-a4c1-8c017909832b@gmail.com> On 12/19/19 5:30 PM, David Holmes wrote: > Hi Ty, > > On 20/12/2019 9:23 am, Ty Young wrote: >> Hi, >> >> >> As of the merging of Records into JDK proper, source code compiling >> fails using a standard command line of: >> >> >> bash configure --disable-warnings-as-errors > > I would have expected that to ensure the warnings were NOT treated as > an error. Is there some build system bug here? Or is there some > double-negative at play ?? spec.gmk has this: # A global flag (true or false) determining if native warnings are considered errors. WARNINGS_AS_ERRORS := false ...implying that it only affects native warnings. The argument naming itself doesn't really suggest that though... > >> >> which fails with: >> >> >> /home/ty/Downloads/jdk-master/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java:30: >> warning: [preview] RecordComponentElement is an API that is part of a >> preview feature >> import javax.lang.model.element.RecordComponentElement; >> ??????????????????????????????? ^ >> /home/ty/Downloads/jdk-master/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java:30: >> warning: [preview] RecordComponentElement is an API that is part of a >> preview feature >> import javax.lang.model.element.RecordComponentElement; >> ??????????????????????????????? ^ >> error: warnings found and -Werror specified > > I think this is more an issue for the language and compiler folk on > compiler-dev. I'm not clear on all the rules around use of preview > features but it seems to me that if we are using them internally and > that generates warnings then we should be suppressing those warnings > (@supressedWarning) at those call sites. Though I don't know whether > you can suppress a warning for an import statement?? > > David > ----- Sending this to them. > >> >> ...which was not the case in 13. I'm assuming this is happening now >> because JDK source code actually utilizes the feature preview where >> as with other preview features before simply existed but weren't used >> in source. >> >> >> I've been told by a JDK developer from the Project Panama mailing >> list that it *does* compile for them, but I'm not aware of the >> command line arguments that JDK developers use. Is this documented >> somewhere? Should it be failing by default like this? >> >> >> Additionally, the argument --with-libclang-include-aux seems to have >> been deprecated in 14. This, as was told to me by a Panama JDK >> developer, is needed to specify clang headers for custom source >> builds. What is the correct way to specify those now in 14? >> From maurizio.cimadamore at oracle.com Fri Dec 20 00:14:35 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Dec 2019 00:14:35 +0000 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> Message-ID: <9eb421ee-b618-0797-a5eb-ecec86863152@oracle.com> On 19/12/2019 23:49, Jonathan Gibbons wrote: > > > On 12/19/19 3:30 PM, David Holmes wrote: >>> >>> /home/ty/Downloads/jdk-master/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java:30: >>> warning: [preview] RecordComponentElement is an API that is part of >>> a preview feature >>> import javax.lang.model.element.RecordComponentElement; >>> ??????????????????????????????? ^ >>> /home/ty/Downloads/jdk-master/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java:30: >>> warning: [preview] RecordComponentElement is an API that is part of >>> a preview feature >>> import javax.lang.model.element.RecordComponentElement; >>> ??????????????????????????????? ^ >>> error: warnings found and -Werror specified >> >> I think this is more an issue for the language and compiler folk on >> compiler-dev. I'm not clear on all the rules around use of preview >> features but it seems to me that if we are using them internally and >> that generates warnings then we should be suppressing those warnings >> (@supressedWarning) at those call sites. Though I don't know whether >> you can suppress a warning for an import statement?? >> >> David >> ----- > > This sounds like a bug.?? In other analogous situations, we decided > not to give warnings on imports. > This was an issue that was fixed few weeks ago by Chris and Jan http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 I believe something else is at play here (like a repository not fully up to date). Maurizio > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From youngty1997 at gmail.com Fri Dec 20 00:22:04 2019 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 19 Dec 2019 18:22:04 -0600 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> <04799b66-a03d-1a06-be40-9e297bbce775@oracle.com> <4369cdda-9371-488e-1059-1c29546d2bdb@gmail.com> Message-ID: <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: > > On 20/12/2019 00:02, Ty Young wrote: >> >> On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: >>> >>> On 19/12/2019 23:30, David Holmes wrote: >>>> I think this is more an issue for the language and compiler folk on >>>> compiler-dev. I'm not clear on all the rules around use of preview >>>> features but it seems to me that if we are using them internally >>>> and that generates warnings then we should be suppressing those >>>> warnings (@supressedWarning) at those call sites. Though I don't >>>> know whether you can suppress a warning for an import statement?? >>> >>> We had an issue 3-4 weeks ago with preview warnings being issues in >>> import. That issue was fixed and integrated with the big record push: >>> >>> http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 >>> >>> In fact, I do not see any warning being triggered in my build. >>> >>> Ty mentioned that he's building from bits obtained from GitHub - so >>> at this point I wonder what's the 'tip' of the jdk/jdk repository >>> you are trying to build? >> >> >> Github link: https://github.com/openjdk/jdk. > > That repo looks fresh - are you sure your local HEAD matches the one > you see in GitHub? git diff @{upstream} shows nothing different. > > Maurizio > >> >> >> I didn't realize it, but it looks like y'all are already working on >> 15. Changes made to 14 are pushed to 15 anyway so it doesn't matter, >> right? >> >> >>> >>> Maurizio >>> From maurizio.cimadamore at oracle.com Fri Dec 20 00:28:53 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Dec 2019 00:28:53 +0000 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> <04799b66-a03d-1a06-be40-9e297bbce775@oracle.com> <4369cdda-9371-488e-1059-1c29546d2bdb@gmail.com> <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> Message-ID: On 20/12/2019 00:22, Ty Young wrote: > > On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: >> >> On 20/12/2019 00:02, Ty Young wrote: >>> >>> On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: >>>> >>>> On 19/12/2019 23:30, David Holmes wrote: >>>>> I think this is more an issue for the language and compiler folk >>>>> on compiler-dev. I'm not clear on all the rules around use of >>>>> preview features but it seems to me that if we are using them >>>>> internally and that generates warnings then we should be >>>>> suppressing those warnings (@supressedWarning) at those call >>>>> sites. Though I don't know whether you can suppress a warning for >>>>> an import statement?? >>>> >>>> We had an issue 3-4 weeks ago with preview warnings being issues in >>>> import. That issue was fixed and integrated with the big record push: >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 >>>> >>>> >>>> In fact, I do not see any warning being triggered in my build. >>>> >>>> Ty mentioned that he's building from bits obtained from GitHub - so >>>> at this point I wonder what's the 'tip' of the jdk/jdk repository >>>> you are trying to build? >>> >>> >>> Github link: https://github.com/openjdk/jdk. >> >> That repo looks fresh - are you sure your local HEAD matches the one >> you see in GitHub? > > > git diff @{upstream} shows nothing different. Ok - but what is your HEAD? At which commit is your local repo? https://stackoverflow.com/questions/1967967/git-command-to-display-head-commit-id Maurizio > > >> >> Maurizio >> >>> >>> >>> I didn't realize it, but it looks like y'all are already working on >>> 15. Changes made to 14 are pushed to 15 anyway so it doesn't matter, >>> right? >>> >>> >>>> >>>> Maurizio >>>> From maurizio.cimadamore at oracle.com Fri Dec 20 00:37:15 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Dec 2019 00:37:15 +0000 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> <04799b66-a03d-1a06-be40-9e297bbce775@oracle.com> <4369cdda-9371-488e-1059-1c29546d2bdb@gmail.com> <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> Message-ID: On 20/12/2019 00:28, Maurizio Cimadamore wrote: > > On 20/12/2019 00:22, Ty Young wrote: >> >> On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: >>> >>> On 20/12/2019 00:02, Ty Young wrote: >>>> >>>> On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: >>>>> >>>>> On 19/12/2019 23:30, David Holmes wrote: >>>>>> I think this is more an issue for the language and compiler folk >>>>>> on compiler-dev. I'm not clear on all the rules around use of >>>>>> preview features but it seems to me that if we are using them >>>>>> internally and that generates warnings then we should be >>>>>> suppressing those warnings (@supressedWarning) at those call >>>>>> sites. Though I don't know whether you can suppress a warning for >>>>>> an import statement?? >>>>> >>>>> We had an issue 3-4 weeks ago with preview warnings being issues >>>>> in import. That issue was fixed and integrated with the big record >>>>> push: >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 >>>>> >>>>> >>>>> In fact, I do not see any warning being triggered in my build. >>>>> >>>>> Ty mentioned that he's building from bits obtained from GitHub - >>>>> so at this point I wonder what's the 'tip' of the jdk/jdk >>>>> repository you are trying to build? >>>> >>>> >>>> Github link: https://github.com/openjdk/jdk. >>> >>> That repo looks fresh - are you sure your local HEAD matches the one >>> you see in GitHub? >> >> >> git diff @{upstream} shows nothing different. > > Ok - but what is your HEAD? At which commit is your local repo? > > https://stackoverflow.com/questions/1967967/git-command-to-display-head-commit-id > If your repo is up to date, I have another possible theory - that you are using a bootstrap JDK (the JDK you use -- among other things -- to compile the compiler contained in the JDK sources) which is in the unfortunate state so that (i) it understands @Preview annotations (and display warnings about them) but (ii) does not yet contain the aforementioned fix to suppress preview warnings on imports. If you could attach your full build log, we might be able to see whether the failure occurs during the so called 'bootstrap' phase, in which case that would be definitively a sign of an 'unlucky' JDK being used as bootstrap JDK. Maurizio > > Maurizio > >> >> >>> >>> Maurizio >>> >>>> >>>> >>>> I didn't realize it, but it looks like y'all are already working on >>>> 15. Changes made to 14 are pushed to 15 anyway so it doesn't >>>> matter, right? >>>> >>>> >>>>> >>>>> Maurizio >>>>> From amaembo at gmail.com Fri Dec 20 00:37:50 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 20 Dec 2019 07:37:50 +0700 Subject: RFR: JDK-8236266: change error message for the case when a class extends j.l.Record In-Reply-To: <67529bf7-e135-c93e-ac09-1e480669f345@oracle.com> References: <67529bf7-e135-c93e-ac09-1e480669f345@oracle.com> Message-ID: Hello! What about merging this message with already existing compiler.err.enum.no.subclassing=\ classes cannot directly extend java.lang.Enum ? I mean, enum could reuse the same message passing java.lang.Enum as {0}. Or this is to big change? Tagir. ??, 20 ???. 2019 ?., 1:00 Vicente Romero : > Please review this one liner fix to [1] at [2]. This is just a minor > change in an error message.Currently if a class extends class: > j.l.Record, javac shows the following error message: > > ExtendingRecordClass.java:1: error: records cannot directly extend Record > class Test extends Record {} > ^ > > when Test is not a record but a class. This fix updates the error message, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236266 > [2] http://cr.openjdk.java.net/~vromero/8236266/webrev.00/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From youngty1997 at gmail.com Fri Dec 20 00:40:31 2019 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 19 Dec 2019 18:40:31 -0600 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> <04799b66-a03d-1a06-be40-9e297bbce775@oracle.com> <4369cdda-9371-488e-1059-1c29546d2bdb@gmail.com> <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> Message-ID: <78456c17-47b0-f07e-b261-c9b69fa3f70c@gmail.com> On 12/19/19 6:28 PM, Maurizio Cimadamore wrote: > > On 20/12/2019 00:22, Ty Young wrote: >> >> On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: >>> >>> On 20/12/2019 00:02, Ty Young wrote: >>>> >>>> On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: >>>>> >>>>> On 19/12/2019 23:30, David Holmes wrote: >>>>>> I think this is more an issue for the language and compiler folk >>>>>> on compiler-dev. I'm not clear on all the rules around use of >>>>>> preview features but it seems to me that if we are using them >>>>>> internally and that generates warnings then we should be >>>>>> suppressing those warnings (@supressedWarning) at those call >>>>>> sites. Though I don't know whether you can suppress a warning for >>>>>> an import statement?? >>>>> >>>>> We had an issue 3-4 weeks ago with preview warnings being issues >>>>> in import. That issue was fixed and integrated with the big record >>>>> push: >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 >>>>> >>>>> >>>>> In fact, I do not see any warning being triggered in my build. >>>>> >>>>> Ty mentioned that he's building from bits obtained from GitHub - >>>>> so at this point I wonder what's the 'tip' of the jdk/jdk >>>>> repository you are trying to build? >>>> >>>> >>>> Github link: https://github.com/openjdk/jdk. >>> >>> That repo looks fresh - are you sure your local HEAD matches the one >>> you see in GitHub? >> >> >> git diff @{upstream} shows nothing different. > > Ok - but what is your HEAD? At which commit is your local repo? > > https://stackoverflow.com/questions/1967967/git-command-to-display-head-commit-id > fb1c57789e5907b0e9fe63d604d9e97a000a4d38 ...which includes the 15.2 tag from 24 hours ago. > > Maurizio > >> >> >>> >>> Maurizio >>> >>>> >>>> >>>> I didn't realize it, but it looks like y'all are already working on >>>> 15. Changes made to 14 are pushed to 15 anyway so it doesn't >>>> matter, right? >>>> >>>> >>>>> >>>>> Maurizio >>>>> From maurizio.cimadamore at oracle.com Fri Dec 20 00:41:35 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Dec 2019 00:41:35 +0000 Subject: RFR: JDK-8236266: change error message for the case when a class extends j.l.Record In-Reply-To: References: <67529bf7-e135-c93e-ac09-1e480669f345@oracle.com> Message-ID: I noticed that too - I assumed we wanted to minimize disruption for now - I'll leave the decision to Vicente Maurizio On 20/12/2019 00:37, Tagir Valeev wrote: > Hello! > > What about merging this message with already existing > > compiler.err.enum.no.subclassing=\ > classes cannot directly extend java.lang.Enum > ? > I mean, enum could reuse the same message passing java.lang.Enum as {0}. Or this is to big change? > Tagir. > > ??, 20 ???. 2019 ?., 1:00 Vicente Romero >: > > Please review this one liner fix to [1] at [2]. This is just a minor > change in an error message.Currently if a class extends class: > j.l.Record, javac shows the following error message: > > ExtendingRecordClass.java:1: error: records cannot directly extend > Record > class Test extends Record {} > ^ > > when Test is not a record but a class. This fix updates the error > message, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8236266 > [2] http://cr.openjdk.java.net/~vromero/8236266/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Dec 20 00:43:30 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Dec 2019 00:43:30 +0000 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: <78456c17-47b0-f07e-b261-c9b69fa3f70c@gmail.com> References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> <04799b66-a03d-1a06-be40-9e297bbce775@oracle.com> <4369cdda-9371-488e-1059-1c29546d2bdb@gmail.com> <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> <78456c17-47b0-f07e-b261-c9b69fa3f70c@gmail.com> Message-ID: On 20/12/2019 00:40, Ty Young wrote: > > On 12/19/19 6:28 PM, Maurizio Cimadamore wrote: >> >> On 20/12/2019 00:22, Ty Young wrote: >>> >>> On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: >>>> >>>> On 20/12/2019 00:02, Ty Young wrote: >>>>> >>>>> On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: >>>>>> >>>>>> On 19/12/2019 23:30, David Holmes wrote: >>>>>>> I think this is more an issue for the language and compiler folk >>>>>>> on compiler-dev. I'm not clear on all the rules around use of >>>>>>> preview features but it seems to me that if we are using them >>>>>>> internally and that generates warnings then we should be >>>>>>> suppressing those warnings (@supressedWarning) at those call >>>>>>> sites. Though I don't know whether you can suppress a warning >>>>>>> for an import statement?? >>>>>> >>>>>> We had an issue 3-4 weeks ago with preview warnings being issues >>>>>> in import. That issue was fixed and integrated with the big >>>>>> record push: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 >>>>>> >>>>>> >>>>>> In fact, I do not see any warning being triggered in my build. >>>>>> >>>>>> Ty mentioned that he's building from bits obtained from GitHub - >>>>>> so at this point I wonder what's the 'tip' of the jdk/jdk >>>>>> repository you are trying to build? >>>>> >>>>> >>>>> Github link: https://github.com/openjdk/jdk. >>>> >>>> That repo looks fresh - are you sure your local HEAD matches the >>>> one you see in GitHub? >>> >>> >>> git diff @{upstream} shows nothing different. >> >> Ok - but what is your HEAD? At which commit is your local repo? >> >> https://stackoverflow.com/questions/1967967/git-command-to-display-head-commit-id >> > > > fb1c57789e5907b0e9fe63d604d9e97a000a4d38 > > > ...which includes the 15.2 tag from 24 hours ago. Yep - that's fresh - please look at my other message; if your repo is up to date, then I'm starting to suspect the bootstrap JDK you are using Maurizio > > >> >> Maurizio >> >>> >>> >>>> >>>> Maurizio >>>> >>>>> >>>>> >>>>> I didn't realize it, but it looks like y'all are already working >>>>> on 15. Changes made to 14 are pushed to 15 anyway so it doesn't >>>>> matter, right? >>>>> >>>>> >>>>>> >>>>>> Maurizio >>>>>> From youngty1997 at gmail.com Fri Dec 20 00:47:43 2019 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 19 Dec 2019 18:47:43 -0600 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> <04799b66-a03d-1a06-be40-9e297bbce775@oracle.com> <4369cdda-9371-488e-1059-1c29546d2bdb@gmail.com> <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> Message-ID: On 12/19/19 6:37 PM, Maurizio Cimadamore wrote: > > On 20/12/2019 00:28, Maurizio Cimadamore wrote: >> >> On 20/12/2019 00:22, Ty Young wrote: >>> >>> On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: >>>> >>>> On 20/12/2019 00:02, Ty Young wrote: >>>>> >>>>> On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: >>>>>> >>>>>> On 19/12/2019 23:30, David Holmes wrote: >>>>>>> I think this is more an issue for the language and compiler folk >>>>>>> on compiler-dev. I'm not clear on all the rules around use of >>>>>>> preview features but it seems to me that if we are using them >>>>>>> internally and that generates warnings then we should be >>>>>>> suppressing those warnings (@supressedWarning) at those call >>>>>>> sites. Though I don't know whether you can suppress a warning >>>>>>> for an import statement?? >>>>>> >>>>>> We had an issue 3-4 weeks ago with preview warnings being issues >>>>>> in import. That issue was fixed and integrated with the big >>>>>> record push: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 >>>>>> >>>>>> >>>>>> In fact, I do not see any warning being triggered in my build. >>>>>> >>>>>> Ty mentioned that he's building from bits obtained from GitHub - >>>>>> so at this point I wonder what's the 'tip' of the jdk/jdk >>>>>> repository you are trying to build? >>>>> >>>>> >>>>> Github link: https://github.com/openjdk/jdk. >>>> >>>> That repo looks fresh - are you sure your local HEAD matches the >>>> one you see in GitHub? >>> >>> >>> git diff @{upstream} shows nothing different. >> >> Ok - but what is your HEAD? At which commit is your local repo? >> >> https://stackoverflow.com/questions/1967967/git-command-to-display-head-commit-id >> > > If your repo is up to date, I have another possible theory - that you > are using a bootstrap JDK (the JDK you use -- among other things -- to > compile the compiler contained in the JDK sources) which is in the > unfortunate state so that (i) it understands @Preview annotations (and > display warnings about them) but (ii) does not yet contain the > aforementioned fix to suppress preview warnings on imports. Sounds plausible... but doesn't every JDK release since 9 understand the preview feature system? > > If you could attach your full build log, we might be able to see > whether the failure occurs during the so called 'bootstrap' phase, in > which case that would be definitively a sign of an 'unlucky' JDK being > used as bootstrap JDK. > I'm using Panama's JDK that has been built from source. I think it was built just before you did the final merge and closing of the jextract-linkToNative branch. Attached is the failed build log... > Maurizio > >> >> Maurizio >> >>> >>> >>>> >>>> Maurizio >>>> >>>>> >>>>> >>>>> I didn't realize it, but it looks like y'all are already working >>>>> on 15. Changes made to 14 are pushed to 15 anyway so it doesn't >>>>> matter, right? >>>>> >>>>> >>>>>> >>>>>> Maurizio >>>>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log Type: text/x-log Size: 1885 bytes Desc: not available URL: From maurizio.cimadamore at oracle.com Fri Dec 20 00:51:27 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Dec 2019 00:51:27 +0000 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> <04799b66-a03d-1a06-be40-9e297bbce775@oracle.com> <4369cdda-9371-488e-1059-1c29546d2bdb@gmail.com> <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> Message-ID: Thanks for the log - it is indeed failing very early in the bootstrap phase. I bet that you get this with and w/o --disable-warnings-as-errors. I suggest you either use a _newer_ bootstrap JDK (e.g. take the latest from [1]), or an older one (e.g. JDK 13). That should cure it. Maurizio [1] - https://jdk.java.net/14/ On 20/12/2019 00:47, Ty Young wrote: > > On 12/19/19 6:37 PM, Maurizio Cimadamore wrote: >> >> On 20/12/2019 00:28, Maurizio Cimadamore wrote: >>> >>> On 20/12/2019 00:22, Ty Young wrote: >>>> >>>> On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: >>>>> >>>>> On 20/12/2019 00:02, Ty Young wrote: >>>>>> >>>>>> On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: >>>>>>> >>>>>>> On 19/12/2019 23:30, David Holmes wrote: >>>>>>>> I think this is more an issue for the language and compiler >>>>>>>> folk on compiler-dev. I'm not clear on all the rules around use >>>>>>>> of preview features but it seems to me that if we are using >>>>>>>> them internally and that generates warnings then we should be >>>>>>>> suppressing those warnings (@supressedWarning) at those call >>>>>>>> sites. Though I don't know whether you can suppress a warning >>>>>>>> for an import statement?? >>>>>>> >>>>>>> We had an issue 3-4 weeks ago with preview warnings being issues >>>>>>> in import. That issue was fixed and integrated with the big >>>>>>> record push: >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 >>>>>>> >>>>>>> >>>>>>> In fact, I do not see any warning being triggered in my build. >>>>>>> >>>>>>> Ty mentioned that he's building from bits obtained from GitHub - >>>>>>> so at this point I wonder what's the 'tip' of the jdk/jdk >>>>>>> repository you are trying to build? >>>>>> >>>>>> >>>>>> Github link: https://github.com/openjdk/jdk. >>>>> >>>>> That repo looks fresh - are you sure your local HEAD matches the >>>>> one you see in GitHub? >>>> >>>> >>>> git diff @{upstream} shows nothing different. >>> >>> Ok - but what is your HEAD? At which commit is your local repo? >>> >>> https://stackoverflow.com/questions/1967967/git-command-to-display-head-commit-id >>> >> >> If your repo is up to date, I have another possible theory - that you >> are using a bootstrap JDK (the JDK you use -- among other things -- >> to compile the compiler contained in the JDK sources) which is in the >> unfortunate state so that (i) it understands @Preview annotations >> (and display warnings about them) but (ii) does not yet contain the >> aforementioned fix to suppress preview warnings on imports. > > > Sounds plausible... but doesn't every JDK release since 9 understand > the preview feature system? > > >> >> If you could attach your full build log, we might be able to see >> whether the failure occurs during the so called 'bootstrap' phase, in >> which case that would be definitively a sign of an 'unlucky' JDK >> being used as bootstrap JDK. >> > > I'm using Panama's JDK that has been built from source. I think it was > built just before you did the final merge and closing of the > jextract-linkToNative branch. > > > Attached is the failed build log... > > >> Maurizio >> >>> >>> Maurizio >>> >>>> >>>> >>>>> >>>>> Maurizio >>>>> >>>>>> >>>>>> >>>>>> I didn't realize it, but it looks like y'all are already working >>>>>> on 15. Changes made to 14 are pushed to 15 anyway so it doesn't >>>>>> matter, right? >>>>>> >>>>>> >>>>>>> >>>>>>> Maurizio >>>>>>> From youngty1997 at gmail.com Fri Dec 20 01:56:38 2019 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 19 Dec 2019 19:56:38 -0600 Subject: Builds fail due to use of preview features & removed arguments In-Reply-To: References: <05a96a8e-0051-b540-0cfd-8cdf34c08e7c@gmail.com> <3196dc32-fefd-2546-fb3f-488000a2870f@oracle.com> <04799b66-a03d-1a06-be40-9e297bbce775@oracle.com> <4369cdda-9371-488e-1059-1c29546d2bdb@gmail.com> <554e3ccf-c7d9-9ca2-4ca0-26f581e04daa@gmail.com> Message-ID: Works now. Thanks for the suggestion! On 12/19/19 6:51 PM, Maurizio Cimadamore wrote: > Thanks for the log - it is indeed failing very early in the bootstrap > phase. > > I bet that you get this with and w/o --disable-warnings-as-errors. > > I suggest you either use a _newer_ bootstrap JDK (e.g. take the latest > from [1]), or an older one (e.g. JDK 13). That should cure it. > > Maurizio > > [1] - https://jdk.java.net/14/ > > > On 20/12/2019 00:47, Ty Young wrote: >> >> On 12/19/19 6:37 PM, Maurizio Cimadamore wrote: >>> >>> On 20/12/2019 00:28, Maurizio Cimadamore wrote: >>>> >>>> On 20/12/2019 00:22, Ty Young wrote: >>>>> >>>>> On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: >>>>>> >>>>>> On 20/12/2019 00:02, Ty Young wrote: >>>>>>> >>>>>>> On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: >>>>>>>> >>>>>>>> On 19/12/2019 23:30, David Holmes wrote: >>>>>>>>> I think this is more an issue for the language and compiler >>>>>>>>> folk on compiler-dev. I'm not clear on all the rules around >>>>>>>>> use of preview features but it seems to me that if we are >>>>>>>>> using them internally and that generates warnings then we >>>>>>>>> should be suppressing those warnings (@supressedWarning) at >>>>>>>>> those call sites. Though I don't know whether you can suppress >>>>>>>>> a warning for an import statement?? >>>>>>>> >>>>>>>> We had an issue 3-4 weeks ago with preview warnings being >>>>>>>> issues in import. That issue was fixed and integrated with the >>>>>>>> big record push: >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/8e76f81d057a?revcount=20#l110.18 >>>>>>>> >>>>>>>> >>>>>>>> In fact, I do not see any warning being triggered in my build. >>>>>>>> >>>>>>>> Ty mentioned that he's building from bits obtained from GitHub >>>>>>>> - so at this point I wonder what's the 'tip' of the jdk/jdk >>>>>>>> repository you are trying to build? >>>>>>> >>>>>>> >>>>>>> Github link: https://github.com/openjdk/jdk. >>>>>> >>>>>> That repo looks fresh - are you sure your local HEAD matches the >>>>>> one you see in GitHub? >>>>> >>>>> >>>>> git diff @{upstream} shows nothing different. >>>> >>>> Ok - but what is your HEAD? At which commit is your local repo? >>>> >>>> https://stackoverflow.com/questions/1967967/git-command-to-display-head-commit-id >>>> >>> >>> If your repo is up to date, I have another possible theory - that >>> you are using a bootstrap JDK (the JDK you use -- among other things >>> -- to compile the compiler contained in the JDK sources) which is in >>> the unfortunate state so that (i) it understands @Preview >>> annotations (and display warnings about them) but (ii) does not yet >>> contain the aforementioned fix to suppress preview warnings on imports. >> >> >> Sounds plausible... but doesn't every JDK release since 9 understand >> the preview feature system? >> >> >>> >>> If you could attach your full build log, we might be able to see >>> whether the failure occurs during the so called 'bootstrap' phase, >>> in which case that would be definitively a sign of an 'unlucky' JDK >>> being used as bootstrap JDK. >>> >> >> I'm using Panama's JDK that has been built from source. I think it >> was built just before you did the final merge and closing of the >> jextract-linkToNative branch. >> >> >> Attached is the failed build log... >> >> >>> Maurizio >>> >>>> >>>> Maurizio >>>> >>>>> >>>>> >>>>>> >>>>>> Maurizio >>>>>> >>>>>>> >>>>>>> >>>>>>> I didn't realize it, but it looks like y'all are already working >>>>>>> on 15. Changes made to 14 are pushed to 15 anyway so it doesn't >>>>>>> matter, right? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Maurizio >>>>>>>> From vicente.romero at oracle.com Fri Dec 20 03:09:18 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Dec 2019 22:09:18 -0500 Subject: RFR: JDK-8236266: change error message for the case when a class extends j.l.Record In-Reply-To: References: <67529bf7-e135-c93e-ac09-1e480669f345@oracle.com> Message-ID: On 12/19/19 7:41 PM, Maurizio Cimadamore wrote: > > I noticed that too - I assumed we wanted to minimize disruption for > now - I'll leave the decision to Vicente > I have already pushed the patch, we can revisit the message merging in a separate effort > Maurizio > Vicente > On 20/12/2019 00:37, Tagir Valeev wrote: >> Hello! >> >> What about merging this message with already existing >> >> compiler.err.enum.no.subclassing=\ >> classes cannot directly extend java.lang.Enum >> ? >> I mean, enum could reuse the same message passing java.lang.Enum as {0}. Or this is to big change? >> Tagir. >> >> ??, 20 ???. 2019 ?., 1:00 Vicente Romero > >: >> >> Please review this one liner fix to [1] at [2]. This is just a minor >> change in an error message.Currently if a class extends class: >> j.l.Record, javac shows the following error message: >> >> ExtendingRecordClass.java:1: error: records cannot directly >> extend Record >> class Test extends Record {} >> ^ >> >> when Test is not a record but a class. This fix updates the error >> message, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8236266 >> [2] http://cr.openjdk.java.net/~vromero/8236266/webrev.00/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenrecyclebin at gmail.com Fri Dec 20 09:01:17 2019 From: greenrecyclebin at gmail.com (Daniel Le Duc Khoi Nguyen) Date: Fri, 20 Dec 2019 17:01:17 +0800 Subject: [PATCH] JDK-8233680: JavacFileManager.close() doesn't clear some cache instance variables In-Reply-To: References: Message-ID: Hi Jon, I've converted the test to Java and moved it under the javadoc package to avoid any confusion of it being a compiler test. I've also simplified and add comments to it. Please refer to JDK-8233680-1.patch. In order to trigger the bug, one must reuse the JavacFileManager object that is created automatically by the compiler tools (when no fileManager argument is passed to getTask) after it's been automatically closed. This is only possible with JavaDoc and not javac. JavacTaskImpl.cleanup and JavacTaskImpl.prepareCompiler together make reusing the JavacFileManager object impossible. If you'd like to remove JavaDoc from the test dependency, please refer to JDK-8233680-javac-test-not-working-wip.patch and see if you could take it further. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8233680-javac-test-not-working-wip.patch Type: text/x-patch Size: 4349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8233680-1.patch Type: text/x-patch Size: 4391 bytes Desc: not available URL: From pavel.rappo at oracle.com Fri Dec 20 15:44:50 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 20 Dec 2019 15:44:50 +0000 Subject: RFR [15] 8236435: Fix typos in javac area Message-ID: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> Hello, Please review the following change for https://bugs.openjdk.java.net/browse/JDK-8236435: http://cr.openjdk.java.net/~prappo/8236435/webrev.00/ I've been reading up on the javadoc code and comments. At one point, jumping through the links, I reached the javax.tools.DocumentationTool and com.sun.tools.javac.util.ClientCodeException, which reside in java.compiler and jdk.compiler respectively. I found a couple of typos there and fixed them. One thing led to another and half an hour later I found myself compulsively checking the full javac code base for typos and spelling. Sigh. Long story short, I just went ahead and fixed as many issues as I could in one sitting. There was a lot. On the bright side, this patch doesn't involve any code changes (except for spelling in internal variables and methods' parameters), addresses aesthetic issues, readability, helps with searches and assists IDEs to pick up usages more reliably when refactoring (e.g. renaming). The initial concern with DocumentationTool turned out to be more subtle and I decided not to include it in this patch. It is definitely not just a typo and might require a CSR. Please review at your convenience. Hopefully, if there are false positives, you'll catch them. I suggest reviewing this change using a diff tool with a character-level resolution. That is, a tool capable of highlighting mismatching characters in lines that differ. All test/langtools tests pass. Copyright years will be fixed before the push. Thanks, -Pavel From jonathan.gibbons at oracle.com Fri Dec 20 16:18:07 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 Dec 2019 08:18:07 -0800 Subject: [PATCH] JDK-8233680: JavacFileManager.close() doesn't clear some cache instance variables In-Reply-To: References: Message-ID: <971f4f15-01a6-11bb-5bc1-e92cf9064ad8@oracle.com> Daniel, Thank you for the followup. I will take? more detailed look at the underlying code and the use of null arguments for the file manager for JavaCompiler and DocumentationTool. -- Jon On 12/20/19 1:01 AM, Daniel Le Duc Khoi Nguyen wrote: > Hi Jon, > > I've converted the test to Java and moved it under the javadoc package to avoid > any confusion of it being a compiler test. I've also simplified and add comments > to it. Please refer to JDK-8233680-1.patch. > > In order to trigger the bug, one must reuse the JavacFileManager object that is > created automatically by the compiler tools (when no fileManager argument is > passed to getTask) after it's been automatically closed. > > This is only possible with JavaDoc and not javac. JavacTaskImpl.cleanup and > JavacTaskImpl.prepareCompiler together make reusing the JavacFileManager object > impossible. > > If you'd like to remove JavaDoc from the test dependency, please refer to > JDK-8233680-javac-test-not-working-wip.patch and see if you could take it > further. Thank you. From jonathan.gibbons at oracle.com Fri Dec 20 17:04:01 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 Dec 2019 09:04:01 -0800 Subject: RFR [15] 8236435: Fix typos in javac area In-Reply-To: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> References: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> Message-ID: <87c5ff6e-8a8d-c087-a049-ebc02895f78e@oracle.com> Pavel, Thanks for looking at this. It was worth reading if only for the occasional amusement at some of the typos, and occasional guilt at recognizing some that I probably made. Here are some notes; none need a followup webrev. I've reviewed all the individual changes, but since neither of us work routinely on all the javac source code, I would recommend also getting buy-in from an active javac developer that a widespread update like this is acceptable. -- Jon In src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java, you missed a typo ;-)? "influences" should be "influenced" In Pretty.java, the guideline is to avoid use of XXX and use something like XYZ instead. - /** Exception to propogate IOException through visitXXX methods */ + /** Exception to propagate IOException through visitXXX methods */ In sjavac Source.java, "lets" should be "let's" - // Oups, the source is already added, could be ok, could be not, lets check. + // Oops, the source is already added, could be ok, could be not, lets check. -- Jon On 12/20/19 7:44 AM, Pavel Rappo wrote: > Hello, > > Please review the following change for https://bugs.openjdk.java.net/browse/JDK-8236435: > > http://cr.openjdk.java.net/~prappo/8236435/webrev.00/ > > I've been reading up on the javadoc code and comments. At one point, jumping > through the links, I reached the javax.tools.DocumentationTool and > com.sun.tools.javac.util.ClientCodeException, which reside in java.compiler and > jdk.compiler respectively. I found a couple of typos there and fixed them. > > One thing led to another and half an hour later I found myself compulsively > checking the full javac code base for typos and spelling. Sigh. > > Long story short, I just went ahead and fixed as many issues as I could in one > sitting. There was a lot. > > On the bright side, this patch doesn't involve any code changes (except for > spelling in internal variables and methods' parameters), addresses aesthetic > issues, readability, helps with searches and assists IDEs to pick up usages > more reliably when refactoring (e.g. renaming). > > The initial concern with DocumentationTool turned out to be more subtle and I > decided not to include it in this patch. It is definitely not just a typo and > might require a CSR. > > Please review at your convenience. Hopefully, if there are false positives, > you'll catch them. > > I suggest reviewing this change using a diff tool with a character-level > resolution. That is, a tool capable of highlighting mismatching characters in > lines that differ. > > All test/langtools tests pass. Copyright years will be fixed before the push. > > Thanks, > -Pavel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at oracle.com Fri Dec 20 18:18:47 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 20 Dec 2019 18:18:47 +0000 Subject: RFR [15] 8236435: Fix typos in javac area In-Reply-To: <87c5ff6e-8a8d-c087-a049-ebc02895f78e@oracle.com> References: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> <87c5ff6e-8a8d-c087-a049-ebc02895f78e@oracle.com> Message-ID: <264A1FED-3F85-429B-AF01-DF242A46A1FE@oracle.com> Thanks, Jon. I will take those on board, once cleared for pushing the initial patch by active members of the compiler team. > On 20 Dec 2019, at 17:04, Jonathan Gibbons wrote: > > Pavel, > > Thanks for looking at this. It was worth reading if only for the occasional amusement at some of the typos, and occasional guilt at recognizing some that I probably made. Here are some notes; none need a followup webrev. > > I've reviewed all the individual changes, but since neither of us work routinely on all the javac source code, I would recommend also getting buy-in from an active javac developer that a widespread update like this is acceptable. > > -- Jon > > > > In src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java, > you missed a typo ;-) "influences" should be "influenced" > > In Pretty.java, the guideline is to avoid use of XXX and use something like XYZ instead. > > - /** Exception to propogate IOException through visitXXX methods */ > + /** Exception to propagate IOException through visitXXX methods */ > In sjavac Source.java, "lets" should be "let's" > > - // Oups, the source is already added, could be ok, could be not, lets check. > > + // Oops, the source is already added, could be ok, could be not, lets check. > > -- Jon > > > On 12/20/19 7:44 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the following change for >> https://bugs.openjdk.java.net/browse/JDK-8236435 >> : >> >> >> http://cr.openjdk.java.net/~prappo/8236435/webrev.00/ >> >> >> I've been reading up on the javadoc code and comments. At one point, jumping >> through the links, I reached the javax.tools.DocumentationTool and >> com.sun.tools.javac.util.ClientCodeException, which reside in java.compiler and >> jdk.compiler respectively. I found a couple of typos there and fixed them. >> >> One thing led to another and half an hour later I found myself compulsively >> checking the full javac code base for typos and spelling. Sigh. >> >> Long story short, I just went ahead and fixed as many issues as I could in one >> sitting. There was a lot. >> >> On the bright side, this patch doesn't involve any code changes (except for >> spelling in internal variables and methods' parameters), addresses aesthetic >> issues, readability, helps with searches and assists IDEs to pick up usages >> more reliably when refactoring (e.g. renaming). >> >> The initial concern with DocumentationTool turned out to be more subtle and I >> decided not to include it in this patch. It is definitely not just a typo and >> might require a CSR. >> >> Please review at your convenience. Hopefully, if there are false positives, >> you'll catch them. >> >> I suggest reviewing this change using a diff tool with a character-level >> resolution. That is, a tool capable of highlighting mismatching characters in >> lines that differ. >> >> All test/langtools tests pass. Copyright years will be fixed before the push. >> >> Thanks, >> -Pavel >> >> From maurizio.cimadamore at oracle.com Fri Dec 20 21:35:41 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Dec 2019 21:35:41 +0000 Subject: RFR [15] 8236435: Fix typos in javac area In-Reply-To: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> References: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> Message-ID: <47516039-ff1e-4511-c6e3-92df66433138@oracle.com> Looks good! Thanks for doing this. Some comments: * ClientCodeWrapper: should "propagate upwards" be replaced with "propagated upwards" ? Or perhaps we should use consistent wording with the phrase below "... are left alone to continue propagating upwards." *? ArgumentAttr: "behavior is influences by the currently selected cache policy." -->? s/influences/influenced * Check.java: "(except this in typesSkip)" -> s/this/those * LambdaToMethod: " (rather than i.e. accessing to captured members" - I think we can drop the "to" * Modules: "not the entire provides tree" - should "provides" be in a code block? * RichDiagnosticFormatter: "after these information is collected" --> s/these/this Maurizio On 20/12/2019 15:44, Pavel Rappo wrote: > Hello, > > Please review the following change for https://bugs.openjdk.java.net/browse/JDK-8236435: > > http://cr.openjdk.java.net/~prappo/8236435/webrev.00/ > > I've been reading up on the javadoc code and comments. At one point, jumping > through the links, I reached the javax.tools.DocumentationTool and > com.sun.tools.javac.util.ClientCodeException, which reside in java.compiler and > jdk.compiler respectively. I found a couple of typos there and fixed them. > > One thing led to another and half an hour later I found myself compulsively > checking the full javac code base for typos and spelling. Sigh. > > Long story short, I just went ahead and fixed as many issues as I could in one > sitting. There was a lot. > > On the bright side, this patch doesn't involve any code changes (except for > spelling in internal variables and methods' parameters), addresses aesthetic > issues, readability, helps with searches and assists IDEs to pick up usages > more reliably when refactoring (e.g. renaming). > > The initial concern with DocumentationTool turned out to be more subtle and I > decided not to include it in this patch. It is definitely not just a typo and > might require a CSR. > > Please review at your convenience. Hopefully, if there are false positives, > you'll catch them. > > I suggest reviewing this change using a diff tool with a character-level > resolution. That is, a tool capable of highlighting mismatching characters in > lines that differ. > > All test/langtools tests pass. Copyright years will be fixed before the push. > > Thanks, > -Pavel > From pavel.rappo at oracle.com Sat Dec 21 00:13:13 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 21 Dec 2019 00:13:13 +0000 Subject: RFR [15] 8236435: Fix typos in javac area In-Reply-To: <47516039-ff1e-4511-c6e3-92df66433138@oracle.com> References: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> <47516039-ff1e-4511-c6e3-92df66433138@oracle.com> Message-ID: Maurizio, > On 20 Dec 2019, at 21:35, Maurizio Cimadamore wrote: > > * ClientCodeWrapper: should "propagate upwards" be replaced with "propagated upwards" ? Or perhaps we should use consistent wording with the phrase below "... are left alone to continue propagating upwards." Would the following be more appropriate? *
  • Checked exceptions are left alone to propagate upwards in the > * ArgumentAttr: "behavior is influences by the currently selected cache policy." --> s/influences/influenced Fixed. (Jon also caught that one.) > * Check.java: "(except this in typesSkip)" -> s/this/those Fixed. > * LambdaToMethod: " (rather than i.e. accessing to captured members" - I think we can drop the "to" Fixed. Separately, I was wondering if "i.e." should've been "e.g." in the first place. It's a dangerous territory, where the semantics could be easily changed. > * Modules: "not the entire provides tree" - should "provides" be in a code block? Hm... I'm not sure I'm following, this is a simple code comment, not the javadoc comment. > * RichDiagnosticFormatter: "after these information is collected" --> s/these/this Thanks. I found that one too right after I have posted the RFR. Below is the incremental (inline) patch, addressing comments made by yourself and Jon, with a couple of extra fixes. Please note, that update also removes a part in DocumentationTool I was talking about, that unfortunately slipped through into the first RFR: diff --git a/src/java.compiler/share/classes/javax/tools/DocumentationTool.java b/src/java.compiler/share/classes/javax/tools/DocumentationTool.java --- a/src/java.compiler/share/classes/javax/tools/DocumentationTool.java +++ b/src/java.compiler/share/classes/javax/tools/DocumentationTool.java @@ -113,8 +113,9 @@ Charset charset); /** - * Interface representing a future for a documentation task. - * To start the task, call the {@linkplain #call call} method. + * Interface representing a future for a documentation task. The + * task has not yet started. To start the task, call + * the {@linkplain #call call} method. * *

    Before calling the {@code call} method, additional aspects of the * task can be configured, for example, by calling the diff --git a/src/java.compiler/share/classes/javax/tools/JavaCompiler.java b/src/java.compiler/share/classes/javax/tools/JavaCompiler.java --- a/src/java.compiler/share/classes/javax/tools/JavaCompiler.java +++ b/src/java.compiler/share/classes/javax/tools/JavaCompiler.java @@ -290,7 +290,7 @@ * compilation task has not yet started. To start the task, call * the {@linkplain #call call} method. * - *

    Before calling the call method, additional aspects of the + *

    Before calling the {@code call} method, additional aspects of the * task can be configured, for example, by calling the * {@linkplain #setProcessors setProcessors} method. */ diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java @@ -73,7 +73,7 @@ * * For each method, exceptions are handled as follows: *

      - *
    • Checked exceptions are left alone and propagate upwards in the + *
    • Checked exceptions are left alone to propagate upwards in the * obvious way, since they are an expected aspect of the method's * specification. *
    • Unchecked exceptions which have already been caught and wrapped in diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java @@ -112,7 +112,7 @@ /** Result of method attribution. */ Type result; - /** Cache for argument types; behavior is influences by the currently selected cache policy. */ + /** Cache for argument types; behavior is influenced by the currently selected cache policy. */ Map> argumentTypeCache = new LinkedHashMap<>(); public static ArgumentAttr instance(Context context) { diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java @@ -1952,7 +1952,7 @@ * @param t1 The first type. * @param t2 The second type. * @param site The most derived type. - * @returns symbol from t2 that conflicts with one in t1. + * @return symbol from t2 that conflicts with one in t1. */ private Symbol firstIncompatibility(DiagnosticPosition pos, Type t1, Type t2, Type site) { Map interfaces1 = new HashMap<>(); @@ -1982,7 +1982,7 @@ } } - /** Compute all the supertypes of t, indexed by type symbol (except this in typesSkip). */ + /** Compute all the supertypes of t, indexed by type symbol (except those in typesSkip). */ private void closure(Type t, Map typesSkip, Map typeMap) { if (!t.hasTag(CLASS)) return; if (typesSkip.get(t.tsym) != null) return; diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java @@ -381,7 +381,7 @@ //translate lambda body //As the lambda body is translated, all references to lambda locals, //captured variables, enclosing members are adjusted accordingly - //to refer to the static method parameters (rather than i.e. accessing to + //to refer to the static method parameters (rather than i.e. accessing //captured members directly). lambdaDecl.body = translate(makeLambdaBody(tree, lambdaDecl)); diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java @@ -52,7 +52,7 @@ /** * A rich diagnostic formatter is a formatter that provides better integration * with javac's type system. A diagnostic is first preprocessed in order to keep - * track of each types/symbols in it; after these information is collected, + * track of each types/symbols in it; after this information is collected, * the diagnostic is rendered using a standard formatter, whose type/symbol printer * has been replaced by a more refined version provided by this rich formatter. * The rich formatter currently enables three different features: (i) simple class diff --git a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java --- a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java @@ -227,7 +227,7 @@ existing = currentModule.lookupSource(file.toString()); if (existing != null) { - // Oops, the source is already added, could be ok, could be not, lets check. + // Oops, the source is already added, could be ok, could be not, let's check. if (inLinksrc) { // So we are collecting sources for linking only. if (existing.isLinkedOnly()) { > On 20/12/2019 15:44, Pavel Rappo wrote: >> Hello, >> >> Please review the following change for https://bugs.openjdk.java.net/browse/JDK-8236435: >> >> http://cr.openjdk.java.net/~prappo/8236435/webrev.00/ >> >> I've been reading up on the javadoc code and comments. At one point, jumping >> through the links, I reached the javax.tools.DocumentationTool and >> com.sun.tools.javac.util.ClientCodeException, which reside in java.compiler and >> jdk.compiler respectively. I found a couple of typos there and fixed them. >> >> One thing led to another and half an hour later I found myself compulsively >> checking the full javac code base for typos and spelling. Sigh. >> >> Long story short, I just went ahead and fixed as many issues as I could in one >> sitting. There was a lot. >> >> On the bright side, this patch doesn't involve any code changes (except for >> spelling in internal variables and methods' parameters), addresses aesthetic >> issues, readability, helps with searches and assists IDEs to pick up usages >> more reliably when refactoring (e.g. renaming). >> >> The initial concern with DocumentationTool turned out to be more subtle and I >> decided not to include it in this patch. It is definitely not just a typo and >> might require a CSR. >> >> Please review at your convenience. Hopefully, if there are false positives, >> you'll catch them. >> >> I suggest reviewing this change using a diff tool with a character-level >> resolution. That is, a tool capable of highlighting mismatching characters in >> lines that differ. >> >> All test/langtools tests pass. Copyright years will be fixed before the push. >> >> Thanks, >> -Pavel >> From jonathan.gibbons at oracle.com Sat Dec 21 00:16:19 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 Dec 2019 16:16:19 -0800 Subject: RFR [15] 8236435: Fix typos in javac area In-Reply-To: References: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> <47516039-ff1e-4511-c6e3-92df66433138@oracle.com> Message-ID: <67221905-adce-7b02-c298-4ae95afe4d6c@oracle.com> On 12/20/19 4:13 PM, Pavel Rappo wrote: >> * LambdaToMethod: " (rather than i.e. accessing to captured members" - I think we can drop the "to" > Fixed. Separately, I was wondering if "i.e." should've been "e.g." in the first > place. It's a dangerous territory, where the semantics could be easily changed. > To answer this, try translating "i.e." to "that is" and "e.g." to "for example" to see which works best. Better still, use the English forms and not the Latin abbreviations ;-) -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sun Dec 22 12:04:20 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 22 Dec 2019 13:04:20 +0100 Subject: Specification amendment (was: JDK-8219318 (???): inferred type does not conform to ...) In-Reply-To: References: <3256d084-626f-9737-3016-29ab289d06fd@oracle.com> <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> <70634e83-a9da-9138-2c96-807a885479f8@oracle.com> Message-ID: Thanks for the confirmation, Maurizio. It may be that I would like to write a draft for this amendment to the JLS for submission to our spec experts. Should I then post it to this mailing-list, file a CSR with the draft inlined or do anything else? Bernard On Thu, 19 Dec 2019 at 16:37, Maurizio Cimadamore wrote: > > > > The problem is that when inferring 'n(m())' the bounds 'X <: I(W), > > I(Integer)' implies 'W=Integer' per ?18.3.1 but with 'o(m())' the > > bounds 'X <: I(W), I(? extends Integer)' should probably imply 'W <: > > Integer' instead of inferring 'W=Object'. > > > > So, I did a voodoo cult devoted to inference which ended up with some > > black magic on our good old friend 'Types::isSameType', see below. > > > > While this experiment is somewhat incomplete, both examples 'putAll()' > > and 'o(m())' are now working without any 'langtools:tier1' failure. > > > > What do you think? > > This extension is, more or less, what I was expecting/suggesting - but I > think this is more of a question for our spec experts (there might be > subtle reasons as to why this wasn't done already). > > Maurizio > > > Bernard From maurizio.cimadamore at oracle.com Sun Dec 22 21:12:58 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sun, 22 Dec 2019 21:12:58 +0000 Subject: RFR [15] 8236435: Fix typos in javac area In-Reply-To: References: <26572007-A4D1-4230-ACAE-8ECAE2F5FE86@oracle.com> <47516039-ff1e-4511-c6e3-92df66433138@oracle.com> Message-ID: <455fb1b7-1f79-b0ab-c327-52f522a36e54@oracle.com> Incremental patch looks good Thanks Maurizio On 21/12/2019 00:13, Pavel Rappo wrote: > Maurizio, > >> On 20 Dec 2019, at 21:35, Maurizio Cimadamore wrote: >> >> * ClientCodeWrapper: should "propagate upwards" be replaced with "propagated upwards" ? Or perhaps we should use consistent wording with the phrase below "... are left alone to continue propagating upwards." > Would the following be more appropriate? > > *
    • Checked exceptions are left alone to propagate upwards in the > >> * ArgumentAttr: "behavior is influences by the currently selected cache policy." --> s/influences/influenced > Fixed. (Jon also caught that one.) > >> * Check.java: "(except this in typesSkip)" -> s/this/those > Fixed. > >> * LambdaToMethod: " (rather than i.e. accessing to captured members" - I think we can drop the "to" > Fixed. Separately, I was wondering if "i.e." should've been "e.g." in the first > place. It's a dangerous territory, where the semantics could be easily changed. > >> * Modules: "not the entire provides tree" - should "provides" be in a code block? > Hm... I'm not sure I'm following, this is a simple code comment, > not the javadoc comment. > >> * RichDiagnosticFormatter: "after these information is collected" --> s/these/this > Thanks. I found that one too right after I have posted the RFR. > > > Below is the incremental (inline) patch, addressing comments made by yourself > and Jon, with a couple of extra fixes. > > Please note, that update also removes a part in DocumentationTool I was talking > about, that unfortunately slipped through into the first RFR: > > diff --git a/src/java.compiler/share/classes/javax/tools/DocumentationTool.java b/src/java.compiler/share/classes/javax/tools/DocumentationTool.java > --- a/src/java.compiler/share/classes/javax/tools/DocumentationTool.java > +++ b/src/java.compiler/share/classes/javax/tools/DocumentationTool.java > @@ -113,8 +113,9 @@ > Charset charset); > > /** > - * Interface representing a future for a documentation task. > - * To start the task, call the {@linkplain #call call} method. > + * Interface representing a future for a documentation task. The > + * task has not yet started. To start the task, call > + * the {@linkplain #call call} method. > * > *

      Before calling the {@code call} method, additional aspects of the > * task can be configured, for example, by calling the > diff --git a/src/java.compiler/share/classes/javax/tools/JavaCompiler.java b/src/java.compiler/share/classes/javax/tools/JavaCompiler.java > --- a/src/java.compiler/share/classes/javax/tools/JavaCompiler.java > +++ b/src/java.compiler/share/classes/javax/tools/JavaCompiler.java > @@ -290,7 +290,7 @@ > * compilation task has not yet started. To start the task, call > * the {@linkplain #call call} method. > * > - *

      Before calling the call method, additional aspects of the > + *

      Before calling the {@code call} method, additional aspects of the > * task can be configured, for example, by calling the > * {@linkplain #setProcessors setProcessors} method. > */ > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java > @@ -73,7 +73,7 @@ > * > * For each method, exceptions are handled as follows: > *

        > - *
      • Checked exceptions are left alone and propagate upwards in the > + *
      • Checked exceptions are left alone to propagate upwards in the > * obvious way, since they are an expected aspect of the method's > * specification. > *
      • Unchecked exceptions which have already been caught and wrapped in > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java > @@ -112,7 +112,7 @@ > /** Result of method attribution. */ > Type result; > > - /** Cache for argument types; behavior is influences by the currently selected cache policy. */ > + /** Cache for argument types; behavior is influenced by the currently selected cache policy. */ > Map> argumentTypeCache = new LinkedHashMap<>(); > > public static ArgumentAttr instance(Context context) { > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java > @@ -1952,7 +1952,7 @@ > * @param t1 The first type. > * @param t2 The second type. > * @param site The most derived type. > - * @returns symbol from t2 that conflicts with one in t1. > + * @return symbol from t2 that conflicts with one in t1. > */ > private Symbol firstIncompatibility(DiagnosticPosition pos, Type t1, Type t2, Type site) { > Map interfaces1 = new HashMap<>(); > @@ -1982,7 +1982,7 @@ > } > } > > - /** Compute all the supertypes of t, indexed by type symbol (except this in typesSkip). */ > + /** Compute all the supertypes of t, indexed by type symbol (except those in typesSkip). */ > private void closure(Type t, Map typesSkip, Map typeMap) { > if (!t.hasTag(CLASS)) return; > if (typesSkip.get(t.tsym) != null) return; > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > @@ -381,7 +381,7 @@ > //translate lambda body > //As the lambda body is translated, all references to lambda locals, > //captured variables, enclosing members are adjusted accordingly > - //to refer to the static method parameters (rather than i.e. accessing to > + //to refer to the static method parameters (rather than i.e. accessing > //captured members directly). > lambdaDecl.body = translate(makeLambdaBody(tree, lambdaDecl)); > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java > @@ -52,7 +52,7 @@ > /** > * A rich diagnostic formatter is a formatter that provides better integration > * with javac's type system. A diagnostic is first preprocessed in order to keep > - * track of each types/symbols in it; after these information is collected, > + * track of each types/symbols in it; after this information is collected, > * the diagnostic is rendered using a standard formatter, whose type/symbol printer > * has been replaced by a more refined version provided by this rich formatter. > * The rich formatter currently enables three different features: (i) simple class > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java > @@ -227,7 +227,7 @@ > existing = currentModule.lookupSource(file.toString()); > if (existing != null) { > > - // Oops, the source is already added, could be ok, could be not, lets check. > + // Oops, the source is already added, could be ok, could be not, let's check. > if (inLinksrc) { > // So we are collecting sources for linking only. > if (existing.isLinkedOnly()) { > >> On 20/12/2019 15:44, Pavel Rappo wrote: >>> Hello, >>> >>> Please review the following change for https://bugs.openjdk.java.net/browse/JDK-8236435: >>> >>> http://cr.openjdk.java.net/~prappo/8236435/webrev.00/ >>> >>> I've been reading up on the javadoc code and comments. At one point, jumping >>> through the links, I reached the javax.tools.DocumentationTool and >>> com.sun.tools.javac.util.ClientCodeException, which reside in java.compiler and >>> jdk.compiler respectively. I found a couple of typos there and fixed them. >>> >>> One thing led to another and half an hour later I found myself compulsively >>> checking the full javac code base for typos and spelling. Sigh. >>> >>> Long story short, I just went ahead and fixed as many issues as I could in one >>> sitting. There was a lot. >>> >>> On the bright side, this patch doesn't involve any code changes (except for >>> spelling in internal variables and methods' parameters), addresses aesthetic >>> issues, readability, helps with searches and assists IDEs to pick up usages >>> more reliably when refactoring (e.g. renaming). >>> >>> The initial concern with DocumentationTool turned out to be more subtle and I >>> decided not to include it in this patch. It is definitely not just a typo and >>> might require a CSR. >>> >>> Please review at your convenience. Hopefully, if there are false positives, >>> you'll catch them. >>> >>> I suggest reviewing this change using a diff tool with a character-level >>> resolution. That is, a tool capable of highlighting mismatching characters in >>> lines that differ. >>> >>> All test/langtools tests pass. Copyright years will be fixed before the push. >>> >>> Thanks, >>> -Pavel >>> From maurizio.cimadamore at oracle.com Sun Dec 22 21:14:27 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sun, 22 Dec 2019 21:14:27 +0000 Subject: Specification amendment In-Reply-To: References: <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> <70634e83-a9da-9138-2c96-807a885479f8@oracle.com> Message-ID: <38a60634-d79b-9b99-9a50-7e090f64e340@oracle.com> There's plenty of discussion and contents in this thread. We already have a spec bug to track this - let's link the bug to this discussion, and I'm sure Dan will look at it when he has some cycles. Maurizio On 22/12/2019 12:04, B. Blaser wrote: > Thanks for the confirmation, Maurizio. > > It may be that I would like to write a draft for this amendment to the > JLS for submission to our spec experts. > Should I then post it to this mailing-list, file a CSR with the draft > inlined or do anything else? > > Bernard > > On Thu, 19 Dec 2019 at 16:37, Maurizio Cimadamore > wrote: >> >>> The problem is that when inferring 'n(m())' the bounds 'X <: I(W), >>> I(Integer)' implies 'W=Integer' per ?18.3.1 but with 'o(m())' the >>> bounds 'X <: I(W), I(? extends Integer)' should probably imply 'W <: >>> Integer' instead of inferring 'W=Object'. >>> >>> So, I did a voodoo cult devoted to inference which ended up with some >>> black magic on our good old friend 'Types::isSameType', see below. >>> >>> While this experiment is somewhat incomplete, both examples 'putAll()' >>> and 'o(m())' are now working without any 'langtools:tier1' failure. >>> >>> What do you think? >> This extension is, more or less, what I was expecting/suggesting - but I >> think this is more of a question for our spec experts (there might be >> subtle reasons as to why this wasn't done already). >> >> Maurizio >> >>> Bernard From jonathan.gibbons at oracle.com Sun Dec 22 22:25:47 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 22 Dec 2019 14:25:47 -0800 Subject: Fwd: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> Message-ID: <805b4bf4-a6e1-d272-fe43-a559d7cd8274@oracle.com> Sergey has posted the following review, which includes changes to jdk.compiler files, to a variety of lists, but not compiler-dev. Rather than replicate the review thread on yet another list, I suggest that anyone who is interested should comment on one of the lists to which the request has already been posted. -- Jon -------- Forwarded Message -------- Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 Date: Sun, 22 Dec 2019 23:24:09 +0300 From: Sergey Bylokhov To: awt-dev at openjdk.java.net , build-dev , hotspot-dev developers , core-libs-dev , swing-dev at openjdk.java.net Hello. Please review the fix for JDK 15. Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 I have updated the source code copyrights by the "update_copyright_year.sh" script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 because of: "JDK-8187443: Forest Consolidation: Move files to unified layout" which touched all files. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Dec 24 18:22:15 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Dec 2019 21:22:15 +0300 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> Message-ID: <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com> Hello. Here is an updated version: Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/ - "jdk.internal.vm.compiler" is removed from the patch. - "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018" On 12/22/19 11:24 pm, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 15. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 > Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch > Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 > > I have updated the source code copyrights by the "update_copyright_year.sh" > script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 > because of: "JDK-8187443: Forest Consolidation: Move files to unified layout" > which touched all files. > > -- Best regards, Sergey. From wdietl at gmail.com Wed Dec 25 15:18:31 2019 From: wdietl at gmail.com (Werner Dietl) Date: Wed, 25 Dec 2019 10:18:31 -0500 Subject: Annotations on record declarations Message-ID: Gavin, all, following-up on https://mail.openjdk.java.net/pipermail/compiler-dev/2019-November/013939.html. Section 9.7.4 http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191121/specs/records-jls.html#jls-9.7.4 states: "or an annotation that applies to a class, interface, enum, record, annotation type" Should the description of ElementType.TYPE at http://hg.openjdk.java.net/jdk/jdk/file/bb0a7975b31d/src/java.base/share/classes/java/lang/annotation/ElementType.java#l74 be changed from "/** Class, interface (including annotation type), or enum declaration */" to "/** Class, interface (including annotation type), enum, or record declaration */" or something like that? Thanks, cu, WMD. -- https://ece.uwaterloo.ca/~wdietl/ From bsrbnd at gmail.com Fri Dec 27 15:41:28 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 27 Dec 2019 16:41:28 +0100 Subject: Specification amendment In-Reply-To: <38a60634-d79b-9b99-9a50-7e090f64e340@oracle.com> References: <3c44d1fa-76dd-e93d-edfc-52ee2773be6d@oracle.com> <43d4201a-172e-e48a-0c77-3522d426b380@oracle.com> <26c6397f-31e6-d3be-ba1c-b67b4ae817a0@oracle.com> <66ee6847-4a47-935d-8419-29f0af41bb9c@oracle.com> <4d447397-18f6-9c75-a7db-0909e34fcc26@oracle.com> <70634e83-a9da-9138-2c96-807a885479f8@oracle.com> <38a60634-d79b-9b99-9a50-7e090f64e340@oracle.com> Message-ID: All right, no problem (this was mostly a suggestion and I'm rather busy too). Note that currently the same example involving capture conversion works perfectly: class Test4 { interface I {} > X m() { return null; } void n(I p) {} void o(I p) {} void run() { Test4 that = null; n(m()); that.o(m()); } } Ciao, Bernard On Sun, 22 Dec 2019 at 22:14, Maurizio Cimadamore wrote: > > There's plenty of discussion and contents in this thread. We already > have a spec bug to track this - let's link the bug to this discussion, > and I'm sure Dan will look at it when he has some cycles. > > Maurizio > > On 22/12/2019 12:04, B. Blaser wrote: > > Thanks for the confirmation, Maurizio. > > > > It may be that I would like to write a draft for this amendment to the > > JLS for submission to our spec experts. > > Should I then post it to this mailing-list, file a CSR with the draft > > inlined or do anything else? > > > > Bernard > > > > On Thu, 19 Dec 2019 at 16:37, Maurizio Cimadamore > > wrote: > >> > >>> The problem is that when inferring 'n(m())' the bounds 'X <: I(W), > >>> I(Integer)' implies 'W=Integer' per ?18.3.1 but with 'o(m())' the > >>> bounds 'X <: I(W), I(? extends Integer)' should probably imply 'W <: > >>> Integer' instead of inferring 'W=Object'. > >>> > >>> So, I did a voodoo cult devoted to inference which ended up with some > >>> black magic on our good old friend 'Types::isSameType', see below. > >>> > >>> While this experiment is somewhat incomplete, both examples 'putAll()' > >>> and 'o(m())' are now working without any 'langtools:tier1' failure. > >>> > >>> What do you think? > >> This extension is, more or less, what I was expecting/suggesting - but I > >> think this is more of a question for our spec experts (there might be > >> subtle reasons as to why this wasn't done already). > >> > >> Maurizio > >> > >>> Bernard