From bsrbnd at gmail.com Fri Jun 1 08:24:58 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 1 Jun 2018 10:24:58 +0200 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> References: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> Message-ID: Hi Vicente, On 23 February 2018 at 22:24, Vicente Romero wrote: > Hi Bernard, > > Usually when we touch this area of the compiler we do the following test: > build the whole JDK, another big corpus could make it too, with and without > the fix applied and then we compare the class files obtained, if no new tag > classes are generated for cases where they shouldn't and if there are no > unjustified changes to the rest of the classes, then we are more confident > about the fix. > > Thanks, > Vicente So, using the fix I provided in [1] I did the following tests: Without patch: $ make clean $ make images $ find ./build/linux-x86_64-normal-server-release/jdk/modules/ -name "*.class" -print | sort > ../modules-clean-classes.txt With patch: $ make clean $ make images $ find ./build/linux-x86_64-normal-server-release/jdk/modules/ -name "*.class" -print | sort > ../modules-patch-classes.txt Tier1 (did anybody also encounter the OutOfMemoryError I announced in [2]?): $ make run-test-tier1 No new tags ? $ diff ../modules-clean-classes.txt ../modules-patch-classes.txt Tier1 is OK and no new tags are generated. Does this look solid enough? Thanks, Bernard [1] https://bugs.openjdk.java.net/secure/attachment/75380/jdk8189335.patch [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011953.html From Pietro.Paolini at alfasystems.com Fri Jun 1 08:29:19 2018 From: Pietro.Paolini at alfasystems.com (Pietro Paolini) Date: Fri, 1 Jun 2018 08:29:19 +0000 Subject: Warn when certain constructor is used In-Reply-To: <29992f5c-0251-3866-2b1c-8c7ee40bf46d@oracle.com> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BBC65@GBEDBP01.chp.co.uk> <29992f5c-0251-3866-2b1c-8c7ee40bf46d@oracle.com> Message-ID: <5D285FC05679A441ACF34A90905BFA922F9BC035@GBEDBP01.chp.co.uk> >(4) > obtain the TreePath for the node (by passing compilation unit and tree), > and then (5) you call getElement on that path. I am probably getting lost here, @Override public Object visitNewClass(NewClassTree newClassTree, Object o) { TreePath treePath = trees.getPath(compilationUnitTree, newClassTree); .... } The TreePath class does provide a getElement() method. From the element somehow I could get to the symbol signature which is exactly what I need, I don't quite know how though. Would you recommend any good source of reliable information on how the compiler organizes the AST and what are the key data structures involved ? I find myself asking you basically everything as - even though I have some familiarity with compiler concepts such as AST, reduce, grammar etc etc - I have a poor knowledge on the javac specific aspects. > -----Original Message----- > From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > Sent: 01 June 2018 00:02 > To: Pietro Paolini > Cc: compiler-dev at openjdk.java.net > Subject: Re: Warn when certain constructor is used > > You can get a treepath from an element here: > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > il/Trees.html#getPath(javax.lang.model.element.Element) > > And from the TreePath you obtain there, you can get a compilation unit: > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > il/TreePath.html#getCompilationUnit() > > Once you have this ingredient, you can finally obtain a path for any > tree you'd like: > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > il/Trees.html#getPath(com.sun.source.tree.CompilationUnitTree,%20com.sun. > source.tree.Tree) > > > So, I suggest you (1) obtain the TreePath form one of your root elements > (2) extract the compilation unit from one of these path and stash it > somewhere (3) when you reach the node you want (visitNewClass), you (4) > obtain the TreePath for the node (by passing compilation unit and tree), > and then (5) you call getElement on that path. > > Maurizio > > On 31/05/18 22:25, Pietro Paolini wrote: > >> > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > >> il/Trees.html#getElement(com.sun.source.util.TreePath) > > On what kind of object ? > > > > if (!roundEnv.processingOver()) { > > Set elements = roundEnv.getRootElements(); > > for (Element element : elements) { > > if (element.getKind() == ElementKind.CLASS) { > > JCTree tree = (JCTree) trees.getTree(element).accept(new > LocalDateUtilDate(), null); > > } > > > > System.out.println(element); > > } > > } > > > > I haven't met any "TreePath" as yet. > > > >> -----Original Message----- > >> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > >> Sent: 31 May 2018 15:45 > >> To: Pietro Paolini > >> Cc: compiler-dev at openjdk.java.net > >> Subject: Re: Warn when certain constructor is used > >> > >> Try to call > >> > >> > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > >> il/Trees.html#getElement(com.sun.source.util.TreePath) > >> > >> This should trigger attribution of the tree and give you the 'symbol' > >> associated with the constructor. From there you can access the symbol > >> signature using > >> > >> > https://docs.oracle.com/javase/7/docs/api/javax/lang/model/element/Eleme > >> nt.html#asType() > >> > >> And downcasting to this: > >> > >> > https://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/Executable > >> Type.html > >> > >> If this works, good, otherwise the solution would be more cumbersome - > >> and it will involve setting up a task listener. But try this first. > >> > >> Maurizio > >> > >> > >> On 31/05/18 13:19, Pietro Paolini wrote: > >>> Hi Maurizio, > >>> > >>> Thanks a lot. I would have an additional, and hopefully last, question. > >>> > >>> I am getting the NewClassTree which seems to provide me access to the - > >> forgive me the coarse wording of it - the "token", namely the textual > >> representation > >>> of it, while I am mainly interested in the type. > >>> > >>> I am getting around it by comparing strings but I wonder if there is any > way > >> to get to the type of the expression : > >>> := new identifier ( arguments ) > >>> > >>> What I have in my mind is to detect all instances in which the identifier > has > >> *type* A and the argument's list is composed by a single *type* , let say B. > >> That allows me to > >>> print something: > >>> > >>> "Hey, constructor new A(B) has been detected" > >>> > >>> Thanks a lot for your help so far, really. > >>> > >>> Thanks, > >>> P. > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > >>>> Sent: 31 May 2018 12:45 > >>>> To: Pietro Paolini > >>>> Cc: compiler-dev at openjdk.java.net > >>>> Subject: Re: Warn when certain constructor is used > >>>> > >>>> > >>>> > >>>> On 31/05/18 12:21, Pietro Paolini wrote: > >>>>> JCTree tree = (JCTree) trees.getTree(element); > >>>>> tree.accept(new LocalDateUtilDate()); > >>>> There re two visitor methods in JCTree, one internal (used by javac), > >>>> one external (used by the API). I don't think you need to cast down to > >>>> JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and > >>>> you will see that the only 'accept' method there takes two arguments: a > >>>> visitor (which you have) and a visitor parameter; since you don't seem > >>>> to need a visitor parameter, you can just pass 'null' as second > parameter. > >>>> > >>>> Maurizio From Pietro.Paolini at alfasystems.com Fri Jun 1 10:31:01 2018 From: Pietro.Paolini at alfasystems.com (Pietro Paolini) Date: Fri, 1 Jun 2018 10:31:01 +0000 Subject: Warn when certain constructor is used In-Reply-To: <2029690261.1796343.1527769127501.JavaMail.zimbra@u-pem.fr> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <2029690261.1796343.1527769127501.JavaMail.zimbra@u-pem.fr> Message-ID: <5D285FC05679A441ACF34A90905BFA922F9BC0B7@GBEDBP01.chp.co.uk> Hi, Thank you very much for the answer, there are probably other ways but, as I am confined in the Java language domain going down to the "javac" path is something that will work and which I don?t dislike as I see it as a long term investment. Moreover I've spent on it some time and I've gone past the non-come-back point :-) Cheers, P. > -----Original Message----- > From: Remi Forax [mailto:forax at univ-mlv.fr] > Sent: 31 May 2018 13:19 > To: Pietro Paolini > Cc: compiler-dev > Subject: Re: Warn when certain constructor is used > > Hi Pietro, > detecting usages of certain API entrypoints is usually done on the bytecode > instead of on the source code in the Java world, it's usually easier because the > bytecode is more stable than the source code and it has also the advantage > to work not only with Java the language but also in Scala, Groovy, Kotlin, etc. > > You can use ASM [1] for that, here is an example [2] from stackoverflow. > > cheers, > R?mi > > [1] http://asm.ow2.io/ > [2] https://stackoverflow.com/questions/930289/how-can-i-find-all-the- > methods-that-call-a-given-method-in-java#931410 > > > ----- Mail original ----- > > De: "Pietro Paolini" > > ?: "compiler-dev" > > Envoy?: Jeudi 31 Mai 2018 11:05:20 > > Objet: Warn when certain constructor is used > > > Hi all, > > > > I am not sure the question is appropriate for compiler-dev but I would like > to > > give it a try anyway. > > > > I would like to detect when a certain class's constructor is used and log its > > usage along with filename and line number somewhere, such as a log file or > > standard output, I can't use an IDE to do that as I am working on a fairly > > large codebase and I need to automate the process, moreover it seems like > an > > interesting problem to solve. > > > > https://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html > > > > I was hoping that could help me but I haven't spot anything as yet, even > though > > I must admit that my knowledge on the matter is limited. > > > > Thanks, > > Pietro > > > > > > Pietro Paolini > > Consultant > > > > Alfa > > ________________________________ > > e: pietro.paolini at alfasystems.com | w: > > alfasystems.com > > t: +44 (0) 20 7920-2643 | Moor Place, 1 Fore Street Avenue, London, EC2Y > 9DT, GB > > ________________________________ > > > > The contents of this communication are not intended to be binding or > constitute > > any form of offer or acceptance or give rise to any legal obligations on > behalf > > of the sender or Alfa. The views or opinions expressed represent those of > the > > author and not necessarily those of Alfa. This email and any attachments > are > > strictly confidential and are intended solely for use by the individual or > > entity to whom it is addressed. If you are not the addressee (or responsible > > for delivery of the message to the addressee) you may not copy, forward, > > disclose or use any part of the message or its attachments. At present the > > integrity of email across the internet cannot be guaranteed and messages > sent > > via this medium are potentially at risk. All liability is excluded to the > > extent permitted by law for any claims arising as a result of the use of this > > medium to transmit information by or to Alfa or its affiliates. > > > > Alfa Financial Software Ltd > > Reg. in England No: 0248 2325 From maurizio.cimadamore at oracle.com Fri Jun 1 11:25:29 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Jun 2018 12:25:29 +0100 Subject: Warn when certain constructor is used In-Reply-To: <5D285FC05679A441ACF34A90905BFA922F9BC035@GBEDBP01.chp.co.uk> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BBC65@GBEDBP01.chp.co.uk> <29992f5c-0251-3866-2b1c-8c7ee40bf46d@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BC035@GBEDBP01.chp.co.uk> Message-ID: <1d51ec79-98a8-38f4-1b66-223185621619@oracle.com> Another option would be to heavily borrow on some frameworks we already have - e.g. the coding rule one we use for testing quality of langtools code: http://hg.openjdk.java.net/jdk/jdk/file/1d5694c1aa03/test/langtools/tools/all/RunCodingRules.java This runs a series of analyzers, defined here: http://hg.openjdk.java.net/jdk/jdk/file/1d5694c1aa03/make/langtools/tools/crules Of these various analyzers, one looks quite similar to what you want: http://hg.openjdk.java.net/jdk/jdk/file/1d5694c1aa03/make/langtools/tools/crules/AssertCheckAnalyzer.java The only difference is that it looks for the symbol associated with a method call, rather than that associated with a new class tree. So, my suggestion is, maybe you can start by pulling in all that code into a project and then gradually chop it down until it just do whatever it is you need? Regarding javac-specific documentation, you can find some info here: http://openjdk.java.net/groups/compiler/ (see links at the bottom) Hope this helps. Maurizio On 01/06/18 09:29, Pietro Paolini wrote: >> (4) >> obtain the TreePath for the node (by passing compilation unit and tree), >> and then (5) you call getElement on that path. > I am probably getting lost here, > > @Override > public Object visitNewClass(NewClassTree newClassTree, Object o) { > > TreePath treePath = trees.getPath(compilationUnitTree, newClassTree); > > .... > } > > The TreePath class does provide a getElement() method. From the element somehow I could get to the symbol signature which is exactly what I need, I don't quite know how though. > > Would you recommend any good source of reliable information on how the compiler organizes the AST and what are the key data structures involved ? I find myself asking you basically everything as - even though I have some familiarity with compiler concepts such as AST, reduce, grammar etc etc - I have a poor knowledge on the javac specific aspects. > > > >> -----Original Message----- >> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] >> Sent: 01 June 2018 00:02 >> To: Pietro Paolini >> Cc: compiler-dev at openjdk.java.net >> Subject: Re: Warn when certain constructor is used >> >> You can get a treepath from an element here: >> >> https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut >> il/Trees.html#getPath(javax.lang.model.element.Element) >> >> And from the TreePath you obtain there, you can get a compilation unit: >> >> https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut >> il/TreePath.html#getCompilationUnit() >> >> Once you have this ingredient, you can finally obtain a path for any >> tree you'd like: >> >> https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut >> il/Trees.html#getPath(com.sun.source.tree.CompilationUnitTree,%20com.sun. >> source.tree.Tree) >> >> >> So, I suggest you (1) obtain the TreePath form one of your root elements >> (2) extract the compilation unit from one of these path and stash it >> somewhere (3) when you reach the node you want (visitNewClass), you (4) >> obtain the TreePath for the node (by passing compilation unit and tree), >> and then (5) you call getElement on that path. >> >> Maurizio >> >> On 31/05/18 22:25, Pietro Paolini wrote: >> https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut >>>> il/Trees.html#getElement(com.sun.source.util.TreePath) >>> On what kind of object ? >>> >>> if (!roundEnv.processingOver()) { >>> Set elements = roundEnv.getRootElements(); >>> for (Element element : elements) { >>> if (element.getKind() == ElementKind.CLASS) { >>> JCTree tree = (JCTree) trees.getTree(element).accept(new >> LocalDateUtilDate(), null); >>> } >>> >>> System.out.println(element); >>> } >>> } >>> >>> I haven't met any "TreePath" as yet. >>> >>>> -----Original Message----- >>>> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] >>>> Sent: 31 May 2018 15:45 >>>> To: Pietro Paolini >>>> Cc: compiler-dev at openjdk.java.net >>>> Subject: Re: Warn when certain constructor is used >>>> >>>> Try to call >>>> >>>> >> https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut >>>> il/Trees.html#getElement(com.sun.source.util.TreePath) >>>> >>>> This should trigger attribution of the tree and give you the 'symbol' >>>> associated with the constructor. From there you can access the symbol >>>> signature using >>>> >>>> >> https://docs.oracle.com/javase/7/docs/api/javax/lang/model/element/Eleme >>>> nt.html#asType() >>>> >>>> And downcasting to this: >>>> >>>> >> https://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/Executable >>>> Type.html >>>> >>>> If this works, good, otherwise the solution would be more cumbersome - >>>> and it will involve setting up a task listener. But try this first. >>>> >>>> Maurizio >>>> >>>> >>>> On 31/05/18 13:19, Pietro Paolini wrote: >>>>> Hi Maurizio, >>>>> >>>>> Thanks a lot. I would have an additional, and hopefully last, question. >>>>> >>>>> I am getting the NewClassTree which seems to provide me access to the - >>>> forgive me the coarse wording of it - the "token", namely the textual >>>> representation >>>>> of it, while I am mainly interested in the type. >>>>> >>>>> I am getting around it by comparing strings but I wonder if there is any >> way >>>> to get to the type of the expression : >>>>> := new identifier ( arguments ) >>>>> >>>>> What I have in my mind is to detect all instances in which the identifier >> has >>>> *type* A and the argument's list is composed by a single *type* , let say B. >>>> That allows me to >>>>> print something: >>>>> >>>>> "Hey, constructor new A(B) has been detected" >>>>> >>>>> Thanks a lot for your help so far, really. >>>>> >>>>> Thanks, >>>>> P. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] >>>>>> Sent: 31 May 2018 12:45 >>>>>> To: Pietro Paolini >>>>>> Cc: compiler-dev at openjdk.java.net >>>>>> Subject: Re: Warn when certain constructor is used >>>>>> >>>>>> >>>>>> >>>>>> On 31/05/18 12:21, Pietro Paolini wrote: >>>>>>> JCTree tree = (JCTree) trees.getTree(element); >>>>>>> tree.accept(new LocalDateUtilDate()); >>>>>> There re two visitor methods in JCTree, one internal (used by javac), >>>>>> one external (used by the API). I don't think you need to cast down to >>>>>> JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and >>>>>> you will see that the only 'accept' method there takes two arguments: a >>>>>> visitor (which you have) and a visitor parameter; since you don't seem >>>>>> to need a visitor parameter, you can just pass 'null' as second >> parameter. >>>>>> Maurizio From jan.lahoda at oracle.com Fri Jun 1 15:19:08 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 1 Jun 2018 17:19:08 +0200 Subject: RFR: 8198378: javac crash when checking imports and a broken class is present Message-ID: <5B1163EC.2060906@oracle.com> Hi, Consider these two files: ---pkg/Missing.java broken ---Test.java import pkg.Missing; --- Compiled like this: $ javac -sourcepath . -XDdev Test.java This crashes in Check.isCanonical, because in Resolve.loadClass, the BadClassFile exception is rethrown, which in turn will lead to unattributed "pkg.Missing" tree, which will lead to the Check.isCanonical crash. The BadClassFile should be handled on this place (I tried it to do in a way that does not change the printed error). While looking at this, it turned out that in a case like this: ---pkg/Missing.java broken ---Test.java import pkg.*; public class Test { Missing m; } --- When this is compiled, it will lead to an error that does not seem ideal: --- Test.java:3: error: cannot find symbol Missing m; ^ symbol: class Missing location: class Test --- The reason is that the BadClassFile is caught and thrown away in Check.importAccessible. Rethrowing he error, and handling it more appropriately in TypeEnter leads to: --- Test.java:3: error: cannot access Missing Missing m; ^ bad source file: ./pkg/Missing.java file does not contain class pkg.Missing Please remove or make sure it appears in the correct subdirectory of the sourcepath. --- For this, I tried to make the behavior close to the JDK 8 behavior for cases like: import pkg.Class.*; //which (by itself) passed even if there was a broken subclass import static pkg.Class.*; //which caused a compile-time error (This is the purpose of the change in Scope.) Bug: https://bugs.openjdk.java.net/browse/JDK-8198378 Webrev: http://cr.openjdk.java.net/~jlahoda/8198378/webrev.00/ How does this look? Thanks, Jan From forax at univ-mlv.fr Fri Jun 1 20:26:19 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 1 Jun 2018 22:26:19 +0200 (CEST) Subject: JEP 330 In-Reply-To: <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> Message-ID: <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "Remi Forax" > Cc: "cay horstmann" , "compiler-dev" > > Envoy?: Jeudi 31 Mai 2018 22:55:14 > Objet: Re: JEP 330 > On May 31, 2018, at 1:36 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> or just put the jar near the shebang file :) > That raises an interesting question: How does the shebang script refer to a side > file > in the same directory? In /bin/sh we would say something like > "${0%/*}/side.jar". > I suppose there is a JVM property which exposes that command line argument > already; > if not there should be. Then an API like java.nio.file.Path can help find the > side file. Amusingly, it's easier to get a jar from a server somewhere on the planet than to get a jar from the same directory of a script :) > ? John R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jun 1 21:14:54 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 1 Jun 2018 17:14:54 -0400 Subject: RFR: 8198378: javac crash when checking imports and a broken class is present In-Reply-To: <5B1163EC.2060906@oracle.com> References: <5B1163EC.2060906@oracle.com> Message-ID: <45234a00-b6af-5cab-8010-9b6ec95797bc@oracle.com> looks good, Vicente On 06/01/2018 11:19 AM, Jan Lahoda wrote: > Hi, > > Consider these two files: > ---pkg/Missing.java > broken > ---Test.java > import pkg.Missing; > --- > > Compiled like this: > $ javac -sourcepath . -XDdev Test.java > > This crashes in Check.isCanonical, because in Resolve.loadClass, the > BadClassFile exception is rethrown, which in turn will lead to > unattributed "pkg.Missing" tree, which will lead to the > Check.isCanonical crash. The BadClassFile should be handled on this > place (I tried it to do in a way that does not change the printed error). > > While looking at this, it turned out that in a case like this: > ---pkg/Missing.java > broken > ---Test.java > import pkg.*; > public class Test { > ??? Missing m; > } > --- > > When this is compiled, it will lead to an error that does not seem ideal: > --- > Test.java:3: error: cannot find symbol > ??? Missing m; > ??? ^ > ? symbol:?? class Missing > ? location: class Test > --- > > The reason is that the BadClassFile is caught and thrown away in > Check.importAccessible. Rethrowing he error, and handling it more > appropriately in TypeEnter leads to: > --- > Test.java:3: error: cannot access Missing > ??? Missing m; > ??? ^ > ? bad source file: ./pkg/Missing.java > ??? file does not contain class pkg.Missing > ??? Please remove or make sure it appears in the correct subdirectory > of the sourcepath. > --- > > For this, I tried to make the behavior close to the JDK 8 behavior for > cases like: > import pkg.Class.*; //which (by itself) passed even if there was a > broken subclass > import static pkg.Class.*; //which caused a compile-time error > > (This is the purpose of the change in Scope.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198378 > Webrev: http://cr.openjdk.java.net/~jlahoda/8198378/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From cay.horstmann at sjsu.edu Fri Jun 1 22:32:51 2018 From: cay.horstmann at sjsu.edu (Cay Horstmann) Date: Fri, 1 Jun 2018 15:32:51 -0700 Subject: JEP 330 In-Reply-To: <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> Message-ID: <1dd6163b-3e95-a4d3-5a73-4727e10aa3e4@gmail.com> Le 01/06/2018 ? 13:26, forax at univ-mlv.fr a ?crit?: > > > ------------------------------------------------------------------------ > > *De: *"John Rose" > *?: *"Remi Forax" > *Cc: *"cay horstmann" , "compiler-dev" > > *Envoy?: *Jeudi 31 Mai 2018 22:55:14 > *Objet: *Re: JEP 330 > > On May 31, 2018, at 1:36 PM, Remi Forax > wrote: > > > or just put the jar near the shebang file :) > > > That raises an interesting question: ?How does the shebang script > refer to a side file > in the same directory? ?In /bin/sh we would say something like > "${0%/*}/side.jar". > I suppose there is a JVM property which exposes that command line > argument already; > if not there should be. ?Then an API like?java.nio.file.Path can > help find the side file. > > > Amusingly, it's easier to get a jar from a server somewhere on the > planet than to get a jar from the same directory of a script :) > Using a JVM property to load a JAR file would be very awkward--the script author would have to load it manually. And no, there is no JVM property that says where the script is. user.dir is the current working directory, but the script is somewhere on the PATH. You can hardcode the path to a JAR file into the shebang. #!/path/to/java --class-path /path/to/side.jar --source version Not attractive, I know. How are relative paths in --class-path be resolved? Relative to the invoking script or relative to the current working directory? BTW, in Linux, everything after the /path/to/java in a shebang is passed to the interpreter as a single string. Will the java executable parse it correctly? Cheers, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From jonathan.gibbons at oracle.com Fri Jun 1 22:53:16 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 01 Jun 2018 15:53:16 -0700 Subject: JEP 330 In-Reply-To: <1dd6163b-3e95-a4d3-5a73-4727e10aa3e4@gmail.com> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> <1dd6163b-3e95-a4d3-5a73-4727e10aa3e4@gmail.com> Message-ID: <5B11CE5C.8030002@oracle.com> On 06/01/2018 03:32 PM, Cay Horstmann wrote: > > BTW, in Linux, everything after the /path/to/java in a shebang is > passed to the interpreter as a single string. Will the java executable > parse it correctly? Yes. That is taken care of. -- Jon From blackdrag at gmx.org Sat Jun 2 01:35:30 2018 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 2 Jun 2018 03:35:30 +0200 Subject: JEP 330 In-Reply-To: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> Message-ID: <733a0c3d-6359-9ad1-bcf8-d3614769ab5e@gmx.org> Am 31.05.2018 um 15:42 schrieb Remi Forax: [...] > My secret hope is to be able to write gradle scripts in Java. you don't need JEP 330 for that. Gradle supports Kotlin and Groovy, both of them compile first and then execute. I don't know about Kotlin in Gradle, but at least the support for Groovy in Gradle does not work by using the launcher we provide or the shebang mechanism we provide. What you require instead is a DSL for Java. bye Jochen From john.r.rose at oracle.com Sat Jun 2 02:01:09 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 1 Jun 2018 19:01:09 -0700 Subject: JEP 330 In-Reply-To: <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> Message-ID: <6E904055-6398-476B-BD0D-FE0717A9E1EC@oracle.com> On Jun 1, 2018, at 1:26 PM, forax at univ-mlv.fr wrote: > > De: "John Rose" > ?: "Remi Forax" > Cc: "cay horstmann" , "compiler-dev" > Envoy?: Jeudi 31 Mai 2018 22:55:14 > Objet: Re: JEP 330 > On May 31, 2018, at 1:36 PM, Remi Forax > wrote: > > or just put the jar near the shebang file :) > > That raises an interesting question: How does the shebang script refer to a side file > in the same directory? In /bin/sh we would say something like "${0%/*}/side.jar". > I suppose there is a JVM property which exposes that command line argument already; > if not there should be. Then an API like java.nio.file.Path can help find the side file. > > Amusingly, it's easier to get a jar from a server somewhere on the planet than to get a jar from the same directory of a script :) This might work: System.getProperty("sun.java.command") At least, it works today to get the class name. Who knows whether it will also give you the script file name. And note the ominous "sun." prefix. Seems like this use case could use some love. Scripts locating themselves require a little work from the launcher, well repaid by portability (relocatability) of the script. As an idealist, I might want Class.getResourceAsStream to return the contents of a side file to the script file. But it's more likely to return null, given the strategy of compiling the script into a temporary artifact in an undisclosed location. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From blackdrag at gmx.org Sat Jun 2 02:01:59 2018 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 2 Jun 2018 04:01:59 +0200 Subject: JEP 330 In-Reply-To: <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> Message-ID: Am 31.05.2018 um 18:30 schrieb Cay Horstmann: [...] > Suppose I have a Java script that uses JavaMail and I want to give it to > a colleague. Let's assume that the colleague knows how to fetch the > dependencies into the Ivy cache. What would the shebang line look like? > A classpath into ~/.ivy2??? I don't know how to do that cross platform. > > Now THAT would be a great problem to solve in the launcher. Well, for the world before jigsaw: http://docs.groovy-lang.org/latest/html/documentation/grape.html if you do not mind using Groovy (which supports most Java syntax). Groovy also has some shebang support True, it allows you to make a nice jetty example in a program of 18 lines, but still I would be surprised if the OpenJDK wants to copy that. But for us it solves the problem of downloading dependencies (via ivy), making them known to the compiler and then execute the program with a modified classloader. bye Jochen From jonathan.gibbons at oracle.com Sun Jun 3 19:45:32 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 3 Jun 2018 12:45:32 -0700 Subject: JEP 330 In-Reply-To: <6E904055-6398-476B-BD0D-FE0717A9E1EC@oracle.com> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> <6E904055-6398-476B-BD0D-FE0717A9E1EC@oracle.com> Message-ID: On 6/1/18 7:01 PM, John Rose wrote: > On Jun 1, 2018, at 1:26 PM, forax at univ-mlv.fr > wrote: >> >> *De:*"John Rose" > > >> *?:*"Remi Forax" > >> *Cc:*"cay horstmann" > >, "compiler-dev" >> > > >> *Envoy?:*Jeudi 31 Mai 2018 22:55:14 >> *Objet:*Re: JEP 330 >> >> On May 31, 2018, at 1:36 PM, Remi Forax > > wrote: >> >> >> or just put the jar near the shebang file :) >> >> >> That raises an interesting question: ?How does the shebang script >> refer to a side file >> in the same directory? ?In /bin/sh we would say something like >> "${0%/*}/side.jar". >> I suppose there is a JVM property which exposes that command line >> argument already; >> if not there should be. ?Then an API like?java.nio.file.Path can >> help find the side file. >> >> >> Amusingly, it's easier to get a jar from a server somewhere on the >> planet than to get a jar from the same directory of a script :) > > This might work: > > ? System.getProperty("sun.java.command") > > At least, it works today to get the class name. ?Who knows whether > it will also give?you the script file name. ?And note the ominous "sun." > prefix. > > Seems like this use case could use some love. ?Scripts locating > themselves require a little work from the launcher, well repaid > by portability (relocatability) of the script. The property is there, but is currently for internal use, as evidenced by the presence of "internal" in the name.? If we so choose, we could rename and include the property in the specification. > > As an idealist, I might want Class.getResourceAsStream to return > the contents of a side file to the script file. ?But it's more likely to > return null, given the strategy of compiling the script into a temporary > artifact in an undisclosed location. Class.getResourceAsStream will find items on the classpath used by the VM. > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pietro.Paolini at alfasystems.com Mon Jun 4 07:23:00 2018 From: Pietro.Paolini at alfasystems.com (Pietro Paolini) Date: Mon, 4 Jun 2018 07:23:00 +0000 Subject: Warn when certain constructor is used In-Reply-To: <1d51ec79-98a8-38f4-1b66-223185621619@oracle.com> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BBC65@GBEDBP01.chp.co.uk> <29992f5c-0251-3866-2b1c-8c7ee40bf46d@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BC035@GBEDBP01.chp.co.uk> <1d51ec79-98a8-38f4-1b66-223185621619@oracle.com> Message-ID: <5D285FC05679A441ACF34A90905BFA922F9BC6E7@GBEDBP01.chp.co.uk> Hi Maurizio, > Of these various analyzers, one looks quite similar to what you want: > > http://hg.openjdk.java.net/jdk/jdk/file/1d5694c1aa03/make/langtools/tools/c > rules/AssertCheckAnalyzer.java > > The only difference is that it looks for the symbol associated with a > method call, rather than that associated with a new class tree. > > So, my suggestion is, maybe you can start by pulling in all that code > into a project and then gradually chop it down until it just do whatever > it is you need? I've got it done that way, it contained all examples I needed, thanks a lot for your help. P. > > Regarding javac-specific documentation, you can find some info here: > > http://openjdk.java.net/groups/compiler/ > > (see links at the bottom) > > Hope this helps. > > Maurizio > > > > On 01/06/18 09:29, Pietro Paolini wrote: > >> (4) > >> obtain the TreePath for the node (by passing compilation unit and tree), > >> and then (5) you call getElement on that path. > > I am probably getting lost here, > > > > @Override > > public Object visitNewClass(NewClassTree newClassTree, Object o) { > > > > TreePath treePath = trees.getPath(compilationUnitTree, > newClassTree); > > > > .... > > } > > > > The TreePath class does provide a getElement() method. From the element > somehow I could get to the symbol signature which is exactly what I need, I > don't quite know how though. > > > > Would you recommend any good source of reliable information on how the > compiler organizes the AST and what are the key data structures involved ? I > find myself asking you basically everything as - even though I have some > familiarity with compiler concepts such as AST, reduce, grammar etc etc - I > have a poor knowledge on the javac specific aspects. > > > > > > > >> -----Original Message----- > >> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > >> Sent: 01 June 2018 00:02 > >> To: Pietro Paolini > >> Cc: compiler-dev at openjdk.java.net > >> Subject: Re: Warn when certain constructor is used > >> > >> You can get a treepath from an element here: > >> > >> > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > >> il/Trees.html#getPath(javax.lang.model.element.Element) > >> > >> And from the TreePath you obtain there, you can get a compilation unit: > >> > >> > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > >> il/TreePath.html#getCompilationUnit() > >> > >> Once you have this ingredient, you can finally obtain a path for any > >> tree you'd like: > >> > >> > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > >> > il/Trees.html#getPath(com.sun.source.tree.CompilationUnitTree,%20com.sun. > >> source.tree.Tree) > >> > >> > >> So, I suggest you (1) obtain the TreePath form one of your root elements > >> (2) extract the compilation unit from one of these path and stash it > >> somewhere (3) when you reach the node you want (visitNewClass), you (4) > >> obtain the TreePath for the node (by passing compilation unit and tree), > >> and then (5) you call getElement on that path. > >> > >> Maurizio > >> > >> On 31/05/18 22:25, Pietro Paolini wrote: > >> > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > >>>> il/Trees.html#getElement(com.sun.source.util.TreePath) > >>> On what kind of object ? > >>> > >>> if (!roundEnv.processingOver()) { > >>> Set elements = roundEnv.getRootElements(); > >>> for (Element element : elements) { > >>> if (element.getKind() == ElementKind.CLASS) { > >>> JCTree tree = (JCTree) trees.getTree(element).accept(new > >> LocalDateUtilDate(), null); > >>> } > >>> > >>> System.out.println(element); > >>> } > >>> } > >>> > >>> I haven't met any "TreePath" as yet. > >>> > >>>> -----Original Message----- > >>>> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > >>>> Sent: 31 May 2018 15:45 > >>>> To: Pietro Paolini > >>>> Cc: compiler-dev at openjdk.java.net > >>>> Subject: Re: Warn when certain constructor is used > >>>> > >>>> Try to call > >>>> > >>>> > >> > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > >>>> il/Trees.html#getElement(com.sun.source.util.TreePath) > >>>> > >>>> This should trigger attribution of the tree and give you the 'symbol' > >>>> associated with the constructor. From there you can access the symbol > >>>> signature using > >>>> > >>>> > >> > https://docs.oracle.com/javase/7/docs/api/javax/lang/model/element/Eleme > >>>> nt.html#asType() > >>>> > >>>> And downcasting to this: > >>>> > >>>> > >> > https://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/Executable > >>>> Type.html > >>>> > >>>> If this works, good, otherwise the solution would be more cumbersome - > >>>> and it will involve setting up a task listener. But try this first. > >>>> > >>>> Maurizio > >>>> > >>>> > >>>> On 31/05/18 13:19, Pietro Paolini wrote: > >>>>> Hi Maurizio, > >>>>> > >>>>> Thanks a lot. I would have an additional, and hopefully last, question. > >>>>> > >>>>> I am getting the NewClassTree which seems to provide me access to the > - > >>>> forgive me the coarse wording of it - the "token", namely the textual > >>>> representation > >>>>> of it, while I am mainly interested in the type. > >>>>> > >>>>> I am getting around it by comparing strings but I wonder if there is any > >> way > >>>> to get to the type of the expression : > >>>>> := new identifier ( arguments ) > >>>>> > >>>>> What I have in my mind is to detect all instances in which the identifier > >> has > >>>> *type* A and the argument's list is composed by a single *type* , let say > B. > >>>> That allows me to > >>>>> print something: > >>>>> > >>>>> "Hey, constructor new A(B) has been detected" > >>>>> > >>>>> Thanks a lot for your help so far, really. > >>>>> > >>>>> Thanks, > >>>>> P. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Maurizio Cimadamore > [mailto:maurizio.cimadamore at oracle.com] > >>>>>> Sent: 31 May 2018 12:45 > >>>>>> To: Pietro Paolini > >>>>>> Cc: compiler-dev at openjdk.java.net > >>>>>> Subject: Re: Warn when certain constructor is used > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 31/05/18 12:21, Pietro Paolini wrote: > >>>>>>> JCTree tree = (JCTree) trees.getTree(element); > >>>>>>> tree.accept(new LocalDateUtilDate()); > >>>>>> There re two visitor methods in JCTree, one internal (used by javac), > >>>>>> one external (used by the API). I don't think you need to cast down to > >>>>>> JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and > >>>>>> you will see that the only 'accept' method there takes two arguments: > a > >>>>>> visitor (which you have) and a visitor parameter; since you don't seem > >>>>>> to need a visitor parameter, you can just pass 'null' as second > >> parameter. > >>>>>> Maurizio From bsrbnd at gmail.com Mon Jun 4 12:16:04 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 4 Jun 2018 14:16:04 +0200 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: References: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> Message-ID: On 1 June 2018 at 10:24, B. Blaser wrote: > Hi Vicente, > > On 23 February 2018 at 22:24, Vicente Romero wrote: >> Hi Bernard, >> >> Usually when we touch this area of the compiler we do the following test: >> build the whole JDK, another big corpus could make it too, with and without >> the fix applied and then we compare the class files obtained, if no new tag >> classes are generated for cases where they shouldn't and if there are no >> unjustified changes to the rest of the classes, then we are more confident >> about the fix. >> >> Thanks, >> Vicente > > So, using the fix I provided in [1] I did the following tests: > > Without patch: > > $ make clean > $ make images > $ find ./build/linux-x86_64-normal-server-release/jdk/modules/ -name > "*.class" -print | sort > ../modules-clean-classes.txt > > With patch: > > $ make clean > $ make images > $ find ./build/linux-x86_64-normal-server-release/jdk/modules/ -name > "*.class" -print | sort > ../modules-patch-classes.txt > > Tier1 (did anybody also encounter the OutOfMemoryError I announced in [2]?): > > $ make run-test-tier1 > > No new tags ? > > $ diff ../modules-clean-classes.txt ../modules-patch-classes.txt > > Tier1 is OK and no new tags are generated. > Does this look solid enough? > > Thanks, > Bernard > > [1] https://bugs.openjdk.java.net/secure/attachment/75380/jdk8189335.patch > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011953.html I also made a class by class comparison which didn't show any difference excepted in 'Lower.class' of course, as next. What do you think? Bernard Without patch: $ make clean $ make images $ cp -r ./build/linux-x86_64-normal-server-release/jdk/modules/ ../clean-modules With patch: $ make clean $ make images $ find ./build/linux-x86_64-normal-server-release/jdk/modules/ -name '*.class' -printf '%P\n' | xargs -I class cmp ../clean-modules/class ./build/linux-x86_64-normal-server-release/jdk/modules/class ../clean-modules/jdk.compiler/com/sun/tools/javac/comp/Lower.class ./build/linux-x86_64-normal-server-release/jdk/modules/jdk.compiler/com/sun/tools/javac/comp/Lower.class differ: byte 10, line 1 From vicente.romero at oracle.com Mon Jun 4 15:07:24 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 4 Jun 2018 11:07:24 -0400 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: References: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> Message-ID: Hi Bernard, Thanks for the additional tests. The patch looks good, I will push it, Vicente On 06/04/2018 08:16 AM, B. Blaser wrote: > On 1 June 2018 at 10:24, B. Blaser wrote: >> Hi Vicente, >> >> On 23 February 2018 at 22:24, Vicente Romero wrote: >>> Hi Bernard, >>> >>> Usually when we touch this area of the compiler we do the following test: >>> build the whole JDK, another big corpus could make it too, with and without >>> the fix applied and then we compare the class files obtained, if no new tag >>> classes are generated for cases where they shouldn't and if there are no >>> unjustified changes to the rest of the classes, then we are more confident >>> about the fix. >>> >>> Thanks, >>> Vicente >> So, using the fix I provided in [1] I did the following tests: >> >> Without patch: >> >> $ make clean >> $ make images >> $ find ./build/linux-x86_64-normal-server-release/jdk/modules/ -name >> "*.class" -print | sort > ../modules-clean-classes.txt >> >> With patch: >> >> $ make clean >> $ make images >> $ find ./build/linux-x86_64-normal-server-release/jdk/modules/ -name >> "*.class" -print | sort > ../modules-patch-classes.txt >> >> Tier1 (did anybody also encounter the OutOfMemoryError I announced in [2]?): >> >> $ make run-test-tier1 >> >> No new tags ? >> >> $ diff ../modules-clean-classes.txt ../modules-patch-classes.txt >> >> Tier1 is OK and no new tags are generated. >> Does this look solid enough? >> >> Thanks, >> Bernard >> >> [1] https://bugs.openjdk.java.net/secure/attachment/75380/jdk8189335.patch >> [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011953.html > I also made a class by class comparison which didn't show any > difference excepted in 'Lower.class' of course, as next. > > What do you think? > Bernard > > Without patch: > > $ make clean > $ make images > $ cp -r ./build/linux-x86_64-normal-server-release/jdk/modules/ ../clean-modules > > With patch: > > $ make clean > $ make images > $ find ./build/linux-x86_64-normal-server-release/jdk/modules/ -name > '*.class' -printf '%P\n' | xargs -I class cmp ../clean-modules/class > ./build/linux-x86_64-normal-server-release/jdk/modules/class > ../clean-modules/jdk.compiler/com/sun/tools/javac/comp/Lower.class > ./build/linux-x86_64-normal-server-release/jdk/modules/jdk.compiler/com/sun/tools/javac/comp/Lower.class > differ: byte 10, line 1 From jonathan.gibbons at oracle.com Mon Jun 4 18:30:56 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 4 Jun 2018 11:30:56 -0700 Subject: RFR: JDK-8200166: Repeating annotations refering to to-be-generated classes don't work. In-Reply-To: <5ABBD106.3050500@oracle.com> References: <5ABBB7C9.5030304@oracle.com> <5ABBD106.3050500@oracle.com> Message-ID: <727cb48e-5148-f81a-de85-388603a22e12@oracle.com> Both variants look good, but 00b looks better. -- Jon On 3/28/18 10:29 AM, Jan Lahoda wrote: > On 28.3.2018 17:49, Jonathan Gibbons wrote: >> It seems surprising that a JCErroneous tree is used in this context. The >> syntax is well-formed; the problem is a semantic one of "name not >> found". >> >> "Expression not allowed"??? would seem to apply to something like >> >> ???? @Annot(System.out) >> >> But >> >> ???? @Annot(DoesNotExist.class) >> >> Should be "Name not found". > > When the parser sees it, it gets parsed OK. But when the annotation is > attributed the missing class is modelled as Attribute.UnresolvedClass > (a subclass of Attribute.Error). > > Then the repeating annotation framework takes this, wraps the > annotation into the container annotation and creates a new AST for the > attributes/compounds, which writes the > Attribute.UnresolvedClass/Attribute.Error as JCErroneous. And when the > new AST is reattributed using Annotate.attributeAnnotationValue, it > will fail on that. > > I guess an alternate fix may be this: > http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00b/ > > Jan > >> >> -- Jon >> >> >> On 3/28/18 8:42 AM, Jan Lahoda wrote: >>> Hi, >>> >>> javac in JDK 10 does not handle properly repeating annotations that >>> contain attributes referring to classes that are generated by an >>> annotation processor. E.g.: >>> --- >>> @Annot(Gen.class) >>> @Annot(Gen.class) >>> public class GeneratedInRepeating { >>> } >>> --- >>> >>> (where "Annot" is a repeating annotation, and "Gen" is a class >>> generated by an annotation processor). This will fail to compile with >>> (please see the bug for a complete example): >>> --- >>> ... error: expression not allowed as annotation value >>> @Annot(Gen.class) >>> --- >>> >>> The annotation processors won't run, so won't have a chance to >>> generate the class. >>> >>> The issue is that Annotate.processRepeatedAnnotations creates a >>> synthetic container annotation for the repeating annotation, >>> constructs an AST for it and tries to attribute it (Annotate lines >>> 821-832). But when the AST is created, as the class in the attribute >>> value is missing, there is an JCErroneous tree generated. And then >>> when Annotate.attributeAnnotationValue checks if the attribute's value >>> is well-formed, it finds the erroneous tree and barks. >>> >>> The code was refactored in JDK-8181464, and was (AFAIK) accepting >>> erroneous trees without producing the error before that. >>> >>> The proposed fix is to ignore the erroneous trees again. If there's an >>> erroneous tree, there should have been an error produced already, so >>> ignoring erroneous trees seems safe. >>> >>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200166 >>> >>> Thanks, >>> ??? Jan >> From victorwssilva at gmail.com Mon Jun 4 22:48:13 2018 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Mon, 4 Jun 2018 19:48:13 -0300 Subject: Compiler bug about string concatenation Message-ID: Hey folks, are you aware of this bug reported on StackOverflow? https://stackoverflow.com/q/50683786/540552 Apparently, JDK 9, 10 and 11 EA have a code duplication bug when handling string concatenation. Victor Williams Stafusa da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Tue Jun 5 08:11:57 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 5 Jun 2018 10:11:57 +0200 Subject: JEP 330 In-Reply-To: References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> <6E904055-6398-476B-BD0D-FE0717A9E1EC@oracle.com> Message-ID: <396fc19a-0872-3c70-a46c-3a2254916ffd@gmail.com> Hi, On 06/03/2018 09:45 PM, Jonathan Gibbons wrote: >> As an idealist, I might want Class.getResourceAsStream to return >> the contents of a side file to the script file. ?But it's more likely to >> return null, given the strategy of compiling the script into a temporary >> artifact in an undisclosed location. > Class.getResourceAsStream will find items on the classpath used by the VM. ...this will find the "content" of items on the classpath. If one wants to find the "location" (i.e. URL) Class.getResource() will return it. But in the context of java launcher executing a "source" file, searching for location of the executing class would return some URL pointing to "memory" where the source was compiled to, wouldn't it? Not something that could be used to locate "side" files - files in the same directory as source/script file. I know that the main purpose of this JEP is to provide a stepping stone for beginners in the Java world. But the experienced will always find it also as a means to write executable scripts in Java. For the later it is important that the feature allows writing scripts that are as portable as possible. I see one obstacle to achieve that. The location of java launcher executable is not standardized across platforms (even UNIX platforms). So hard-coding absolute path in the shebang script is bound to create non portable script. Locating the java launcher using PATH would be much more portable. Java, if installed properly, is usually added to PATH. The standard way to locate script interpreters using PATH is by indirection through /bin/env utility: #!/bin/env java public class Cmd { ??? public static void main(String ...args) { ??? ??? ... ??? } } While this works and passes script arguments to java executable as intended, it does not work when combined with additional options passed to script interpreter (like "--source 11") in the script itself: #!/bin/env java --source 11 public class Cmd { ??? public static void main(String ...args) { ??? ??? ... ??? } } At least on Linux, env tries to locate executable called "java --source 11" on the PATH and bails out with: /bin/env: ?java --source 11?: No such file or directory So the best bet here is a hybrid script that starts as a bash script which "computes" the environment and paths and then executes java launcher with all required arguments. One way to do that is using "here" documents. Stuart Marks provided an example: #!/bin/bash exec java --source 11 /dev/fd/3 "$@" 3< References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> <1376121378.2413170.1527884779743.JavaMail.zimbra@u-pem.fr> <6E904055-6398-476B-BD0D-FE0717A9E1EC@oracle.com> <396fc19a-0872-3c70-a46c-3a2254916ffd@gmail.com> Message-ID: On 6/5/18 1:11 AM, Peter Levart wrote: > Hi, > > On 06/03/2018 09:45 PM, Jonathan Gibbons wrote: >>> As an idealist, I might want Class.getResourceAsStream to return >>> the contents of a side file to the script file. ?But it's more >>> likely to >>> return null, given the strategy of compiling the script into a >>> temporary >>> artifact in an undisclosed location. >> Class.getResourceAsStream will find items on the classpath used by >> the VM. > > ...this will find the "content" of items on the classpath. If one > wants to find the "location" (i.e. URL) Class.getResource() will > return it. > > But in the context of java launcher executing a "source" file, > searching for location of the executing class would return some URL > pointing to "memory" where the source was compiled to, wouldn't it? > Not something that could be used to locate "side" files - files in the > same directory as source/script file. I was intending to imply that because Class.getResource[AsStream] will find items on the classpath used by the VM, if you set -classpath appropriately you will be able to locate side files that way.? I agree that you will not be able to locate side files relative to the location of the compiled classes. > > I know that the main purpose of this JEP is to provide a stepping > stone for beginners in the Java world. But the experienced will always > find it also as a means to write executable scripts in Java. For the > later it is important that the feature allows writing scripts that are > as portable as possible. I see one obstacle to achieve that. The > location of java launcher executable is not standardized across > platforms (even UNIX platforms). So hard-coding absolute path in the > shebang script is bound to create non portable script. Locating the > java launcher using PATH would be much more portable. Java, if > installed properly, is usually added to PATH. The standard way to > locate script interpreters using PATH is by indirection through > /bin/env utility: > > #!/bin/env java > > public class Cmd { > ??? public static void main(String ...args) { > ??? ??? ... > ??? } > } > > > While this works and passes script arguments to java executable as > intended, it does not work when combined with additional options > passed to script interpreter (like "--source 11") in the script itself: > > #!/bin/env java --source 11 > > public class Cmd { > ??? public static void main(String ...args) { > ??? ??? ... > ??? } > } > > > At least on Linux, env tries to locate executable called "java > --source 11" on the PATH and bails out with: > > /bin/env: ?java --source 11?: No such file or directory Yes, that is a property of the Linux support for shebang files. > > > So the best bet here is a hybrid script that starts as a bash script > which "computes" the environment and paths and then executes java > launcher with all required arguments. One way to do that is using > "here" documents. Stuart Marks provided an example: > > #!/bin/bash > exec java --source 11 /dev/fd/3 "$@" 3< public class Hello { > ??? public static void main(String[] args) { > ??????? String name = System.console().readLine("Please enter your > name: "); > ??????? System.console().printf("Hello, %s!%n", name); > ??? } > } > EOF > > This script uses an OS feature where special file /dev/fd/N when > opened, provides a file handle dup-ed from the file handle N. I don't > know how portable this is across UNIX-es. Linux and Mac at least do > have it and use same paths. What about other UNIX-like OS-es where > OpenJDK is built? If for some OS the feature is not available, then > java launcher could help here by interpreting a special syntax of file > specified as "/dev/fd/N" and executing the necessary dup itself on > such OS. > > > What do you think? I agree that for maximum flexibility and portability, using "here" documents such as you describe is a good way to go, and this is now listed as one of the "Alternatives" in the JEP. However, while it is reasonable to disable the filename check in situations like this, to _allow_ the use of /dev/fd/N where it is available, IMO it would be a step too far to have the Java launcher conditionally _implement_ support for "/dev/fd/N" on platforms that did not otherwise provide it. -- Jon > > Regards, Peter > From brian.goetz at oracle.com Tue Jun 5 18:44:12 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 5 Jun 2018 14:44:12 -0400 Subject: Compiler bug about string concatenation In-Reply-To: References: Message-ID: <26466cab-951d-47de-7921-8d264fe58400@oracle.com> Yes, see: ??? https://bugs.openjdk.java.net/browse/JDK-8204322 On 6/4/2018 6:48 PM, Victor Williams Stafusa da Silva wrote: > Hey folks, are you aware of this bug reported on StackOverflow? > > https://stackoverflow.com/q/50683786/540552 > > Apparently, JDK 9, 10 and 11 EA have a code duplication bug when > handling string concatenation. > > Victor Williams Stafusa da Silva From jan.lahoda at oracle.com Wed Jun 6 12:27:48 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 6 Jun 2018 14:27:48 +0200 Subject: RFR: JDK-8196618: Create API to list supported values for javac --release option Message-ID: <5B17D344.1000603@oracle.com> Hi, This enhancement requests that test need to be able to query the list of supported --release options. This is possible using the JDKPlatformProvider, so I updated two tests where this seemed useful. But while doing this, it turned out the jdeprscan was not yet fully updated to JDK 11 (still refers to java.se.ee and did not list 11 in the help text for the --release option), so I updated that as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8196618 Webrev: http://cr.openjdk.java.net/~jlahoda/8196618/webrev.00/ How does this look? Thanks, Jan From vicente.romero at oracle.com Wed Jun 6 13:23:50 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 6 Jun 2018 09:23:50 -0400 Subject: RFR: 8204322: "+=" applied to String operands can provoke side effects Message-ID: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> Please review the fix for [1] at [2]. Javac was generating incorrect code for the case when the `+=` operand was applied to Strings and it is visible for test cases like: public class Test { ?? static int test() { ?????? System.out.println("evaluated"); ?????? return 0; ?? } ?? public static void main(String[] args) { ?????? String[] array = {""}; ?????? array[test()] += "a"; ?? } } the string "evaluated" is printed twice. Some items were missing in the stack, the solution is to duplicate those missing items plus not to evaluate the lhs expression twice. Thanks in advance for the comments, Vicente Thanks to Aleksey Shipilev for the great regression test. [1] https://bugs.openjdk.java.net/browse/JDK-8204322 [2] http://cr.openjdk.java.net/~vromero/8204322/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jun 6 14:05:51 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 6 Jun 2018 15:05:51 +0100 Subject: RFR: 8204322: "+=" applied to String operands can provoke side effects In-Reply-To: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> References: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> Message-ID: <411d0fe9-a602-cf30-0f28-14c146147524@oracle.com> Looks solid! Thanks for everybody involved in the fix. Cheers Maurizio On 06/06/18 14:23, Vicente Romero wrote: > Please review the fix for [1] at [2]. Javac was generating incorrect > code for the case when the `+=` operand was applied to Strings and it > is visible for test cases like: > > public class Test { > ?? static int test() { > ?????? System.out.println("evaluated"); > ?????? return 0; > ?? } > > ?? public static void main(String[] args) { > ?????? String[] array = {""}; > ?????? array[test()] += "a"; > ?? } > } > > the string "evaluated" is printed twice. Some items were missing in > the stack, the solution is to duplicate those missing items plus not > to evaluate the lhs expression twice. > > Thanks in advance for the comments, > Vicente > > Thanks to Aleksey Shipilev for the great regression test. > > [1] https://bugs.openjdk.java.net/browse/JDK-8204322 > [2] http://cr.openjdk.java.net/~vromero/8204322/webrev.01/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jun 6 14:05:47 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 6 Jun 2018 16:05:47 +0200 Subject: RFR: 8204322: "+=" applied to String operands can provoke side effects In-Reply-To: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> References: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> Message-ID: <5B17EA3B.4040106@oracle.com> Looks good to me. Jan On 6.6.2018 15:23, Vicente Romero wrote: > Please review the fix for [1] at [2]. Javac was generating incorrect > code for the case when the `+=` operand was applied to Strings and it is > visible for test cases like: > > public class Test { > static int test() { > System.out.println("evaluated"); > return 0; > } > > public static void main(String[] args) { > String[] array = {""}; > array[test()] += "a"; > } > } > > the string "evaluated" is printed twice. Some items were missing in the > stack, the solution is to duplicate those missing items plus not to > evaluate the lhs expression twice. > > Thanks in advance for the comments, > Vicente > > Thanks to Aleksey Shipilev for the great regression test. > > [1] https://bugs.openjdk.java.net/browse/JDK-8204322 > [2] http://cr.openjdk.java.net/~vromero/8204322/webrev.01/ > From vicente.romero at oracle.com Wed Jun 6 14:19:36 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 6 Jun 2018 10:19:36 -0400 Subject: RFR: 8204322: "+=" applied to String operands can provoke side effects In-Reply-To: <411d0fe9-a602-cf30-0f28-14c146147524@oracle.com> References: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> <411d0fe9-a602-cf30-0f28-14c146147524@oracle.com> Message-ID: <05f4e3b8-deed-ad5b-16f9-532139c01627@oracle.com> On 06/06/2018 10:05 AM, Maurizio Cimadamore wrote: > > Looks solid! > > Thanks for everybody involved in the fix. > yep, thanks, great teamwork! > Cheers > Maurizio > Vicente > > On 06/06/18 14:23, Vicente Romero wrote: >> Please review the fix for [1] at [2]. Javac was generating incorrect >> code for the case when the `+=` operand was applied to Strings and it >> is visible for test cases like: >> >> public class Test { >> ?? static int test() { >> ?????? System.out.println("evaluated"); >> ?????? return 0; >> ?? } >> >> ?? public static void main(String[] args) { >> ?????? String[] array = {""}; >> ?????? array[test()] += "a"; >> ?? } >> } >> >> the string "evaluated" is printed twice. Some items were missing in >> the stack, the solution is to duplicate those missing items plus not >> to evaluate the lhs expression twice. >> >> Thanks in advance for the comments, >> Vicente >> >> Thanks to Aleksey Shipilev for the great regression test. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8204322 >> [2] http://cr.openjdk.java.net/~vromero/8204322/webrev.01/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Wed Jun 6 15:50:38 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 6 Jun 2018 17:50:38 +0200 Subject: RFR: 8204322: "+=" applied to String operands can provoke side effects In-Reply-To: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> References: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> Message-ID: Hi Vicente, On 6 June 2018 at 15:23, Vicente Romero wrote: > Please review the fix for [1] at [2]. Javac was generating incorrect code > for the case when the `+=` operand was applied to Strings and it is visible > for test cases like: > > public class Test { > static int test() { > System.out.println("evaluated"); > return 0; > } > > public static void main(String[] args) { > String[] array = {""}; > array[test()] += "a"; > } > } > > the string "evaluated" is printed twice. Some items were missing in the > stack, the solution is to duplicate those missing items plus not to evaluate > the lhs expression twice. > > Thanks in advance for the comments, > Vicente > > Thanks to Aleksey Shipilev for the great regression test. > > [1] https://bugs.openjdk.java.net/browse/JDK-8204322 > [2] http://cr.openjdk.java.net/~vromero/8204322/webrev.01/ > I hope I'm not too late, but I was also trying to solve this problem (here under). So, our solutions are quite identical (yours being a bit better), but I think you could avoid 'boolean first' using 'arg == args.head' instead. Cheers, Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java @@ -261,18 +261,18 @@ public Item makeConcat(JCTree.JCAssignOp tree) { List args = collectAll(tree.lhs, tree.rhs); Item l = gen.genExpr(tree.lhs, tree.lhs.type); - emit(args, tree.type, tree.pos()); + emit(l, args, tree.type, tree.pos()); return l; } @Override public Item makeConcat(JCTree.JCBinary tree) { List args = collectAll(tree.lhs, tree.rhs); - emit(args, tree.type, tree.pos()); + emit(null, args, tree.type, tree.pos()); return gen.getItems().makeStackItem(syms.stringType); } - protected abstract void emit(List args, Type type, JCDiagnostic.DiagnosticPosition pos); + protected abstract void emit(Item lhs, List args, Type type, JCDiagnostic.DiagnosticPosition pos); /** Peel the argument list into smaller chunks. */ protected List> split(List args) { @@ -318,7 +318,7 @@ } /** Emit the indy concat for all these arguments, possibly peeling along the way */ - protected void emit(List args, Type type, JCDiagnostic.DiagnosticPosition pos) { + protected void emit(Item lhs, List args, Type type, JCDiagnostic.DiagnosticPosition pos) { List> split = split(args); for (List t : split) { @@ -333,7 +333,13 @@ } else { dynamicArgs.add(sharpestAccessible(arg.type)); } - gen.genExpr(arg, arg.type).load(); + + if (lhs != null && arg == args.head) { + lhs.duplicate(); + lhs.load(); + } + else + gen.genExpr(arg, arg.type).load(); } doCall(type, pos, dynamicArgs.toList()); @@ -402,7 +408,7 @@ } @Override - protected void emit(List args, Type type, JCDiagnostic.DiagnosticPosition pos) { + protected void emit(Item lhs, List args, Type type, JCDiagnostic.DiagnosticPosition pos) { List> split = split(args); for (List t : split) { @@ -433,7 +439,13 @@ // Ordinary arguments come through the dynamic arguments. recipe.append(TAG_ARG); dynamicArgs.add(sharpestAccessible(arg.type)); - gen.genExpr(arg, arg.type).load(); + + if (lhs != null && arg == args.head) { + lhs.duplicate(); + lhs.load(); + } + else + gen.genExpr(arg, arg.type).load(); } } From vicente.romero at oracle.com Wed Jun 6 15:51:38 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 6 Jun 2018 11:51:38 -0400 Subject: Compiler bug about string concatenation In-Reply-To: References: Message-ID: <4e452729-fde8-5dc0-7f48-d62d82aea92f@oracle.com> Hi Victor, We have already fixed it in dev [1] Thanks, Vicente [1] http://hg.openjdk.java.net/jdk/jdk/rev/6659a8f57d78 On 06/04/2018 06:48 PM, Victor Williams Stafusa da Silva wrote: > Hey folks, are you aware of this bug reported on StackOverflow? > > https://stackoverflow.com/q/50683786/540552 > > Apparently, JDK 9, 10 and 11 EA have a code duplication bug when > handling string concatenation. > > Victor Williams Stafusa da Silva From vicente.romero at oracle.com Wed Jun 6 15:55:57 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 6 Jun 2018 11:55:57 -0400 Subject: RFR: 8204322: "+=" applied to String operands can provoke side effects In-Reply-To: References: <92a2bba0-8dc5-7050-7243-4b0fb6306bcd@oracle.com> Message-ID: <024c8ead-bdac-2177-e6ef-c10d260e4e76@oracle.com> Hi, On 06/06/2018 11:50 AM, B. Blaser wrote: > Hi Vicente, > > On 6 June 2018 at 15:23, Vicente Romero wrote: >> Please review the fix for [1] at [2]. Javac was generating incorrect code >> for the case when the `+=` operand was applied to Strings and it is visible >> for test cases like: >> >> public class Test { >> static int test() { >> System.out.println("evaluated"); >> return 0; >> } >> >> public static void main(String[] args) { >> String[] array = {""}; >> array[test()] += "a"; >> } >> } >> >> the string "evaluated" is printed twice. Some items were missing in the >> stack, the solution is to duplicate those missing items plus not to evaluate >> the lhs expression twice. >> >> Thanks in advance for the comments, >> Vicente >> >> Thanks to Aleksey Shipilev for the great regression test. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8204322 >> [2] http://cr.openjdk.java.net/~vromero/8204322/webrev.01/ >> > I hope I'm not too late, but I was also trying to solve this problem > (here under). > So, our solutions are quite identical (yours being a bit better), but > I think you could avoid 'boolean first' using 'arg == args.head' just pushed it a while ago :( but yes I like your suggestion I will leave a note for a future improvement > instead. > > Cheers, > Bernard Thanks, Vicente > > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java > @@ -261,18 +261,18 @@ > public Item makeConcat(JCTree.JCAssignOp tree) { > List args = collectAll(tree.lhs, tree.rhs); > Item l = gen.genExpr(tree.lhs, tree.lhs.type); > - emit(args, tree.type, tree.pos()); > + emit(l, args, tree.type, tree.pos()); > return l; > } > > @Override > public Item makeConcat(JCTree.JCBinary tree) { > List args = collectAll(tree.lhs, tree.rhs); > - emit(args, tree.type, tree.pos()); > + emit(null, args, tree.type, tree.pos()); > return gen.getItems().makeStackItem(syms.stringType); > } > > - protected abstract void emit(List args, Type type, > JCDiagnostic.DiagnosticPosition pos); > + protected abstract void emit(Item lhs, List args, > Type type, JCDiagnostic.DiagnosticPosition pos); > > /** Peel the argument list into smaller chunks. */ > protected List> split(List args) { > @@ -318,7 +318,7 @@ > } > > /** Emit the indy concat for all these arguments, possibly > peeling along the way */ > - protected void emit(List args, Type type, > JCDiagnostic.DiagnosticPosition pos) { > + protected void emit(Item lhs, List args, Type type, > JCDiagnostic.DiagnosticPosition pos) { > List> split = split(args); > > for (List t : split) { > @@ -333,7 +333,13 @@ > } else { > dynamicArgs.add(sharpestAccessible(arg.type)); > } > - gen.genExpr(arg, arg.type).load(); > + > + if (lhs != null && arg == args.head) { > + lhs.duplicate(); > + lhs.load(); > + } > + else > + gen.genExpr(arg, arg.type).load(); > } > > doCall(type, pos, dynamicArgs.toList()); > @@ -402,7 +408,7 @@ > } > > @Override > - protected void emit(List args, Type type, > JCDiagnostic.DiagnosticPosition pos) { > + protected void emit(Item lhs, List args, Type type, > JCDiagnostic.DiagnosticPosition pos) { > List> split = split(args); > > for (List t : split) { > @@ -433,7 +439,13 @@ > // Ordinary arguments come through the > dynamic arguments. > recipe.append(TAG_ARG); > dynamicArgs.add(sharpestAccessible(arg.type)); > - gen.genExpr(arg, arg.type).load(); > + > + if (lhs != null && arg == args.head) { > + lhs.duplicate(); > + lhs.load(); > + } > + else > + gen.genExpr(arg, arg.type).load(); > } > } From david.holmes at oracle.com Thu Jun 7 10:02:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Jun 2018 20:02:12 +1000 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> Message-ID: Hi compiler-team, Was just getting ready to push this when I discovered a newly added test doesn't pass under nestmates: tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassConstructorsTest.java webrev: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v5-incr/ Fix was to reduce expected number of synthetic methods from 2 to 0, and expected number of synthetic classes from 1 to 0. This is similar to a previous change: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java.cdiff.html Thanks, David On 15/05/2018 10:52 AM, David Holmes wrote: > This review is being spread across four groups: langtools, core-libs, > hotspot and serviceability. This is the specific review thread for > langtools - webrev: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ > > See below for full details - including annotated full webrev guiding the > review. > > The intent is to have JEP-181 targeted and integrated by the end of this > month. > > Thanks, > David > ----- > > The nestmates project (JEP-181) introduces new classfile attributes to > identify classes and interfaces in the same nest, so that the VM can > perform access control based on those attributes and so allow direct > private access between nestmates without requiring javac to generate > synthetic accessor methods. These access control changes also extend to > core reflection and the MethodHandle.Lookup contexts. > > Direct private calls between nestmates requires a more general calling > context than is permitted by invokespecial, and so the JVMS is updated > to allow, and javac updated to use, invokevirtual and invokeinterface > for private class and interface method calls respectively. These changed > semantics also extend to MethodHandle findXXX operations. > > At this time we are only concerned with static nest definitions, which > map to a top-level class/interface as the nest-host and all its nested > types as nest-members. > > Please see the JEP for further details. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 > Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 > CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 > > All of the specification changes have been previously been worked out by > the Valhalla Project Expert Group, and the implementation reviewed by > the various contributors and discussed on the valhalla-dev mailing list. > > Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, > Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir > Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan > > Master webrev of all changes: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ > > Annotated master webrev index: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html > > Performance: this is expected to be performance neutral in a general > sense. Benchmarking and performance runs are about to start. > > Testing Discussion: > ------------------ > > The testing for nestmates can be broken into four main groups: > > -? New tests specifically related to nestmates and currently in the > runtime/Nestmates directory > > - New tests to complement existing tests by adding in testcases not > previously expressible. > ? -? For example java/lang/invoke/SpecialInterfaceCall.java tests use > of invokespecial for private interface methods and performing receiver > typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do > similar tests for invokeinterface. > > -? New JVM TI tests to verify the spec changes related to nest attributes. > > -? Existing tests significantly affected by the nestmates changes, > primarily: > ?? -? runtime/SelectionResolution > > ?? In most cases the nestmate changes makes certain invocations that > were illegal, legal (e.g. not requiring invokespecial to invoke private > interface methods; allowing access to private members via > reflection/Methodhandles that were previously not allowed). > > - Existing tests incidentally affected by the nestmate changes > > ? This includes tests of things utilising class > redefinition/retransformation to alter nested types but which > unintentionally alter nest relationships (which is not permitted). > > There are still a number of tests problem-listed with issues filed > against them to have them adapted to work with nestmates. Some of these > are intended to be addressed in the short-term, while some (such as the > runtime/SelectionResolution test changes) may not eventuate. > > - https://bugs.openjdk.java.net/browse/JDK-8203033 > - https://bugs.openjdk.java.net/browse/JDK-8199450 > - https://bugs.openjdk.java.net/browse/JDK-8196855 > - https://bugs.openjdk.java.net/browse/JDK-8194857 > - https://bugs.openjdk.java.net/browse/JDK-8187655 > > There is also further test work still to be completed (the JNI and JDI > invocation tests): > - https://bugs.openjdk.java.net/browse/JDK-8191117 > which will continue in parallel with the main RFR. > > Pre-integration Testing: > ?- General: > ??? - Mach5: hs/jdk tier1,2 > ??? - Mach5: hs-nightly (tiers 1 -3) > ?- Targetted > ?? - nashorn (for asm changes) > ?? - hotspot: runtime/* > ????????????? serviceability/* > ????????????? compiler/* > ????????????? vmTestbase/* > ?? - jdk: java/lang/invoke/* > ????????? java/lang/reflect/* > ????????? java/lang/instrument/* > ????????? java/lang/Class/* > ????????? java/lang/management/* > ? - langtools: tools/javac > ?????????????? tools/javap > From amaembo at gmail.com Thu Jun 7 10:58:10 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 7 Jun 2018 17:58:10 +0700 Subject: Parenthesized "this" and final fields Message-ID: Hello! I've found this issue: https://bugs.openjdk.java.net/browse/JDK-8156180 In Java 8 "(this)" expression was not specially handled as qualifier with respect to DA/DU analysis. This issue says to fix the problem. However to me it seems that the problem was fixed only partially. E.g. the following code still compiles in Java 10: class Unassigned { final int x = (this).y + 1; final int y = (this).x + 1; } While removing parentheses make it failing of course. Also the following code fails: class Unassigned { final int x; Unassigned() { (this).x = 1; } } While removing parentheses make it working. I expect that either parentheses should be allowed everywhere or disallowed everywhere. It was consistent in Java 8 (disallowed everywhere), and now it looks confusing. What do you think? Does this behavior follow the spec? With best regards, Tagir Valeev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Jun 7 11:42:35 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 7 Jun 2018 12:42:35 +0100 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> Message-ID: <93b8ed0f-43a4-9ee2-ef4d-2c7e5b468bef@oracle.com> Looks good Thanks David Maurizio On 07/06/18 11:02, David Holmes wrote: > Hi compiler-team, > > Was just getting ready to push this when I discovered a newly added > test doesn't pass under nestmates: > > tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassConstructorsTest.java > > > webrev: > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v5-incr/ > > Fix was to reduce expected number of synthetic methods from 2 to 0, > and expected number of synthetic classes from 1 to 0. This is similar > to a previous change: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java.cdiff.html > > > Thanks, > David > > On 15/05/2018 10:52 AM, David Holmes wrote: >> This review is being spread across four groups: langtools, core-libs, >> hotspot and serviceability. This is the specific review thread for >> langtools - webrev: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ >> >> See below for full details - including annotated full webrev guiding >> the review. >> >> The intent is to have JEP-181 targeted and integrated by the end of >> this month. >> >> Thanks, >> David >> ----- >> >> The nestmates project (JEP-181) introduces new classfile attributes >> to identify classes and interfaces in the same nest, so that the VM >> can perform access control based on those attributes and so allow >> direct private access between nestmates without requiring javac to >> generate synthetic accessor methods. These access control changes >> also extend to core reflection and the MethodHandle.Lookup contexts. >> >> Direct private calls between nestmates requires a more general >> calling context than is permitted by invokespecial, and so the JVMS >> is updated to allow, and javac updated to use, invokevirtual and >> invokeinterface for private class and interface method calls >> respectively. These changed semantics also extend to MethodHandle >> findXXX operations. >> >> At this time we are only concerned with static nest definitions, >> which map to a top-level class/interface as the nest-host and all its >> nested types as nest-members. >> >> Please see the JEP for further details. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 >> >> All of the specification changes have been previously been worked out >> by the Valhalla Project Expert Group, and the implementation reviewed >> by the various contributors and discussed on the valhalla-dev mailing >> list. >> >> Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, >> Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, >> Vladimir Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan >> >> Master webrev of all changes: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ >> >> Annotated master webrev index: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html >> >> Performance: this is expected to be performance neutral in a general >> sense. Benchmarking and performance runs are about to start. >> >> Testing Discussion: >> ------------------ >> >> The testing for nestmates can be broken into four main groups: >> >> -? New tests specifically related to nestmates and currently in the >> runtime/Nestmates directory >> >> - New tests to complement existing tests by adding in testcases not >> previously expressible. >> ?? -? For example java/lang/invoke/SpecialInterfaceCall.java tests >> use of invokespecial for private interface methods and performing >> receiver typechecks, so we add >> java/lang/invoke/PrivateInterfaceCall.java to do similar tests for >> invokeinterface. >> >> -? New JVM TI tests to verify the spec changes related to nest >> attributes. >> >> -? Existing tests significantly affected by the nestmates changes, >> primarily: >> ??? -? runtime/SelectionResolution >> >> ??? In most cases the nestmate changes makes certain invocations that >> were illegal, legal (e.g. not requiring invokespecial to invoke >> private interface methods; allowing access to private members via >> reflection/Methodhandles that were previously not allowed). >> >> - Existing tests incidentally affected by the nestmate changes >> >> ?? This includes tests of things utilising class >> redefinition/retransformation to alter nested types but which >> unintentionally alter nest relationships (which is not permitted). >> >> There are still a number of tests problem-listed with issues filed >> against them to have them adapted to work with nestmates. Some of >> these are intended to be addressed in the short-term, while some >> (such as the runtime/SelectionResolution test changes) may not >> eventuate. >> >> - https://bugs.openjdk.java.net/browse/JDK-8203033 >> - https://bugs.openjdk.java.net/browse/JDK-8199450 >> - https://bugs.openjdk.java.net/browse/JDK-8196855 >> - https://bugs.openjdk.java.net/browse/JDK-8194857 >> - https://bugs.openjdk.java.net/browse/JDK-8187655 >> >> There is also further test work still to be completed (the JNI and >> JDI invocation tests): >> - https://bugs.openjdk.java.net/browse/JDK-8191117 >> which will continue in parallel with the main RFR. >> >> Pre-integration Testing: >> ??- General: >> ???? - Mach5: hs/jdk tier1,2 >> ???? - Mach5: hs-nightly (tiers 1 -3) >> ??- Targetted >> ??? - nashorn (for asm changes) >> ??? - hotspot: runtime/* >> ?????????????? serviceability/* >> ?????????????? compiler/* >> ?????????????? vmTestbase/* >> ??? - jdk: java/lang/invoke/* >> ?????????? java/lang/reflect/* >> ?????????? java/lang/instrument/* >> ?????????? java/lang/Class/* >> ?????????? java/lang/management/* >> ?? - langtools: tools/javac >> ??????????????? tools/javap >> From david.holmes at oracle.com Thu Jun 7 12:11:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Jun 2018 22:11:21 +1000 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <93b8ed0f-43a4-9ee2-ef4d-2c7e5b468bef@oracle.com> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> <93b8ed0f-43a4-9ee2-ef4d-2c7e5b468bef@oracle.com> Message-ID: <862664b3-90ed-7839-65bd-cc665a773669@oracle.com> Thanks Maurizio! David On 7/06/2018 9:42 PM, Maurizio Cimadamore wrote: > Looks good > > Thanks David > > Maurizio > > > On 07/06/18 11:02, David Holmes wrote: >> Hi compiler-team, >> >> Was just getting ready to push this when I discovered a newly added >> test doesn't pass under nestmates: >> >> tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassConstructorsTest.java >> >> >> webrev: >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v5-incr/ >> >> >> Fix was to reduce expected number of synthetic methods from 2 to 0, >> and expected number of synthetic classes from 1 to 0. This is similar >> to a previous change: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java.cdiff.html >> >> >> Thanks, >> David >> >> On 15/05/2018 10:52 AM, David Holmes wrote: >>> This review is being spread across four groups: langtools, core-libs, >>> hotspot and serviceability. This is the specific review thread for >>> langtools - webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ >>> >>> See below for full details - including annotated full webrev guiding >>> the review. >>> >>> The intent is to have JEP-181 targeted and integrated by the end of >>> this month. >>> >>> Thanks, >>> David >>> ----- >>> >>> The nestmates project (JEP-181) introduces new classfile attributes >>> to identify classes and interfaces in the same nest, so that the VM >>> can perform access control based on those attributes and so allow >>> direct private access between nestmates without requiring javac to >>> generate synthetic accessor methods. These access control changes >>> also extend to core reflection and the MethodHandle.Lookup contexts. >>> >>> Direct private calls between nestmates requires a more general >>> calling context than is permitted by invokespecial, and so the JVMS >>> is updated to allow, and javac updated to use, invokevirtual and >>> invokeinterface for private class and interface method calls >>> respectively. These changed semantics also extend to MethodHandle >>> findXXX operations. >>> >>> At this time we are only concerned with static nest definitions, >>> which map to a top-level class/interface as the nest-host and all its >>> nested types as nest-members. >>> >>> Please see the JEP for further details. >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 >>> >>> All of the specification changes have been previously been worked out >>> by the Valhalla Project Expert Group, and the implementation reviewed >>> by the various contributors and discussed on the valhalla-dev mailing >>> list. >>> >>> Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, >>> Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, >>> Vladimir Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan >>> >>> Master webrev of all changes: >>> >>> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ >>> >>> Annotated master webrev index: >>> >>> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html >>> >>> Performance: this is expected to be performance neutral in a general >>> sense. Benchmarking and performance runs are about to start. >>> >>> Testing Discussion: >>> ------------------ >>> >>> The testing for nestmates can be broken into four main groups: >>> >>> -? New tests specifically related to nestmates and currently in the >>> runtime/Nestmates directory >>> >>> - New tests to complement existing tests by adding in testcases not >>> previously expressible. >>> ?? -? For example java/lang/invoke/SpecialInterfaceCall.java tests >>> use of invokespecial for private interface methods and performing >>> receiver typechecks, so we add >>> java/lang/invoke/PrivateInterfaceCall.java to do similar tests for >>> invokeinterface. >>> >>> -? New JVM TI tests to verify the spec changes related to nest >>> attributes. >>> >>> -? Existing tests significantly affected by the nestmates changes, >>> primarily: >>> ??? -? runtime/SelectionResolution >>> >>> ??? In most cases the nestmate changes makes certain invocations that >>> were illegal, legal (e.g. not requiring invokespecial to invoke >>> private interface methods; allowing access to private members via >>> reflection/Methodhandles that were previously not allowed). >>> >>> - Existing tests incidentally affected by the nestmate changes >>> >>> ?? This includes tests of things utilising class >>> redefinition/retransformation to alter nested types but which >>> unintentionally alter nest relationships (which is not permitted). >>> >>> There are still a number of tests problem-listed with issues filed >>> against them to have them adapted to work with nestmates. Some of >>> these are intended to be addressed in the short-term, while some >>> (such as the runtime/SelectionResolution test changes) may not >>> eventuate. >>> >>> - https://bugs.openjdk.java.net/browse/JDK-8203033 >>> - https://bugs.openjdk.java.net/browse/JDK-8199450 >>> - https://bugs.openjdk.java.net/browse/JDK-8196855 >>> - https://bugs.openjdk.java.net/browse/JDK-8194857 >>> - https://bugs.openjdk.java.net/browse/JDK-8187655 >>> >>> There is also further test work still to be completed (the JNI and >>> JDI invocation tests): >>> - https://bugs.openjdk.java.net/browse/JDK-8191117 >>> which will continue in parallel with the main RFR. >>> >>> Pre-integration Testing: >>> ??- General: >>> ???? - Mach5: hs/jdk tier1,2 >>> ???? - Mach5: hs-nightly (tiers 1 -3) >>> ??- Targetted >>> ??? - nashorn (for asm changes) >>> ??? - hotspot: runtime/* >>> ?????????????? serviceability/* >>> ?????????????? compiler/* >>> ?????????????? vmTestbase/* >>> ??? - jdk: java/lang/invoke/* >>> ?????????? java/lang/reflect/* >>> ?????????? java/lang/instrument/* >>> ?????????? java/lang/Class/* >>> ?????????? java/lang/management/* >>> ?? - langtools: tools/javac >>> ??????????????? tools/javap >>> > From maurizio.cimadamore at oracle.com Thu Jun 7 12:37:40 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 7 Jun 2018 13:37:40 +0100 Subject: Parenthesized "this" and final fields In-Reply-To: References: Message-ID: (Adding Alex/Dan, question for you at the bottom) I believe there's some confusion here. First the bug you mention refers to a bug in DA/DU implementation. DA/DU only applies to local variables and blank finals, so you see that your examples totally avoid any kind of DA/DU enforcement. The examples you report fall in the 'forward reference' category, which is dealt with in this section: 8.3.3. Restrictions on Field References in Initializers Here, basically, the spec says that unqualified forward references are disallowed, for both statics and instance fields. This means (surprisingly, and I've been surprised by this many times) - that: class Foo { ??? int x = y; ??? int y = 2; } is illegal, but this is legal class Foo { ??? int x = this.y; ??? int y = 2; } (similar examples can be constructed for static fields, just replace 'this' with 'Foo'). So, when a qualified reference is used, as in your example, all bets are off - the compiler doesn't check anything - you are pulling the plug on static checking, in a way. That covers your first example. As for the second example, I think the point of contention is all around this sentence in the spec: > Throughout the rest of this chapter, we will, unless explicitly stated otherwise, write V to represent a local variable or blank |final| field which is in scope (?6.3 ). Likewise, we will use |a|, |b|, |c|, and |e| to represent expressions, and S and T to represent statements. We will use the phrase "|a| is V" to mean that |a| is either the simple name of the variable V, or V's simple name qualified by |this| (ignoring parentheses). We will use the phrase "|a| is not V" to mean the negation of "|a| is V". What does this mean? I see many different ways to add parenthesis to a qualified this reference: (this).x = value //as in your example (this.x) = value I trust that the spec here means that every parenthesis should be dropped; which would suggest we have a bug here. Alex, Dan, could you please comment on this point? Maurizio On 07/06/18 11:58, Tagir Valeev wrote: > Hello! > > I've found this issue: > https://bugs.openjdk.java.net/browse/JDK-8156180 > > In Java 8 "(this)" expression was not specially handled as qualifier > with respect to DA/DU analysis. This issue says to fix the problem. > However to me it seems that the problem was fixed only partially. E.g. > the following code still compiles in Java 10: > > class Unassigned { > ? final int x = (this).y + 1; > ? final int y = (this).x + 1; > } > > While removing parentheses make it failing of course. Also the > following code fails: > > class Unassigned { > ? final int x; > > ? Unassigned() { > ? ? (this).x = 1; > ? } > } > > While removing parentheses make it working. I expect that either > parentheses should be allowed everywhere or disallowed everywhere. It > was consistent in Java 8 (disallowed everywhere), and now it looks > confusing. > > What do you think? Does this behavior follow the spec? > > With best regards, > Tagir Valeev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jun 7 13:41:09 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 7 Jun 2018 15:41:09 +0200 Subject: RFR: JDK-8193302: Javac AssertionError: typeSig ERROR on usage of @Generated Message-ID: <5B1935F5.2090206@oracle.com> Hi, When seeing an import-on-demand importing from a package, javac may currently accept an import from a package that is not visible to the current module, but whose name is a prefix of a name of a package that is visible. For example: import java.*; This contradicts JLS 7.5.2. (Type-Import-on-Demand Declarations), which requires that the package named in the import is uniquely visible. The proposal here is to produce errors for such not-visible packages in imports. Bug: https://bugs.openjdk.java.net/browse/JDK-8193302 CSR: https://bugs.openjdk.java.net/browse/JDK-8204534 Release note: https://bugs.openjdk.java.net/browse/JDK-8204542 Webrev: http://cr.openjdk.java.net/~jlahoda/8193302/webrev.00/ Any feedback and/or comments? Thanks, Jan From bsrbnd at gmail.com Thu Jun 7 16:36:23 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 7 Jun 2018 18:36:23 +0200 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> Message-ID: Hi David, On 7 June 2018 at 12:02, David Holmes wrote: > Hi compiler-team, > > Was just getting ready to push this when I discovered a newly added test > doesn't pass under nestmates: > > tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassConstructorsTest.java > > webrev: > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v5-incr/ > > Fix was to reduce expected number of synthetic methods from 2 to 0, and > expected number of synthetic classes from 1 to 0. This is similar to a > previous change: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java.cdiff.html > > Thanks, > David Looks good to me too. I recently added this test while correcting an ancient bug which will be implicitly solved by JEP 181 if target >= 11. Cheers, Bernard From alex.buckley at oracle.com Thu Jun 7 19:01:04 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 07 Jun 2018 12:01:04 -0700 Subject: Parenthesized "this" and final fields In-Reply-To: References: Message-ID: <5B1980F0.8040105@oracle.com> On 6/7/2018 5:37 AM, Maurizio Cimadamore wrote: > The examples you report fall in the 'forward reference' category, which > is dealt with in this section: > > 8.3.3. Restrictions on Field References in Initializers > > Here, basically, the spec says that unqualified forward references are > disallowed, for both statics and instance fields. > > This means (surprisingly, and I've been surprised by this many times) - > that: > > class Foo { > int x = y; > int y = 2; > } > > is illegal, but this is legal > > class Foo { > int x = this.y; > int y = 2; > } > > (similar examples can be constructed for static fields, just replace > 'this' with 'Foo'). > > So, when a qualified reference is used, as in your example, all bets are > off - the compiler doesn't check anything - you are pulling the plug on > static checking, in a way. > > That covers your first example. Frankly, allowing the forward reference in `int x = this.y;` is as silly as allowing access to the blank final field in `final int x; int y = this.x;`. We eventually prohibited the blank final access, and we ought to prohibit the forward reference too, by having 8.3.3 adopt the "or simple name qualified by this" clause seen in 16.0. Still, right now, JLS10 says that Tagir's first example, with parentheses removed, should compile, but he says it doesn't: class Unassigned { final int x = this.y + 1; final int y = this.x + 1; } > As for the second example, I think the point of contention is all around > this sentence in the spec: > > > Throughout the rest of this chapter, we will, unless explicitly > stated otherwise, write V to represent a local variable or blank |final| > field which is in scope (?6.3 > ). Likewise, > we will use |a|, |b|, |c|, and |e| to represent expressions, and S and T > to represent statements. We will use the phrase "|a| is V" to mean that > |a| is either the simple name of the variable V, or V's simple name > qualified by |this| (ignoring parentheses). We will use the phrase "|a| > is not V" to mean the negation of "|a| is V". > > What does this mean? I see many different ways to add parenthesis to a > qualified this reference: > > (this).x = value //as in your example > (this.x) = value > > I trust that the spec here means that every parenthesis should be > dropped; which would suggest we have a bug here. Right. The "ignoring parentheses" clause ought to appear in 16.0 too. Alex From vicente.romero at oracle.com Thu Jun 7 19:28:03 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 7 Jun 2018 15:28:03 -0400 Subject: RFR: JDK-8193302: Javac AssertionError: typeSig ERROR on usage of @Generated In-Reply-To: <5B1935F5.2090206@oracle.com> References: <5B1935F5.2090206@oracle.com> Message-ID: Hi, the change looks good to me. I have made some editions to the csr, just a proposal, and added myself as reviewer, Vicente On 06/07/2018 09:41 AM, Jan Lahoda wrote: > Hi, > > When seeing an import-on-demand importing from a package, javac may > currently accept an import from a package that is not visible to the > current module, but whose name is a prefix of a name of a package that > is visible. For example: > import java.*; > > This contradicts JLS 7.5.2. (Type-Import-on-Demand Declarations), > which requires that the package named in the import is uniquely visible. > > The proposal here is to produce errors for such not-visible packages > in imports. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193302 > CSR: https://bugs.openjdk.java.net/browse/JDK-8204534 > Release note: https://bugs.openjdk.java.net/browse/JDK-8204542 > Webrev: http://cr.openjdk.java.net/~jlahoda/8193302/webrev.00/ > > Any feedback and/or comments? > > Thanks, > ??? Jan From maurizio.cimadamore at oracle.com Thu Jun 7 20:54:38 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 7 Jun 2018 21:54:38 +0100 Subject: Parenthesized "this" and final fields In-Reply-To: <5B1980F0.8040105@oracle.com> References: <5B1980F0.8040105@oracle.com> Message-ID: > > Still, right now, JLS10 says that Tagir's first example, with > parentheses removed, should compile, but he says it doesn't: > > class Unassigned { > ? final int x = this.y + 1; > ? final int y = this.x + 1; > } I tested it and this compiles correctly. I don't know what specific example Tagir was referring to. > >> As for the second example, I think the point of contention is all around >> this sentence in the spec: >> >> ?> Throughout the rest of this chapter, we will, unless explicitly >> stated otherwise, write V to represent a local variable or blank |final| >> field which is in scope (?6.3 >> ). >> Likewise, >> we will use |a|, |b|, |c|, and |e| to represent expressions, and S and T >> to represent statements. We will use the phrase "|a| is V" to mean that >> |a| is either the simple name of the variable V, or V's simple name >> qualified by |this| (ignoring parentheses). We will use the phrase "|a| >> is not V" to mean the negation of "|a| is V". >> >> What does this mean? I see many different ways to add parenthesis to a >> qualified this reference: >> >> (this).x = value //as in your example >> (this.x) = value >> >> I trust that the spec here means that every parenthesis should be >> dropped; which would suggest we have a bug here. > > Right. The "ignoring parentheses" clause ought to appear in 16.0 too. I mean, I think the spec is fine here, but javac only deals with the second kind of parenthesis, not the former - should javac be changed to drop both kind of parenthesis? Maurizio > > Alex From alex.buckley at oracle.com Thu Jun 7 21:45:39 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 07 Jun 2018 14:45:39 -0700 Subject: Parenthesized "this" and final fields In-Reply-To: References: <5B1980F0.8040105@oracle.com> Message-ID: <5B19A783.3030203@oracle.com> On 6/7/2018 1:54 PM, Maurizio Cimadamore wrote: >>> > Throughout the rest of this chapter, we will, unless explicitly >>> stated otherwise, write V to represent a local variable or blank |final| >>> field which is in scope (?6.3 >>> ). >>> Likewise, >>> we will use |a|, |b|, |c|, and |e| to represent expressions, and S and T >>> to represent statements. We will use the phrase "|a| is V" to mean that >>> |a| is either the simple name of the variable V, or V's simple name >>> qualified by |this| (ignoring parentheses). We will use the phrase "|a| >>> is not V" to mean the negation of "|a| is V". >>> >>> What does this mean? I see many different ways to add parenthesis to a >>> qualified this reference: >>> >>> (this).x = value //as in your example >>> (this.x) = value >>> >>> I trust that the spec here means that every parenthesis should be >>> dropped; which would suggest we have a bug here. >> >> Right. The "ignoring parentheses" clause ought to appear in 16.0 too. > I mean, I think the spec is fine here, but javac only deals with the > second kind of parenthesis, not the former - should javac be changed to > drop both kind of parenthesis? Yes. The 16.0 text "Throughout the rest of this chapter ..." surely intends to look through parentheses as much as possible -- V should be `this.x` in ( (( (((this))).x )) ++ ) Alex From david.holmes at oracle.com Thu Jun 7 22:16:36 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jun 2018 08:16:36 +1000 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> Message-ID: <48753e05-01e3-f364-c77f-f31e2dcb90a6@oracle.com> Thanks Bernard! David On 8/06/2018 2:36 AM, B. Blaser wrote: > Hi David, > > On 7 June 2018 at 12:02, David Holmes wrote: >> Hi compiler-team, >> >> Was just getting ready to push this when I discovered a newly added test >> doesn't pass under nestmates: >> >> tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassConstructorsTest.java >> >> webrev: >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v5-incr/ >> >> Fix was to reduce expected number of synthetic methods from 2 to 0, and >> expected number of synthetic classes from 1 to 0. This is similar to a >> previous change: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java.cdiff.html >> >> Thanks, >> David > > Looks good to me too. > I recently added this test while correcting an ancient bug which will > be implicitly solved by JEP 181 if target >= 11. > > Cheers, > Bernard > From stuart.marks at oracle.com Thu Jun 7 22:53:42 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 7 Jun 2018 15:53:42 -0700 Subject: RFR: JDK-8196618: Create API to list supported values for javac --release option In-Reply-To: <5B17D344.1000603@oracle.com> References: <5B17D344.1000603@oracle.com> Message-ID: <885994eb-7cec-6d3a-752b-a4a71471d742@oracle.com> Hi Jan, Thanks for looking at jdeprscan. This is very timely. Michel was "bugging" me about some JDK 11 bugs (which are in jdeprscan) and I was looking at them, and I thought, I need to ask Jan about how to get the set of supported release values. And here we are! In jdeprscan/Main.java there's a bit of ad-hoc logic to determine whether a particular release is modular and whether it has the Java EE modules. Offhand I can't think of a better way to do this, but maybe this is something we can put in the back of our heads and think about a bit. For the help message, it turns out that String.join() consumes an Iterable, so you can probably just do something like String supportedReleases = String.join("|", pp.getSupportedPlatformNames()); instead of creating a Stream. For jdeprscan/TestRelease.java, why not just iterate over all supported platform names, calling invoke() on each one? I'm not sure what the filtering and "minimal coverage" logic is supposed to accomplish. If they're not in the set of supported platforms, forcing "9" and "10" seems likely to create an error. And we still want to test the old, non-modular releases. Note further that TestRelease.java is currently on the problem list, so it's not getting run at the moment. I'm ok if you go ahead with those changes, as it doesn't matter much. I'll need to revisit this test at some point anyway. s'marks On 6/6/18 5:27 AM, Jan Lahoda wrote: > Hi, > > This enhancement requests that test need to be able to query the list of > supported --release options. This is possible using the JDKPlatformProvider, so > I updated two tests where this seemed useful. But while doing this, it turned > out the jdeprscan was not yet fully updated to JDK 11 (still refers to > java.se.ee and did not list 11 in the help text for the --release option), so I > updated that as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196618 > Webrev: http://cr.openjdk.java.net/~jlahoda/8196618/webrev.00/ > > How does this look? > > Thanks, > ??? Jan > From s.2016.kay at gmail.com Fri Jun 8 00:13:10 2018 From: s.2016.kay at gmail.com (Ess Kay) Date: Fri, 8 Jun 2018 10:13:10 +1000 Subject: Any bytecode containing CONSTANT_Dynamic? Message-ID: We are needing to test our applications ability to correctly handle the new CONSTANT_Dynamic constant pool entry. Is there any Java source code available anywhere that would result in the Java 11 javac generating bytecode containing CONSTANT_Dynamic pool entries? -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Fri Jun 8 00:38:20 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 8 Jun 2018 07:38:20 +0700 Subject: Parenthesized "this" and final fields In-Reply-To: References: <5B1980F0.8040105@oracle.com> Message-ID: Hello! On Fri, Jun 8, 2018 at 3:54 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > >> Still, right now, JLS10 says that Tagir's first example, with parentheses >> removed, should compile, but he says it doesn't: >> >> class Unassigned { >> final int x = this.y + 1; >> final int y = this.x + 1; >> } >> > I tested it and this compiles correctly. I don't know what specific > example Tagir was referring to. > Sorry for confusion. I don't know why I decided this does not compile, probably tried wrong source file. Yes, it compiles correctly for me. Please forget this case then. With best regards, Tagir Valeev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jun 8 00:47:38 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 8 Jun 2018 01:47:38 +0100 Subject: Parenthesized "this" and final fields In-Reply-To: <5B19A783.3030203@oracle.com> References: <5B1980F0.8040105@oracle.com> <5B19A783.3030203@oracle.com> Message-ID: > Yes. The 16.0 text "Throughout the rest of this chapter ..." surely > intends to look through parentheses as much as possible -- V should be > `this.x` in > > ? ( (( (((this))).x )) ++ ) Thanks Alex, Tagir I will file a bug on this one and fix it. Maurizio > > Alex From david.holmes at oracle.com Fri Jun 8 02:20:39 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jun 2018 12:20:39 +1000 Subject: (trivial) RFR: 8204589: ProblemList failing launcher tests Message-ID: <33d65120-5ae0-0dfb-6450-b3475d87a61e@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8204589 webrev: http://cr.openjdk.java.net/~dholmes/8204589/webrev/ After the push for: JDK-8201274 Launch Single-File Source-Code Programs there are a few test failures in our CI testing, so they are being ProblemListed to keep tiers 1 and 2 clean. Thanks, David From joe.darcy at oracle.com Fri Jun 8 02:22:22 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 07 Jun 2018 19:22:22 -0700 Subject: (trivial) RFR: 8204589: ProblemList failing launcher tests In-Reply-To: <33d65120-5ae0-0dfb-6450-b3475d87a61e@oracle.com> References: <33d65120-5ae0-0dfb-6450-b3475d87a61e@oracle.com> Message-ID: <5B19E85E.40805@oracle.com> +1 -Joe On 6/7/2018 7:20 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8204589 > webrev: http://cr.openjdk.java.net/~dholmes/8204589/webrev/ > > After the push for: > > JDK-8201274 Launch Single-File Source-Code Programs > > there are a few test failures in our CI testing, so they are being > ProblemListed to keep tiers 1 and 2 clean. > > Thanks, > David From david.holmes at oracle.com Fri Jun 8 02:30:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jun 2018 12:30:43 +1000 Subject: (trivial) RFR: 8204589: ProblemList failing launcher tests In-Reply-To: <5B19E85E.40805@oracle.com> References: <33d65120-5ae0-0dfb-6450-b3475d87a61e@oracle.com> <5B19E85E.40805@oracle.com> Message-ID: Thanks Joe! Pushed. Should be in CI 753. David On 8/06/2018 12:22 PM, Joseph D. Darcy wrote: > +1 > > -Joe > > On 6/7/2018 7:20 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8204589 >> webrev: http://cr.openjdk.java.net/~dholmes/8204589/webrev/ >> >> After the push for: >> >> ?JDK-8201274 Launch Single-File Source-Code Programs >> >> there are a few test failures in our CI testing, so they are being >> ProblemListed to keep tiers 1 and 2 clean. >> >> Thanks, >> David > From forax at univ-mlv.fr Fri Jun 8 10:39:29 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 8 Jun 2018 12:39:29 +0200 (CEST) Subject: Any bytecode containing CONSTANT_Dynamic? In-Reply-To: References: Message-ID: <454736629.1863548.1528454369401.JavaMail.zimbra@u-pem.fr> > De: "Ess Kay" > ?: "compiler-dev" > Envoy?: Vendredi 8 Juin 2018 02:13:10 > Objet: Any bytecode containing CONSTANT_Dynamic? > We are needing to test our applications ability to correctly handle the new > CONSTANT_Dynamic constant pool entry. Is there any Java source code available > anywhere that would result in the Java 11 javac generating bytecode containing > CONSTANT_Dynamic pool entries? Constant lambdas are translated into constant dynamic at least by the javac of Amber, but i do not know if the javac of the jdk11 does that too. Otherwise, if you look for classes containing constant dynamic, we use this class [1] that was generated using the javac of Amber when testing ASM. If you want a more complex example, you can play with cplisp which encode lisp atoms into the constant pool using constant dynamic [2]. regards, R?mi [1] https://gitlab.ow2.org/asm/asm/blob/master/asm-test/src/main/resources/jdk11/LambdaCondy.class [2] https://github.com/forax/cplisp/blob/master/.travis.yml -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jun 8 13:22:26 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 8 Jun 2018 09:22:26 -0400 Subject: Any bytecode containing CONSTANT_Dynamic? In-Reply-To: <454736629.1863548.1528454369401.JavaMail.zimbra@u-pem.fr> References: <454736629.1863548.1528454369401.JavaMail.zimbra@u-pem.fr> Message-ID: <5fe43740-462c-a4b1-f8b1-d8b072981f2a@oracle.com> On 06/08/2018 06:39 AM, Remi Forax wrote: > > ------------------------------------------------------------------------ > > *De: *"Ess Kay" > *?: *"compiler-dev" > *Envoy?: *Vendredi 8 Juin 2018 02:13:10 > *Objet: *Any bytecode containing CONSTANT_Dynamic? > > We are needing to test our applications ability to correctly > handle the new |CONSTANT_Dynamic| constant pool entry.? Is there > any Java source code available anywhere that would result in the > Java 11 javac generating bytecode containing |CONSTANT_Dynamic| > pool entries? > > > Constant lambdas are translated into constant dynamic at least by the > javac of Amber, but i do not know if the javac of the jdk11 does that too. right you can clone the repo at [3] and move to the condy-folding branch. Once you build it you will have a JDK that is able to generate condy for non-capturing lambdas, also for lambdas that only capture constants: Runnable r = () -> {} -------------------------------- String prefix = "__"; Function s -> prefix + s; etc Thanks, Vicente > > Otherwise, if you look for classes containing constant dynamic, we use > this class [1] that was generated using the javac of Amber when > testing ASM. > If you want a more complex example, you can play with cplisp which > encode lisp atoms into the constant pool using constant dynamic [2]. > > regards, > R?mi > > [1] > https://gitlab.ow2.org/asm/asm/blob/master/asm-test/src/main/resources/jdk11/LambdaCondy.class > [2] https://github.com/forax/cplisp/blob/master/.travis.yml > [3] http://hg.openjdk.java.net/amber/amber -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Jun 8 13:51:52 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 8 Jun 2018 15:51:52 +0200 Subject: RFR: JDK-8196618: Create API to list supported values for javac --release option In-Reply-To: <885994eb-7cec-6d3a-752b-a4a71471d742@oracle.com> References: <5B17D344.1000603@oracle.com> <885994eb-7cec-6d3a-752b-a4a71471d742@oracle.com> Message-ID: <5B1A89F8.2010909@oracle.com> Hi Stuart, Thanks for your comments! I've updated the patch according to them (simplifying the join, cleaning up the logic in tests, removing the tests from the list of ignored tests). The updated patch is here: http://cr.openjdk.java.net/~jlahoda/8196618/webrev.01/ On 8.6.2018 00:53, Stuart Marks wrote: > Hi Jan, > > Thanks for looking at jdeprscan. This is very timely. Michel was > "bugging" me about some JDK 11 bugs (which are in jdeprscan) and I was > looking at them, and I thought, I need to ask Jan about how to get the > set of supported release values. And here we are! > > In jdeprscan/Main.java there's a bit of ad-hoc logic to determine > whether a particular release is modular and whether it has the Java EE > modules. Offhand I can't think of a better way to do this, but maybe > this is something we can put in the back of our heads and think about a > bit. I agree the logic there is a ad-hoc. I was thinking of using ALL-SYSTEM, but that would mean updating the TraverseProc, probably taking all modules and using those whose names start with "java.", so I decided to keep it similar to what existed before. But I can try this, if you prefer. Thanks, Jan > > For the help message, it turns out that String.join() consumes an > Iterable, so you can probably just do something like > > String supportedReleases = String.join("|", > pp.getSupportedPlatformNames()); > > instead of creating a Stream. > > For jdeprscan/TestRelease.java, why not just iterate over all supported > platform names, calling invoke() on each one? I'm not sure what the > filtering and "minimal coverage" logic is supposed to accomplish. If > they're not in the set of supported platforms, forcing "9" and "10" > seems likely to create an error. And we still want to test the old, > non-modular releases. > > Note further that TestRelease.java is currently on the problem list, so > it's not getting run at the moment. I'm ok if you go ahead with those > changes, as it doesn't matter much. I'll need to revisit this test at > some point anyway. > > s'marks > > > On 6/6/18 5:27 AM, Jan Lahoda wrote: >> Hi, >> >> This enhancement requests that test need to be able to query the list >> of supported --release options. This is possible using the >> JDKPlatformProvider, so I updated two tests where this seemed useful. >> But while doing this, it turned out the jdeprscan was not yet fully >> updated to JDK 11 (still refers to java.se.ee and did not list 11 in >> the help text for the --release option), so I updated that as well. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196618 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8196618/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan >> From maurizio.cimadamore at oracle.com Fri Jun 8 13:55:47 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 8 Jun 2018 14:55:47 +0100 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments Message-ID: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> Hi, this patch fixes the problem we have been talking about yesterday [1]. Basically, javac does not consistently skip parenthesis when enforcing foward refs and DA/DU rules. I decided to consolidate the 'is this a variable name, possibly qualified by "this" ', into a separate TreeInfo routine, and call that from Flow and Attr (it turned out that the wrong logic was applied in both places). I have included a combo test which tests several combinations of the kind ((this).(x)) = 1 This might include (as in the example above, as the selected variable symbol can't be wrapped in its own parenthesis) nonsensical combination, which the test makes sure they are rejected. Webrev: http://cr.openjdk.java.net/~mcimadamore/8204610/ Cheers Maurizio [1] - http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012005.html From jan.lahoda at oracle.com Fri Jun 8 13:57:45 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 8 Jun 2018 15:57:45 +0200 Subject: RFR: JDK-8193302: Javac AssertionError: typeSig ERROR on usage of @Generated In-Reply-To: References: <5B1935F5.2090206@oracle.com> Message-ID: <5B1A8B59.90909@oracle.com> Thanks Vicente! Jan On 7.6.2018 21:28, Vicente Romero wrote: > Hi, > > the change looks good to me. I have made some editions to the csr, just > a proposal, and added myself as reviewer, > > Vicente > > On 06/07/2018 09:41 AM, Jan Lahoda wrote: >> Hi, >> >> When seeing an import-on-demand importing from a package, javac may >> currently accept an import from a package that is not visible to the >> current module, but whose name is a prefix of a name of a package that >> is visible. For example: >> import java.*; >> >> This contradicts JLS 7.5.2. (Type-Import-on-Demand Declarations), >> which requires that the package named in the import is uniquely visible. >> >> The proposal here is to produce errors for such not-visible packages >> in imports. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193302 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8204534 >> Release note: https://bugs.openjdk.java.net/browse/JDK-8204542 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8193302/webrev.00/ >> >> Any feedback and/or comments? >> >> Thanks, >> Jan > From vicente.romero at oracle.com Fri Jun 8 14:43:43 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 8 Jun 2018 10:43:43 -0400 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> Message-ID: <5e8f364b-f95f-4dca-bd0a-1c75dec5385e@oracle.com> looks good, Vicente On 06/08/2018 09:55 AM, Maurizio Cimadamore wrote: > Hi, > this patch fixes the problem we have been talking about yesterday [1]. > > Basically, javac does not consistently skip parenthesis when enforcing > foward refs and DA/DU rules. > > I decided to consolidate the 'is this a variable name, possibly > qualified by "this" ', into a separate TreeInfo routine, and call that > from Flow and Attr (it turned out that the wrong logic was applied in > both places). > > I have included a combo test which tests several combinations of the kind > > ((this).(x)) = 1 > > This might include (as in the example above, as the selected variable > symbol can't be wrapped in its own parenthesis) nonsensical > combination, which the test makes sure they are rejected. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8204610/ > > Cheers > > Maurizio > > [1] - > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012005.html > From victorwssilva at gmail.com Fri Jun 8 17:39:38 2018 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Fri, 8 Jun 2018 14:39:38 -0300 Subject: Compiler confused by parenthesized "this" in final fields assignments Message-ID: What about this? public class AssignBug { private final int y; private final AssignBug x = this; private final int z = x.y; private final int w = getY(); { y = 42; } public static void main(String[] args) { AssignBug h = new AssignBug(); System.out.println(h.y + "|" + h.z + "|" + h.w); } public int getY() { return y; } } By assign "this" to some other variable and acessing the unitilized field of that variable, it becomes easy to defeat the final variable initialization check. It can also be defeated by acessing it through a method. The JLS (chapter 16) says: Each local variable (?14.4 ) and every blank final field (?4.12.4 , ?8.3.1.2 ) must have a *definitely assigned* value when any access of its value occurs. An access to its value consists of the simple name of the variable (or, for a field, the simple name of the field qualified by this) occurring anywhere in an expression except as the left-hand operand of the simple assignment operator = (?15.26.1 ). For every access of a local variable or blank final field x, x must be definitely assigned before the access, or a compile-time error occurs. Saying "must be definitely assigned before the access, or a compile-time error occurs" is a very bold statement that is simply unenforceable and broken. The chapter 16 details many of the rules when a variable should be considered definitely assigned or definitely unassigned, but it overlooks those two cases. Victor Williams Stafusa da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Fri Jun 8 18:15:12 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 8 Jun 2018 14:15:12 -0400 Subject: RFR: 8204630: generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment Message-ID: Hi, This patch fixes an NPE in JavacProcessingEnvironment when attempting to generate the class file for an anonymous class from an annotation processor using Filer#createClassFile. bug: https://bugs.openjdk.java.net/browse/JDK-8204630 webrev: http://cr.openjdk.java.net/~cushon/8204630/webrev.00/ Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Fri Jun 8 21:59:39 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 8 Jun 2018 14:59:39 -0700 Subject: RFR: JDK-8196618: Create API to list supported values for javac --release option In-Reply-To: <5B1A89F8.2010909@oracle.com> References: <5B17D344.1000603@oracle.com> <885994eb-7cec-6d3a-752b-a4a71471d742@oracle.com> <5B1A89F8.2010909@oracle.com> Message-ID: On 6/8/18 6:51 AM, Jan Lahoda wrote: > Thanks for your comments! I've updated the patch according to them (simplifying > the join, cleaning up the logic in tests, removing the tests from the list of > ignored tests). The updated patch is here: > http://cr.openjdk.java.net/~jlahoda/8196618/webrev.01/ OK, the jdeprscan stuff looks good. Thanks for pulling the tests off the problem list, too. I assume that means they pass now! (Note, I've only reviewed files in this changeset that are relevant to jdeprscan.) >> In jdeprscan/Main.java there's a bit of ad-hoc logic to determine >> whether a particular release is modular and whether it has the Java EE >> modules. Offhand I can't think of a better way to do this, but maybe >> this is something we can put in the back of our heads and think about a >> bit. > > I agree the logic there is a ad-hoc. I was thinking of using ALL-SYSTEM, but > that would mean updating the TraverseProc, probably taking all modules and using > those whose names start with "java.", so I decided to keep it similar to what > existed before. But I can try this, if you prefer. No need for further changes right now. What you have is good enough. In the longer term maybe we'll do something different, but it's not obvious what at this point. Thanks, s'marks > > Thanks, > ??? Jan > >> >> For the help message, it turns out that String.join() consumes an >> Iterable, so you can probably just do something like >> >> ???? String supportedReleases = String.join("|", >> pp.getSupportedPlatformNames()); >> >> instead of creating a Stream. >> >> For jdeprscan/TestRelease.java, why not just iterate over all supported >> platform names, calling invoke() on each one? I'm not sure what the >> filtering and "minimal coverage" logic is supposed to accomplish. If >> they're not in the set of supported platforms, forcing "9" and "10" >> seems likely to create an error. And we still want to test the old, >> non-modular releases. >> >> Note further that TestRelease.java is currently on the problem list, so >> it's not getting run at the moment. I'm ok if you go ahead with those >> changes, as it doesn't matter much. I'll need to revisit this test at >> some point anyway. >> >> s'marks >> >> >> On 6/6/18 5:27 AM, Jan Lahoda wrote: >>> Hi, >>> >>> This enhancement requests that test need to be able to query the list >>> of supported --release options. This is possible using the >>> JDKPlatformProvider, so I updated two tests where this seemed useful. >>> But while doing this, it turned out the jdeprscan was not yet fully >>> updated to JDK 11 (still refers to java.se.ee and did not list 11 in >>> the help text for the --release option), so I updated that as well. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196618 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8196618/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> ???? Jan >>> From alex.buckley at oracle.com Sat Jun 9 00:09:54 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 08 Jun 2018 17:09:54 -0700 Subject: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: References: Message-ID: <5B1B1AD2.60100@oracle.com> On 6/8/2018 10:39 AM, Victor Williams Stafusa da Silva wrote: > By assign "this" to some other variable and acessing the unitilized > field of that variable, it becomes easy to defeat the final variable > initialization check. It can also be defeated by acessing it through a > method. Yes, of course. > The JLS (chapter 16) says: > > Each local variable (?14.4 > ) > and every blank|final|field (?4.12.4 > ,?8.3.1.2 > ) > must have a/definitely assigned/value when any access of its value > occurs. > > An access to its value consists of the simple name of the variable > (or, for a field, the simple name of the field qualified by|this|) > occurring anywhere in an expression except as the left-hand operand > of the simple assignment operator|=|(?15.26.1 > ). > > For every access of a local variable or blank|final|field|x|,|x|must > be definitely assigned before the access, or a compile-time error > occurs. > > Saying "must be definitely assigned before the access, or a compile-time > error occurs" is a very bold statement that is simply unenforceable and > broken. The chapter 16 details many of the rules when a variable should > be considered definitely assigned or definitely unassigned, but it > overlooks those two cases. I know what you mean, but in: private final int y; private final AssignBug x = this; private final int z = x.y; private final int w = getY(); neither `x.y` nor `getY()` is an access according to the definition "An access to its value consists of ...". Therefore, there is no requirement that `y` be DA before `x.y` or `getY()`, even though a human reader who understands aliasing would obviously like `y` to be so. Alex From alex.buckley at oracle.com Sat Jun 9 00:17:14 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 08 Jun 2018 17:17:14 -0700 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> Message-ID: <5B1B1C8A.10004@oracle.com> On 6/8/2018 6:55 AM, Maurizio Cimadamore wrote: > Basically, javac does not consistently skip parenthesis when enforcing > foward refs and DA/DU rules. I want to check that javac skips parentheses for `x` and `this.x` in DA/DU rules, but only for `x` in a forward field reference. At this time, JLS 8.3.3 detects a forward field reference only if made with a simple name; it's a bit late to expand that for JLS11, so I'm a bit alarmed by this unified treatment of variable access: > I decided to consolidate the 'is this a variable name, possibly > qualified by "this" ', into a separate TreeInfo routine, and call that > from Flow and Attr (it turned out that the wrong logic was applied in > both places). Alex From cushon at google.com Sat Jun 9 02:46:44 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 8 Jun 2018 22:46:44 -0400 Subject: RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference Message-ID: Hi, Please consider the following fix for JDK-8203679. I added some notes to the bug: https://bugs.openjdk.java.net/browse/JDK-8203679?focusedCommentId=14186441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14186441 The proposed fix seems harmless assuming this implementation comment is correct: > once the value for overloadKind is determined for a copy, it can be safely forwarded to > the copied tree, we want to profit from that The current logic only propagates the overloadKind to the copied tree the first time an overloadKind is set for any copy of that tree. If it was possible to compute different overloadKinds for different copies, that approach wouldn't work. I added an assertion that the computed overloadKind is stable to make sure that assumption holds. bug: https://bugs.openjdk.java.net/browse/JDK-8203679 webrev: http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sat Jun 9 10:37:01 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 9 Jun 2018 12:37:01 +0200 Subject: RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference In-Reply-To: References: Message-ID: Hi Liam, At least 'make.at()' looks good ;-) I already fixed it here: https://bugs.openjdk.java.net/browse/JDK-8202372 http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac Bernard On 9 June 2018 at 04:46, Liam Miller-Cushon wrote: > Hi, > > Please consider the following fix for JDK-8203679. > > I added some notes to the bug: > https://bugs.openjdk.java.net/browse/JDK-8203679?focusedCommentId=14186441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14186441 > > The proposed fix seems harmless assuming this implementation comment is > correct: > >> once the value for overloadKind is determined for a copy, it can be safely >> forwarded to >> the copied tree, we want to profit from that > > The current logic only propagates the overloadKind to the copied tree the > first time an overloadKind is set for any copy of that tree. If it was > possible to compute different overloadKinds for different copies, that > approach wouldn't work. I added an assertion that the computed overloadKind > is stable to make sure that assumption holds. > > bug: https://bugs.openjdk.java.net/browse/JDK-8203679 > webrev: http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ > > Thanks, > Liam From bsrbnd at gmail.com Sat Jun 9 18:02:50 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 9 Jun 2018 20:02:50 +0200 Subject: RFR JDK-8203813: javac accepts an illegal name as a receiver parameter name Message-ID: Hi, As noted in the JBS issue, the following example should be rejected because the receiver parameter name is invalid: class C { C c; void foo(C c.c) { } } The suggested fix is to make the parser conform to the receiver parameter syntax (JLS10 ?8.4.1): ReceiverParameter: {Annotation} UnannType [Identifier .] this Tier1 is OK. Any feedback is welcome, Bernard Bug: https://bugs.openjdk.java.net/browse/JDK-8203813 Suggested fix: diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java @@ -3126,6 +3126,9 @@ if (token.kind == LBRACKET) { log.error(token.pos, Errors.ArrayAndReceiver); } + if (pn.hasTag(Tag.SELECT) && ((JCFieldAccess)pn).name != names._this) { + log.error(token.pos, Errors.WrongReceiver); + } } return toP(F.at(pos).ReceiverVarDef(mods, pn, type)); } diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties @@ -677,6 +677,9 @@ compiler.err.array.and.receiver =\ legacy array notation not allowed on receiver parameter +compiler.err.wrong.receiver =\ + Wrong receiver parameter + compiler.err.variable.not.allowed=\ variable declaration not allowed here diff --git a/test/langtools/tools/javac/diags/examples/WrongReceiver.java b/test/langtools/tools/javac/diags/examples/WrongReceiver.java new file mode 100644 --- /dev/null +++ b/test/langtools/tools/javac/diags/examples/WrongReceiver.java @@ -0,0 +1,6 @@ +// key: compiler.err.wrong.receiver + +class WrongReceiver { + WrongReceiver wr; + void f(WrongReceiver wr.wr); +} From cushon at google.com Sat Jun 9 19:58:30 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Sat, 9 Jun 2018 15:58:30 -0400 Subject: RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference In-Reply-To: References: Message-ID: Oops, thanks. There was an issue with the webrev: I generated the diff against the wrong base revision. It's fixed now: http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ On Sat, Jun 9, 2018 at 6:37 AM B. Blaser wrote: > Hi Liam, > > At least 'make.at()' looks good ;-) > I already fixed it here: > > https://bugs.openjdk.java.net/browse/JDK-8202372 > http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac > > Bernard > > On 9 June 2018 at 04:46, Liam Miller-Cushon wrote: > > Hi, > > > > Please consider the following fix for JDK-8203679. > > > > I added some notes to the bug: > > > https://bugs.openjdk.java.net/browse/JDK-8203679?focusedCommentId=14186441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14186441 > > > > The proposed fix seems harmless assuming this implementation comment is > > correct: > > > >> once the value for overloadKind is determined for a copy, it can be > safely > >> forwarded to > >> the copied tree, we want to profit from that > > > > The current logic only propagates the overloadKind to the copied tree the > > first time an overloadKind is set for any copy of that tree. If it was > > possible to compute different overloadKinds for different copies, that > > approach wouldn't work. I added an assertion that the computed > overloadKind > > is stable to make sure that assumption holds. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8203679 > > webrev: http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ > > > > Thanks, > > Liam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jun 11 10:34:48 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 11 Jun 2018 11:34:48 +0100 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: <5B1B1C8A.10004@oracle.com> References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> Message-ID: <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> On 09/06/18 01:17, Alex Buckley wrote: > On 6/8/2018 6:55 AM, Maurizio Cimadamore wrote: >> Basically, javac does not consistently skip parenthesis when enforcing >> foward refs and DA/DU rules. > > I want to check that javac skips parentheses for `x` and `this.x` in > DA/DU rules, but only for `x` in a forward field reference. At this > time, JLS 8.3.3 detects a forward field reference only if made with a > simple name; it's a bit late to expand that for JLS11, so I'm a bit > alarmed by this unified treatment of variable access: Javac is still implementing the same rule for forward references. E.g. a forward reference is treated as such only if it's unqualified (e.g. in the 'x' form); qualified access (this.x) will be allowed, as before. I think my comment was a bit misleading - what I found is that there was duplicated logic in javac where we checked multiple times whether some 'this.x' was ok to assign to; one was DA/DU (in Flow), another was a custom check (in Attr); both are now using the same paren skipping rules, to avoid spurious errors. In the long term we should consider dropping the Attr check, which should be subsumed by DA/DU. Maurizio > >> I decided to consolidate the 'is this a variable name, possibly >> qualified by "this" ', into a separate TreeInfo routine, and call that >> from Flow and Attr (it turned out that the wrong logic was applied in >> both places). > > Alex From maurizio.cimadamore at oracle.com Mon Jun 11 10:55:52 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 11 Jun 2018 11:55:52 +0100 Subject: RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference In-Reply-To: References: Message-ID: <9c59be80-81d2-a776-e7b8-213017303a89@oracle.com> Looks good - the fix allows recursion to take place and to follow the links from copy to copy to fetch the right overload kind. One minor nit is that we could avoid calling t.getOverloadKind twice e.g. instead of: if (t.getOverloadKind() == null) { t.setOverloadKind(overloadKind); } else { Assert.check(overloadKind == t.getOverloadKind()); } Do: OverloadKind kind = t.getOverloadKind(); if (kind == null) { ?t.setOverloadKind(overloadKind); } else { Assert.check(overloadKind == kind); } Maurizio On 09/06/18 20:58, Liam Miller-Cushon wrote: > Oops, thanks. There was an issue with the webrev: I generated the diff > against the wrong base revision. > > It's fixed now: http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ > > > On Sat, Jun 9, 2018 at 6:37 AM B. Blaser > wrote: > > Hi Liam, > > At least 'make.at ()' looks good ;-) > I already fixed it here: > > https://bugs.openjdk.java.net/browse/JDK-8202372 > http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac > > Bernard > > On 9 June 2018 at 04:46, Liam Miller-Cushon > wrote: > > Hi, > > > > Please consider the following fix for JDK-8203679. > > > > I added some notes to the bug: > > > https://bugs.openjdk.java.net/browse/JDK-8203679?focusedCommentId=14186441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14186441 > > > > The proposed fix seems harmless assuming this implementation > comment is > > correct: > > > >> once the value for overloadKind is determined for a copy, it > can be safely > >> forwarded to > >> the copied tree, we want to profit from that > > > > The current logic only propagates the overloadKind to the copied > tree the > > first time an overloadKind is set for any copy of that tree. If > it was > > possible to compute different overloadKinds for different > copies, that > > approach wouldn't work. I added an assertion that the computed > overloadKind > > is stable to make sure that assumption holds. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8203679 > > webrev: http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ > > > > > Thanks, > > Liam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Jun 11 11:31:11 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 11 Jun 2018 13:31:11 +0200 Subject: RFR: JDK-8204674: Inconsistent lambda parameter span Message-ID: <5B1E5D7F.9000203@oracle.com> Hi, There are a few cases where the positions for lambda parameters seem to be not ideal: java.util.function.IntBinaryOperator c = (var x, testType) -> 1; The span for the "var x" variable does not include "var". The span of "testType" does not include "testType" after attribution. The proposed patch tweaks the code to provide more consistent positions. Bug: https://bugs.openjdk.java.net/browse/JDK-8204674 Webrev: http://cr.openjdk.java.net/~jlahoda/8204674/webrev.00/ How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Mon Jun 11 11:42:31 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 11 Jun 2018 12:42:31 +0100 Subject: RFR: JDK-8204674: Inconsistent lambda parameter span In-Reply-To: <5B1E5D7F.9000203@oracle.com> References: <5B1E5D7F.9000203@oracle.com> Message-ID: <242e0ded-8cc7-44da-8fc2-05652753cf60@oracle.com> Looks good Maurizio On 11/06/18 12:31, Jan Lahoda wrote: > Hi, > > There are a few cases where the positions for lambda parameters seem > to be not ideal: > > java.util.function.IntBinaryOperator c = (var x, testType) -> 1; > > The span for the "var x" variable does not include "var". The span of > "testType" does not include "testType" after attribution. > > The proposed patch tweaks the code to provide more consistent positions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204674 > Webrev: http://cr.openjdk.java.net/~jlahoda/8204674/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From bsrbnd at gmail.com Mon Jun 11 14:42:46 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 11 Jun 2018 16:42:46 +0200 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac Message-ID: Hi, By the light of Maurizio's JBS comment [1], I suggest the following fix which virtualizes and overrides 'TypeVar.bound()' in the cloned type var and uses it in 'Types.getBounds()'. Any comment is welcome (langtools:tier1 is OK), Bernard [1] https://bugs.openjdk.java.net/browse/JDK-8193367 diff -r 65e65d5905bc src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java Sun Jun 10 12:58:38 2018 +0300 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java Mon Jun 11 15:50:12 2018 +0200 @@ -1636,11 +1636,16 @@ this.lower = lower; } + public Type bound() { return bound; } + @Override public TypeVar cloneWithMetadata(TypeMetadata md) { return new TypeVar(tsym, bound, lower, md) { @Override public Type baseType() { return TypeVar.this.baseType(); } + + @Override + public Type bound() { return TypeVar.this.bound; } }; } diff -r 65e65d5905bc 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 Sun Jun 10 12:58:38 2018 +0300 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java Mon Jun 11 15:50:12 2018 +0200 @@ -2666,10 +2666,10 @@ * Return list of bounds of the given type variable. */ public List getBounds(TypeVar t) { - if (t.bound.hasTag(NONE)) + if (t.bound().hasTag(NONE)) return List.nil(); - else if (t.bound.isErroneous() || !t.bound.isCompound()) - return List.of(t.bound); + else if (t.bound().isErroneous() || !t.bound().isCompound()) + return List.of(t.bound()); else if ((erasure(t).tsym.flags() & INTERFACE) == 0) return interfaces(t).prepend(supertype(t)); else diff -r 65e65d5905bc test/langtools/tools/javac/generics/typevars/AnnoTypeVarBounds.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/langtools/tools/javac/generics/typevars/AnnoTypeVarBounds.java Mon Jun 11 15:50:12 2018 +0200 @@ -0,0 +1,15 @@ +/* + * @test + * @bug 8193367 + * @summary Annotated type variable bounds crash javac + * @compile AnnoTypeVarBounds.java + */ +import java.lang.annotation.ElementType; +import java.lang.annotation.Target; + +class AnnoTypeVarBounds { + @Target(value = {ElementType.TYPE_USE}) + @interface A{} + class Sup { } + class Sub extends Sup { } +} From maurizio.cimadamore at oracle.com Mon Jun 11 17:23:07 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 11 Jun 2018 18:23:07 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: Message-ID: I think this patch is a good start, but to be complete, we'd need to completely virtualize access on the 'bound' field, otherwise we risk turning this into a whack-a-mole exercise. There are e.g. 30 usages in Types alone, each of those could lead to issues with type annos. Maurizio On 11/06/18 15:42, B. Blaser wrote: > Hi, > > By the light of Maurizio's JBS comment [1], I suggest the following > fix which virtualizes and overrides 'TypeVar.bound()' in the cloned > type var and uses it in 'Types.getBounds()'. > > Any comment is welcome (langtools:tier1 is OK), > Bernard > > [1] https://bugs.openjdk.java.net/browse/JDK-8193367 > > > diff -r 65e65d5905bc > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > Sun Jun 10 12:58:38 2018 +0300 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > Mon Jun 11 15:50:12 2018 +0200 > @@ -1636,11 +1636,16 @@ > this.lower = lower; > } > > + public Type bound() { return bound; } > + > @Override > public TypeVar cloneWithMetadata(TypeMetadata md) { > return new TypeVar(tsym, bound, lower, md) { > @Override > public Type baseType() { return TypeVar.this.baseType(); } > + > + @Override > + public Type bound() { return TypeVar.this.bound; } > }; > } > > diff -r 65e65d5905bc > 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 > Sun Jun 10 12:58:38 2018 +0300 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > Mon Jun 11 15:50:12 2018 +0200 > @@ -2666,10 +2666,10 @@ > * Return list of bounds of the given type variable. > */ > public List getBounds(TypeVar t) { > - if (t.bound.hasTag(NONE)) > + if (t.bound().hasTag(NONE)) > return List.nil(); > - else if (t.bound.isErroneous() || !t.bound.isCompound()) > - return List.of(t.bound); > + else if (t.bound().isErroneous() || !t.bound().isCompound()) > + return List.of(t.bound()); > else if ((erasure(t).tsym.flags() & INTERFACE) == 0) > return interfaces(t).prepend(supertype(t)); > else > diff -r 65e65d5905bc > test/langtools/tools/javac/generics/typevars/AnnoTypeVarBounds.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/langtools/tools/javac/generics/typevars/AnnoTypeVarBounds.java > Mon Jun 11 15:50:12 2018 +0200 > @@ -0,0 +1,15 @@ > +/* > + * @test > + * @bug 8193367 > + * @summary Annotated type variable bounds crash javac > + * @compile AnnoTypeVarBounds.java > + */ > +import java.lang.annotation.ElementType; > +import java.lang.annotation.Target; > + > +class AnnoTypeVarBounds { > + @Target(value = {ElementType.TYPE_USE}) > + @interface A{} > + class Sup { } > + class Sub extends Sup { } > +} From bsrbnd at gmail.com Mon Jun 11 18:42:12 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 11 Jun 2018 20:42:12 +0200 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: Message-ID: That's what I thought too but I wanted a confirmation before doing the whole job... Thanks, Bernard On 11 June 2018 at 19:23, Maurizio Cimadamore wrote: > I think this patch is a good start, but to be complete, we'd need to > completely virtualize access on the 'bound' field, otherwise we risk turning > this into a whack-a-mole exercise. There are e.g. 30 usages in Types alone, > each of those could lead to issues with type annos. > > Maurizio From alex.buckley at oracle.com Mon Jun 11 19:42:26 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 11 Jun 2018 12:42:26 -0700 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> Message-ID: <5B1ED0A2.9020301@oracle.com> On 6/11/2018 3:34 AM, Maurizio Cimadamore wrote: > On 09/06/18 01:17, Alex Buckley wrote: >> On 6/8/2018 6:55 AM, Maurizio Cimadamore wrote: >>> Basically, javac does not consistently skip parenthesis when enforcing >>> foward refs and DA/DU rules. >> >> I want to check that javac skips parentheses for `x` and `this.x` in >> DA/DU rules, but only for `x` in a forward field reference. At this >> time, JLS 8.3.3 detects a forward field reference only if made with a >> simple name; it's a bit late to expand that for JLS11, so I'm a bit >> alarmed by this unified treatment of variable access: > Javac is still implementing the same rule for forward references. E.g. a > forward reference is treated as such only if it's unqualified (e.g. in > the 'x' form); qualified access (this.x) will be allowed, as before. Thanks for clarifying. I filed https://bugs.openjdk.java.net/browse/JDK-8204693 to track the possible tightening of forward field reference (disallow `this.x`) in JLS 8.3.3. A finger-in-the-air guess the impact of this source-incompatible change: 1/4 the impact of banning `_` as a variable name. Alex From cushon at google.com Mon Jun 11 19:56:50 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 11 Jun 2018 12:56:50 -0700 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: <5B1ED0A2.9020301@oracle.com> References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> <5B1ED0A2.9020301@oracle.com> Message-ID: Where does qualified 'this' fit in here (e.g. `TypeName.this.x = 1`)? Should it be handled similarly? Related: JDK-8193904 On Mon, Jun 11, 2018 at 12:43 PM Alex Buckley wrote: > A finger-in-the-air guess the impact of this source-incompatible change: > 1/4 the impact of banning `_` as a variable name. > I'd be happy to help measure the impact of that change once there's a prototype. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jun 11 20:21:11 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 11 Jun 2018 21:21:11 +0100 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> <5B1ED0A2.9020301@oracle.com> Message-ID: <523b603e-d0d3-98f0-74d8-08e43dcceeeb@oracle.com> On 11/06/18 20:56, Liam Miller-Cushon wrote: > Where does qualified 'this' fit in here (e.g. `TypeName.this.x = 1`)? > Should it be handled similarly? My 0.02$ is that they should be handles similarly. > > Related:?JDK-8193904 > > On Mon, Jun 11, 2018 at 12:43 PM Alex Buckley > wrote: > > A finger-in-the-air guess the impact of this source-incompatible > change: > 1/4 the impact of banning `_` as a variable name. > > > I'd be happy to help measure the impact of that change once there's a > prototype. Cool - I can cook up a patch for you to try out Thanks Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Mon Jun 11 21:16:24 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 11 Jun 2018 14:16:24 -0700 Subject: RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference In-Reply-To: <9c59be80-81d2-a776-e7b8-213017303a89@oracle.com> References: <9c59be80-81d2-a776-e7b8-213017303a89@oracle.com> Message-ID: Thanks, done. (I went with 'previous' instead of 'kind' for the local to disambiguate with the parameter, but I don't have a strong opinion about it.) http://cr.openjdk.java.net/~cushon/8203679/webrev.01/ On Mon, Jun 11, 2018 at 3:55 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Looks good - the fix allows recursion to take place and to follow the > links from copy to copy to fetch the right overload kind. > > One minor nit is that we could avoid calling t.getOverloadKind twice e.g. > instead of: > > if (t.getOverloadKind() == null) { > t.setOverloadKind(overloadKind);} else { Assert.check(overloadKind == t.getOverloadKind()); > } > > > > Do: > > OverloadKind kind = t.getOverloadKind(); > if (kind == null) { > t.setOverloadKind(overloadKind);} else { Assert.check(overloadKind == kind); > } > > > Maurizio > > On 09/06/18 20:58, Liam Miller-Cushon wrote: > > Oops, thanks. There was an issue with the webrev: I generated the diff > against the wrong base revision. > > It's fixed now: http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ > > On Sat, Jun 9, 2018 at 6:37 AM B. Blaser wrote: > >> Hi Liam, >> >> At least 'make.at()' looks good ;-) >> I already fixed it here: >> >> https://bugs.openjdk.java.net/browse/JDK-8202372 >> http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac >> >> Bernard >> >> On 9 June 2018 at 04:46, Liam Miller-Cushon wrote: >> > Hi, >> > >> > Please consider the following fix for JDK-8203679. >> > >> > I added some notes to the bug: >> > >> https://bugs.openjdk.java.net/browse/JDK-8203679?focusedCommentId=14186441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14186441 >> > >> > The proposed fix seems harmless assuming this implementation comment is >> > correct: >> > >> >> once the value for overloadKind is determined for a copy, it can be >> safely >> >> forwarded to >> >> the copied tree, we want to profit from that >> > >> > The current logic only propagates the overloadKind to the copied tree >> the >> > first time an overloadKind is set for any copy of that tree. If it was >> > possible to compute different overloadKinds for different copies, that >> > approach wouldn't work. I added an assertion that the computed >> overloadKind >> > is stable to make sure that assumption holds. >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8203679 >> > webrev: http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ >> > >> > Thanks, >> > Liam >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon Jun 11 21:35:54 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 11 Jun 2018 14:35:54 -0700 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> <5B1ED0A2.9020301@oracle.com> Message-ID: <5B1EEB3A.5080405@oracle.com> Qualified-`this` is a fair point to raise, but it's not obvious to me that we should go there. JLS1 was deliberate in limiting the DU/DA and forward-field analyses to simple names -- big payoff for little cost. Many years later, with lots of people having "discovered" that `this.x` slipped through the DU/DA net, it seemed reasonable to catch that too. After all, it's just two terms with a separator, how hard could it be to implement? Well, it turns out that javac got a little tripped up by parentheses, so the answer is "Harder than you would think." With qualified-`this`, the door is open to a blank final access with an arbitrary number of terms -- `int y = com.foo.bar.quux.outer.red.inner.green.this.x + 1;`. You might say, "This code is idiotic. More than any other code, its diversionary tactics need to be stopped." But we are now a long way from catching `int y = x + 1;`, and we're bound to tickle more compiler bugs around qualified names. All that said, if you can count the qualified-`this` names used in your codebase to (i, RHS) access a variable's value, and (ii, LHS) denote the variable to assign to, then it would be interesting info. Alex On 6/11/2018 12:56 PM, Liam Miller-Cushon wrote: > Where does qualified 'this' fit in here (e.g. `TypeName.this.x = 1`)? > Should it be handled similarly? > > Related: JDK-8193904 > > On Mon, Jun 11, 2018 at 12:43 PM Alex Buckley > wrote: > > A finger-in-the-air guess the impact of this source-incompatible > change: > 1/4 the impact of banning `_` as a variable name. > > > I'd be happy to help measure the impact of that change once there's a > prototype. From amaembo at gmail.com Tue Jun 12 01:00:46 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 12 Jun 2018 08:00:46 +0700 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> <5B1ED0A2.9020301@oracle.com> Message-ID: ??, 12 ???? 2018 ?., 2:57 Liam Miller-Cushon : > Where does qualified 'this' fit in here (e.g. `TypeName.this.x = 1`)? > Should it be handled similarly? > I think that the programmer can always cheat. E. g. how about (true?this:this).x? Or ((TypeName)this).x. So there's no point to overcomplicate the compiler further to handle more cases as something will still be unsupported. After all one can always declare instance method like TypeName getThis() { return this;} and use getThis().x. With best regards, Tagir Valeev > Related: JDK-8193904 > > On Mon, Jun 11, 2018 at 12:43 PM Alex Buckley > wrote: > >> A finger-in-the-air guess the impact of this source-incompatible change: >> 1/4 the impact of banning `_` as a variable name. >> > > I'd be happy to help measure the impact of that change once there's a > prototype. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jun 12 02:41:37 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 11 Jun 2018 19:41:37 -0700 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> <5B1ED0A2.9020301@oracle.com> Message-ID: On Mon, Jun 11, 2018 at 2:35 PM Alex Buckley wrote: > All that said, if you can count the qualified-`this` names used in your > codebase to (i, RHS) access a variable's value, and (ii, LHS) denote the > variable to assign to, then it would be interesting info. > I found about 3200 occurrences of (i) and 7100 occurrences of (ii). That's not a large absolute number. (As expected, it's a small fraction of unqualified this accesses.) I take the point that handling arbitrarily complex expressions that result in blank final access is both impossible and not a path we want to go very far down. For what it's worth, though, I think qualified this (even if the type name is fully-qualified) is less obscure than the other examples that have come up. Treating equivalent unqualified and qualified this accesses differently feels surprising to me in a way that, say, treating `(true?this:this).x` and `this.x` differently doesn't. On Mon, Jun 11, 2018 at 6:00 PM Tagir Valeev wrote: > > > ??, 12 ???? 2018 ?., 2:57 Liam Miller-Cushon : > >> Where does qualified 'this' fit in here (e.g. `TypeName.this.x = 1`)? >> Should it be handled similarly? >> > > I think that the programmer can always cheat. E. g. how about > (true?this:this).x? Or ((TypeName)this).x. So there's no point to > overcomplicate the compiler further to handle more cases as something will > still be unsupported. After all one can always declare instance method like > TypeName getThis() { return this;} and use getThis().x. > > With best regards, > Tagir Valeev > > >> Related: JDK-8193904 >> >> On Mon, Jun 11, 2018 at 12:43 PM Alex Buckley >> wrote: >> >>> A finger-in-the-air guess the impact of this source-incompatible change: >>> 1/4 the impact of banning `_` as a variable name. >>> >> >> I'd be happy to help measure the impact of that change once there's a >> prototype. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue Jun 12 05:31:12 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Jun 2018 22:31:12 -0700 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> <5B1ED0A2.9020301@oracle.com> Message-ID: On Jun 11, 2018, at 7:41 PM, Liam Miller-Cushon wrote: > > Treating equivalent unqualified and qualified this accesses differently feels surprising to me in a way that, say, treating `(true?this:this).x` and `this.x` differently doesn't. Yes, it?s a special move for setting blank finals. Back in the day, we considered not allowing qualified this in that position, as a simpler design, but it would have made it impossible for constructors to use the same names for both fields and arguments (or temps). I personally prefer to use consistent names for recurring values, and believe it is good practice. So couldn?t imagine *not* allowing such naming consistency in constructors which after all are at the heart of classes. That and no other reason is why we have the funny alias this.x for x when x is DU, so it can be initialized from a parameter of the same name. From jan.lahoda at oracle.com Tue Jun 12 14:13:36 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 12 Jun 2018 16:13:36 +0200 Subject: RFR: 8204630: generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment In-Reply-To: References: Message-ID: <5B1FD510.1090808@oracle.com> Hi Liam, Thanks for looking at this. I was looking at why the: cs.owner.members().enter(cs); line was added (as I assume that is the biggest offender). The reason is that JavacElements.getTypeElement first tries Symtab.getClass and if that fails to find the class, it tries JavaCompiler.resolveIdent. Before modules, the classes entered in JavacProcessingEnvironment were found by Symtab.getClass; I don't think that is guaranteed in the modular structure. So it may fall back to resolveIdent, and for that to work, for classes in the unnamed package, the class must be a member of that package. So adding the class into the package's scope. So the change in JavacProcessingEnvironment could be, I think, rewritten as: if (cs.owner.kind == PCK) { cs.owner.members().enterIfAbsent(cs); } (that would also prevent an unnecessary complete.) The change in ClassReader seems unnecessary, or am I mistaken? What do you think? Thanks, Jan On 8.6.2018 20:15, Liam Miller-Cushon wrote: > Hi, > > This patch fixes an NPE in JavacProcessingEnvironment when attempting to > generate the class file for an anonymous class from an annotation > processor using Filer#createClassFile. > > bug: https://bugs.openjdk.java.net/browse/JDK-8204630 > webrev: http://cr.openjdk.java.net/~cushon/8204630/webrev.00/ > > Thanks, > Liam From maurizio.cimadamore at oracle.com Tue Jun 12 15:04:22 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 12 Jun 2018 16:04:22 +0100 Subject: RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference In-Reply-To: References: <9c59be80-81d2-a776-e7b8-213017303a89@oracle.com> Message-ID: Looks good to me! Thanks Maurizio On 11/06/18 22:16, Liam Miller-Cushon wrote: > Thanks, done. (I went with 'previous' instead of 'kind' for the local > to disambiguate with the parameter, but I don't have a strong opinion > about it.) > > http://cr.openjdk.java.net/~cushon/8203679/webrev.01/ > > > On Mon, Jun 11, 2018 at 3:55 AM Maurizio Cimadamore > > wrote: > > Looks good - the fix allows recursion to take place and to follow > the links from copy to copy to fetch the right overload kind. > > One minor nit is that we could avoid calling t.getOverloadKind > twice e.g. instead of: > > if (t.getOverloadKind() == null) { > t.setOverloadKind(overloadKind); > } else { > Assert.check(overloadKind == t.getOverloadKind()); > } > > > Do: > > OverloadKind kind = t.getOverloadKind(); > if (kind == null) { > ?t.setOverloadKind(overloadKind); > } else { > Assert.check(overloadKind == kind); > } > > > Maurizio > > On 09/06/18 20:58, Liam Miller-Cushon wrote: >> Oops, thanks. There was an issue with the webrev: I generated the >> diff against the wrong base revision. >> >> It's fixed now: >> http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ >> >> >> On Sat, Jun 9, 2018 at 6:37 AM B. Blaser > > wrote: >> >> Hi Liam, >> >> At least 'make.at ()' looks good ;-) >> I already fixed it here: >> >> https://bugs.openjdk.java.net/browse/JDK-8202372 >> http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac >> >> Bernard >> >> On 9 June 2018 at 04:46, Liam Miller-Cushon >> > wrote: >> > Hi, >> > >> > Please consider the following fix for JDK-8203679. >> > >> > I added some notes to the bug: >> > >> https://bugs.openjdk.java.net/browse/JDK-8203679?focusedCommentId=14186441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14186441 >> > >> > The proposed fix seems harmless assuming this >> implementation comment is >> > correct: >> > >> >> once the value for overloadKind is determined for a copy, >> it can be safely >> >> forwarded to >> >> the copied tree, we want to profit from that >> > >> > The current logic only propagates the overloadKind to the >> copied tree the >> > first time an overloadKind is set for any copy of that >> tree. If it was >> > possible to compute different overloadKinds for different >> copies, that >> > approach wouldn't work. I added an assertion that the >> computed overloadKind >> > is stable to make sure that assumption holds. >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8203679 >> > webrev: >> http://cr.openjdk.java.net/~cushon/8203679/webrev.00/ >> >> > >> > Thanks, >> > Liam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Jun 12 18:05:30 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 12 Jun 2018 11:05:30 -0700 Subject: RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments In-Reply-To: References: <07726f0b-8247-0335-abf9-b40c078ce5c3@oracle.com> <5B1B1C8A.10004@oracle.com> <96846cb7-5f90-02d2-004d-12ff25d3c83d@oracle.com> <5B1ED0A2.9020301@oracle.com> Message-ID: <5B200B6A.9090603@oracle.com> On 6/11/2018 7:41 PM, Liam Miller-Cushon wrote: > On Mon, Jun 11, 2018 at 2:35 PM Alex Buckley > wrote: > > All that said, if you can count the qualified-`this` names used in your > codebase to (i, RHS) access a variable's value, and (ii, LHS) denote the > variable to assign to, then it would be interesting info. > > I found about 3200 occurrences of (i) and 7100 occurrences of (ii). > > That's not a large absolute number. (As expected, it's a small fraction > of unqualified this accesses.) Sorry, I should have been clearer. Let's set assignment aside. I wanted to ask how many times `TYPENAME.this.x` is used to access the value of a blank final field in an enclosing class. However, my question is ill-formed. As below, a blank final field (x) in an enclosing class (A) must be assigned by the end of construction of that class; if it isn't, and the compiler gives an error, then it's moot whether an enclosed class (B) refers to the blank final field via `A.this.x`. public class Top { class A { final int x; class B { int y = A.this.x + 1; } } public static void main(String[] a) { Top.A.B b = new Top().new A().new B(); } } Let's set aside blank final fields, and return to ordinary forward field references. How many times is `this.x` or `TYPENAME.this.x` used to forward-reference a field where using simple `x` would raise an error? Alex From cushon at google.com Wed Jun 13 02:50:59 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 12 Jun 2018 19:50:59 -0700 Subject: RFR: 8204630: generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment In-Reply-To: <5B1FD510.1090808@oracle.com> References: <5B1FD510.1090808@oracle.com> Message-ID: Hi Jan, Thanks for the review, and the explanation! On Tue, Jun 12, 2018 at 7:13 AM Jan Lahoda wrote: > So the change in JavacProcessingEnvironment could be, I think, rewritten > as: > if (cs.owner.kind == PCK) { > cs.owner.members().enterIfAbsent(cs); > } > Done. The change in ClassReader seems unnecessary, or am I mistaken? > Nope, I think you're right. Updated webrev: http://cr.openjdk.java.net/~cushon/8204630/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jun 13 08:05:14 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 13 Jun 2018 09:05:14 +0100 Subject: RFR 8178150: Regression in logic for handling inference stuck constraints In-Reply-To: References: <7ac44223-93da-f4d0-fc20-293b8db99707@oracle.com> <461326c8-f7fe-6f11-95e9-5da6c3ff7fa9@oracle.com> <4055d274-054c-605d-9d80-c8b28d68f431@oracle.com> Message-ID: <21bbe7f3-7e3f-b5ad-0920-e3068621e809@oracle.com> Resurrecting this old thread. There haven't been many comments on the spec side of this. I'm tempted to go ahead and submit (after proper re-testing)? one last iteration of this patch. The focus would be on fixing the regression in stuck constraint resolution that has been affecting the compiler for a while - I plan to leave performance and spec-related issues as part of follow up tasks - I don't think we came across on evidence that this patch regresses on either fronts. Thoughts? Maurizio On 25/10/17 01:33, Maurizio Cimadamore wrote: > > > > On 25/10/17 00:43, Maurizio Cimadamore wrote: >> lead to the same set of input variables; there is actually a very >> tiny difference, in that the latter constraint doesn't add in the >> input variable set the input variables of the constraints coming from >> the return expressions of the lambda - and that's because, I think, >> you can reason about exceptions being thrown by a lambda even if some >> return expressions are 'stuck'. Which means I guess, at least >> hypothetically, you could write a test where the spec picks >> ?/LambdaExpression/ ?_/throws/ T? and decides to process that ahead >> of? ?/LambdaExpression/ ? T? - while in javac the two happen at the >> same time (because javac doesn't have the distinction between these >> two constraints - throws constraints are evaluated as part of >> evaluating the lambda compatibility constraint). > Actually, it's slightly different - that is: > > ?/LambdaExpression/ ?_/throws/ T? > > has a _broader_ set of input variables than > > ??/LambdaExpression/ ? T? > > As the former includes as input variables all variables mentioned in > the return type of the function type derived from T. > > This reduces the mismatch even further - basically what the spec is > saying is that you don't want to process checked exception constraints > in cases where the target contains free variables, because such > variables might affect the set of thrown types by the lambda. > > That said, I will have to think more about specific cases where the > spec would consider ?/LambdaExpression/ ?_// T? ahead of the companion > constraint ?/LambdaExpression/ ?_// throws T?, and see what's the > impact in terms of real code. From the looks of it this looks like (i) > something that was there even before the regression that this patch is > attempting to fix and (ii) probably more in the corner case territory; > while non conformance issues should be treated for what they are, I > think there's enough of a case here to investigate this as part of a > followup issue? > > Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Wed Jun 13 10:09:25 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 13 Jun 2018 12:09:25 +0200 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: Message-ID: Here it is, in attachment. It completely privatizes and virtualizes 'TypeVar.bound'. Apologies for not providing a web-rev, this is still on my to-do list... Any feedback is welcome (tier1 is OK), Bernard On 11 June 2018 at 20:42, B. Blaser wrote: > That's what I thought too but I wanted a confirmation before doing the > whole job... > > Thanks, > Bernard > > On 11 June 2018 at 19:23, Maurizio Cimadamore > wrote: >> I think this patch is a good start, but to be complete, we'd need to >> completely virtualize access on the 'bound' field, otherwise we risk turning >> this into a whack-a-mole exercise. There are e.g. 30 usages in Types alone, >> each of those could lead to issues with type annos. >> >> Maurizio -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8193367.patch Type: text/x-patch Size: 22927 bytes Desc: not available URL: From bsrbnd at gmail.com Wed Jun 13 10:25:11 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 13 Jun 2018 12:25:11 +0200 Subject: RFR JDK-8203813: javac accepts an illegal name as a receiver parameter name In-Reply-To: References: Message-ID: I just fixed two typo mistakes in 'compiler.properties' and in 'WrongReceiver.java', as attached. Any feedback is welcome (tier1 is OK), Bernard On 9 June 2018 at 20:02, B. Blaser wrote: > Hi, > > As noted in the JBS issue, the following example should be rejected > because the receiver parameter name is invalid: > > class C { > C c; > void foo(C c.c) { > } > } > > The suggested fix is to make the parser conform to the receiver > parameter syntax (JLS10 ?8.4.1): > > ReceiverParameter: > {Annotation} UnannType [Identifier .] this > > Tier1 is OK. > > Any feedback is welcome, > Bernard > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203813 -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8203813.patch Type: text/x-patch Size: 2863 bytes Desc: not available URL: From bsrbnd at gmail.com Wed Jun 13 11:01:01 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 13 Jun 2018 13:01:01 +0200 Subject: RFR 8178150: Regression in logic for handling inference stuck constraints In-Reply-To: <21bbe7f3-7e3f-b5ad-0920-e3068621e809@oracle.com> References: <7ac44223-93da-f4d0-fc20-293b8db99707@oracle.com> <461326c8-f7fe-6f11-95e9-5da6c3ff7fa9@oracle.com> <4055d274-054c-605d-9d80-c8b28d68f431@oracle.com> <21bbe7f3-7e3f-b5ad-0920-e3068621e809@oracle.com> Message-ID: On 13 June 2018 at 10:05, Maurizio Cimadamore wrote: > Resurrecting this old thread. > > There haven't been many comments on the spec side of this. > > I'm tempted to go ahead and submit (after proper re-testing) one last > iteration of this patch. The focus would be on fixing the regression in > stuck constraint resolution that has been affecting the compiler for a while > - I plan to leave performance and spec-related issues as part of follow up > tasks - I don't think we came across on evidence that this patch regresses > on either fronts. > > Thoughts? > > Maurizio I looked again at this issue some time ago and I didn't have any objection with your latest fix. I didn't saw any clear and major non-conformity issue with the JLS and further optimization isn't essential (adding a cache may be brittle and other suggestions I made are probably more on cleanup than on performance gain). So, without any conformance & performance regression evidence, I think this looks good. Bernard From vicente.romero at oracle.com Wed Jun 13 12:43:12 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 13 Jun 2018 08:43:12 -0400 Subject: RFR 8178150: Regression in logic for handling inference stuck constraints In-Reply-To: <21bbe7f3-7e3f-b5ad-0920-e3068621e809@oracle.com> References: <7ac44223-93da-f4d0-fc20-293b8db99707@oracle.com> <461326c8-f7fe-6f11-95e9-5da6c3ff7fa9@oracle.com> <4055d274-054c-605d-9d80-c8b28d68f431@oracle.com> <21bbe7f3-7e3f-b5ad-0920-e3068621e809@oracle.com> Message-ID: <48133cd4-afab-5c56-629f-903f8f2a3b71@oracle.com> On 06/13/2018 04:05 AM, Maurizio Cimadamore wrote: > > Resurrecting this old thread. > > There haven't been many comments on the spec side of this. > > I'm tempted to go ahead and submit (after proper re-testing) one last > iteration of this patch. The focus would be on fixing the regression > in stuck constraint resolution that has been affecting the compiler > for a while - I plan to leave performance and spec-related issues as > part of follow up tasks - I don't think we came across on evidence > that this patch regresses on either fronts. > > Thoughts? > go for it :) > Maurizio > Vicente > > On 25/10/17 01:33, Maurizio Cimadamore wrote: >> >> >> >> On 25/10/17 00:43, Maurizio Cimadamore wrote: >>> lead to the same set of input variables; there is actually a very >>> tiny difference, in that the latter constraint doesn't add in the >>> input variable set the input variables of the constraints coming >>> from the return expressions of the lambda - and that's because, I >>> think, you can reason about exceptions being thrown by a lambda even >>> if some return expressions are 'stuck'. Which means I guess, at >>> least hypothetically, you could write a test where the spec picks >>> ?/LambdaExpression/ ?_/throws/ T? and decides to process that ahead >>> of? ?/LambdaExpression/ ? T? - while in javac the two happen at the >>> same time (because javac doesn't have the distinction between these >>> two constraints - throws constraints are evaluated as part of >>> evaluating the lambda compatibility constraint). >> Actually, it's slightly different - that is: >> >> ?/LambdaExpression/ ?_/throws/ T? >> >> has a _broader_ set of input variables than >> >> ??/LambdaExpression/ ? T? >> >> As the former includes as input variables all variables mentioned in >> the return type of the function type derived from T. >> >> This reduces the mismatch even further - basically what the spec is >> saying is that you don't want to process checked exception >> constraints in cases where the target contains free variables, >> because such variables might affect the set of thrown types by the >> lambda. >> >> That said, I will have to think more about specific cases where the >> spec would consider ?/LambdaExpression/ ?_// T? ahead of the >> companion constraint ?/LambdaExpression/ ?_// throws T?, and see >> what's the impact in terms of real code. From the looks of it this >> looks like (i) something that was there even before the regression >> that this patch is attempting to fix and (ii) probably more in the >> corner case territory; while non conformance issues should be treated >> for what they are, I think there's enough of a case here to >> investigate this as part of a followup issue? >> >> Maurizio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jun 13 14:41:50 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 13 Jun 2018 10:41:50 -0400 Subject: RFR JDK-8203813: javac accepts an illegal name as a receiver parameter name In-Reply-To: References: Message-ID: <60089d18-c7e8-115b-6f10-2d4b95507929@oracle.com> Hi Bernard, Thanks for the patch, it looks good to me, I will push it, Vicente On 06/13/2018 06:25 AM, B. Blaser wrote: > I just fixed two typo mistakes in 'compiler.properties' and in > 'WrongReceiver.java', as attached. > > Any feedback is welcome (tier1 is OK), > Bernard > > On 9 June 2018 at 20:02, B. Blaser wrote: >> Hi, >> >> As noted in the JBS issue, the following example should be rejected >> because the receiver parameter name is invalid: >> >> class C { >> C c; >> void foo(C c.c) { >> } >> } >> >> The suggested fix is to make the parser conform to the receiver >> parameter syntax (JLS10 ?8.4.1): >> >> ReceiverParameter: >> {Annotation} UnannType [Identifier .] this >> >> Tier1 is OK. >> >> Any feedback is welcome, >> Bernard >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203813 From maurizio.cimadamore at oracle.com Wed Jun 13 16:01:25 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 13 Jun 2018 17:01:25 +0100 Subject: RFR 8178150: Regression in logic for handling inference stuck constraints In-Reply-To: <48133cd4-afab-5c56-629f-903f8f2a3b71@oracle.com> References: <7ac44223-93da-f4d0-fc20-293b8db99707@oracle.com> <461326c8-f7fe-6f11-95e9-5da6c3ff7fa9@oracle.com> <4055d274-054c-605d-9d80-c8b28d68f431@oracle.com> <21bbe7f3-7e3f-b5ad-0920-e3068621e809@oracle.com> <48133cd4-afab-5c56-629f-903f8f2a3b71@oracle.com> Message-ID: <549fb213-db45-a929-8b99-3c180059b626@oracle.com> Here's a finalized webrev; I've incorporated few comments from this discussion: * have predictable inference var resolution (B. Blaser) * change stream back to for each (A. Golovnin) Webrev: http://cr.openjdk.java.net/~mcimadamore/8178150_v3/ Cheers Maurizio On 13/06/18 13:43, Vicente Romero wrote: > > > On 06/13/2018 04:05 AM, Maurizio Cimadamore wrote: >> >> Resurrecting this old thread. >> >> There haven't been many comments on the spec side of this. >> >> I'm tempted to go ahead and submit (after proper re-testing) one last >> iteration of this patch. The focus would be on fixing the regression >> in stuck constraint resolution that has been affecting the compiler >> for a while - I plan to leave performance and spec-related issues as >> part of follow up tasks - I don't think we came across on evidence >> that this patch regresses on either fronts. >> >> Thoughts? >> > > go for it :) > >> Maurizio >> > > Vicente > >> >> On 25/10/17 01:33, Maurizio Cimadamore wrote: >>> >>> >>> >>> On 25/10/17 00:43, Maurizio Cimadamore wrote: >>>> lead to the same set of input variables; there is actually a very >>>> tiny difference, in that the latter constraint doesn't add in the >>>> input variable set the input variables of the constraints coming >>>> from the return expressions of the lambda - and that's because, I >>>> think, you can reason about exceptions being thrown by a lambda >>>> even if some return expressions are 'stuck'. Which means I guess, >>>> at least hypothetically, you could write a test where the spec >>>> picks ?/LambdaExpression/ ?_/throws/ T? and decides to process that >>>> ahead of? ?/LambdaExpression/ ? T? - while in javac the two happen >>>> at the same time (because javac doesn't have the distinction >>>> between these two constraints - throws constraints are evaluated as >>>> part of evaluating the lambda compatibility constraint). >>> Actually, it's slightly different - that is: >>> >>> ?/LambdaExpression/ ?_/throws/ T? >>> >>> has a _broader_ set of input variables than >>> >>> ??/LambdaExpression/ ? T? >>> >>> As the former includes as input variables all variables mentioned in >>> the return type of the function type derived from T. >>> >>> This reduces the mismatch even further - basically what the spec is >>> saying is that you don't want to process checked exception >>> constraints in cases where the target contains free variables, >>> because such variables might affect the set of thrown types by the >>> lambda. >>> >>> That said, I will have to think more about specific cases where the >>> spec would consider ?/LambdaExpression/ ?_// T? ahead of the >>> companion constraint ?/LambdaExpression/ ?_// throws T?, and see >>> what's the impact in terms of real code. From the looks of it this >>> looks like (i) something that was there even before the regression >>> that this patch is attempting to fix and (ii) probably more in the >>> corner case territory; while non conformance issues should be >>> treated for what they are, I think there's enough of a case here to >>> investigate this as part of a followup issue? >>> >>> Maurizio >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jun 13 17:29:01 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 13 Jun 2018 13:29:01 -0400 Subject: RFR: JDK-8196618: Create API to list supported values for javac --release option In-Reply-To: <5B1A89F8.2010909@oracle.com> References: <5B17D344.1000603@oracle.com> <885994eb-7cec-6d3a-752b-a4a71471d742@oracle.com> <5B1A89F8.2010909@oracle.com> Message-ID: <76a9c11d-26b0-6602-671a-cd92df9b5645@oracle.com> looks good to me, Thanks, Vicente On 06/08/2018 09:51 AM, Jan Lahoda wrote: > Hi Stuart, > > Thanks for your comments! I've updated the patch according to them > (simplifying the join, cleaning up the logic in tests, removing the > tests from the list of ignored tests). The updated patch is here: > http://cr.openjdk.java.net/~jlahoda/8196618/webrev.01/ > > On 8.6.2018 00:53, Stuart Marks wrote: >> Hi Jan, >> >> Thanks for looking at jdeprscan. This is very timely. Michel was >> "bugging" me about some JDK 11 bugs (which are in jdeprscan) and I was >> looking at them, and I thought, I need to ask Jan about how to get the >> set of supported release values. And here we are! >> >> In jdeprscan/Main.java there's a bit of ad-hoc logic to determine >> whether a particular release is modular and whether it has the Java EE >> modules. Offhand I can't think of a better way to do this, but maybe >> this is something we can put in the back of our heads and think about a >> bit. > > I agree the logic there is a ad-hoc. I was thinking of using > ALL-SYSTEM, but that would mean updating the TraverseProc, probably > taking all modules and using those whose names start with "java.", so > I decided to keep it similar to what existed before. But I can try > this, if you prefer. > > Thanks, > ??? Jan > >> >> For the help message, it turns out that String.join() consumes an >> Iterable, so you can probably just do something like >> >> ???? String supportedReleases = String.join("|", >> pp.getSupportedPlatformNames()); >> >> instead of creating a Stream. >> >> For jdeprscan/TestRelease.java, why not just iterate over all supported >> platform names, calling invoke() on each one? I'm not sure what the >> filtering and "minimal coverage" logic is supposed to accomplish. If >> they're not in the set of supported platforms, forcing "9" and "10" >> seems likely to create an error. And we still want to test the old, >> non-modular releases. >> >> Note further that TestRelease.java is currently on the problem list, so >> it's not getting run at the moment. I'm ok if you go ahead with those >> changes, as it doesn't matter much. I'll need to revisit this test at >> some point anyway. >> >> s'marks >> >> >> On 6/6/18 5:27 AM, Jan Lahoda wrote: >>> Hi, >>> >>> This enhancement requests that test need to be able to query the list >>> of supported --release options. This is possible using the >>> JDKPlatformProvider, so I updated two tests where this seemed useful. >>> But while doing this, it turned out the jdeprscan was not yet fully >>> updated to JDK 11 (still refers to java.se.ee and did not list 11 in >>> the help text for the --release option), so I updated that as well. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196618 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8196618/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> ???? Jan >>> From bsrbnd at gmail.com Wed Jun 13 18:34:40 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 13 Jun 2018 20:34:40 +0200 Subject: RFR 8178150: Regression in logic for handling inference stuck constraints In-Reply-To: <549fb213-db45-a929-8b99-3c180059b626@oracle.com> References: <7ac44223-93da-f4d0-fc20-293b8db99707@oracle.com> <461326c8-f7fe-6f11-95e9-5da6c3ff7fa9@oracle.com> <4055d274-054c-605d-9d80-c8b28d68f431@oracle.com> <21bbe7f3-7e3f-b5ad-0920-e3068621e809@oracle.com> <48133cd4-afab-5c56-629f-903f8f2a3b71@oracle.com> <549fb213-db45-a929-8b99-3c180059b626@oracle.com> Message-ID: On 13 June 2018 at 18:01, Maurizio Cimadamore wrote: > Here's a finalized webrev; I've incorporated few comments from this > discussion: > > * have predictable inference var resolution (B. Blaser) > * change stream back to for each (A. Golovnin) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8178150_v3/ > > Cheers > Maurizio Looks great! Bernard From vicente.romero at oracle.com Thu Jun 14 03:56:03 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 13 Jun 2018 23:56:03 -0400 Subject: RFR 8178150: Regression in logic for handling inference stuck constraints In-Reply-To: <549fb213-db45-a929-8b99-3c180059b626@oracle.com> References: <7ac44223-93da-f4d0-fc20-293b8db99707@oracle.com> <461326c8-f7fe-6f11-95e9-5da6c3ff7fa9@oracle.com> <4055d274-054c-605d-9d80-c8b28d68f431@oracle.com> <21bbe7f3-7e3f-b5ad-0920-e3068621e809@oracle.com> <48133cd4-afab-5c56-629f-903f8f2a3b71@oracle.com> <549fb213-db45-a929-8b99-3c180059b626@oracle.com> Message-ID: looks good, Vicente On 06/13/2018 12:01 PM, Maurizio Cimadamore wrote: > > Here's a finalized webrev; I've incorporated few comments from this > discussion: > > * have predictable inference var resolution (B. Blaser) > * change stream back to for each (A. Golovnin) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8178150_v3/ > > Cheers > Maurizio > > > > On 13/06/18 13:43, Vicente Romero wrote: >> >> >> On 06/13/2018 04:05 AM, Maurizio Cimadamore wrote: >>> >>> Resurrecting this old thread. >>> >>> There haven't been many comments on the spec side of this. >>> >>> I'm tempted to go ahead and submit (after proper re-testing)? one >>> last iteration of this patch. The focus would be on fixing the >>> regression in stuck constraint resolution that has been affecting >>> the compiler for a while - I plan to leave performance and >>> spec-related issues as part of follow up tasks - I don't think we >>> came across on evidence that this patch regresses on either fronts. >>> >>> Thoughts? >>> >> >> go for it :) >> >>> Maurizio >>> >> >> Vicente >> >>> >>> On 25/10/17 01:33, Maurizio Cimadamore wrote: >>>> >>>> >>>> >>>> On 25/10/17 00:43, Maurizio Cimadamore wrote: >>>>> lead to the same set of input variables; there is actually a very >>>>> tiny difference, in that the latter constraint doesn't add in the >>>>> input variable set the input variables of the constraints coming >>>>> from the return expressions of the lambda - and that's because, I >>>>> think, you can reason about exceptions being thrown by a lambda >>>>> even if some return expressions are 'stuck'. Which means I guess, >>>>> at least hypothetically, you could write a test where the spec >>>>> picks ?/LambdaExpression/ ?_/throws/ T? and decides to process >>>>> that ahead of? ?/LambdaExpression/ ? T? - while in javac the two >>>>> happen at the same time (because javac doesn't have the >>>>> distinction between these two constraints - throws constraints are >>>>> evaluated as part of evaluating the lambda compatibility constraint). >>>> Actually, it's slightly different - that is: >>>> >>>> ?/LambdaExpression/ ?_/throws/ T? >>>> >>>> has a _broader_ set of input variables than >>>> >>>> ??/LambdaExpression/ ? T? >>>> >>>> As the former includes as input variables all variables mentioned >>>> in the return type of the function type derived from T. >>>> >>>> This reduces the mismatch even further - basically what the spec is >>>> saying is that you don't want to process checked exception >>>> constraints in cases where the target contains free variables, >>>> because such variables might affect the set of thrown types by the >>>> lambda. >>>> >>>> That said, I will have to think more about specific cases where the >>>> spec would consider ?/LambdaExpression/ ?_// T? ahead of the >>>> companion constraint ?/LambdaExpression/ ?_// throws T?, and see >>>> what's the impact in terms of real code. From the looks of it this >>>> looks like (i) something that was there even before the regression >>>> that this patch is attempting to fix and (ii) probably more in the >>>> corner case territory; while non conformance issues should be >>>> treated for what they are, I think there's enough of a case here to >>>> investigate this as part of a followup issue? >>>> >>>> Maurizio >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Jun 14 17:03:50 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Jun 2018 18:03:50 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: Message-ID: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Looks ok, I think I'd rather prefer setBound to bound(arg), as the name you chose doesn't make assignment explicit. Long term, I think we should find ways to avoid mutating the bound after creation... but I did some experimental work on this, and it's not a piece of cake, as you often need mutation when handling recursive bounds - e.g. set some initial bound first, then do a subst and set final bounds later (I think there's a bunch of methods in Types that use this idiom). Maurizio On 13/06/18 11:09, B. Blaser wrote: > Here it is, in attachment. > It completely privatizes and virtualizes 'TypeVar.bound'. > > Apologies for not providing a web-rev, this is still on my to-do list... > > Any feedback is welcome (tier1 is OK), > Bernard > > On 11 June 2018 at 20:42, B. Blaser wrote: >> That's what I thought too but I wanted a confirmation before doing the >> whole job... >> >> Thanks, >> Bernard >> >> On 11 June 2018 at 19:23, Maurizio Cimadamore >> wrote: >>> I think this patch is a good start, but to be complete, we'd need to >>> completely virtualize access on the 'bound' field, otherwise we risk turning >>> this into a whack-a-mole exercise. There are e.g. 30 usages in Types alone, >>> each of those could lead to issues with type annos. >>> >>> Maurizio From maurizio.cimadamore at oracle.com Thu Jun 14 18:25:53 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Jun 2018 19:25:53 +0100 Subject: RFR 8195293: Issue more comprehensive warnings for use of "var" in earlier source versions Message-ID: <897f01b0-c776-af3e-339f-0010bf7d22bc@oracle.com> Hi, this is a followup of the issue fixed by Joe some time ago [1]. The goal is to issue warnings when programs are using 'var' and -source < 10. The original fix made by Joe detects a subset of the cases - more specifically it doesn't detect uses in type positions. This fix, which was briefly discussed back then - but dropped because of the risk (we were at a fairly late stage of the release cycle), resolves that problem. It is somewhat convoluted as it needs to avoid generating the same warning multiple times. As you can see from the golden test output, the compiler now warns about a lot more uses of 'var' than before. Note that I've also fixed a resource key which is using a diag argument simply to say ''var'', which can and should be hardwired in the resource file, instead of having the compiler passing strings around. Cheers Maurizio [1] - http://mail.openjdk.java.net/pipermail/compiler-dev/2018-January/011518.html From maurizio.cimadamore at oracle.com Thu Jun 14 18:26:40 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Jun 2018 19:26:40 +0100 Subject: RFR 8195293: Issue more comprehensive warnings for use of "var" in earlier source versions In-Reply-To: <897f01b0-c776-af3e-339f-0010bf7d22bc@oracle.com> References: <897f01b0-c776-af3e-339f-0010bf7d22bc@oracle.com> Message-ID: Whoops - webrev here http://cr.openjdk.java.net/~mcimadamore/8195293/ Maurizio On 14/06/18 19:25, Maurizio Cimadamore wrote: > Hi, > this is a followup of the issue fixed by Joe some time ago [1]. The > goal is to issue warnings when programs are using 'var' and -source < > 10. The original fix made by Joe detects a subset of the cases - more > specifically it doesn't detect uses in type positions. This fix, which > was briefly discussed back then - but dropped because of the risk (we > were at a fairly late stage of the release cycle), resolves that > problem. It is somewhat convoluted as it needs to avoid generating the > same warning multiple times. > > As you can see from the golden test output, the compiler now warns > about a lot more uses of 'var' than before. > > Note that I've also fixed a resource key which is using a diag > argument simply to say ''var'', which can and should be hardwired in > the resource file, instead of having the compiler passing strings around. > > Cheers > Maurizio > > [1] - > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-January/011518.html > From jan.lahoda at oracle.com Fri Jun 15 13:47:58 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 15 Jun 2018 15:47:58 +0200 Subject: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError() Message-ID: <5B23C38E.9060402@oracle.com> Hi, The Nashorn APIs have been enhanced in JDK 8 updates. The proposal here is to update the historical data for --release 8 to JDK 8u40. Note this includes removal of: jdk.nashorn.api.scripting.NashornException.ENGINE_SCRIPT_SOURCE_NAME and: jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(...) and a change of: jdk.nashorn.api.scripting.ScriptUtils.wrap(...) Bug: https://bugs.openjdk.java.net/browse/JDK-8203814 Webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.00/ How does this look? Thanks, Jan From hannes.wallnoefer at oracle.com Fri Jun 15 14:52:08 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 15 Jun 2018 16:52:08 +0200 Subject: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError() In-Reply-To: <5B23C38E.9060402@oracle.com> References: <5B23C38E.9060402@oracle.com> Message-ID: <319CCAE9-FF1F-450B-A61F-A14F57E30DE2@oracle.com> Thanks for helping out with this, Jan. Unfortunately I found another change that was backported to 8u102 that changes the signatures of ScriptUtils makeSynchronizedFunction(?) and wrap(?) methods (again). https://bugs.openjdk.java.net/browse/JDK-8148379 I?m sorry about this, I should have checked when you first asked me about it. Otherwise the patch looks good to me. Hannes > Am 15.06.2018 um 15:47 schrieb Jan Lahoda : > > Hi, > > The Nashorn APIs have been enhanced in JDK 8 updates. The proposal here is to update the historical data for --release 8 to JDK 8u40. > > Note this includes removal of: > jdk.nashorn.api.scripting.NashornException.ENGINE_SCRIPT_SOURCE_NAME > and: > jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(...) > and a change of: > jdk.nashorn.api.scripting.ScriptUtils.wrap(...) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203814 > Webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.00/ > > How does this look? > > Thanks, > Jan From maurizio.cimadamore at oracle.com Fri Jun 15 18:05:57 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Jun 2018 19:05:57 +0100 Subject: RFR 8203838: javac performance regression in 11+11 Message-ID: Hi, this patch fixes a performance regression that has been picked up by our internal test runs. Vicente did a great job at fixing some of the excessive exception sharing that takes place in the compiler, as part of [1], [2]. However, there's a very hot execution path (Resolve::reportMC) in which we can't affort allocating a new exception every time a method check fails. This patch reintroduce some flyweight pattern for that particular case only (along with some documentation which explains the hack :-)). Webrev here: http://cr.openjdk.java.net/~mcimadamore/8203838/ Cheers Maurizio From maurizio.cimadamore at oracle.com Fri Jun 15 18:07:12 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Jun 2018 19:07:12 +0100 Subject: RFR 8203838: javac performance regression in 11+11 In-Reply-To: References: Message-ID: <137a3c71-3f18-5a52-52aa-861ee44e3618@oracle.com> Related issues: [1] - https://bugs.openjdk.java.net/browse/JDK-8202157 [2] - https://bugs.openjdk.java.net/browse/JDK-8201281 Maurizio On 15/06/18 19:05, Maurizio Cimadamore wrote: > Hi, > this patch fixes a performance regression that has been picked up by > our internal test runs. Vicente did a great job at fixing some of the > excessive exception sharing that takes place in the compiler, as part > of [1], [2]. However, there's a very hot execution path > (Resolve::reportMC) in which we can't affort allocating a new > exception every time a method check fails. > > This patch reintroduce some flyweight pattern for that particular case > only (along with some documentation which explains the hack :-)). > > Webrev here: > > http://cr.openjdk.java.net/~mcimadamore/8203838/ > > Cheers > Maurizio > > From vicente.romero at oracle.com Fri Jun 15 18:11:30 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 15 Jun 2018 14:11:30 -0400 Subject: RFR 8203838: javac performance regression in 11+11 In-Reply-To: References: Message-ID: looks good, Thanks, Vicente On 06/15/2018 02:05 PM, Maurizio Cimadamore wrote: > Hi, > this patch fixes a performance regression that has been picked up by > our internal test runs. Vicente did a great job at fixing some of the > excessive exception sharing that takes place in the compiler, as part > of [1], [2]. However, there's a very hot execution path > (Resolve::reportMC) in which we can't affort allocating a new > exception every time a method check fails. > > This patch reintroduce some flyweight pattern for that particular case > only (along with some documentation which explains the hack :-)). > > Webrev here: > > http://cr.openjdk.java.net/~mcimadamore/8203838/ > > Cheers > Maurizio > > From bsrbnd at gmail.com Sat Jun 16 12:13:54 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 16 Jun 2018 14:13:54 +0200 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: I've attached the nomenclature change you suggested. I agree that 'setBound()' is more expressive. Tier1 is still OK. Cheers, Bernard On 14 June 2018 at 19:03, Maurizio Cimadamore wrote: > Looks ok, I think I'd rather prefer setBound to bound(arg), as the name you > chose doesn't make assignment explicit. > > Long term, I think we should find ways to avoid mutating the bound after > creation... but I did some experimental work on this, and it's not a piece > of cake, as you often need mutation when handling recursive bounds - e.g. > set some initial bound first, then do a subst and set final bounds later (I > think there's a bunch of methods in Types that use this idiom). > > Maurizio > > > > > On 13/06/18 11:09, B. Blaser wrote: >> >> Here it is, in attachment. >> It completely privatizes and virtualizes 'TypeVar.bound'. >> >> Apologies for not providing a web-rev, this is still on my to-do list... >> >> Any feedback is welcome (tier1 is OK), >> Bernard >> >> On 11 June 2018 at 20:42, B. Blaser wrote: >>> >>> That's what I thought too but I wanted a confirmation before doing the >>> whole job... >>> >>> Thanks, >>> Bernard >>> >>> On 11 June 2018 at 19:23, Maurizio Cimadamore >>> wrote: >>>> >>>> I think this patch is a good start, but to be complete, we'd need to >>>> completely virtualize access on the 'bound' field, otherwise we risk >>>> turning >>>> this into a whack-a-mole exercise. There are e.g. 30 usages in Types >>>> alone, >>>> each of those could lead to issues with type annos. >>>> >>>> Maurizio > > -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8193367b.patch Type: text/x-patch Size: 22996 bytes Desc: not available URL: From bsrbnd at gmail.com Sat Jun 16 22:20:21 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 17 Jun 2018 00:20:21 +0200 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException Message-ID: Hi, As noted in the JBS issue, the following example fails at run-time with a CCE: List.of('x', 'y').stream().max((a, b) -> { return List.of(a).get(0); }); The interesting point here is that removing 'return' makes it run successfully: List.of('x', 'y').stream().max((a, b) -> List.of(a).get(0)); The problem seems to be in 'TransType.visitReturn()'. The lambda method doesn't yet exist ('currentMethod == null', see 'TransType.visitLambda()') causing the return expression type to be set to the erasure of 'List.get()' (= Object) which further causes the type conversion problem (see 'LambdaToMethod.makeLambdaStatementBody()'). The suggested fix (here under) is to keep the original erased expression type (= Character) if 'currentMethod == null'. Tier1 is OK. Any feedback is welcome, Bernard diff -r ed8de3d0cd28 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java Sat Jun 16 10:10:54 2018 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java Sat Jun 16 21:16:33 2018 +0200 @@ -601,7 +601,8 @@ } public void visitReturn(JCReturn tree) { - tree.expr = translate(tree.expr, currentMethod != null ? types.erasure(currentMethod.type).getReturnType() : null); + tree.expr = translate(tree.expr, currentMethod != null ? types.erasure(currentMethod.type).getReturnType() : + tree.expr != null ? types.erasure(tree.expr.type) : null); result = tree; } From vicente.romero at oracle.com Mon Jun 18 00:53:42 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Sun, 17 Jun 2018 20:53:42 -0400 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: bike shedding: shouldn't it be getBound / setBound instead of bound / setBound Vicente On 06/16/2018 08:13 AM, B. Blaser wrote: > I've attached the nomenclature change you suggested. > I agree that 'setBound()' is more expressive. > Tier1 is still OK. > > Cheers, > Bernard > > On 14 June 2018 at 19:03, Maurizio Cimadamore > wrote: >> Looks ok, I think I'd rather prefer setBound to bound(arg), as the name you >> chose doesn't make assignment explicit. >> >> Long term, I think we should find ways to avoid mutating the bound after >> creation... but I did some experimental work on this, and it's not a piece >> of cake, as you often need mutation when handling recursive bounds - e.g. >> set some initial bound first, then do a subst and set final bounds later (I >> think there's a bunch of methods in Types that use this idiom). >> >> Maurizio >> >> >> >> >> On 13/06/18 11:09, B. Blaser wrote: >>> Here it is, in attachment. >>> It completely privatizes and virtualizes 'TypeVar.bound'. >>> >>> Apologies for not providing a web-rev, this is still on my to-do list... >>> >>> Any feedback is welcome (tier1 is OK), >>> Bernard >>> >>> On 11 June 2018 at 20:42, B. Blaser wrote: >>>> That's what I thought too but I wanted a confirmation before doing the >>>> whole job... >>>> >>>> Thanks, >>>> Bernard >>>> >>>> On 11 June 2018 at 19:23, Maurizio Cimadamore >>>> wrote: >>>>> I think this patch is a good start, but to be complete, we'd need to >>>>> completely virtualize access on the 'bound' field, otherwise we risk >>>>> turning >>>>> this into a whack-a-mole exercise. There are e.g. 30 usages in Types >>>>> alone, >>>>> each of those could lead to issues with type annos. >>>>> >>>>> Maurizio >> From vicente.romero at oracle.com Mon Jun 18 02:29:03 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Sun, 17 Jun 2018 22:29:03 -0400 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: References: Message-ID: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> Hi, Not sure about this one. I think that the type of the return expression inside a lambda should be erased to the erasure of the return type of the lambda type. The `currentMethod` field at TransTypes is just a carrier to actually access the erasure of the return type of the current method, and this access happens only inside visitReturn. So I wonder if we actually should have a field in TransTypes that could hold that erasure directly. At TransTypes.visitMethodDef we could have: theField = types.erasure(tree.type.getReturnType()); and at TransTypes.visitLambda it could be: theField = types.erasure(tree.getDescriptorType(types).asMethodType().restype); of course with a better name, and then at TransTypes.visitReturn, it could use the field to erase the returned expression. Thanks, Vicente On 06/16/2018 06:20 PM, B. Blaser wrote: > Hi, > > As noted in the JBS issue, the following example fails at run-time with a CCE: > > List.of('x', 'y').stream().max((a, b) -> { return List.of(a).get(0); }); > > The interesting point here is that removing 'return' makes it run successfully: > > List.of('x', 'y').stream().max((a, b) -> List.of(a).get(0)); > > The problem seems to be in 'TransType.visitReturn()'. The lambda > method doesn't yet exist ('currentMethod == null', see > 'TransType.visitLambda()') causing the return expression type to be > set to the erasure of 'List.get()' (= Object) which further causes the > type conversion problem (see > 'LambdaToMethod.makeLambdaStatementBody()'). > > The suggested fix (here under) is to keep the original erased > expression type (= Character) if 'currentMethod == null'. > > Tier1 is OK. > > Any feedback is welcome, > Bernard > > diff -r ed8de3d0cd28 > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java > Sat Jun 16 10:10:54 2018 +0100 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java > Sat Jun 16 21:16:33 2018 +0200 > @@ -601,7 +601,8 @@ > } > > public void visitReturn(JCReturn tree) { > - tree.expr = translate(tree.expr, currentMethod != null ? > types.erasure(currentMethod.type).getReturnType() : null); > + tree.expr = translate(tree.expr, currentMethod != null ? > types.erasure(currentMethod.type).getReturnType() : > + tree.expr != null ? types.erasure(tree.expr.type) : null); > result = tree; > } From bsrbnd at gmail.com Mon Jun 18 13:30:08 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 18 Jun 2018 15:30:08 +0200 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> Message-ID: The suggested fix is intended to reflect the actual successful behavior without 'return': http://hg.openjdk.java.net/jdk/jdk/file/8f1d5d706bdd/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java#l540 If 'tree.body.type != null', the single expression without 'return' is translated with 'pt = erasure(tree.body.type)' becoming '(Character)List.of(a).get(0)'. Further in 'LambdaToMethod.makeLambdaExpressionBody()' the 'return' is added (along with another type conversion to the lambda return type when necessary): http://hg.openjdk.java.net/jdk/jdk/file/8f1d5d706bdd/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l660 ... ending with '{ return (Character)List.of(a).get(0); }' which will later be successfully unboxed. So, the suggested fix is performing the same thing with 'return': http://hg.openjdk.java.net/jdk/jdk/file/8f1d5d706bdd/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java#l604 If 'currentMethod == null' means we are in a lambda and the fix adds 'pt = types.erasure(tree.expr.type)' if 'tree.expr != null' (an expression is returned), ending also with '{ return (Character)List.of(a).get(0); }' which will later be successfully unboxed. I guess the current patch is rather safe because it mirrors the actual behavior without 'return' (it simply keeps the original expression typing) but I'll take a look at your suggestion too. What do you think? Thanks, Bernard On 18 June 2018 at 04:29, Vicente Romero wrote: > Hi, > > Not sure about this one. I think that the type of the return expression > inside a lambda should be erased to the erasure of the return type of the > lambda type. The `currentMethod` field at TransTypes is just a carrier to > actually access the erasure of the return type of the current method, and > this access happens only inside visitReturn. So I wonder if we actually > should have a field in TransTypes that could hold that erasure directly. At > TransTypes.visitMethodDef we could have: > > theField = types.erasure(tree.type.getReturnType()); > > and at TransTypes.visitLambda it could be: > > theField = > types.erasure(tree.getDescriptorType(types).asMethodType().restype); > > of course with a better name, and then at TransTypes.visitReturn, it could > use the field to erase the returned expression. > > Thanks, > Vicente > > > On 06/16/2018 06:20 PM, B. Blaser wrote: >> >> Hi, >> >> As noted in the JBS issue, the following example fails at run-time with a >> CCE: >> >> List.of('x', 'y').stream().max((a, b) -> { return List.of(a).get(0); >> }); >> >> The interesting point here is that removing 'return' makes it run >> successfully: >> >> List.of('x', 'y').stream().max((a, b) -> List.of(a).get(0)); >> >> The problem seems to be in 'TransType.visitReturn()'. The lambda >> method doesn't yet exist ('currentMethod == null', see >> 'TransType.visitLambda()') causing the return expression type to be >> set to the erasure of 'List.get()' (= Object) which further causes the >> type conversion problem (see >> 'LambdaToMethod.makeLambdaStatementBody()'). >> >> The suggested fix (here under) is to keep the original erased >> expression type (= Character) if 'currentMethod == null'. >> >> Tier1 is OK. >> >> Any feedback is welcome, >> Bernard >> >> diff -r ed8de3d0cd28 >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java >> Sat Jun 16 10:10:54 2018 +0100 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java >> Sat Jun 16 21:16:33 2018 +0200 >> @@ -601,7 +601,8 @@ >> } >> >> public void visitReturn(JCReturn tree) { >> - tree.expr = translate(tree.expr, currentMethod != null ? >> types.erasure(currentMethod.type).getReturnType() : null); >> + tree.expr = translate(tree.expr, currentMethod != null ? >> types.erasure(currentMethod.type).getReturnType() : >> + tree.expr != null ? types.erasure(tree.expr.type) : >> null); >> result = tree; >> } > > From bsrbnd at gmail.com Mon Jun 18 13:44:00 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 18 Jun 2018 15:44:00 +0200 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: Honestly, I find 'TypeVar.getBound()' a bit heavy and not compliant with the existing 'TypeVar.baseType()' naming. But if everybody agrees with 'getBound()/setBound()' we can change it. What should we do? Bernard On 18 June 2018 at 02:53, Vicente Romero wrote: > bike shedding: shouldn't it be getBound / setBound instead of bound / > setBound > > Vicente > > > On 06/16/2018 08:13 AM, B. Blaser wrote: >> >> I've attached the nomenclature change you suggested. >> I agree that 'setBound()' is more expressive. >> Tier1 is still OK. >> >> Cheers, >> Bernard >> >> On 14 June 2018 at 19:03, Maurizio Cimadamore >> wrote: >>> >>> Looks ok, I think I'd rather prefer setBound to bound(arg), as the name >>> you >>> chose doesn't make assignment explicit. >>> >>> Long term, I think we should find ways to avoid mutating the bound after >>> creation... but I did some experimental work on this, and it's not a >>> piece >>> of cake, as you often need mutation when handling recursive bounds - e.g. >>> set some initial bound first, then do a subst and set final bounds later >>> (I >>> think there's a bunch of methods in Types that use this idiom). >>> >>> Maurizio >>> >>> >>> >>> >>> On 13/06/18 11:09, B. Blaser wrote: >>>> >>>> Here it is, in attachment. >>>> It completely privatizes and virtualizes 'TypeVar.bound'. >>>> >>>> Apologies for not providing a web-rev, this is still on my to-do list... >>>> >>>> Any feedback is welcome (tier1 is OK), >>>> Bernard >>>> >>>> On 11 June 2018 at 20:42, B. Blaser wrote: >>>>> >>>>> That's what I thought too but I wanted a confirmation before doing the >>>>> whole job... >>>>> >>>>> Thanks, >>>>> Bernard >>>>> >>>>> On 11 June 2018 at 19:23, Maurizio Cimadamore >>>>> wrote: >>>>>> >>>>>> I think this patch is a good start, but to be complete, we'd need to >>>>>> completely virtualize access on the 'bound' field, otherwise we risk >>>>>> turning >>>>>> this into a whack-a-mole exercise. There are e.g. 30 usages in Types >>>>>> alone, >>>>>> each of those could lead to issues with type annos. >>>>>> >>>>>> Maurizio >>> >>> > From maurizio.cimadamore at oracle.com Mon Jun 18 14:15:58 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 18 Jun 2018 15:15:58 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: I'm fine with bound() - I have no strong opinion on this though. In terms of conformity with other code, javac typically uses getXyz() names. Could you please post a webrev somewhere? Thanks Maurizio On 18/06/18 14:44, B. Blaser wrote: > Honestly, I find 'TypeVar.getBound()' a bit heavy and not compliant > with the existing 'TypeVar.baseType()' naming. > But if everybody agrees with 'getBound()/setBound()' we can change it. > > What should we do? > Bernard > > On 18 June 2018 at 02:53, Vicente Romero wrote: >> bike shedding: shouldn't it be getBound / setBound instead of bound / >> setBound >> >> Vicente >> >> >> On 06/16/2018 08:13 AM, B. Blaser wrote: >>> I've attached the nomenclature change you suggested. >>> I agree that 'setBound()' is more expressive. >>> Tier1 is still OK. >>> >>> Cheers, >>> Bernard >>> >>> On 14 June 2018 at 19:03, Maurizio Cimadamore >>> wrote: >>>> Looks ok, I think I'd rather prefer setBound to bound(arg), as the name >>>> you >>>> chose doesn't make assignment explicit. >>>> >>>> Long term, I think we should find ways to avoid mutating the bound after >>>> creation... but I did some experimental work on this, and it's not a >>>> piece >>>> of cake, as you often need mutation when handling recursive bounds - e.g. >>>> set some initial bound first, then do a subst and set final bounds later >>>> (I >>>> think there's a bunch of methods in Types that use this idiom). >>>> >>>> Maurizio >>>> >>>> >>>> >>>> >>>> On 13/06/18 11:09, B. Blaser wrote: >>>>> Here it is, in attachment. >>>>> It completely privatizes and virtualizes 'TypeVar.bound'. >>>>> >>>>> Apologies for not providing a web-rev, this is still on my to-do list... >>>>> >>>>> Any feedback is welcome (tier1 is OK), >>>>> Bernard >>>>> >>>>> On 11 June 2018 at 20:42, B. Blaser wrote: >>>>>> That's what I thought too but I wanted a confirmation before doing the >>>>>> whole job... >>>>>> >>>>>> Thanks, >>>>>> Bernard >>>>>> >>>>>> On 11 June 2018 at 19:23, Maurizio Cimadamore >>>>>> wrote: >>>>>>> I think this patch is a good start, but to be complete, we'd need to >>>>>>> completely virtualize access on the 'bound' field, otherwise we risk >>>>>>> turning >>>>>>> this into a whack-a-mole exercise. There are e.g. 30 usages in Types >>>>>>> alone, >>>>>>> each of those could lead to issues with type annos. >>>>>>> >>>>>>> Maurizio >>>> From vicente.romero at oracle.com Mon Jun 18 18:17:41 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 18 Jun 2018 14:17:41 -0400 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: Hi Bernard, On 06/18/2018 09:44 AM, B. Blaser wrote: > Honestly, I find 'TypeVar.getBound()' a bit heavy and not compliant > with the existing 'TypeVar.baseType()' naming. > But if everybody agrees with 'getBound()/setBound()' we can change it. I would prefer get/set but it's just a personal opinion so your call, I'm OK with any > > What should we do? > Bernard Vicente > > On 18 June 2018 at 02:53, Vicente Romero wrote: >> bike shedding: shouldn't it be getBound / setBound instead of bound / >> setBound >> >> Vicente >> >> >> On 06/16/2018 08:13 AM, B. Blaser wrote: >>> I've attached the nomenclature change you suggested. >>> I agree that 'setBound()' is more expressive. >>> Tier1 is still OK. >>> >>> Cheers, >>> Bernard >>> >>> On 14 June 2018 at 19:03, Maurizio Cimadamore >>> wrote: >>>> Looks ok, I think I'd rather prefer setBound to bound(arg), as the name >>>> you >>>> chose doesn't make assignment explicit. >>>> >>>> Long term, I think we should find ways to avoid mutating the bound after >>>> creation... but I did some experimental work on this, and it's not a >>>> piece >>>> of cake, as you often need mutation when handling recursive bounds - e.g. >>>> set some initial bound first, then do a subst and set final bounds later >>>> (I >>>> think there's a bunch of methods in Types that use this idiom). >>>> >>>> Maurizio >>>> >>>> >>>> >>>> >>>> On 13/06/18 11:09, B. Blaser wrote: >>>>> Here it is, in attachment. >>>>> It completely privatizes and virtualizes 'TypeVar.bound'. >>>>> >>>>> Apologies for not providing a web-rev, this is still on my to-do list... >>>>> >>>>> Any feedback is welcome (tier1 is OK), >>>>> Bernard >>>>> >>>>> On 11 June 2018 at 20:42, B. Blaser wrote: >>>>>> That's what I thought too but I wanted a confirmation before doing the >>>>>> whole job... >>>>>> >>>>>> Thanks, >>>>>> Bernard >>>>>> >>>>>> On 11 June 2018 at 19:23, Maurizio Cimadamore >>>>>> wrote: >>>>>>> I think this patch is a good start, but to be complete, we'd need to >>>>>>> completely virtualize access on the 'bound' field, otherwise we risk >>>>>>> turning >>>>>>> this into a whack-a-mole exercise. There are e.g. 30 usages in Types >>>>>>> alone, >>>>>>> each of those could lead to issues with type annos. >>>>>>> >>>>>>> Maurizio >>>> From maurizio.cimadamore at oracle.com Mon Jun 18 20:09:26 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 18 Jun 2018 21:09:26 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: On 18/06/18 19:17, Vicente Romero wrote: > Hi Bernard, > > On 06/18/2018 09:44 AM, B. Blaser wrote: >> Honestly, I find 'TypeVar.getBound()' a bit heavy and not compliant >> with the existing 'TypeVar.baseType()' naming. >> But if everybody agrees with 'getBound()/setBound()' we can change it. > > I would prefer get/set but it's just a personal opinion so your call, > I'm OK with any Also, note that there's another related method: getUpperBound. This is *almost* like getBound() but it does few extra checks on top. While, I'm confident that this patch is not risky, I'm a bit worried that exposing yet another accessor will create confusion to clients - should they use Type::getUpperBound, Types::upperBound, or the new Type::bound/getBound? I wonder if we need some consolidation here before moving forward with the fix (which would mean, given the late stage, postpone to 12). Opinions? Maurizio > >> >> What should we do? >> Bernard > > Vicente > >> >> On 18 June 2018 at 02:53, Vicente Romero >> wrote: >>> bike shedding: shouldn't it be getBound / setBound instead of bound / >>> setBound >>> >>> Vicente >>> >>> >>> On 06/16/2018 08:13 AM, B. Blaser wrote: >>>> I've attached the nomenclature change you suggested. >>>> I agree that 'setBound()' is more expressive. >>>> Tier1 is still OK. >>>> >>>> Cheers, >>>> Bernard >>>> >>>> On 14 June 2018 at 19:03, Maurizio Cimadamore >>>> wrote: >>>>> Looks ok, I think I'd rather prefer setBound to bound(arg), as the >>>>> name >>>>> you >>>>> chose doesn't make assignment explicit. >>>>> >>>>> Long term, I think we should find ways to avoid mutating the bound >>>>> after >>>>> creation... but I did some experimental work on this, and it's not a >>>>> piece >>>>> of cake, as you often need mutation when handling recursive bounds >>>>> - e.g. >>>>> set some initial bound first, then do a subst and set final bounds >>>>> later >>>>> (I >>>>> think there's a bunch of methods in Types that use this idiom). >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> >>>>> >>>>> On 13/06/18 11:09, B. Blaser wrote: >>>>>> Here it is, in attachment. >>>>>> It completely privatizes and virtualizes 'TypeVar.bound'. >>>>>> >>>>>> Apologies for not providing a web-rev, this is still on my to-do >>>>>> list... >>>>>> >>>>>> Any feedback is welcome (tier1 is OK), >>>>>> Bernard >>>>>> >>>>>> On 11 June 2018 at 20:42, B. Blaser wrote: >>>>>>> That's what I thought too but I wanted a confirmation before >>>>>>> doing the >>>>>>> whole job... >>>>>>> >>>>>>> Thanks, >>>>>>> Bernard >>>>>>> >>>>>>> On 11 June 2018 at 19:23, Maurizio Cimadamore >>>>>>> wrote: >>>>>>>> I think this patch is a good start, but to be complete, we'd >>>>>>>> need to >>>>>>>> completely virtualize access on the 'bound' field, otherwise we >>>>>>>> risk >>>>>>>> turning >>>>>>>> this into a whack-a-mole exercise. There are e.g. 30 usages in >>>>>>>> Types >>>>>>>> alone, >>>>>>>> each of those could lead to issues with type annos. >>>>>>>> >>>>>>>> Maurizio >>>>> > From maurizio.cimadamore at oracle.com Mon Jun 18 20:12:35 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 18 Jun 2018 21:12:35 +0100 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> Message-ID: <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> I think that we should use the (erased) return type of the functional descriptor as the target of the translation. In both the expression/statement case. For statement, why not assigning currentMethod to the full method descriptor type? Or, if we really use currentMethod just for visitReturn, maybe just storing the expected return (as Vicente suggests) is ok? Maurizio On 18/06/18 03:29, Vicente Romero wrote: > Hi, > > Not sure about this one. I think that the type of the return > expression inside a lambda should be erased to the erasure of the > return type of the lambda type. The `currentMethod` field at > TransTypes is just a carrier to actually access the erasure of the > return type of the current method, and this access happens only inside > visitReturn. So I wonder if we actually should have a field in > TransTypes that could hold that erasure directly. At > TransTypes.visitMethodDef we could have: > > theField = types.erasure(tree.type.getReturnType()); > > and at TransTypes.visitLambda it could be: > > theField = > types.erasure(tree.getDescriptorType(types).asMethodType().restype); > > of course with a better name, and then at TransTypes.visitReturn, it > could use the field to erase the returned expression. > > Thanks, > Vicente > > On 06/16/2018 06:20 PM, B. Blaser wrote: >> Hi, >> >> As noted in the JBS issue, the following example fails at run-time >> with a CCE: >> >> ???? List.of('x', 'y').stream().max((a, b) -> { return >> List.of(a).get(0); }); >> >> The interesting point here is that removing 'return' makes it run >> successfully: >> >> ???? List.of('x', 'y').stream().max((a, b) -> List.of(a).get(0)); >> >> The problem seems to be in 'TransType.visitReturn()'. The lambda >> method doesn't yet exist ('currentMethod == null', see >> 'TransType.visitLambda()') causing the return expression type to be >> set to the erasure of 'List.get()' (= Object) which further causes the >> type conversion problem (see >> 'LambdaToMethod.makeLambdaStatementBody()'). >> >> The suggested fix (here under) is to keep the original erased >> expression type (= Character) if 'currentMethod == null'. >> >> Tier1 is OK. >> >> Any feedback is welcome, >> Bernard >> >> diff -r ed8de3d0cd28 >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java >> ??? Sat Jun 16 10:10:54 2018 +0100 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java >> ??? Sat Jun 16 21:16:33 2018 +0200 >> @@ -601,7 +601,8 @@ >> ????? } >> >> ????? public void visitReturn(JCReturn tree) { >> -??????? tree.expr = translate(tree.expr, currentMethod != null ? >> types.erasure(currentMethod.type).getReturnType() : null); >> +??????? tree.expr = translate(tree.expr, currentMethod != null ? >> types.erasure(currentMethod.type).getReturnType() : >> +??????????????? tree.expr != null ? types.erasure(tree.expr.type) : >> null); >> ????????? result = tree; >> ????? } > From bsrbnd at gmail.com Mon Jun 18 20:52:45 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 18 Jun 2018 22:52:45 +0200 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: On 18 June 2018 at 22:09, Maurizio Cimadamore wrote: > > > On 18/06/18 19:17, Vicente Romero wrote: >> >> Hi Bernard, >> >> On 06/18/2018 09:44 AM, B. Blaser wrote: >>> >>> Honestly, I find 'TypeVar.getBound()' a bit heavy and not compliant >>> with the existing 'TypeVar.baseType()' naming. >>> But if everybody agrees with 'getBound()/setBound()' we can change it. >> >> >> I would prefer get/set but it's just a personal opinion so your call, I'm >> OK with any > > Also, note that there's another related method: getUpperBound. This is > *almost* like getBound() but it does few extra checks on top. > > While, I'm confident that this patch is not risky, I'm a bit worried that > exposing yet another accessor will create confusion to clients - should they > use Type::getUpperBound, Types::upperBound, or the new Type::bound/getBound? > > I wonder if we need some consolidation here before moving forward with the > fix (which would mean, given the late stage, postpone to 12). > > Opinions? Personally I'm OK with 'getBound()/setBound()' and I suggest to move forward with the fix to 11 as it doesn't seem risky and corrects a variety of potential failures with annotated type variable bounds. Further cleanup and consolidation should be postponed to 12 to minimize the impact of the fix, I think. If we all agree, I can provide an updated patch with 'getBound()/setBound()'? Bernard > Maurizio > >> >>> >>> What should we do? >>> Bernard >> >> >> Vicente From bsrbnd at gmail.com Mon Jun 18 21:09:09 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 18 Jun 2018 23:09:09 +0200 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> Message-ID: On 18 June 2018 at 22:12, Maurizio Cimadamore wrote: > I think that we should use the (erased) return type of the functional > descriptor as the target of the translation. In both the > expression/statement case. > > For statement, why not assigning currentMethod to the full method descriptor > type? Or, if we really use currentMethod just for visitReturn, maybe just > storing the expected return (as Vicente suggests) is ok? > > Maurizio I think this should probably work too but it might have more side-effects than the fix I suggested. I'll take a look and provide another patch with this variant if all goes well... Bernard From vicente.romero at oracle.com Tue Jun 19 02:53:29 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 18 Jun 2018 22:53:29 -0400 Subject: RFR JDK-8205052: No compilation error thrown when no valid parameterization exists for functional interface type Message-ID: <8ec558cc-f95c-8188-3ee4-8f522a3f4eac@oracle.com> Hi, Please review the fix for bug [1], the fix can be found at [2]. Basically the fix for [3] modified javac so that it could use intersection types as the target type of functional expressions during type attribution. Some code paths were not prepared to deal with intersections. This patch is fixing Types.DescriptorCache.FunctionDescriptor::getType which also checks for the well formed-ness of the target type. The proposed fix is to split the intersection into its components and check for the well formed-ness of every component. Regarding the proposed error message there are two options it can refer to the whole intersection type, which is what this patch is doing, or to the particular component that is not well formed. I'm OK with either. Thanks, Vicente PS, thanks to Maurizio for an analysis of the possible solutions to this issue [1] https://bugs.openjdk.java.net/browse/JDK-8205052 [2] http://cr.openjdk.java.net/~vromero/8205052/webrev.00/ [3] https://bugs.openjdk.java.net/browse/8148354 From maurizio.cimadamore at oracle.com Tue Jun 19 09:57:16 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 19 Jun 2018 10:57:16 +0100 Subject: RFR JDK-8205052: No compilation error thrown when no valid parameterization exists for functional interface type In-Reply-To: <8ec558cc-f95c-8188-3ee4-8f522a3f4eac@oracle.com> References: <8ec558cc-f95c-8188-3ee4-8f522a3f4eac@oracle.com> Message-ID: <018b7ebb-680d-6780-1c54-e99090087304@oracle.com> Looks good! Thanks Maurizio On 19/06/18 03:53, Vicente Romero wrote: > Hi, > > Please review the fix for bug [1], the fix can be found at [2]. > Basically the fix for [3] modified javac so that it could use > intersection types as the target type of functional expressions during > type attribution. Some code paths were not prepared to deal with > intersections. This patch is fixing > Types.DescriptorCache.FunctionDescriptor::getType which also checks > for the well formed-ness of the target type. The proposed fix is to > split the intersection into its components and check for the well > formed-ness of every component. Regarding the proposed error message > there are two options it can refer to the whole intersection type, > which is what this patch is doing, or to the particular component that > is not well formed. I'm OK with either. > > Thanks, > Vicente > > PS, thanks to Maurizio for an analysis of the possible solutions to > this issue > > [1] https://bugs.openjdk.java.net/browse/JDK-8205052 > [2] http://cr.openjdk.java.net/~vromero/8205052/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/8148354 From jan.lahoda at oracle.com Tue Jun 19 11:14:33 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 19 Jun 2018 13:14:33 +0200 Subject: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError() In-Reply-To: <319CCAE9-FF1F-450B-A61F-A14F57E30DE2@oracle.com> References: <5B23C38E.9060402@oracle.com> <319CCAE9-FF1F-450B-A61F-A14F57E30DE2@oracle.com> Message-ID: <5B28E599.7000107@oracle.com> Hi Hannes, Thanks for the comment, updated webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.01/ (It also includes a few more tweaks that turned out to be needed.) Jan On 15.6.2018 16:52, Hannes Walln?fer wrote: > Thanks for helping out with this, Jan. > > Unfortunately I found another change that was backported to 8u102 that changes the signatures of ScriptUtils makeSynchronizedFunction(?) and wrap(?) methods (again). > > https://bugs.openjdk.java.net/browse/JDK-8148379 > > I?m sorry about this, I should have checked when you first asked me about it. > > Otherwise the patch looks good to me. > > Hannes > > >> Am 15.06.2018 um 15:47 schrieb Jan Lahoda : >> >> Hi, >> >> The Nashorn APIs have been enhanced in JDK 8 updates. The proposal here is to update the historical data for --release 8 to JDK 8u40. >> >> Note this includes removal of: >> jdk.nashorn.api.scripting.NashornException.ENGINE_SCRIPT_SOURCE_NAME >> and: >> jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(...) >> and a change of: >> jdk.nashorn.api.scripting.ScriptUtils.wrap(...) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203814 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan > From hannes.wallnoefer at oracle.com Tue Jun 19 13:14:16 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 19 Jun 2018 15:14:16 +0200 Subject: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError() In-Reply-To: <5B28E599.7000107@oracle.com> References: <5B23C38E.9060402@oracle.com> <319CCAE9-FF1F-450B-A61F-A14F57E30DE2@oracle.com> <5B28E599.7000107@oracle.com> Message-ID: Hi Jan, The changes for Nashorn symbols all look good to me. Thanks, Hannes > Am 19.06.2018 um 13:14 schrieb Jan Lahoda : > > Hi Hannes, > > Thanks for the comment, updated webrev: > http://cr.openjdk.java.net/~jlahoda/8203814/webrev.01/ > > (It also includes a few more tweaks that turned out to be needed.) > > Jan > > On 15.6.2018 16:52, Hannes Walln?fer wrote: >> Thanks for helping out with this, Jan. >> >> Unfortunately I found another change that was backported to 8u102 that changes the signatures of ScriptUtils makeSynchronizedFunction(?) and wrap(?) methods (again). >> >> https://bugs.openjdk.java.net/browse/JDK-8148379 >> >> I?m sorry about this, I should have checked when you first asked me about it. >> >> Otherwise the patch looks good to me. >> >> Hannes >> >> >>> Am 15.06.2018 um 15:47 schrieb Jan Lahoda : >>> >>> Hi, >>> >>> The Nashorn APIs have been enhanced in JDK 8 updates. The proposal here is to update the historical data for --release 8 to JDK 8u40. >>> >>> Note this includes removal of: >>> jdk.nashorn.api.scripting.NashornException.ENGINE_SCRIPT_SOURCE_NAME >>> and: >>> jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(...) >>> and a change of: >>> jdk.nashorn.api.scripting.ScriptUtils.wrap(...) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203814 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan >> From bsrbnd at gmail.com Tue Jun 19 18:31:47 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 19 Jun 2018 20:31:47 +0200 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> Message-ID: On 18 June 2018 at 23:09, B. Blaser wrote: > On 18 June 2018 at 22:12, Maurizio Cimadamore > wrote: >> I think that we should use the (erased) return type of the functional >> descriptor as the target of the translation. In both the >> expression/statement case. >> >> For statement, why not assigning currentMethod to the full method descriptor >> type? Or, if we really use currentMethod just for visitReturn, maybe just >> storing the expected return (as Vicente suggests) is ok? >> >> Maurizio > > I think this should probably work too but it might have more > side-effects than the fix I suggested. > I'll take a look and provide another patch with this variant if all goes well... > > Bernard I've attached the variant you both suggested. Any comment is welcome (langtools:tier1 is OK)! Bernard -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8203338b.patch Type: text/x-patch Size: 4395 bytes Desc: not available URL: From jan.lahoda at oracle.com Tue Jun 19 18:36:41 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 19 Jun 2018 20:36:41 +0200 Subject: RFR 8195293: Issue more comprehensive warnings for use of "var" in earlier source versions In-Reply-To: References: <897f01b0-c776-af3e-339f-0010bf7d22bc@oracle.com> Message-ID: <5B294D39.7040604@oracle.com> Looks OK to me. Jan On 14.6.2018 20:26, Maurizio Cimadamore wrote: > Whoops - webrev here > > http://cr.openjdk.java.net/~mcimadamore/8195293/ > > Maurizio > > > On 14/06/18 19:25, Maurizio Cimadamore wrote: >> Hi, >> this is a followup of the issue fixed by Joe some time ago [1]. The >> goal is to issue warnings when programs are using 'var' and -source < >> 10. The original fix made by Joe detects a subset of the cases - more >> specifically it doesn't detect uses in type positions. This fix, which >> was briefly discussed back then - but dropped because of the risk (we >> were at a fairly late stage of the release cycle), resolves that >> problem. It is somewhat convoluted as it needs to avoid generating the >> same warning multiple times. >> >> As you can see from the golden test output, the compiler now warns >> about a lot more uses of 'var' than before. >> >> Note that I've also fixed a resource key which is using a diag >> argument simply to say ''var'', which can and should be hardwired in >> the resource file, instead of having the compiler passing strings around. >> >> Cheers >> Maurizio >> >> [1] - >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-January/011518.html >> >> > From maurizio.cimadamore at oracle.com Tue Jun 19 20:02:21 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 19 Jun 2018 21:02:21 +0100 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> Message-ID: I was not 100% sure that removing all coerce logic from LambdaToMethod is gonna work - LambdaToMethod is actively rewriting method reference expression as lambdas - and these synthetic lambdas are not seen by TransTypes - see here: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l903 But luckily, it seems L2M already handles these from inside the MemberReferenceToLambda class: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l1051 So that should be ok? But I'd be more comfortable if the tests included a case that stressed the method reference path - e.g. an example of a method reference that requires a synthetic cast to be compliant with the target type - just to make sure. Maurizio On 19/06/18 19:31, B. Blaser wrote: > On 18 June 2018 at 23:09, B. Blaser wrote: >> On 18 June 2018 at 22:12, Maurizio Cimadamore >> wrote: >>> I think that we should use the (erased) return type of the functional >>> descriptor as the target of the translation. In both the >>> expression/statement case. >>> >>> For statement, why not assigning currentMethod to the full method descriptor >>> type? Or, if we really use currentMethod just for visitReturn, maybe just >>> storing the expected return (as Vicente suggests) is ok? >>> >>> Maurizio >> I think this should probably work too but it might have more >> side-effects than the fix I suggested. >> I'll take a look and provide another patch with this variant if all goes well... >> >> Bernard > I've attached the variant you both suggested. > Any comment is welcome (langtools:tier1 is OK)! > > Bernard From vicente.romero at oracle.com Tue Jun 19 20:37:27 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 19 Jun 2018 16:37:27 -0400 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> Message-ID: <221b28f1-4e60-fb09-496a-1abc1ca467e6@oracle.com> Hi, I agree with Maurizio that another test covering method references would be nice. Apart from that I like the patch, thanks for taking the time to test this other approach. Vicente On 06/19/2018 04:02 PM, Maurizio Cimadamore wrote: > I was not 100% sure that removing all coerce logic from LambdaToMethod > is gonna work - LambdaToMethod is actively rewriting method reference > expression as lambdas - and these synthetic lambdas are not seen by > TransTypes - see here: > > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l903 > > > But luckily, it seems L2M already handles these from inside the > MemberReferenceToLambda class: > > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l1051 > > > So that should be ok? But I'd be more comfortable if the tests > included a case that stressed the method reference path - e.g. an > example of a method reference that requires a synthetic cast to be > compliant with the target type - just to make sure. > > Maurizio > > > > On 19/06/18 19:31, B. Blaser wrote: >> On 18 June 2018 at 23:09, B. Blaser wrote: >>> On 18 June 2018 at 22:12, Maurizio Cimadamore >>> wrote: >>>> I think that we should use the (erased) return type of the functional >>>> descriptor as the target of the translation. In both the >>>> expression/statement case. >>>> >>>> For statement, why not assigning currentMethod to the full method >>>> descriptor >>>> type? Or, if we really use currentMethod just for visitReturn, >>>> maybe just >>>> storing the expected return (as Vicente suggests) is ok? >>>> >>>> Maurizio >>> I think this should probably work too but it might have more >>> side-effects than the fix I suggested. >>> I'll take a look and provide another patch with this variant if all >>> goes well... >>> >>> Bernard >> I've attached the variant you both suggested. >> Any comment is welcome (langtools:tier1 is OK)! >> >> Bernard > From vicente.romero at oracle.com Wed Jun 20 01:47:17 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 19 Jun 2018 21:47:17 -0400 Subject: RFR JDK-8203195: Anonymous class type inference results in NPE Message-ID: Please review the patch for [1] which can be found at [2]. The issue is a bit weird. This is the test case that shows it: A.java: --------------------------------------------------------- import foo.B; public class A { ? interface Foo { ??? T foo(B key); ? } ? private Foo foo; ? A() { ??? Object baz = foo.foo(new B<>() {}); ? } } --------------------------------------------------------- B.java: --------------------------------------------------------- package foo; public class B { /* ? // if the constructor is placed here the compilation is accepted ? B(int baz) { ? } */ ? protected B() { ? } ? // but fails if placed here ? B(int baz) { ? } } --------------------------------------------------------- so depending on the order in which the constructor, B(int), appears, the output of the compiler is different. This code path is used for all methods so I had some doubts about modifying it but in any case I think that having a different outcome depending on the order in which a method appears in a class should be fixed. The proposed fix is to return an access error symbol in more cases than before at Resolve::selectBest. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8203195 [2] http://cr.openjdk.java.net/~vromero/8203195/webrev.00/ From maurizio.cimadamore at oracle.com Wed Jun 20 09:39:23 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 20 Jun 2018 10:39:23 +0100 Subject: RFR JDK-8203195: Anonymous class type inference results in NPE In-Reply-To: References: Message-ID: <7159a5a7-de81-5839-c83b-a1fe3883096c@oracle.com> Hi Vicente, I think the fix might not be aiming at the right problem. If I recall correctly (Srikanth, please correct me if I'm wrong), when you have an anonymous diamond of the kind: new Foo<>() { } in a method context, during overload resolution javac drops the anon definition, and uses something like this: new Foo<>() This is a per JLS/design, since the body of the anon class might depend on the target type (which becomes the supertype of the anon class). So what I suspect is happening here is that this: new B() { } is correct, because B has a protected constructor, which is called by the synthetic default constructor added to the anon class. But this: new B() is not correct, because it's invoking the protected constructor directly from another package, so you get a spurious access error which is the result of the specific lowering that has been applied to anonymous diamond during overload selection. This is in JLS 15.9.3: "If the class instance creation expression uses <>, then: If C is not an anonymous class, let D be the same as C. *If C is an anonymous class, let D be the superclass or superinterface of C named by the class instance creation expression*. " Then: "If D is a class, let |c_1 |...|c_n | be the constructors of class D" And then: "A list of methods |m_1 |...|m_n | is defined for the purpose of overload resolution and type argument inference. For all /j/ (1 ? /j/ ? /n/), |m_j | is defined in terms of |c_j | as follows:" Among the description on how to map mj to cj, we find this: "*The modifiers of **|m_j |**are those of **|c_j |*" And finally: "To choose a constructor, we temporarily consider |m_1 |...|m_n | to be members of D. One of |m_1 |...|m_n | is chosen, as determined by the class instance creation expression's argument expressions, using the process specified in ?15.12.2 ." So, in this case, m1 used by the logic described above is simply B's protected constructor? - and it inherits its 'protected' status. This means that m1 won't be callable from A (which resides in a different package) and overload selection for the constructors yields an error. In other words, without a spec change, I believe this code should be rejected by javac (at least I can't find a basis to accept it with current JLS). The NPE is probably coming from the fact that the resolution error is swallowed (likely, by deferred attribution), not reported, and the compiler goes ahead with flow analysis on a partially unattributed tree. Maurizio On 20/06/18 02:47, Vicente Romero wrote: > Please review the patch for [1] which can be found at [2]. The issue > is a bit weird. This is the test case that shows it: > > A.java: > --------------------------------------------------------- > import foo.B; > > public class A { > > ? interface Foo { > ??? T foo(B key); > ? } > > ? private Foo foo; > > ? A() { > ??? Object baz = foo.foo(new B<>() {}); > ? } > } > --------------------------------------------------------- > > B.java: > --------------------------------------------------------- > package foo; > > public class B { > /* > ? // if the constructor is placed here the compilation is accepted > ? B(int baz) { > ? } > */ > > ? protected B() { > ? } > > > ? // but fails if placed here > ? B(int baz) { > ? } > > } > --------------------------------------------------------- > > so depending on the order in which the constructor, B(int), appears, > the output of the compiler is different. This code path is used for > all methods so I had some doubts about modifying it but in any case I > think that having a different outcome depending on the order in which > a method appears in a class should be fixed. The proposed fix is to > return an access error symbol in more cases than before at > Resolve::selectBest. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8203195 > [2] http://cr.openjdk.java.net/~vromero/8203195/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jun 20 10:28:04 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 20 Jun 2018 11:28:04 +0100 Subject: RFR JDK-8203195: Anonymous class type inference results in NPE In-Reply-To: <7159a5a7-de81-5839-c83b-a1fe3883096c@oracle.com> References: <7159a5a7-de81-5839-c83b-a1fe3883096c@oracle.com> Message-ID: More specifically, and implementation-wise, the error is swallowed because the env.info.selectSuper is set differently during the overload vs. check phase (as this flag is set to true only if the new instance creation has a body, which it doesn't as explained earlier, during overload). This discrepancy makes the compiler see an error during speculative attribution (in ArgumentAttr) - the error is swallowed (as all speculative errors), but is then not reproduced when we run in full check mode because, when that happens, env.info.selectSuper is set correctly. The correct fix is to set this flag either to true (that would require a spec change?) or to false but in a consistent way across overload and check phases. I can't find the spec equivalent for the javac's isSuper magic incantation - not even for non-diamond anonymous classes. E.g. if the superclass of an anonymous class has a protected constructor, and the superclass is defined in a different package, how is the logic in the JLS supposed to resolve it? The spec simply says: "The process specified in ?15.12.2 , modified to handle constructors, is used to choose one of the constructors of the direct superclass of C and determine its |throws| clause." In both diamond, non-diamond, anon and non-anon cases. No special access relaxation seem to be implied here? Maurizio On 20/06/18 10:39, Maurizio Cimadamore wrote: > > Hi Vicente, > I think the fix might not be aiming at the right problem. If I recall > correctly (Srikanth, please correct me if I'm wrong), when you have an > anonymous diamond of the kind: > > new Foo<>() { } > > in a method context, during overload resolution javac drops the anon > definition, and uses something like this: > > new Foo<>() > > This is a per JLS/design, since the body of the anon class might > depend on the target type (which becomes the supertype of the anon class). > > So what I suspect is happening here is that this: > > new B() { } > > is correct, because B has a protected constructor, which is called by > the synthetic default constructor added to the anon class. > > But this: > > new B() > > is not correct, because it's invoking the protected constructor > directly from another package, so you get a spurious access error > which is the result of the specific lowering that has been applied to > anonymous diamond during overload selection. > > This is in JLS 15.9.3: > > "If the class instance creation expression uses <>, then: > > If C is not an anonymous class, let D be the same as C. *If C is an > anonymous class, let D be the superclass or superinterface of C named > by the class instance creation expression*. " > > Then: > > "If D is a class, let |c_1 |...|c_n | be the constructors of class D" > > And then: > > "A list of methods |m_1 |...|m_n | is defined for the purpose of > overload resolution and type argument inference. For all /j/ (1 ? /j/ > ? /n/), |m_j | is defined in terms of |c_j | as follows:" > > Among the description on how to map mj to cj, we find this: > > "*The modifiers of **|m_j |**are those of **|c_j |*" > > And finally: > > "To choose a constructor, we temporarily consider |m_1 |...|m_n | to > be members of D. One of |m_1 |...|m_n | is chosen, as determined by > the class instance creation expression's argument expressions, using > the process specified in ?15.12.2 > ." > > > So, in this case, m1 used by the logic described above is simply B's > protected constructor? - and it inherits its 'protected' status. This > means that m1 won't be callable from A (which resides in a different > package) and overload selection for the constructors yields an error. > > In other words, without a spec change, I believe this code should be > rejected by javac (at least I can't find a basis to accept it with > current JLS). The NPE is probably coming from the fact that the > resolution error is swallowed (likely, by deferred attribution), not > reported, and the compiler goes ahead with flow analysis on a > partially unattributed tree. > > Maurizio > > > On 20/06/18 02:47, Vicente Romero wrote: >> Please review the patch for [1] which can be found at [2]. The issue >> is a bit weird. This is the test case that shows it: >> >> A.java: >> --------------------------------------------------------- >> import foo.B; >> >> public class A { >> >> ? interface Foo { >> ??? T foo(B key); >> ? } >> >> ? private Foo foo; >> >> ? A() { >> ??? Object baz = foo.foo(new B<>() {}); >> ? } >> } >> --------------------------------------------------------- >> >> B.java: >> --------------------------------------------------------- >> package foo; >> >> public class B { >> /* >> ? // if the constructor is placed here the compilation is accepted >> ? B(int baz) { >> ? } >> */ >> >> ? protected B() { >> ? } >> >> >> ? // but fails if placed here >> ? B(int baz) { >> ? } >> >> } >> --------------------------------------------------------- >> >> so depending on the order in which the constructor, B(int), appears, >> the output of the compiler is different. This code path is used for >> all methods so I had some doubts about modifying it but in any case I >> think that having a different outcome depending on the order in which >> a method appears in a class should be fixed. The proposed fix is to >> return an access error symbol in more cases than before at >> Resolve::selectBest. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8203195 >> [2] http://cr.openjdk.java.net/~vromero/8203195/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Wed Jun 20 14:15:04 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 20 Jun 2018 16:15:04 +0200 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: <221b28f1-4e60-fb09-496a-1abc1ca467e6@oracle.com> References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> <221b28f1-4e60-fb09-496a-1abc1ca467e6@oracle.com> Message-ID: I've attached the patch along with the following test cases: * lambda without 'return' (coercion + unboxing + widening primitive) * lambda with 'return' (idem) * method reference converted to lambda (coercion) * method with 'return' (idem) Any comment (tier1 is OK)? Bernard On 19 June 2018 at 22:37, Vicente Romero wrote: > Hi, > > I agree with Maurizio that another test covering method references would be > nice. Apart from that I like the patch, thanks for taking the time to test > this other approach. > > Vicente > > > On 06/19/2018 04:02 PM, Maurizio Cimadamore wrote: >> >> I was not 100% sure that removing all coerce logic from LambdaToMethod is >> gonna work - LambdaToMethod is actively rewriting method reference >> expression as lambdas - and these synthetic lambdas are not seen by >> TransTypes - see here: >> >> >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l903 >> >> But luckily, it seems L2M already handles these from inside the >> MemberReferenceToLambda class: >> >> >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l1051 >> >> So that should be ok? But I'd be more comfortable if the tests included a >> case that stressed the method reference path - e.g. an example of a method >> reference that requires a synthetic cast to be compliant with the target >> type - just to make sure. >> >> Maurizio >> >> >> >> On 19/06/18 19:31, B. Blaser wrote: >>> >>> On 18 June 2018 at 23:09, B. Blaser wrote: >>>> >>>> On 18 June 2018 at 22:12, Maurizio Cimadamore >>>> wrote: >>>>> >>>>> I think that we should use the (erased) return type of the functional >>>>> descriptor as the target of the translation. In both the >>>>> expression/statement case. >>>>> >>>>> For statement, why not assigning currentMethod to the full method >>>>> descriptor >>>>> type? Or, if we really use currentMethod just for visitReturn, maybe >>>>> just >>>>> storing the expected return (as Vicente suggests) is ok? >>>>> >>>>> Maurizio >>>> >>>> I think this should probably work too but it might have more >>>> side-effects than the fix I suggested. >>>> I'll take a look and provide another patch with this variant if all goes >>>> well... >>>> >>>> Bernard >>> >>> I've attached the variant you both suggested. >>> Any comment is welcome (langtools:tier1 is OK)! >>> >>> Bernard >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8203338c.patch Type: text/x-patch Size: 5735 bytes Desc: not available URL: From maurizio.cimadamore at oracle.com Wed Jun 20 15:11:40 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 20 Jun 2018 16:11:40 +0100 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> <221b28f1-4e60-fb09-496a-1abc1ca467e6@oracle.com> Message-ID: <11f8dff2-5cf3-b0e4-ed92-5ca0fb5be15e@oracle.com> Looks good to me - thanks Maurizio On 20/06/18 15:15, B. Blaser wrote: > I've attached the patch along with the following test cases: > * lambda without 'return' (coercion + unboxing + widening primitive) > * lambda with 'return' (idem) > * method reference converted to lambda (coercion) > * method with 'return' (idem) > > Any comment (tier1 is OK)? > Bernard > > On 19 June 2018 at 22:37, Vicente Romero wrote: >> Hi, >> >> I agree with Maurizio that another test covering method references would be >> nice. Apart from that I like the patch, thanks for taking the time to test >> this other approach. >> >> Vicente >> >> >> On 06/19/2018 04:02 PM, Maurizio Cimadamore wrote: >>> I was not 100% sure that removing all coerce logic from LambdaToMethod is >>> gonna work - LambdaToMethod is actively rewriting method reference >>> expression as lambdas - and these synthetic lambdas are not seen by >>> TransTypes - see here: >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l903 >>> >>> But luckily, it seems L2M already handles these from inside the >>> MemberReferenceToLambda class: >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l1051 >>> >>> So that should be ok? But I'd be more comfortable if the tests included a >>> case that stressed the method reference path - e.g. an example of a method >>> reference that requires a synthetic cast to be compliant with the target >>> type - just to make sure. >>> >>> Maurizio >>> >>> >>> >>> On 19/06/18 19:31, B. Blaser wrote: >>>> On 18 June 2018 at 23:09, B. Blaser wrote: >>>>> On 18 June 2018 at 22:12, Maurizio Cimadamore >>>>> wrote: >>>>>> I think that we should use the (erased) return type of the functional >>>>>> descriptor as the target of the translation. In both the >>>>>> expression/statement case. >>>>>> >>>>>> For statement, why not assigning currentMethod to the full method >>>>>> descriptor >>>>>> type? Or, if we really use currentMethod just for visitReturn, maybe >>>>>> just >>>>>> storing the expected return (as Vicente suggests) is ok? >>>>>> >>>>>> Maurizio >>>>> I think this should probably work too but it might have more >>>>> side-effects than the fix I suggested. >>>>> I'll take a look and provide another patch with this variant if all goes >>>>> well... >>>>> >>>>> Bernard >>>> I've attached the variant you both suggested. >>>> Any comment is welcome (langtools:tier1 is OK)! >>>> >>>> Bernard >>> From vicente.romero at oracle.com Wed Jun 20 15:34:57 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 20 Jun 2018 11:34:57 -0400 Subject: RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException In-Reply-To: References: <47e6bb11-6d6f-54b8-d49c-47f12cb9f25b@oracle.com> <59c25fd4-64db-72a0-38da-b33b5829cc2a@oracle.com> <221b28f1-4e60-fb09-496a-1abc1ca467e6@oracle.com> Message-ID: <5dad5394-6ea7-17a9-e26f-666770737bf6@oracle.com> looks good, Vicente PS, I will take care of the rest of the paperwork On 06/20/2018 10:15 AM, B. Blaser wrote: > I've attached the patch along with the following test cases: > * lambda without 'return' (coercion + unboxing + widening primitive) > * lambda with 'return' (idem) > * method reference converted to lambda (coercion) > * method with 'return' (idem) > > Any comment (tier1 is OK)? > Bernard > > On 19 June 2018 at 22:37, Vicente Romero wrote: >> Hi, >> >> I agree with Maurizio that another test covering method references would be >> nice. Apart from that I like the patch, thanks for taking the time to test >> this other approach. >> >> Vicente >> >> >> On 06/19/2018 04:02 PM, Maurizio Cimadamore wrote: >>> I was not 100% sure that removing all coerce logic from LambdaToMethod is >>> gonna work - LambdaToMethod is actively rewriting method reference >>> expression as lambdas - and these synthetic lambdas are not seen by >>> TransTypes - see here: >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l903 >>> >>> But luckily, it seems L2M already handles these from inside the >>> MemberReferenceToLambda class: >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l1051 >>> >>> So that should be ok? But I'd be more comfortable if the tests included a >>> case that stressed the method reference path - e.g. an example of a method >>> reference that requires a synthetic cast to be compliant with the target >>> type - just to make sure. >>> >>> Maurizio >>> >>> >>> >>> On 19/06/18 19:31, B. Blaser wrote: >>>> On 18 June 2018 at 23:09, B. Blaser wrote: >>>>> On 18 June 2018 at 22:12, Maurizio Cimadamore >>>>> wrote: >>>>>> I think that we should use the (erased) return type of the functional >>>>>> descriptor as the target of the translation. In both the >>>>>> expression/statement case. >>>>>> >>>>>> For statement, why not assigning currentMethod to the full method >>>>>> descriptor >>>>>> type? Or, if we really use currentMethod just for visitReturn, maybe >>>>>> just >>>>>> storing the expected return (as Vicente suggests) is ok? >>>>>> >>>>>> Maurizio >>>>> I think this should probably work too but it might have more >>>>> side-effects than the fix I suggested. >>>>> I'll take a look and provide another patch with this variant if all goes >>>>> well... >>>>> >>>>> Bernard >>>> I've attached the variant you both suggested. >>>> Any comment is welcome (langtools:tier1 is OK)! >>>> >>>> Bernard >>> From jan.lahoda at oracle.com Thu Jun 21 11:43:46 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 21 Jun 2018 13:43:46 +0200 Subject: RFR: JDK-8205418: Assorted improvements to source code model Message-ID: <5B2B8F72.8040707@oracle.com> Hi, I'd like to propose a few improvements to the source code model as seen through the com.sun.source APIs. The changes include better error recovery, a fix end positions, and a fix for Trees.getScope when used with a TreePath that point to a block of a lambda expression, including cases where there's an error in the source code. Bug: https://bugs.openjdk.java.net/browse/JDK-8205418 Webrev: http://cr.openjdk.java.net/~jlahoda/8205418/webrev.00/ How does this look? Thanks, Jan From jan.lahoda at oracle.com Thu Jun 21 12:07:53 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 21 Jun 2018 14:07:53 +0200 Subject: RFR: JDK-8195077: [Testbug] tools/javac/processing/model/completionfailure/NoAbortForBadClassFile.java - AccessDeniedException Message-ID: <5B2B9519.9090503@oracle.com> Hi, The tools/javac/processing/model/completionfailure/NoAbortForBadClassFile.java test has many sub-tests, and reuses the same working directory for each sub-test, but clearing the directory. This seems to break from time to time on Windows, so I'd like to change that so that each sub-test would have its own working directory. Bug: https://bugs.openjdk.java.net/browse/JDK-8195077 Webrev: http://cr.openjdk.java.net/~jlahoda/8195077/webrev.00/ How does this look? Thanks, Jan From vicente.romero at oracle.com Thu Jun 21 12:26:42 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 21 Jun 2018 08:26:42 -0400 Subject: RFR: JDK-8195077: [Testbug] tools/javac/processing/model/completionfailure/NoAbortForBadClassFile.java - AccessDeniedException In-Reply-To: <5B2B9519.9090503@oracle.com> References: <5B2B9519.9090503@oracle.com> Message-ID: <39adb13f-a333-397a-e1d7-281729f1220f@oracle.com> looks good, Vicente On 06/21/2018 08:07 AM, Jan Lahoda wrote: > Hi, > > The > tools/javac/processing/model/completionfailure/NoAbortForBadClassFile.java > test has many sub-tests, and reuses the same working directory for > each sub-test, but clearing the directory. This seems to break from > time to time on Windows, so I'd like to change that so that each > sub-test would have its own working directory. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195077 > Webrev: http://cr.openjdk.java.net/~jlahoda/8195077/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Thu Jun 21 15:01:03 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 21 Jun 2018 11:01:03 -0400 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: <5B2B8F72.8040707@oracle.com> References: <5B2B8F72.8040707@oracle.com> Message-ID: <0ed1fd08-1b4d-c1f6-7d1b-c208c77de26c@oracle.com> Hi, The patch looks good but my recommendation would be to push it to 12 first as it modifies some bits that have usually proven to be brittle. Let it bake in 12 for a while could be sensible, Thanks, Vicente On 06/21/2018 07:43 AM, Jan Lahoda wrote: > Hi, > > I'd like to propose a few improvements to the source code model as > seen through the com.sun.source APIs. > > The changes include better error recovery, a fix end positions, and a > fix for Trees.getScope when used with a TreePath that point to a block > of a lambda expression, including cases where there's an error in the > source code. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205418 > Webrev: http://cr.openjdk.java.net/~jlahoda/8205418/webrev.00/ > > How does this look? > > Thanks, > ?? Jan From jonathan.gibbons at oracle.com Thu Jun 21 20:39:49 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 21 Jun 2018 13:39:49 -0700 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: <5B2B8F72.8040707@oracle.com> References: <5B2B8F72.8040707@oracle.com> Message-ID: <5B2C0D15.6040500@oracle.com> On 06/21/2018 04:43 AM, Jan Lahoda wrote: > Hi, > > I'd like to propose a few improvements to the source code model as > seen through the com.sun.source APIs. > > The changes include better error recovery, a fix end positions, and a > fix for Trees.getScope when used with a TreePath that point to a block > of a lambda expression, including cases where there's an error in the > source code. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205418 > Webrev: http://cr.openjdk.java.net/~jlahoda/8205418/webrev.00/ > > How does this look? > > Thanks, > Jan Generally OK. In Operators: Although the number of args is typically small, the following runs the stream twice: 213 if (Stream.of(args).noneMatch(Type::isErroneous) && 214 Stream.of(args).noneMatch(t -> t == Type.recoveryType)) { and could be simplified to 213 if (Stream.of(args).noneMatch(t -> t.isErroneous || t == Type.recoveryType)) { -- Jon From maurizio.cimadamore at oracle.com Fri Jun 22 09:53:22 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 22 Jun 2018 10:53:22 +0100 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: <5B2B8F72.8040707@oracle.com> References: <5B2B8F72.8040707@oracle.com> Message-ID: <454b1e9d-b7ad-287a-61b1-140cc686785b@oracle.com> Hi Jan, * in Types and Operators, I wonder if using 'xyz == Type.recoveryType' is the right thing - and we wouldn't be more general by doing xyz.hasTag(NONE), as in other functions. I mean, is the tweaking you did for the castable function something that should only happen if the type involved in a cast has to do with recovery? Or, more generally, we want just to skip spurious error generation when a type info isn't there? I think the latter might be better? * RecoveryInfo - why was the report() method changed not to report errors? Was this generating spurious messages? Now that, with your change, some recoveryInfo _do_ have expected type info associated with them - is it still the case that we should always have 'compatible' return true, (and not emit error messages) ? Also, nit, I'd prefer adding a comment in the empty body saying 'do nothing' e.g. showing it's a deliberate choice (we do that elsewhere). * Resolve - not sure I get the bestCandidate part. I mean, it seems you want to check that all candidates point to the same symbol. But you don't seem to look as to whether the candidate was applicable or not (and the phase at which it was not applicable is discarded too). Sure that errCandidate() isn't what you want here? errCandidate picks the last non-applicable candidate (which has the higher resolution phase). Note that when an InapplicableSymbolError is issued, there should always be just _one_ inapplicable method, otherwise you'd get an InapplicableSymbol_s_Error. So I'm not sure why you have that logic to check that all candidates are the same. * DeferredAttr - seems that at least some of the hoops you have to jump through to enforce an expected type with the mapping could be avoided if you made the mapper accept a Type visitor argument (currently, DeferredMap has a Void type argument). * Resolve - I believe what your changes want to do here is: if we issued an ambiguous error, then we shouldn't have * T8071432.out - I'd say the fact that one error is missing here is step backwards? Is this caused by the removal of logging in the recovery info? * IgnoreLambdaBodyDuringResolutionTest2.out - this time the removal of the diagnostic seems more benign As for whether this should go in 11 or 12, I guess I don't have a strong opinion. Some of the things you touch are sensitive, as Vicente mentioned, but at the same time I can't see obvious ways as to why they should impact correctness - but they will almost surely have some non-trivial consequences on compiler diagnostics - which might even perceived as regressions (see above). Maurizio On 21/06/18 12:43, Jan Lahoda wrote: > Hi, > > I'd like to propose a few improvements to the source code model as > seen through the com.sun.source APIs. > > The changes include better error recovery, a fix end positions, and a > fix for Trees.getScope when used with a TreePath that point to a block > of a lambda expression, including cases where there's an error in the > source code. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205418 > Webrev: http://cr.openjdk.java.net/~jlahoda/8205418/webrev.00/ > > How does this look? > > Thanks, > ?? Jan From jan.lahoda at oracle.com Fri Jun 22 11:29:07 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 22 Jun 2018 13:29:07 +0200 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: <454b1e9d-b7ad-287a-61b1-140cc686785b@oracle.com> References: <5B2B8F72.8040707@oracle.com> <454b1e9d-b7ad-287a-61b1-140cc686785b@oracle.com> Message-ID: <5B2CDD83.6090600@oracle.com> Hi Maurizio, Thanks for the comments. On 22.6.2018 11:53, Maurizio Cimadamore wrote: > Hi Jan, > > * in Types and Operators, I wonder if using 'xyz == Type.recoveryType' > is the right thing - and we wouldn't be more general by doing > xyz.hasTag(NONE), as in other functions. I mean, is the tweaking you did > for the castable function something that should only happen if the type > involved in a cast has to do with recovery? Or, more generally, we want > just to skip spurious error generation when a type info isn't there? I > think the latter might be better? NONE sounds good as well, will change that. > > * RecoveryInfo - why was the report() method changed not to report > errors? Was this generating spurious messages? Now that, with your Yes, there were some extra error messages (that didn't seem very useful). > change, some recoveryInfo _do_ have expected type info associated with > them - is it still the case that we should always have 'compatible' > return true, (and not emit error messages) ? Also, nit, I'd prefer I think (hope) not emitting the error messages is fine - the intent here is only to fill the model with some (hopefully) meaningful data. > adding a comment in the empty body saying 'do nothing' e.g. showing it's > a deliberate choice (we do that elsewhere). Sure, will do (unless this change is undone). > > * Resolve - not sure I get the bestCandidate part. I mean, it seems you > want to check that all candidates point to the same symbol. But you > don't seem to look as to whether the candidate was applicable or not > (and the phase at which it was not applicable is discarded too). Sure > that errCandidate() isn't what you want here? errCandidate picks the > last non-applicable candidate (which has the higher resolution phase). > Note that when an InapplicableSymbolError is issued, there should always > be just _one_ inapplicable method, otherwise you'd get an > InapplicableSymbol_s_Error. So I'm not sure why you have that logic to > check that all candidates are the same. InapplicableSymbol_s_Error extends from InapplicableSymbolError, right? So there may be multiple inapplicable symbols, I think. The intent is here to try to recover in case where the expected symbol is obvious, but to not a pick a candidate if there's any ambiguity possible. > > * DeferredAttr - seems that at least some of the hoops you have to jump > through to enforce an expected type with the mapping could be avoided if > you made the mapper accept a Type visitor argument (currently, > DeferredMap has a Void type argument). Thanks, will look into that. > > * Resolve - I believe what your changes want to do here is: if we issued > an ambiguous error, then we shouldn't have > > * T8071432.out - I'd say the fact that one error is missing here is step > backwards? Is this caused by the removal of logging in the recovery info? For default/simplified errors, there is only one error message that is the same before and after this patch: --- T8071432.java:47: error: incompatible types: cannot infer type-variable(s) U System.out.println(c.stream().reduce(0.0, ^ (argument mismatch; bad return type in lambda expression int cannot be converted to Double) where U,T are type-variables: U extends Object declared in method reduce(U,BiFunction,BinaryOperator) T extends Object declared in interface Stream Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 1 error --- But it is true that for -Xdiags:verbose, there were two errors, and with this patch there is only one, and the error that is missing is probably the more useful one. I'll investigate what are the options. Thanks for the comments! Jan > > * IgnoreLambdaBodyDuringResolutionTest2.out - this time the removal of > the diagnostic seems more benign > > As for whether this should go in 11 or 12, I guess I don't have a strong > opinion. Some of the things you touch are sensitive, as Vicente > mentioned, but at the same time I can't see obvious ways as to why they > should impact correctness - but they will almost surely have some > non-trivial consequences on compiler diagnostics - which might even > perceived as regressions (see above). > > Maurizio > > > On 21/06/18 12:43, Jan Lahoda wrote: >> Hi, >> >> I'd like to propose a few improvements to the source code model as >> seen through the com.sun.source APIs. >> >> The changes include better error recovery, a fix end positions, and a >> fix for Trees.getScope when used with a TreePath that point to a block >> of a lambda expression, including cases where there's an error in the >> source code. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8205418 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8205418/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan > From jan.lahoda at oracle.com Fri Jun 22 11:30:33 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 22 Jun 2018 13:30:33 +0200 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: <5B2C0D15.6040500@oracle.com> References: <5B2B8F72.8040707@oracle.com> <5B2C0D15.6040500@oracle.com> Message-ID: <5B2CDDD9.3020302@oracle.com> On 21.6.2018 22:39, Jonathan Gibbons wrote: > > > On 06/21/2018 04:43 AM, Jan Lahoda wrote: >> Hi, >> >> I'd like to propose a few improvements to the source code model as >> seen through the com.sun.source APIs. >> >> The changes include better error recovery, a fix end positions, and a >> fix for Trees.getScope when used with a TreePath that point to a block >> of a lambda expression, including cases where there's an error in the >> source code. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8205418 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8205418/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan > > Generally OK. > > In Operators: > > Although the number of args is typically small, the following runs the > stream twice: > > 213 if (Stream.of(args).noneMatch(Type::isErroneous) && > 214 Stream.of(args).noneMatch(t -> t == Type.recoveryType)) { > > and could be simplified to > > 213 if (Stream.of(args).noneMatch(t -> t.isErroneous || t == > Type.recoveryType)) { Thanks Jon, will do (changing t == recoveryType to t.hasTag(TypeTag.NONE) as Maurizio suggested). Jan > > > -- Jon From maurizio.cimadamore at oracle.com Fri Jun 22 12:32:34 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 22 Jun 2018 13:32:34 +0100 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: <5B2CDD83.6090600@oracle.com> References: <5B2B8F72.8040707@oracle.com> <454b1e9d-b7ad-287a-61b1-140cc686785b@oracle.com> <5B2CDD83.6090600@oracle.com> Message-ID: > >> >> * Resolve - not sure I get the bestCandidate part. I mean, it seems you >> want to check that all candidates point to the same symbol. But you >> don't seem to look as to whether the candidate was applicable or not >> (and the phase at which it was not applicable is discarded too). Sure >> that errCandidate() isn't what you want here? errCandidate picks the >> last non-applicable candidate (which has the higher resolution phase). >> Note that when an InapplicableSymbolError is issued, there should always >> be just _one_ inapplicable method, otherwise you'd get an >> InapplicableSymbol_s_Error. So I'm not sure why you have that logic to >> check that all candidates are the same. > > InapplicableSymbol_s_Error extends from InapplicableSymbolError, > right? So there may be multiple inapplicable symbols, I think. The > intent is here to try to recover in case where the expected symbol is > obvious, but to not a pick a candidate if there's any ambiguity possible. Right, they are one subclass of the other - so, maybe InapplicableSymbol_S_ could override 'bestCandidate' and return null - at that point,? in InapplicableSymbol I think it's safe to have bestCandidate delegate to errCandidate. >> * T8071432.out - I'd say the fact that one error is missing here is step >> backwards? Is this caused by the removal of logging in the recovery >> info? > > For default/simplified errors, there is only one error message that is > the same before and after this patch: > --- > T8071432.java:47: error: incompatible types: cannot infer > type-variable(s) U > ??????? System.out.println(c.stream().reduce(0.0, > ??????????????????????????????????????????? ^ > ??? (argument mismatch; bad return type in lambda expression > ????? int cannot be converted to Double) > ? where U,T are type-variables: > ??? U extends Object declared in method reduce(U,BiFunction super T,U>,BinaryOperator) > ??? T extends Object declared in interface Stream > Note: Some messages have been simplified; recompile with > -Xdiags:verbose to get full output > 1 error > --- When messages are simplified, basically we turn errors into other errors - e.g. look at InapplicableSymbol_S_Error::getDiagnostic - there is some logic and then, if there's really onlt one relevant candidate, we go back to an InapplicableSymbol (without S) error, where 'errCandidate' is overridden to return the filtered symbol. Another reason to rely more on errCandidate :-) Maurizio > > But it is true that for -Xdiags:verbose, there were two errors, and > with this patch there is only one, and the error that is missing is > probably the more useful one. I'll investigate what are the options. > > Thanks for the comments! > > Jan > >> >> * IgnoreLambdaBodyDuringResolutionTest2.out - this time the removal of >> the diagnostic seems more benign >> >> As for whether this should go in 11 or 12, I guess I don't have a strong >> opinion. Some of the things you touch are sensitive, as Vicente >> mentioned, but at the same time I can't see obvious ways as to why they >> should impact correctness - but they will almost surely have some >> non-trivial consequences on compiler diagnostics - which might even >> perceived as regressions (see above). >> >> Maurizio >> >> >> On 21/06/18 12:43, Jan Lahoda wrote: >>> Hi, >>> >>> I'd like to propose a few improvements to the source code model as >>> seen through the com.sun.source APIs. >>> >>> The changes include better error recovery, a fix end positions, and a >>> fix for Trees.getScope when used with a TreePath that point to a block >>> of a lambda expression, including cases where there's an error in the >>> source code. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205418 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8205418/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> ?? Jan >> From maurizio.cimadamore at oracle.com Fri Jun 22 12:37:28 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 22 Jun 2018 13:37:28 +0100 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: References: <5B2B8F72.8040707@oracle.com> <454b1e9d-b7ad-287a-61b1-140cc686785b@oracle.com> <5B2CDD83.6090600@oracle.com> Message-ID: On 22/06/18 13:32, Maurizio Cimadamore wrote: > When messages are simplified, basically we turn errors into other > errors - e.g. look at InapplicableSymbol_S_Error::getDiagnostic - > there is some logic and then, if there's really onlt one relevant > candidate, we go back to an InapplicableSymbol (without S) error, > where 'errCandidate' is overridden to return the filtered symbol. > > Another reason to rely more on errCandidate More specifically, if simplified diagnostics are disabled, you go remain in the multiple symbols world, which means you still have more candidates and you fail to see that only one was really the good one. So, I think InapplicableSymbolsError should override bestCandidate (which I also suggested in previous email), and should call filterCandidates before doing the processing. This will ensure that 'redundant' candidates are dropped, and you get back the symbol that is most likely to be the correct one. Maurizio From cushon at google.com Fri Jun 22 16:02:45 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 22 Jun 2018 09:02:45 -0700 Subject: Problems building with --release=8 In-Reply-To: <5c0ad745-def9-6617-96a3-ce9bc20fe349@oracle.com> References: <5c0ad745-def9-6617-96a3-ce9bc20fe349@oracle.com> Message-ID: Hi, On Wed, Jan 17, 2018 at 9:43 AM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > That being said, there has been discussion recently about providing > access to some of the API that precedes jdk.unsupported, as a special > case. > What was the outcome of the discussion you mentioned? Is there still interest in making it possible to access those APIs when using --release < 9? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Jun 25 14:55:21 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 25 Jun 2018 16:55:21 +0200 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: References: <5B2B8F72.8040707@oracle.com> <454b1e9d-b7ad-287a-61b1-140cc686785b@oracle.com> <5B2CDD83.6090600@oracle.com> Message-ID: <5B310259.6040107@oracle.com> Thanks for all the comments. I've updated the patch according to the comment, and uploaded the new patch here: http://cr.openjdk.java.net/~jlahoda/8205418/webrev.01/ (For the RecoveryInfo.CheckContext.report, I've disabled the errors only when the new recovery is active, which should limit the effects on error messages.) Any feedback is welcome! Thanks, Jan On 22.6.2018 14:37, Maurizio Cimadamore wrote: > > > On 22/06/18 13:32, Maurizio Cimadamore wrote: >> When messages are simplified, basically we turn errors into other >> errors - e.g. look at InapplicableSymbol_S_Error::getDiagnostic - >> there is some logic and then, if there's really onlt one relevant >> candidate, we go back to an InapplicableSymbol (without S) error, >> where 'errCandidate' is overridden to return the filtered symbol. >> >> Another reason to rely more on errCandidate > More specifically, if simplified diagnostics are disabled, you go remain > in the multiple symbols world, which means you still have more > candidates and you fail to see that only one was really the good one. > > So, I think InapplicableSymbolsError should override bestCandidate > (which I also suggested in previous email), and should call > filterCandidates before doing the processing. This will ensure that > 'redundant' candidates are dropped, and you get back the symbol that is > most likely to be the correct one. > > Maurizio > From joe.darcy at oracle.com Mon Jun 25 18:38:45 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 25 Jun 2018 11:38:45 -0700 Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 / JDK-8193292, JDK-8193290 Message-ID: <73b0e964-ae47-0938-0986-088624fb973a@oracle.com> Hello, With the JDK 11 and 12 split fast approaching [1], it is time to work on the various start of release update tasks for JDK 12. Those tasks are being tracked under the umbrella bug JDK-8205615: "Start of release updates for JDK 12". For JDK 12, we're attempting to get the full set of related changes (updated JDK version number, bumped class file version update, new javac -source/-target values, etc.) pushed simultaneously. This thread is to review the langtools-related portions of the work including ??? JDK-8193292: Add SourceVersion.RELEASE_12 ??? JDK-8193290: Add source 12 and target 12 to javac as well as updates to the langtools tests for the class file update. Current webrev: ??? http://cr.openjdk.java.net/~darcy/8205615.4/ As part of JDK-8193292: "Add SourceVersion.RELEASE_12", the JDK-9 era visitors in javax.lang.model.util are updated to state they model over version 9 through 12. For now, tools/javac/options/smokeTests/OptionSmokeTest.java is problem listed since it has many hard-coding version checks. Preview language features are only supported against the current source version so those tests need their explicit version number updated. A handful of test failures still need to be addressed, so there will be some minor adjustments to the aggregate set of changes before they are pushed. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html From stuart.marks at oracle.com Mon Jun 25 22:28:08 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 25 Jun 2018 15:28:08 -0700 Subject: RFR(s): JDK-8205455: jdeprscan issues annotation processor warning regarding RELEASE_10 Message-ID: <24e14c63-4b8f-2ce1-d4b9-c24be769e833@oracle.com> Hi all, Please review this small changeset that updates one of jdeprscan's annotation processors to RELEASE_11 in order to prevent warning messages from being issued. This changeset also includes some additional output lines so that the output of jdeprscan's TestRelease.java test is more readable. Patch appended below. Bug: https://bugs.openjdk.java.net/browse/JDK-8205455 Thanks, s'marks # HG changeset patch # User smarks # Date 1529965383 25200 # Mon Jun 25 15:23:03 2018 -0700 # Node ID c243b75831dc8047173586c145a9086e38ebfd76 # Parent b85ca7757c381b7a5fe6ab4ad3a0e981541eff0e 8205455: jdeprscan issues annotation processor warning regarding RELEASE_10 Reviewed-by: XXX diff -r b85ca7757c38 -r c243b75831dc src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java Mon Jun 25 15:02:31 2018 -0700 +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java Mon Jun 25 15:23:03 2018 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -45,14 +45,14 @@ import javax.lang.model.element.TypeElement; import javax.lang.model.util.Elements; -import static javax.lang.model.SourceVersion.RELEASE_10; +import static javax.lang.model.SourceVersion.RELEASE_11; import javax.lang.model.element.Element; import javax.lang.model.element.ElementKind; import javax.lang.model.element.Modifier; import javax.lang.model.element.PackageElement; import javax.tools.Diagnostic; - at SupportedSourceVersion(RELEASE_10) + at SupportedSourceVersion(RELEASE_11) @SupportedAnnotationTypes("*") public class TraverseProc extends AbstractProcessor { Elements elements; diff -r b85ca7757c38 -r c243b75831dc test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java --- a/test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java Mon Jun 25 15:02:31 2018 -0700 +++ b/test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java Mon Jun 25 15:23:03 2018 -0700 @@ -44,7 +44,10 @@ public class TestRelease { static boolean invoke(String arg) { - return Main.call(System.out, System.err, "--list", "--release", arg); + System.err.println(">>> invoking Main.call with arguments: --list --release " + arg); + boolean r = Main.call(System.out, System.err, "--list", "--release", arg); + System.err.println(">>> Main.call returned " + r); + return r; } @Test From jonathan.gibbons at oracle.com Mon Jun 25 22:35:48 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 25 Jun 2018 15:35:48 -0700 Subject: RFR(s): JDK-8205455: jdeprscan issues annotation processor warning regarding RELEASE_10 In-Reply-To: <24e14c63-4b8f-2ce1-d4b9-c24be769e833@oracle.com> References: <24e14c63-4b8f-2ce1-d4b9-c24be769e833@oracle.com> Message-ID: <1309b09f-bbbc-867d-7220-25fbf02ba1ea@oracle.com> Stuart, This would be more future-proof if you did not use these lines: - at SupportedSourceVersion(RELEASE_10) + at SupportedSourceVersion(RELEASE_11) but instead provided an override definition like this, taken from test/langtools/tools/javac/lib/JavacTestingAbstractProcessor: /** * Return the latest source version. Unless this method is * overridden, an {@code IllegalStateException} will be thrown if a * subclass has a {@code SupportedSourceVersion} annotation. */ @Override public SourceVersion getSupportedSourceVersion() { SupportedSourceVersion ssv = this.getClass().getAnnotation(SupportedSourceVersion.class); if (ssv != null) throw new IllegalStateException("SupportedSourceVersion annotation not supported here."); return SourceVersion.latest(); } or, more simply @Override public SourceVersion getSupportedSourceVersion() { return SourceVersion.latest(); } On 6/25/18 3:28 PM, Stuart Marks wrote: > Hi all, > > Please review this small changeset that updates one of jdeprscan's > annotation processors to RELEASE_11 in order to prevent warning > messages from being issued. This changeset also includes some > additional output lines so that the output of jdeprscan's > TestRelease.java test is more readable. > > Patch appended below. > > Bug: > > ??? https://bugs.openjdk.java.net/browse/JDK-8205455 > > Thanks, > > s'marks > > > # HG changeset patch > # User smarks > # Date 1529965383 25200 > #????? Mon Jun 25 15:23:03 2018 -0700 > # Node ID c243b75831dc8047173586c145a9086e38ebfd76 > # Parent? b85ca7757c381b7a5fe6ab4ad3a0e981541eff0e > 8205455: jdeprscan issues annotation processor warning regarding > RELEASE_10 > Reviewed-by: XXX > > diff -r b85ca7757c38 -r c243b75831dc > src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java > --- > a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java > Mon Jun 25 15:02:31 2018 -0700 > +++ > b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java > Mon Jun 25 15:23:03 2018 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -45,14 +45,14 @@ > ?import javax.lang.model.element.TypeElement; > ?import javax.lang.model.util.Elements; > > -import static javax.lang.model.SourceVersion.RELEASE_10; > +import static javax.lang.model.SourceVersion.RELEASE_11; > ?import javax.lang.model.element.Element; > ?import javax.lang.model.element.ElementKind; > ?import javax.lang.model.element.Modifier; > ?import javax.lang.model.element.PackageElement; > ?import javax.tools.Diagnostic; > > - at SupportedSourceVersion(RELEASE_10) > + at SupportedSourceVersion(RELEASE_11) > ?@SupportedAnnotationTypes("*") > ?public class TraverseProc extends AbstractProcessor { > ???? Elements elements; > diff -r b85ca7757c38 -r c243b75831dc > test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java > --- > a/test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java > Mon Jun 25 15:02:31 2018 -0700 > +++ > b/test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java > Mon Jun 25 15:23:03 2018 -0700 > @@ -44,7 +44,10 @@ > > ?public class TestRelease { > ???? static boolean invoke(String arg) { > -??????? return Main.call(System.out, System.err, "--list", > "--release", arg); > +??????? System.err.println(">>> invoking Main.call with arguments: > --list --release " + arg); > +??????? boolean r = Main.call(System.out, System.err, "--list", > "--release", arg); > +??????? System.err.println(">>> Main.call returned " + r); > +??????? return r; > ???? } > > ???? @Test -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Tue Jun 26 00:04:52 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 25 Jun 2018 17:04:52 -0700 Subject: RFR(s): JDK-8205455: jdeprscan issues annotation processor warning regarding RELEASE_10 In-Reply-To: <1309b09f-bbbc-867d-7220-25fbf02ba1ea@oracle.com> References: <24e14c63-4b8f-2ce1-d4b9-c24be769e833@oracle.com> <1309b09f-bbbc-867d-7220-25fbf02ba1ea@oracle.com> Message-ID: <47364090-cd43-8f63-57b4-475fde77ffef@oracle.com> Hi Jon, Good point. It seems fairly unlikely for jdeprscan to be outright broken by a model change, given that jdeprscan uses annotation processing for class scanning, not source code analysis. I've posted an updated webrev here: ??? http://cr.openjdk.java.net/~smarks/reviews/8205455/webrev.1/ (previous patch posted as webrev.0 for completeness) s'marks On 6/25/18 3:35 PM, Jonathan Gibbons wrote: > > Stuart, > > This would be more future-proof if you did not use these lines: > > > - at SupportedSourceVersion(RELEASE_10) > + at SupportedSourceVersion(RELEASE_11) > > but instead provided an override definition like this, taken from > test/langtools/tools/javac/lib/JavacTestingAbstractProcessor: > > /** > * Return the latest source version. Unless this method is > * overridden, an {@code IllegalStateException} will be thrown if a > * subclass has a {@code SupportedSourceVersion} annotation. > */ > @Override > public SourceVersion getSupportedSourceVersion() { > SupportedSourceVersion ssv = > this.getClass().getAnnotation(SupportedSourceVersion.class); > if (ssv != null) > throw new IllegalStateException("SupportedSourceVersion annotation not > supported here."); > > return SourceVersion.latest(); > } > > or, more simply > > @Override > public SourceVersion getSupportedSourceVersion() { > return SourceVersion.latest(); > } > On 6/25/18 3:28 PM, Stuart Marks wrote: >> Hi all, >> >> Please review this small changeset that updates one of jdeprscan's annotation >> processors to RELEASE_11 in order to prevent warning messages from being >> issued. This changeset also includes some additional output lines so that the >> output of jdeprscan's TestRelease.java test is more readable. >> >> Patch appended below. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8205455 >> >> Thanks, >> >> s'marks >> >> >> # HG changeset patch >> # User smarks >> # Date 1529965383 25200 >> #????? Mon Jun 25 15:23:03 2018 -0700 >> # Node ID c243b75831dc8047173586c145a9086e38ebfd76 >> # Parent? b85ca7757c381b7a5fe6ab4ad3a0e981541eff0e >> 8205455: jdeprscan issues annotation processor warning regarding RELEASE_10 >> Reviewed-by: XXX >> >> diff -r b85ca7757c38 -r c243b75831dc >> src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java >> --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java >> Mon Jun 25 15:02:31 2018 -0700 >> +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java >> Mon Jun 25 15:23:03 2018 -0700 >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -45,14 +45,14 @@ >> ?import javax.lang.model.element.TypeElement; >> ?import javax.lang.model.util.Elements; >> >> -import static javax.lang.model.SourceVersion.RELEASE_10; >> +import static javax.lang.model.SourceVersion.RELEASE_11; >> ?import javax.lang.model.element.Element; >> ?import javax.lang.model.element.ElementKind; >> ?import javax.lang.model.element.Modifier; >> ?import javax.lang.model.element.PackageElement; >> ?import javax.tools.Diagnostic; >> >> - at SupportedSourceVersion(RELEASE_10) >> + at SupportedSourceVersion(RELEASE_11) >> ?@SupportedAnnotationTypes("*") >> ?public class TraverseProc extends AbstractProcessor { >> ???? Elements elements; >> diff -r b85ca7757c38 -r c243b75831dc >> test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java >> --- a/test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java Mon >> Jun 25 15:02:31 2018 -0700 >> +++ b/test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java Mon >> Jun 25 15:23:03 2018 -0700 >> @@ -44,7 +44,10 @@ >> >> ?public class TestRelease { >> ???? static boolean invoke(String arg) { >> -??????? return Main.call(System.out, System.err, "--list", "--release", arg); >> +??????? System.err.println(">>> invoking Main.call with arguments: --list >> --release " + arg); >> +??????? boolean r = Main.call(System.out, System.err, "--list", "--release", >> arg); >> +??????? System.err.println(">>> Main.call returned " + r); >> +??????? return r; >> ???? } >> >> ???? @Test > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Jun 26 00:07:33 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 25 Jun 2018 17:07:33 -0700 Subject: RFR(s): JDK-8205455: jdeprscan issues annotation processor warning regarding RELEASE_10 In-Reply-To: <47364090-cd43-8f63-57b4-475fde77ffef@oracle.com> References: <24e14c63-4b8f-2ce1-d4b9-c24be769e833@oracle.com> <1309b09f-bbbc-867d-7220-25fbf02ba1ea@oracle.com> <47364090-cd43-8f63-57b4-475fde77ffef@oracle.com> Message-ID: <5B3183C5.4060100@oracle.com> +1 On 06/25/2018 05:04 PM, Stuart Marks wrote: > > Hi Jon, > > Good point. It seems fairly unlikely for jdeprscan to be outright > broken by a model change, given that jdeprscan uses annotation > processing for class scanning, not source code analysis. > > I've posted an updated webrev here: > > http://cr.openjdk.java.net/~smarks/reviews/8205455/webrev.1/ > > (previous patch posted as webrev.0 for completeness) > > s'marks > > > On 6/25/18 3:35 PM, Jonathan Gibbons wrote: >> >> Stuart, >> >> This would be more future-proof if you did not use these lines: >> >> >> - at SupportedSourceVersion(RELEASE_10) >> + at SupportedSourceVersion(RELEASE_11) >> >> but instead provided an override definition like this, taken from >> test/langtools/tools/javac/lib/JavacTestingAbstractProcessor: >> >> /** >> * Return the latest source version. Unless this method is >> * overridden, an {@code IllegalStateException} will be thrown if a >> * subclass has a {@code SupportedSourceVersion} annotation. >> */ >> @Override >> public SourceVersion getSupportedSourceVersion() { >> SupportedSourceVersion ssv = this.getClass().getAnnotation(SupportedSourceVersion.class); >> if (ssv != null) >> throw new IllegalStateException("SupportedSourceVersion annotation not supported here."); >> >> return SourceVersion.latest(); >> } >> >> or, more simply >> >> @Override >> public SourceVersion getSupportedSourceVersion() { >> return SourceVersion.latest(); >> } >> >> On 6/25/18 3:28 PM, Stuart Marks wrote: >>> Hi all, >>> >>> Please review this small changeset that updates one of jdeprscan's >>> annotation processors to RELEASE_11 in order to prevent warning >>> messages from being issued. This changeset also includes some >>> additional output lines so that the output of jdeprscan's >>> TestRelease.java test is more readable. >>> >>> Patch appended below. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8205455 >>> >>> Thanks, >>> >>> s'marks >>> >>> >>> # HG changeset patch >>> # User smarks >>> # Date 1529965383 25200 >>> # Mon Jun 25 15:23:03 2018 -0700 >>> # Node ID c243b75831dc8047173586c145a9086e38ebfd76 >>> # Parent b85ca7757c381b7a5fe6ab4ad3a0e981541eff0e >>> 8205455: jdeprscan issues annotation processor warning regarding >>> RELEASE_10 >>> Reviewed-by: XXX >>> >>> diff -r b85ca7757c38 -r c243b75831dc >>> src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java >>> --- >>> a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java >>> Mon Jun 25 15:02:31 2018 -0700 >>> +++ >>> b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java >>> Mon Jun 25 15:23:03 2018 -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2016, 2018, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -45,14 +45,14 @@ >>> import javax.lang.model.element.TypeElement; >>> import javax.lang.model.util.Elements; >>> >>> -import static javax.lang.model.SourceVersion.RELEASE_10; >>> +import static javax.lang.model.SourceVersion.RELEASE_11; >>> import javax.lang.model.element.Element; >>> import javax.lang.model.element.ElementKind; >>> import javax.lang.model.element.Modifier; >>> import javax.lang.model.element.PackageElement; >>> import javax.tools.Diagnostic; >>> >>> - at SupportedSourceVersion(RELEASE_10) >>> + at SupportedSourceVersion(RELEASE_11) >>> @SupportedAnnotationTypes("*") >>> public class TraverseProc extends AbstractProcessor { >>> Elements elements; >>> diff -r b85ca7757c38 -r c243b75831dc >>> test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java >>> --- >>> a/test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java Mon >>> Jun 25 15:02:31 2018 -0700 >>> +++ >>> b/test/langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java Mon >>> Jun 25 15:23:03 2018 -0700 >>> @@ -44,7 +44,10 @@ >>> >>> public class TestRelease { >>> static boolean invoke(String arg) { >>> - return Main.call(System.out, System.err, "--list", >>> "--release", arg); >>> + System.err.println(">>> invoking Main.call with arguments: >>> --list --release " + arg); >>> + boolean r = Main.call(System.out, System.err, "--list", >>> "--release", arg); >>> + System.err.println(">>> Main.call returned " + r); >>> + return r; >>> } >>> >>> @Test >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Jun 26 09:42:43 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Jun 2018 10:42:43 +0100 Subject: RFR: JDK-8205418: Assorted improvements to source code model In-Reply-To: <5B310259.6040107@oracle.com> References: <5B2B8F72.8040707@oracle.com> <454b1e9d-b7ad-287a-61b1-140cc686785b@oracle.com> <5B2CDD83.6090600@oracle.com> <5B310259.6040107@oracle.com> Message-ID: <4a3857e7-3f69-4ea6-b22c-5aa012903067@oracle.com> Looks very good. I think esp. the changes in Resolve will help in getting more consistent diagnostics in the compiler. P.S. Since we're looking here - there is a long-standing issue in resolution errors that I think should be addressed (not as part of this fix of course): whenever there's an ambiguous call, javac picks one of the two methods as the result of overload selection, and this can lead to spurious downstream diagnostics - consider the following example: class Amb { ??? String m(int i1, Integer i2) { return ""; } ??? int m(Integer i1, int i2) { return 32; } ??? void test() { ???????? int i = m(42, 42); ??? } } This gives the following errors: Amb.java:9: error: reference to m is ambiguous ???????? int i = m(42, 42); ???????????????? ^ ? both method m(int,Integer) in Amb and method m(Integer,int) in Amb match Amb.java:9: error: incompatible types: String cannot be converted to int ???????? int i = m(42, 42); ????????????????? ^ 2 errors As you can see, the first one is genuine, the second is spurious, and order-dependent. Maurizio On 25/06/18 15:55, Jan Lahoda wrote: > Thanks for all the comments. > > I've updated the patch according to the comment, and uploaded the new > patch here: > http://cr.openjdk.java.net/~jlahoda/8205418/webrev.01/ > > (For the RecoveryInfo.CheckContext.report, I've disabled the errors > only when the new recovery is active, which should limit the effects > on error messages.) > > Any feedback is welcome! > > Thanks, > ??? Jan > > On 22.6.2018 14:37, Maurizio Cimadamore wrote: >> >> >> On 22/06/18 13:32, Maurizio Cimadamore wrote: >>> When messages are simplified, basically we turn errors into other >>> errors - e.g. look at InapplicableSymbol_S_Error::getDiagnostic - >>> there is some logic and then, if there's really onlt one relevant >>> candidate, we go back to an InapplicableSymbol (without S) error, >>> where 'errCandidate' is overridden to return the filtered symbol. >>> >>> Another reason to rely more on errCandidate >> More specifically, if simplified diagnostics are disabled, you go remain >> in the multiple symbols world, which means you still have more >> candidates and you fail to see that only one was really the good one. >> >> So, I think InapplicableSymbolsError should override bestCandidate >> (which I also suggested in previous email), and should call >> filterCandidates before doing the processing. This will ensure that >> 'redundant' candidates are dropped, and you get back the symbol that is >> most likely to be the correct one. >> >> Maurizio >> From joe.darcy at oracle.com Tue Jun 26 17:05:34 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 26 Jun 2018 10:05:34 -0700 Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 / JDK-8193292, JDK-8193290 In-Reply-To: <73b0e964-ae47-0938-0986-088624fb973a@oracle.com> References: <73b0e964-ae47-0938-0986-088624fb973a@oracle.com> Message-ID: <45e80485-d044-175b-8819-686507b554bd@oracle.com> Slightly updated patch: ??? http://cr.openjdk.java.net/~darcy/8205615.5/ Cheers, -Joe On 6/25/2018 11:38 AM, joe darcy wrote: > Hello, > > With the JDK 11 and 12 split fast approaching [1], it is time to work > on the various start of release update tasks for JDK 12. Those tasks > are being tracked under the umbrella bug JDK-8205615: "Start of > release updates for JDK 12". For JDK 12, we're attempting to get the > full set of related changes (updated JDK version number, bumped class > file version update, new javac -source/-target values, etc.) pushed > simultaneously. This thread is to review the langtools-related > portions of the work including > > ??? JDK-8193292: Add SourceVersion.RELEASE_12 > ??? JDK-8193290: Add source 12 and target 12 to javac > > as well as updates to the langtools tests for the class file update. > > Current webrev: > > ??? http://cr.openjdk.java.net/~darcy/8205615.4/ > > As part of JDK-8193292: "Add SourceVersion.RELEASE_12", the JDK-9 era > visitors in javax.lang.model.util are updated to state they model over > version 9 through 12. > > For now, tools/javac/options/smokeTests/OptionSmokeTest.java is > problem listed since it has many hard-coding version checks. > > Preview language features are only supported against the current > source version so those tests need their explicit version number updated. > > A handful of test failures still need to be addressed, so there will > be some minor adjustments to the aggregate set of changes before they > are pushed. > > Thanks, > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html > From jan.lahoda at oracle.com Wed Jun 27 14:10:09 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 27 Jun 2018 16:10:09 +0200 Subject: RFR: JDK-8205913: Inconsistent source code model Message-ID: <5B339AC1.4050206@oracle.com> Hi, For code like: for (name : names) { } javac creates a VariableTree for "name", but it has null modifiers and name, which appears to be inconsistent with other similar cases. So the proposal is to change this so that there are non-null modifiers and non-null name (). Webrev: http://cr.openjdk.java.net/~jlahoda/8205913/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8205913 Any feedback is welcome. Thanks, Jan From maurizio.cimadamore at oracle.com Wed Jun 27 14:20:00 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Jun 2018 15:20:00 +0100 Subject: RFR: JDK-8205913: Inconsistent source code model In-Reply-To: <5B339AC1.4050206@oracle.com> References: <5B339AC1.4050206@oracle.com> Message-ID: Looks good Maurizio On 27/06/18 15:10, Jan Lahoda wrote: > Hi, > > For code like: > for (name : names) { } > > javac creates a VariableTree for "name", but it has null modifiers and > name, which appears to be inconsistent with other similar cases. So > the proposal is to change this so that there are non-null modifiers > and non-null name (). > > Webrev: http://cr.openjdk.java.net/~jlahoda/8205913/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8205913 > > Any feedback is welcome. > > Thanks, > ??? Jan From jan.lahoda at oracle.com Wed Jun 27 16:16:22 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 27 Jun 2018 18:16:22 +0200 Subject: RFR (JDK11): JDK-8195986: Incorrect javac -h output with annotation processing and missing classes Message-ID: <5B33B856.8040104@oracle.com> Hi, javac tries to reuse ClassSymbol across annotation processing rounds, so that they don't need to be load multiple times from the classfiles. But, in some cases (namely, when some of the ClassSymbols that were loaded from the classfiles depend on unknown class that may be generated by the annotation processor), javac clears all suspicious ClassSymbols, and recompletes them again. But it, currently, also sets new Types for all the cleared ClassSymbols. This then leads to new types assigned to critical classes like j.l.String, which then leads to: Symtab.stringType != Symtab.stringType.tsym.type (because Symtab.stringType contains the very original type assigned to j.l.String, but Symtab.stringType.tsym.type is the one assigned in the last annotation processing round.) This then misguides the JNIWriter to write a wrong native header, but could potentially lead to other problems as well. I believe the need to set new types is for the case where the ClassSymbol's type is erroneous (and needs to be fixed back to ClassType), so the proposed patch is to only set new types for ERR ClassSymbols. (ClassTypes should be cleared to their pristine state in ClassSymbol.reset().) An alternative fix would be to fix the JNIWriter to use Symtab.stringType.tsym for comparison instead of Symtab.stringType. Webrev: http://cr.openjdk.java.net/~jlahoda/8195986/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8195986 Any feedback is welcome. Thanks, Jan From vicente.romero at oracle.com Wed Jun 27 19:29:49 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 27 Jun 2018 15:29:49 -0400 Subject: RFR (JDK11): JDK-8195986: Incorrect javac -h output with annotation processing and missing classes In-Reply-To: <5B33B856.8040104@oracle.com> References: <5B33B856.8040104@oracle.com> Message-ID: <4d8fb348-c76b-7492-145e-9e3a2aea2576@oracle.com> looks good, Vicente On 06/27/2018 12:16 PM, Jan Lahoda wrote: > Hi, > > javac tries to reuse ClassSymbol across annotation processing rounds, > so that they don't need to be load multiple times from the classfiles. > > But, in some cases (namely, when some of the ClassSymbols that were > loaded from the classfiles depend on unknown class that may be > generated by the annotation processor), javac clears all suspicious > ClassSymbols, and recompletes them again. But it, currently, also sets > new Types for all the cleared ClassSymbols. > > This then leads to new types assigned to critical classes like > j.l.String, which then leads to: > Symtab.stringType != Symtab.stringType.tsym.type > > (because Symtab.stringType contains the very original type assigned to > j.l.String, but Symtab.stringType.tsym.type is the one assigned in the > last annotation processing round.) > > This then misguides the JNIWriter to write a wrong native header, but > could potentially lead to other problems as well. > > I believe the need to set new types is for the case where the > ClassSymbol's type is erroneous (and needs to be fixed back to > ClassType), so the proposed patch is to only set new types for ERR > ClassSymbols. (ClassTypes should be cleared to their pristine state in > ClassSymbol.reset().) > > An alternative fix would be to fix the JNIWriter to use > Symtab.stringType.tsym for comparison instead of Symtab.stringType. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8195986/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8195986 > > Any feedback is welcome. > > Thanks, > ??? Jan From jan.lahoda at oracle.com Thu Jun 28 11:11:37 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 28 Jun 2018 13:11:37 +0200 Subject: RFR: JDK-8205985: Remove tools/javac/options/release/ReleaseOptionUnsupported.java from problem list Message-ID: <5B34C269.3010307@oracle.com> Hi, The langtools' test problem list excludes a test whose bug has been fixed, so I'd like to remove that exclude. Webrev: http://cr.openjdk.java.net/~jlahoda/8205985/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8205985 Thanks, Jan From vicente.romero at oracle.com Thu Jun 28 13:03:46 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 28 Jun 2018 09:03:46 -0400 Subject: RFR: JDK-8205985: Remove tools/javac/options/release/ReleaseOptionUnsupported.java from problem list In-Reply-To: <5B34C269.3010307@oracle.com> References: <5B34C269.3010307@oracle.com> Message-ID: looks good, Vicente On 06/28/2018 07:11 AM, Jan Lahoda wrote: > Hi, > > The langtools' test problem list excludes a test whose bug has been > fixed, so I'd like to remove that exclude. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8205985/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8205985 > > Thanks, > ?? Jan From joe.darcy at oracle.com Thu Jun 28 23:18:01 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 28 Jun 2018 16:18:01 -0700 Subject: JDK 12 RFR of JDK-8206083: Make tools/javac/api/T6265137.java robust to JDK version changes Message-ID: <8823d612-d41c-926a-72ce-31348ad28a14@oracle.com> Hello, Please review the change? below for ??? JDK-8206083: Make tools/javac/api/T6265137.java robust to JDK version changes ??? http://cr.openjdk.java.net/~darcy/8206083.0/ which removes the need to explicitly update this test when the JDK version changes, assuming the JDK version corresponds to a valid -target value. Alternatively, the target option to pass could be derived from information in javax.lang.model.SourceVersion. Thanks, -Joe --- old/test/langtools/tools/javac/api/T6265137.java 2018-06-28 16:13:53.531566685 -0700 +++ new/test/langtools/tools/javac/api/T6265137.java??? 2018-06-28 16:13:52.683142659 -0700 @@ -52,7 +52,9 @@ ???????????? String srcdir = System.getProperty("test.src"); ???????????? Iterable files = ???????????????? fm.getJavaFileObjectsFromFiles(Arrays.asList(new File(srcdir, "T6265137a.java"))); -??????????? javac.getTask(null, fm, dl, Arrays.asList("-target", "12"), null, files).call(); +??????????? javac.getTask(null, fm, dl, +????????????????????????? Arrays.asList("-target", Integer.toString(Runtime.version().feature())), +????????????????????????? null, files).call(); ???????? } ???? } ?} From jonathan.gibbons at oracle.com Thu Jun 28 23:22:22 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 28 Jun 2018 16:22:22 -0700 Subject: JDK 12 RFR of JDK-8206083: Make tools/javac/api/T6265137.java robust to JDK version changes In-Reply-To: <8823d612-d41c-926a-72ce-31348ad28a14@oracle.com> References: <8823d612-d41c-926a-72ce-31348ad28a14@oracle.com> Message-ID: <5B356DAE.7030303@oracle.com> +1 On 06/28/2018 04:18 PM, joe darcy wrote: > Hello, > > Please review the change below for > > JDK-8206083: Make tools/javac/api/T6265137.java robust to JDK > version changes > http://cr.openjdk.java.net/~darcy/8206083.0/ > > which removes the need to explicitly update this test when the JDK > version changes, assuming the JDK version corresponds to a valid > -target value. > > Alternatively, the target option to pass could be derived from > information in javax.lang.model.SourceVersion. > > Thanks, > > -Joe > > --- old/test/langtools/tools/javac/api/T6265137.java 2018-06-28 > 16:13:53.531566685 -0700 > +++ new/test/langtools/tools/javac/api/T6265137.java 2018-06-28 > 16:13:52.683142659 -0700 > @@ -52,7 +52,9 @@ > String srcdir = System.getProperty("test.src"); > Iterable files = > fm.getJavaFileObjectsFromFiles(Arrays.asList(new > File(srcdir, "T6265137a.java"))); > - javac.getTask(null, fm, dl, Arrays.asList("-target", > "12"), null, files).call(); > + javac.getTask(null, fm, dl, > + Arrays.asList("-target", > Integer.toString(Runtime.version().feature())), > + null, files).call(); > } > } > } > From cushon at google.com Fri Jun 29 00:19:03 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 28 Jun 2018 17:19:03 -0700 Subject: RFR: 8204630: generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment In-Reply-To: References: <5B1FD510.1090808@oracle.com> Message-ID: Hi, Is there any more feedback on this? The bug is currently targeted for JDK 11, but I can defer it if there are any concerns. Thanks, Liam On Tue, Jun 12, 2018 at 7:50 PM Liam Miller-Cushon wrote: > Hi Jan, > > Thanks for the review, and the explanation! > > On Tue, Jun 12, 2018 at 7:13 AM Jan Lahoda wrote: > >> So the change in JavacProcessingEnvironment could be, I think, rewritten >> as: >> if (cs.owner.kind == PCK) { >> cs.owner.members().enterIfAbsent(cs); >> } >> > > Done. > > The change in ClassReader seems unnecessary, or am I mistaken? >> > > Nope, I think you're right. > > Updated webrev: > http://cr.openjdk.java.net/~cushon/8204630/webrev.01/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Jun 29 03:15:47 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 28 Jun 2018 20:15:47 -0700 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java Message-ID: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> Hello, Fresh off of updating ??? langtools/tools/javac/versions/Versions.java for the JDK 11 -> 12 transition, I'd like to refactor the test to reduce the maintenance needed when adding new versions (as in new releases) or removing versions (as is planned for later in JDK 12): ??? http://cr.openjdk.java.net/~darcy/8206085.0/ Thanks, -Joe From jonathan.gibbons at oracle.com Fri Jun 29 16:55:16 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 29 Jun 2018 09:55:16 -0700 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> Message-ID: <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> There's more static in this file than on my high-school Van de Graaf generator! Can we follow the convention of creating an instance in main, and then using instance methods. The naming of some methods is also novel, with respect to case-conventions. -- Jon On 6/28/18 8:15 PM, joe darcy wrote: > Hello, > > Fresh off of updating > > ??? langtools/tools/javac/versions/Versions.java > > for the JDK 11 -> 12 transition, I'd like to refactor the test to > reduce the maintenance needed when adding new versions (as in new > releases) or removing versions (as is planned for later in JDK 12): > > ??? http://cr.openjdk.java.net/~darcy/8206085.0/ > > Thanks, > > -Joe > From joe.darcy at oracle.com Fri Jun 29 19:41:31 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 29 Jun 2018 12:41:31 -0700 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> Message-ID: <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> Dis-charged revision along with JDK 11 specific source example now up at ??? http://cr.openjdk.java.net/~darcy/8206085.1/ Thanks, -Joe On 6/29/2018 9:55 AM, Jonathan Gibbons wrote: > There's more static in this file than on my high-school Van de Graaf > generator! > > Can we follow the convention of creating an instance in main, and then > using instance methods. > > The naming of some methods is also novel, with respect to > case-conventions. > > -- Jon > > > On 6/28/18 8:15 PM, joe darcy wrote: >> Hello, >> >> Fresh off of updating >> >> ??? langtools/tools/javac/versions/Versions.java >> >> for the JDK 11 -> 12 transition, I'd like to refactor the test to >> reduce the maintenance needed when adding new versions (as in new >> releases) or removing versions (as is planned for later in JDK 12): >> >> ??? http://cr.openjdk.java.net/~darcy/8206085.0/ >> >> Thanks, >> >> -Joe >> > From forax at univ-mlv.fr Fri Jun 29 21:13:59 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 29 Jun 2018 23:13:59 +0200 (CEST) Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> Message-ID: <452192210.1891425.1530306839541.JavaMail.zimbra@u-pem.fr> Hi Joe, can you declare the instance fields of the enum 'final', thinking that there is a mutable enum constant somewhere make me sad. regards, R?mi ----- Mail original ----- > De: "joe darcy" > ?: "jonathan gibbons" , "compiler-dev" > Envoy?: Vendredi 29 Juin 2018 21:41:31 > Objet: Re: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java > Dis-charged revision along with JDK 11 specific source example now up at > > ??? http://cr.openjdk.java.net/~darcy/8206085.1/ > > Thanks, > > -Joe > > > On 6/29/2018 9:55 AM, Jonathan Gibbons wrote: >> There's more static in this file than on my high-school Van de Graaf >> generator! >> >> Can we follow the convention of creating an instance in main, and then >> using instance methods. >> >> The naming of some methods is also novel, with respect to >> case-conventions. >> >> -- Jon >> >> >> On 6/28/18 8:15 PM, joe darcy wrote: >>> Hello, >>> >>> Fresh off of updating >>> >>> ??? langtools/tools/javac/versions/Versions.java >>> >>> for the JDK 11 -> 12 transition, I'd like to refactor the test to >>> reduce the maintenance needed when adding new versions (as in new >>> releases) or removing versions (as is planned for later in JDK 12): >>> >>> ??? http://cr.openjdk.java.net/~darcy/8206085.0/ >>> >>> Thanks, >>> >>> -Joe >>> From cushon at google.com Fri Jun 29 22:55:30 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 29 Jun 2018 15:55:30 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter Message-ID: Hi, Please consider this fix for JDK-8198945, which I prepared in collaboration with wmdietl. bug: https://bugs.openjdk.java.net/browse/JDK-8198945 webrev: http://cr.openjdk.java.net/~cushon/8198945/webrev.00/ The issue involves annotations on the type of an anonymous class declaration. Consider e.g.: ``` import java.lang.annotation.*; class Test { @Target(ElementType.TYPE_USE) @interface TA {} @Target(ElementType.TYPE_USE) @interface TB {} interface I {} void f() { new @TA I<@TB Object>() {}; } } ``` Note that the use of `I` in the anonymous class declaration corresponds to the supertype of the declared anonymous class, not the type of the anonymous class Test$1. With javac 11-ea+19 the annotations are attached to the supertype of Test$1, as expected: $ javap -v 'Test$1' ... RuntimeInvisibleTypeAnnotations: 0: #21(): CLASS_EXTENDS, type_index=0, location=[TYPE_ARGUMENT(0)] Test$TB 1: #24(): CLASS_EXTENDS, type_index=0 Test$TA However the annotations also appear at the enclosing method declaration: $ javap -v Test ... void f(); descriptor: ()V flags: (0x0000) Code: stack=3, locals=1, args_size=1 0: new #2 // class Test$1 3: dup 4: aload_0 5: invokespecial #3 // Method Test$1."":(LTest;)V ... RuntimeInvisibleTypeAnnotations: 0: #19(): NEW, offset=0 Test$TB 1: #20(): NEW, offset=0 Test$TA RuntimeInvisibleTypeAnnotations: 0: #19(): CLASS_EXTENDS, type_index=0, location=[TYPE_ARGUMENT(0)] Test$TB The handling of @TB in particular is clearly incorrect: * @TB appears with a `NEW` type path that leads to the top-level type of the 'new' expression, even though @TB appeared on a type argument of that type and not at the top level. * @TB also appears on 'f' with a `CLASS_EXTENDS` path and no bytecode offset, which does not provide enough information to associate it with the annotated location. The handling of @TA is also questionable. It makes some sense to use the same type path for an annotation on the type of an anonymous class declaration as the type of a regular 'new' expression. However that results in the same use of @TA appearing twice in bytecode, and conflates the type of the anonymous class with its supertype. I think it is more correct to only emit @TA as a `CLASS_EXTENDS` annotation on Test$1, and not include a copy of it at the enclosing method. Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Jun 29 23:39:17 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 29 Jun 2018 16:39:17 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: Message-ID: <5B36C325.7080605@oracle.com> On 6/29/2018 3:55 PM, Liam Miller-Cushon wrote: > The handling of @TB in particular is clearly incorrect: > > * @TB appears with a `NEW` type path that leads to the top-level type of > the 'new' expression, even though @TB appeared on a type argument of > that type and not at the top level. > > * @TB also appears on 'f' with a `CLASS_EXTENDS` path and no bytecode > offset, which does not provide enough information to associate it with > the annotated location. I agree with both points. It is egregious that the method_info structure for `f` (as opposed to the Code attribute therein) as a Runtime*TypeAnnotations attribute. > The handling of @TA is also questionable. It makes some sense to use the > same type path for an annotation on the type of an anonymous class > declaration as the type of a regular 'new' expression. However that > results in the same use of @TA appearing twice in bytecode, and > conflates the type of the anonymous class with its supertype. > > I think it is more correct to only emit @TA as a `CLASS_EXTENDS` > annotation on Test$1, and not include a copy of it at the enclosing method. I did some digging and found three threads from 2013: 1. "Annotations on anonymous classes" http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-February/000063.html 2. "Desugaring of anonymous classes" http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-April/000092.html 3. "Desugaring of anonymous classes" (followup) http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-August/000127.html It seems like I changed my mind on the matter of recording @TA: - In February I agreed with your view, Liam, that @TA should appear only as a CLASS_EXTENDS path in the implicit class declaration (Test$1), and not as a NEW path in the code of `f`. - But in April, I said that @TA should be recorded as both paths. Per the followup mail in August, this was driven by a longstanding policy that "In the classfile, the type annotations are copied to the class declaration and to its instantiation (new expression)." In June 2018, I do not mind whether @TA appears as CLASS_EXTENDS only, or as CLASS_EXTENDS + NEW. If you and Werner have agreed on CLASS_EXTENDS only, and if your fix (which is mostly deletion) makes the recording of both @TA and @TB more reliable, then I defer to your decision. Alex From joe.darcy at oracle.com Sat Jun 30 16:17:39 2018 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 30 Jun 2018 09:17:39 -0700 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: <452192210.1891425.1530306839541.JavaMail.zimbra@u-pem.fr> References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> <452192210.1891425.1530306839541.JavaMail.zimbra@u-pem.fr> Message-ID: <5f836f22-dcd9-c7a6-04c2-fabd6a686970@oracle.com> Hi Remi, On 6/29/2018 2:13 PM, Remi Forax wrote: > Hi Joe, > can you declare the instance fields of the enum 'final', thinking that there is a mutable enum constant somewhere make me sad. > So noted; I'll make the fields explicitly finale. However, no cause to be glum, the field were set exactly once in the constructor ;-) Thanks, -Joe From joe.darcy at oracle.com Sat Jun 30 16:45:25 2018 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 30 Jun 2018 09:45:25 -0700 Subject: JDK 12 RFR of JDK-8206114: Refactor langtools/tools/javac/classfiles/ClassVersionChecker.java Message-ID: <6ad3c11c-a581-720c-ee38-21a6a8ec4386@oracle.com> Hello, Another day, another version-related test refactoring: ??? JDK-8206114: Refactor langtools/tools/javac/classfiles/ClassVersionChecker.java ??? http://cr.openjdk.java.net/~darcy/8206114.0/ I've verified the ease of maintenance of the test by removing the TWELVE enum value and running the test against JDK 11. This is overlap in the test coverage of this test and other other test out for review, but I haven't not tried to precisely determine or eliminate that overlap. Thanks, -Joe