From brucechapman at paradise.net.nz Sat Nov 1 08:58:36 2014 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Sat, 01 Nov 2014 21:58:36 +1300 Subject: JEP 222: Java Read-Eval-Print Loop (REPL) In-Reply-To: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> References: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> Message-ID: <5454A0BC.5020907@paradise.net.nz> I built (for some value of "built" near to the value of "hack") one of these back in 2009 for our local java user group [1] as a demo for the compiler API and an annotation processor test framework I built [2] If you are interested I can find and dust off the code and make sure it still all works (why wouldn't it). Bruce [1] http://wellingtonjug.org.nz/talk200905.html [2] https://java.net/projects/hickory On 31/10/2014 10:56 a.m., mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/222 > > - Mark > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From robert.field at oracle.com Sat Nov 1 16:03:29 2014 From: robert.field at oracle.com (Robert Field) Date: Sat, 01 Nov 2014 09:03:29 -0700 Subject: JEP 222: Java Read-Eval-Print Loop (REPL) In-Reply-To: <5454A0BC.5020907@paradise.net.nz> References: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> <5454A0BC.5020907@paradise.net.nz> Message-ID: <54550451.40802@oracle.com> Thanks Bruce. I'm quite far along, so I doubt that would be useful. -Robert On 11/01/14 01:58, Bruce Chapman wrote: > I built (for some value of "built" near to the value of "hack") one of > these back in 2009 for our local java user group [1] as a demo for the > compiler API and an annotation processor test framework I built [2] > > If you are interested I can find and dust off the code and make sure > it still all works (why wouldn't it). > > Bruce > > > > [1] http://wellingtonjug.org.nz/talk200905.html > [2] https://java.net/projects/hickory > > > On 31/10/2014 10:56 a.m., mark.reinhold at oracle.com wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/222 >> >> - Mark >> > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > From brian.goetz at oracle.com Sat Nov 1 16:14:40 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 01 Nov 2014 12:14:40 -0400 Subject: JEP 222: Java Read-Eval-Print Loop (REPL) In-Reply-To: <54550451.40802@oracle.com> References: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> <5454A0BC.5020907@paradise.net.nz> <54550451.40802@oracle.com> Message-ID: <545506F0.7040706@oracle.com> What might be useful, though, is any *usability* experience that you had with people trying it out. What did people complain about? What non-obvious features did people seem to expect should be part of the feature set? (Note, though, that we're asking for *actual* experience of "I built X and people who used it complained of Y", not theorizing of the form "I could imagine I might want Y in some situation...".) On 11/1/2014 12:03 PM, Robert Field wrote: > Thanks Bruce. I'm quite far along, so I doubt that would be useful. > > -Robert > > On 11/01/14 01:58, Bruce Chapman wrote: >> I built (for some value of "built" near to the value of "hack") one of >> these back in 2009 for our local java user group [1] as a demo for the >> compiler API and an annotation processor test framework I built [2] >> >> If you are interested I can find and dust off the code and make sure >> it still all works (why wouldn't it). >> >> Bruce >> >> >> >> [1] http://wellingtonjug.org.nz/talk200905.html >> [2] https://java.net/projects/hickory >> >> >> On 31/10/2014 10:56 a.m., mark.reinhold at oracle.com wrote: >>> New JEP Candidate: http://openjdk.java.net/jeps/222 >>> >>> - Mark >>> >> >> >> --- >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> http://www.avast.com >> > From forax at univ-mlv.fr Sat Nov 1 21:45:37 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 01 Nov 2014 22:45:37 +0100 Subject: JEP 222: Java Read-Eval-Print Loop (REPL) In-Reply-To: <545506F0.7040706@oracle.com> References: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> <5454A0BC.5020907@paradise.net.nz> <54550451.40802@oracle.com> <545506F0.7040706@oracle.com> Message-ID: <54555481.309@univ-mlv.fr> On 11/01/2014 05:14 PM, Brian Goetz wrote: > What might be useful, though, is any *usability* experience that you > had with people trying it out. What did people complain about? What > non-obvious features did people seem to expect should be part of the > feature set? I build 3 REPLs for mostly DSLs that runs on top of the JVM. features: history, code completion, doc, record/replay usual comments: - number 1: it works in the REPL but not with a file. - number 2: can I avoid to declare the types (see number 1). - it doesn't work like bash, zsh, ipython. - can I have the feature XXX of IntelliJ/Eclipse/Netbeans ? - the doc of this method is too big, I want only the interesting part. - record/replay, I want only to replay the part that are not me messing around. > > (Note, though, that we're asking for *actual* experience of "I built X > and people who used it complained of Y", not theorizing of the form "I > could imagine I might want Y in some situation...".) cheers, R?mi > > On 11/1/2014 12:03 PM, Robert Field wrote: >> Thanks Bruce. I'm quite far along, so I doubt that would be useful. >> >> -Robert >> >> On 11/01/14 01:58, Bruce Chapman wrote: >>> I built (for some value of "built" near to the value of "hack") one of >>> these back in 2009 for our local java user group [1] as a demo for the >>> compiler API and an annotation processor test framework I built [2] >>> >>> If you are interested I can find and dust off the code and make sure >>> it still all works (why wouldn't it). >>> >>> Bruce >>> >>> >>> >>> [1] http://wellingtonjug.org.nz/talk200905.html >>> [2] https://java.net/projects/hickory >>> >>> >>> On 31/10/2014 10:56 a.m., mark.reinhold at oracle.com wrote: >>>> New JEP Candidate: http://openjdk.java.net/jeps/222 >>>> >>>> - Mark >>>> >>> >>> >>> --- >>> This email is free from viruses and malware because avast! Antivirus >>> protection is active. >>> http://www.avast.com >>> >> From robert.field at oracle.com Sat Nov 1 23:34:19 2014 From: robert.field at oracle.com (Robert Field) Date: Sat, 01 Nov 2014 16:34:19 -0700 Subject: JEP 222: Java Read-Eval-Print Loop (REPL) In-Reply-To: <54555481.309@univ-mlv.fr> References: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> <5454A0BC.5020907@paradise.net.nz> <54550451.40802@oracle.com> <545506F0.7040706@oracle.com> <54555481.309@univ-mlv.fr> Message-ID: <1496db58cd8.27a6.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thanks Remi. Does automatic creation of a temp variable for an expression address 2 without breaking 1? Bash et al, was that compatibility or features, if features, what features? What were your answers to these? Thanks, Robert On November 1, 2014 2:46:03 PM Remi Forax wrote: > > On 11/01/2014 05:14 PM, Brian Goetz wrote: > > What might be useful, though, is any *usability* experience that you > > had with people trying it out. What did people complain about? What > > non-obvious features did people seem to expect should be part of the > > feature set? > > I build 3 REPLs for mostly DSLs that runs on top of the JVM. > > features: history, code completion, doc, record/replay > > usual comments: > - number 1: it works in the REPL but not with a file. > - number 2: can I avoid to declare the types (see number 1). > - it doesn't work like bash, zsh, ipython. > - can I have the feature XXX of IntelliJ/Eclipse/Netbeans ? > - the doc of this method is too big, I want only the interesting part. > - record/replay, I want only to replay the part that are not me > messing around. > > > > > (Note, though, that we're asking for *actual* experience of "I built X > > and people who used it complained of Y", not theorizing of the form "I > > could imagine I might want Y in some situation...".) > > cheers, > R?mi > > > > > On 11/1/2014 12:03 PM, Robert Field wrote: > >> Thanks Bruce. I'm quite far along, so I doubt that would be useful. > >> > >> -Robert > >> > >> On 11/01/14 01:58, Bruce Chapman wrote: > >>> I built (for some value of "built" near to the value of "hack") one of > >>> these back in 2009 for our local java user group [1] as a demo for the > >>> compiler API and an annotation processor test framework I built [2] > >>> > >>> If you are interested I can find and dust off the code and make sure > >>> it still all works (why wouldn't it). > >>> > >>> Bruce > >>> > >>> > >>> > >>> [1] http://wellingtonjug.org.nz/talk200905.html > >>> [2] https://java.net/projects/hickory > >>> > >>> > >>> On 31/10/2014 10:56 a.m., mark.reinhold at oracle.com wrote: > >>>> New JEP Candidate: http://openjdk.java.net/jeps/222 > >>>> > >>>> - Mark > >>>> > >>> > >>> > >>> --- > >>> This email is free from viruses and malware because avast! Antivirus > >>> protection is active. > >>> http://www.avast.com > >>> > >> > From forax at univ-mlv.fr Sun Nov 2 01:08:55 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 02 Nov 2014 02:08:55 +0100 Subject: JEP 222: Java Read-Eval-Print Loop (REPL) In-Reply-To: <1496db58cd8.27a6.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> <5454A0BC.5020907@paradise.net.nz> <54550451.40802@oracle.com> <545506F0.7040706@oracle.com> <54555481.309@univ-mlv.fr> <1496db58cd8.27a6.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <54558427.8010406@univ-mlv.fr> On 11/02/2014 12:34 AM, Robert Field wrote: > Thanks Remi. > > Does automatic creation of a temp variable for an expression address 2 > without breaking 1? I end up doing something like this, all variables created in the REPL are stored in a Map and I re-create all of them as local variables before execution the expression and after executing the expression, I save the ones that have been created/modified back into the map. I need to do that instead of transforming the access to a REPL variable to a map.get()/map.put() because of the semantics of the captured local variables in lambdas/blocks. About 2 without breaking 1, the main issue is in function (let say that they are translated into Java static method), if you do not allow to not declare type, then it doesn't work like at the top level of the REPL and if you do then it doesn't work like in a classical Java file. > > Bash et al, was that compatibility or features, if features, what > features? Features and compatibility, the feature asked were syntax highlighting and programmable completion, and the compatibility was with the different format to specify syntax highlighting, programmable completion, and also corner cases in the way to use glob when searching history, do text substitution, etc. > > What were your answers to these? standard answers, hire another guy to do the customization or in case of the open source project, i accept pull requests ! not something i'm very proud of but i had/have to stay focused. > > Thanks, > Robert cheers, R?mi > > > > On November 1, 2014 2:46:03 PM Remi Forax wrote: > >> >> On 11/01/2014 05:14 PM, Brian Goetz wrote: >> > What might be useful, though, is any *usability* experience that you >> > had with people trying it out. What did people complain about? What >> > non-obvious features did people seem to expect should be part of the >> > feature set? >> >> I build 3 REPLs for mostly DSLs that runs on top of the JVM. >> >> features: history, code completion, doc, record/replay >> >> usual comments: >> - number 1: it works in the REPL but not with a file. >> - number 2: can I avoid to declare the types (see number 1). >> - it doesn't work like bash, zsh, ipython. >> - can I have the feature XXX of IntelliJ/Eclipse/Netbeans ? >> - the doc of this method is too big, I want only the interesting part. >> - record/replay, I want only to replay the part that are not me >> messing around. >> >> > >> > (Note, though, that we're asking for *actual* experience of "I built X >> > and people who used it complained of Y", not theorizing of the form "I >> > could imagine I might want Y in some situation...".) >> >> cheers, >> R?mi >> >> > >> > On 11/1/2014 12:03 PM, Robert Field wrote: >> >> Thanks Bruce. I'm quite far along, so I doubt that would be useful. >> >> >> >> -Robert >> >> >> >> On 11/01/14 01:58, Bruce Chapman wrote: >> >>> I built (for some value of "built" near to the value of "hack") >> one of >> >>> these back in 2009 for our local java user group [1] as a demo >> for the >> >>> compiler API and an annotation processor test framework I built [2] >> >>> >> >>> If you are interested I can find and dust off the code and make sure >> >>> it still all works (why wouldn't it). >> >>> >> >>> Bruce >> >>> >> >>> >> >>> >> >>> [1] http://wellingtonjug.org.nz/talk200905.html >> >>> [2] https://java.net/projects/hickory >> >>> >> >>> >> >>> On 31/10/2014 10:56 a.m., mark.reinhold at oracle.com wrote: >> >>>> New JEP Candidate: http://openjdk.java.net/jeps/222 >> >>>> >> >>>> - Mark >> >>>> >> >>> >> >>> >> >>> --- >> >>> This email is free from viruses and malware because avast! Antivirus >> >>> protection is active. >> >>> http://www.avast.com >> >>> >> >> >> > > From archie at dellroad.org Sun Nov 2 16:40:12 2014 From: archie at dellroad.org (Archie Cobbs) Date: Sun, 2 Nov 2014 10:40:12 -0600 Subject: JEP 222: Java Read-Eval-Print Loop (REPL) In-Reply-To: <545506F0.7040706@oracle.com> References: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> <5454A0BC.5020907@paradise.net.nz> <54550451.40802@oracle.com> <545506F0.7040706@oracle.com> Message-ID: (resent from the correct email address) Hi Brian, Here are some notes from my experience. A little background... this was needed for a Java-centric database project. Like any other database, it required a command line interface (CLI) where you can perform database queries, filter results, perform maintenance tasks, etc. With this database all queries, predicates, etc. are specified using normal Java, so for the CLI a Java expression parser was needed. So the equivalent of $ SELECT name FROM Person WHERE name LIKE `Jon%' AND registered = 1 would be $ eval foreach( filter( all(Person), $x, $x.name.startsWith("Jon") && $x.registered), $y, $y.name) Here eval is a command that evaluates an expression, and this is what the parser was needed for. Note the language for "expression" contains but is larger than Java expressions, e.g., global functions such as filter(), foreach(), and all(), and variable expressions $x and $y. Also, the parameters to the global functions are not always Java expressions, e.g. all() takes a database type name while filter() and foreach() require a variable expression (not evaluated) as the second parameter. I had to write a custom (tail-recursive) parser; existing libraries and ANTLR were not sufficiently flexible. Some custom requirements and issues encountered were... - Application-supplied functions that exist in the top-level namespace (noted above) - Custom parse "atoms" with arbitrary syntax. Used for variables like $x as well as other things. For example, object ID's, which are 64-bit values, can be expressed using an at-sign literal notation like @64a80cffdd9e7b7f. - Tab completion. This is a bit tricky. Internally, on any parse error we throw a ParseException which contains the index of the error and (optionally) valid completions from that point. These are used by the CLI main loop for tab completion. This makes is relatively easy to add pervasive tab completion support incrementally over time. One subtlety here is that completions are not necessarily limited to syntax. For example, if you enter eval @64a80cff it performs an actual query for objects in the database whose ID has the prefix 64a80cff. This invalidates the whole idea of parsing to get a valid AST first, then interpreting it semantically in a separate step. - What about generics and erasure? Will you emit unchecked warnings, or simply disallow unchecked expressions? My parser punts: we don't allow generic syntax, everything is raw types, and any subsequent ClassCastExceptions are normal errors just like any other. On the other end of the spectrum, could you support carrying type information along with all values, eliminating erasure altogether and opening up possibilities like foo instanceof Set? - Additional operator semantics. E.g., the && operator applied to two Sets computes the union, > and < can be applied to Comparables, etc. - Other syntactic sugar: allowing p.name for p.getName(), p.name = "foo" for p.setName("foo"); allowing the [] operator for List and Map lookup, etc. -Archie On Sat, Nov 1, 2014 at 11:14 AM, Brian Goetz wrote: > What might be useful, though, is any *usability* experience that you had > with people trying it out. What did people complain about? What > non-obvious features did people seem to expect should be part of the > feature set? > > (Note, though, that we're asking for *actual* experience of "I built X and > people who used it complained of Y", not theorizing of the form "I could > imagine I might want Y in some situation...".) > > On 11/1/2014 12:03 PM, Robert Field wrote: > >> Thanks Bruce. I'm quite far along, so I doubt that would be useful. >> >> -Robert >> >> On 11/01/14 01:58, Bruce Chapman wrote: >> >>> I built (for some value of "built" near to the value of "hack") one of >>> these back in 2009 for our local java user group [1] as a demo for the >>> compiler API and an annotation processor test framework I built [2] >>> >>> If you are interested I can find and dust off the code and make sure >>> it still all works (why wouldn't it). >>> >>> Bruce >>> >>> >>> >>> [1] http://wellingtonjug.org.nz/talk200905.html >>> [2] https://java.net/projects/hickory >>> >>> >>> On 31/10/2014 10:56 a.m., mark.reinhold at oracle.com wrote: >>> >>>> New JEP Candidate: http://openjdk.java.net/jeps/222 >>>> >>>> - Mark >>>> >>>> >>> >>> --- >>> This email is free from viruses and malware because avast! Antivirus >>> protection is active. >>> http://www.avast.com >>> >>> >> -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From victorwssilva at gmail.com Mon Nov 3 02:12:39 2014 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Mon, 3 Nov 2014 00:12:39 -0200 Subject: Compiler bug: Instantiating non-static inner classes using constructor references inside lambdas Message-ID: Hi, I used javac 1.8.0_25 with this code: package com.example; > import java.util.function.Function; > public class MakeVerifyError { > public void foo() { > Boom es = new Boom(); > go(() -> es.test(Crash::new)); > } > private static void go(Runnable run) {} > public class Crash { public Crash(Boom e) {} } > public static class Boom { public void test(Function ctor) {} > } > public static void main(String[] args) {} > } And this was the result: java.lang.VerifyError: Bad type on operand stack > Exception Details: > Location: > > com/example/MakeVerifyError.lambda$foo$0(Lcom/example/MakeVerifyError$Boom;)V > @2: invokedynamic > Reason: > Type 'com/example/MakeVerifyError$Boom' (current frame, stack[1]) is > not assignable to 'com/example/MakeVerifyError' > Current Frame: > bci: @2 > flags: { } > locals: { 'com/example/MakeVerifyError$Boom' } > stack: { 'com/example/MakeVerifyError$Boom', > 'com/example/MakeVerifyError$Boom' } > Bytecode: > 0x0000000: 2a2a ba00 0600 00b6 0007 b1 > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2693) > at java.lang.Class.privateGetMethodRecursive(Class.java:3040) > at java.lang.Class.getMethod0(Class.java:3010) > at java.lang.Class.getMethod(Class.java:1776) > at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) > at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) > Exception in thread "main" Java Result: 1 If the 'static' modifier is added to the Crash class, it works fine. If the 'test' method call is moved to outside the lambda, it works fine. If the Boom object is instantiated inside the lambda, it fails to load the class: Error: Could not find or load main class com.example.MakeVerifyError > Java Result: 1 So, obviously this looks like a compiler bug. Do somebody already saw that before? Victor Williams Stafusa da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomasz.kowalczewski at gmail.com Mon Nov 3 11:15:30 2014 From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski) Date: Mon, 3 Nov 2014 12:15:30 +0100 Subject: javac compilation error when passing method reference to method accepting interface. Message-ID: Hi, please excuse my ignorance if this is a known bug, was discussed here or is plain silly. I have a curious problem when calling a method with lambda or method reference as an argument. This happens on several versions of Java 8 including latest (u25). Test case is: package test; import java.util.LinkedHashMap; import java.util.Map; import java.util.concurrent.Callable; public class CompilationProblem { public void shouldCompile() { toMap(() -> new LinkedHashMap()); // Compilation error toMap(LinkedHashMap::new); // Compilation error } public Map toMap(Func0> mapFactory) { return null; } interface Func0 extends Callable { public R call(); } } The errors are: Error:(10, 17) java: method toMap in class pl.codewise.voluum.server.db.CompilationProblem cannot be applied to given types; required: pl.codewise.voluum.server.db.CompilationProblem.Func0> found: ()->new Li[...]Map() reason: cannot infer type-variable(s) K,V (argument mismatch; bad return type in lambda expression java.util.LinkedHashMap cannot be converted to ? extends java.util.Map) Error:(11, 22) java: incompatible types: no instance(s) of type variable(s) K,V exist so that java.util.LinkedHashMap conforms to ? extends java.util.Map This test case compiles if Func0 does not extend Callable. How does Callable influence type inference here? What does it change? -- Regards, Tomasz Kowalczewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Mon Nov 3 20:01:10 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Mon, 3 Nov 2014 21:01:10 +0100 Subject: RFR: 8062740: Since changeset 2686:56f8be952a5c test/tools/sjavac/DependencyCollection.java does no longer compile Message-ID: <20141103200110.GD492@e6430> Hi compiler-dev, Please review this fix for JDK-8062740. Patch inlined below: --------------------------------------------- diff -r 10100ecb0c97 -r e98b2c43f2a3 test/tools/sjavac/DependencyCollection.java --- a/test/tools/sjavac/DependencyCollection.java Mon Nov 03 10:20:34 2014 +0100 +++ b/test/tools/sjavac/DependencyCollection.java Mon Nov 03 13:03:10 2014 +0100 @@ -32,6 +32,7 @@ * @run main Wrapper DependencyCollection */ +import java.io.IOException; import java.io.PrintWriter; import java.nio.file.Path; import java.nio.file.Paths; @@ -55,7 +56,7 @@ public class DependencyCollection { - public static void main(String[] args) { + public static void main(String[] args) throws IOException { Path src = Paths.get(ToolBox.testSrc, "test-input", "src"); JavaCompiler javac = ToolProvider.getSystemJavaCompiler(); --------------------------------------------- Link to bug report: https://bugs.openjdk.java.net/browse/JDK-8062740 Thanks, Andreas From andreas.lundblad at oracle.com Mon Nov 3 20:05:21 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Mon, 3 Nov 2014 21:05:21 +0100 Subject: RFR: 8062737: Sjavac creates unnecessarily many SjavacClient/PooledSjavac/SjavacImpl instances Message-ID: <20141103200520.GE492@e6430> Hi compiler-dev, Please review this small fix for JDK-8062737. Description: Sjavac (re)initializes 'sjavac' each compile iteration. This should be done once before entering the loop. Link to bug report: https://bugs.openjdk.java.net/browse/JDK-8062737 Link to webrev: http://cr.openjdk.java.net/~alundblad/8062737 Thanks, Andreas From jonathan.gibbons at oracle.com Mon Nov 3 21:01:36 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 03 Nov 2014 13:01:36 -0800 Subject: RFR: 8062740: Since changeset 2686:56f8be952a5c test/tools/sjavac/DependencyCollection.java does no longer compile In-Reply-To: <20141103200110.GD492@e6430> References: <20141103200110.GD492@e6430> Message-ID: <5457ED30.5000401@oracle.com> Approved. -- Jon On 11/03/2014 12:01 PM, Andreas Lundblad wrote: > Hi compiler-dev, > > Please review this fix for JDK-8062740. Patch inlined below: > > --------------------------------------------- > diff -r 10100ecb0c97 -r e98b2c43f2a3 test/tools/sjavac/DependencyCollection.java > --- a/test/tools/sjavac/DependencyCollection.java Mon Nov 03 10:20:34 2014 +0100 > +++ b/test/tools/sjavac/DependencyCollection.java Mon Nov 03 13:03:10 2014 +0100 > @@ -32,6 +32,7 @@ > * @run main Wrapper DependencyCollection > */ > > +import java.io.IOException; > import java.io.PrintWriter; > import java.nio.file.Path; > import java.nio.file.Paths; > @@ -55,7 +56,7 @@ > > public class DependencyCollection { > > - public static void main(String[] args) { > + public static void main(String[] args) throws IOException { > Path src = Paths.get(ToolBox.testSrc, "test-input", "src"); > > JavaCompiler javac = ToolProvider.getSystemJavaCompiler(); > --------------------------------------------- > > Link to bug report: https://bugs.openjdk.java.net/browse/JDK-8062740 > > Thanks, > Andreas From forax at univ-mlv.fr Tue Nov 4 00:47:50 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 04 Nov 2014 01:47:50 +0100 Subject: Compiler bug: Instantiating non-static inner classes using constructor references inside lambdas In-Reply-To: References: Message-ID: <54582236.80903@univ-mlv.fr> Hi Victor, hi all, it seems that javac forget that an inner class has a hidden argument that should be passed at creation time :( First, in order to compile javac should rewrite foo like this, it's a little more complex in reality because the second lambda can be loaded as a real method reference public void foo() { Boom es = new Boom(); go(() -> es.test(boom -> this.new Crash(boom))); } but the generated bytecode of foo and of the corresponding lambda seems very wrong, first the code of foo, public void foo(); Code: 0: new #2 // class MakeVerifyError$Boom 3: dup 4: invokespecial #3 // Method MakeVerifyError$Boom."":()V 7: astore_1 8: aload_1 9: invokedynamic #4, 0 // InvokeDynamic #0:run:(LMakeVerifyError$Boom;)Ljava/lang/Runnable; 14: invokestatic #5 // Method go:(Ljava/lang/Runnable;)V 17: return as you can see the problem is that the first lambda should capture 2 arguments 'es' and 'this' but the code capture only 'es'. javac seems to forget that to create a Crash you need a MakeVerifyError because it's an inner class. so the code should be: ... 7: astore_1 8: aload_0 // load this ! 9: aload_1 10: invokedynamic #4, 0 // InvokeDynamic #0:run:(LMakeVerifyError;LMakeVerifyError$Boom;)Ljava/lang/Runnable; 15: invokestatic #5 // Method go:(Ljava/lang/Runnable;)V 18: return and the code of the lambda is wrong too, instead of: private static void lambda$foo$0(MakeVerifyError$Boom); Code: 0: aload_0 1: aload_0 2: invokedynamic #6, 0 // InvokeDynamic #1:apply:(LMakeVerifyError;)Ljava/util/function/Function; 7: invokevirtual #7 // Method MakeVerifyError$Boom.test:(Ljava/util/function/Function;)V 10: return it should be: private static void lambda$foo$0(MakeVerifyError,MakeVerifyError$Boom); Code: 0: aload_1 1: aload_0 2: invokedynamic #6, 0 // InvokeDynamic #1:apply:(LMakeVerifyError;)Ljava/util/function/Function; 7: invokevirtual #7 // Method MakeVerifyError$Boom.test:(Ljava/util/function/Function;)V 10: return I hope this can help. cheers, R?mi On 11/03/2014 03:12 AM, Victor Williams Stafusa da Silva wrote: > Hi, I used javac 1.8.0_25 with this code: > > package com.example; > import java.util.function.Function; > public class MakeVerifyError { > public void foo() { > Boom es = new Boom(); > go(() -> es.test(Crash::new)); > } > private static void go(Runnable run) {} > public class Crash { public Crash(Boom e) {} } > public static class Boom { public void test(Function > ctor) {} } > public static void main(String[] args) {} > } > > > And this was the result: > > java.lang.VerifyError: Bad type on operand stack > Exception Details: > Location: > com/example/MakeVerifyError.lambda$foo$0(Lcom/example/MakeVerifyError$Boom;)V > @2: invokedynamic > Reason: > Type 'com/example/MakeVerifyError$Boom' (current frame, > stack[1]) is not assignable to 'com/example/MakeVerifyError' > Current Frame: > bci: @2 > flags: { } > locals: { 'com/example/MakeVerifyError$Boom' } > stack: { 'com/example/MakeVerifyError$Boom', > 'com/example/MakeVerifyError$Boom' } > Bytecode: > 0x0000000: 2a2a ba00 0600 00b6 0007 b1 > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2693) > at java.lang.Class.privateGetMethodRecursive(Class.java:3040) > at java.lang.Class.getMethod0(Class.java:3010) > at java.lang.Class.getMethod(Class.java:1776) > at > sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) > at > sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) > Exception in thread "main" Java Result: 1 > > > If the 'static' modifier is added to the Crash class, it works fine. > If the 'test' method call is moved to outside the lambda, it works fine. > If the Boom object is instantiated inside the lambda, it fails to load > the class: > > Error: Could not find or load main class com.example.MakeVerifyError > Java Result: 1 > > > So, obviously this looks like a compiler bug. > Do somebody already saw that before? > > Victor Williams Stafusa da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Nov 4 18:14:59 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 04 Nov 2014 10:14:59 -0800 Subject: Compiler bug: Instantiating non-static inner classes using constructor references inside lambdas In-Reply-To: <54582236.80903@univ-mlv.fr> References: <54582236.80903@univ-mlv.fr> Message-ID: <545917A3.90102@oracle.com> Hi all, I can't reproduce this error on jdk9 repo but it's still present in 8udev repo. Thanks for the report and for the small example. I will locate the related changeset and create a backport to 8udev repo. Vicente On 11/03/2014 04:47 PM, Remi Forax wrote: > Hi Victor, hi all, > it seems that javac forget that an inner class has a hidden argument > that should be passed at creation time :( > > First, in order to compile javac should rewrite foo like this, > it's a little more complex in reality because the second lambda can be > loaded as a real method reference > > public void foo() { > Boom es = new Boom(); > go(() -> es.test(boom -> this.new Crash(boom))); > } > > but the generated bytecode of foo and of the corresponding lambda > seems very wrong, > first the code of foo, > public void foo(); > Code: > 0: new #2 // class MakeVerifyError$Boom > 3: dup > 4: invokespecial #3 // Method > MakeVerifyError$Boom."":()V > 7: astore_1 > 8: aload_1 > 9: invokedynamic #4, 0 // InvokeDynamic > #0:run:(LMakeVerifyError$Boom;)Ljava/lang/Runnable; > 14: invokestatic #5 // Method > go:(Ljava/lang/Runnable;)V > 17: return > > as you can see the problem is that the first lambda should capture 2 > arguments 'es' and 'this' but > the code capture only 'es'. javac seems to forget that to create a > Crash you need a MakeVerifyError > because it's an inner class. > > so the code should be: > ... > 7: astore_1 > 8: aload_0 // load this ! > 9: aload_1 > 10: invokedynamic #4, 0 // InvokeDynamic > #0:run:(LMakeVerifyError;LMakeVerifyError$Boom;)Ljava/lang/Runnable; > 15: invokestatic #5 // Method > go:(Ljava/lang/Runnable;)V > 18: return > > and the code of the lambda is wrong too, instead of: > private static void lambda$foo$0(MakeVerifyError$Boom); > Code: > 0: aload_0 > 1: aload_0 > 2: invokedynamic #6, 0 // InvokeDynamic > #1:apply:(LMakeVerifyError;)Ljava/util/function/Function; > 7: invokevirtual #7 // Method > MakeVerifyError$Boom.test:(Ljava/util/function/Function;)V > 10: return > > it should be: > private static void > lambda$foo$0(MakeVerifyError,MakeVerifyError$Boom); > Code: > 0: aload_1 > 1: aload_0 > 2: invokedynamic #6, 0 // InvokeDynamic > #1:apply:(LMakeVerifyError;)Ljava/util/function/Function; > 7: invokevirtual #7 // Method > MakeVerifyError$Boom.test:(Ljava/util/function/Function;)V > 10: return > > I hope this can help. > > cheers, > R?mi > > On 11/03/2014 03:12 AM, Victor Williams Stafusa da Silva wrote: >> Hi, I used javac 1.8.0_25 with this code: >> >> package com.example; >> import java.util.function.Function; >> public class MakeVerifyError { >> public void foo() { >> Boom es = new Boom(); >> go(() -> es.test(Crash::new)); >> } >> private static void go(Runnable run) {} >> public class Crash { public Crash(Boom e) {} } >> public static class Boom { public void test(Function >> ctor) {} } >> public static void main(String[] args) {} >> } >> >> >> And this was the result: >> >> java.lang.VerifyError: Bad type on operand stack >> Exception Details: >> Location: >> com/example/MakeVerifyError.lambda$foo$0(Lcom/example/MakeVerifyError$Boom;)V >> @2: invokedynamic >> Reason: >> Type 'com/example/MakeVerifyError$Boom' (current frame, >> stack[1]) is not assignable to 'com/example/MakeVerifyError' >> Current Frame: >> bci: @2 >> flags: { } >> locals: { 'com/example/MakeVerifyError$Boom' } >> stack: { 'com/example/MakeVerifyError$Boom', >> 'com/example/MakeVerifyError$Boom' } >> Bytecode: >> 0x0000000: 2a2a ba00 0600 00b6 0007 b1 >> at java.lang.Class.getDeclaredMethods0(Native Method) >> at java.lang.Class.privateGetDeclaredMethods(Class.java:2693) >> at java.lang.Class.privateGetMethodRecursive(Class.java:3040) >> at java.lang.Class.getMethod0(Class.java:3010) >> at java.lang.Class.getMethod(Class.java:1776) >> at >> sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) >> at >> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) >> Exception in thread "main" Java Result: 1 >> >> >> If the 'static' modifier is added to the Crash class, it works fine. >> If the 'test' method call is moved to outside the lambda, it works fine. >> If the Boom object is instantiated inside the lambda, it fails to >> load the class: >> >> Error: Could not find or load main class com.example.MakeVerifyError >> Java Result: 1 >> >> >> So, obviously this looks like a compiler bug. >> Do somebody already saw that before? >> >> Victor Williams Stafusa da Silva > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Nov 5 16:16:36 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 5 Nov 2014 08:16:36 -0800 Subject: NullPointerException in Infer.java Message-ID: Is this a known issue? It affects 8u20, and reproduces at head in 9-dev (I tested @03dc012a11a5). The crash bisects down to: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cf78452cdb3b https://bugs.openjdk.java.net/browse/JDK-8029002 Here's the repro: === import java.util.List; class Test { interface TypeToken {} interface TypeMap { T getInstance(TypeToken type); } void m(TypeMap[]> map, TypeToken[]> type) { List[] result = map.getInstance(type); } } === $ javac Test.java ... java.lang.NullPointerException at com.sun.tools.javac.comp.Infer$IncorporationStep$7.apply(Infer.java:874) at com.sun.tools.javac.comp.Infer.checkWithinBounds(Infer.java:596) at com.sun.tools.javac.comp.Infer$GraphSolver.solve(Infer.java:1681) at com.sun.tools.javac.comp.Infer$InferenceContext.solve(Infer.java:2315) at com.sun.tools.javac.comp.Infer$InferenceContext.solve(Infer.java:2307) at com.sun.tools.javac.comp.Infer$InferenceContext.solve(Infer.java:2322) at com.sun.tools.javac.comp.Infer.instantiateMethod(Infer.java:201) at com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:568) at com.sun.tools.javac.comp.Resolve.checkMethod(Resolve.java:606) ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Nov 5 17:25:12 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 05 Nov 2014 17:25:12 +0000 Subject: NullPointerException in Infer.java In-Reply-To: References: Message-ID: <545A5D78.5090206@oracle.com> This is a new issue - thanks. A new bug has been filed: https://bugs.openjdk.java.net/browse/JDK-8062977 Maurizio On 05/11/14 16:16, Liam Miller-Cushon wrote: > mport java.util.List; > > class Test { > interface TypeToken {} > interface TypeMap { > T getInstance(TypeToken type); > } > > void m(TypeMap[]> map, TypeToken[]> type) { > List[] result = map.getInstance(type); > } > } From cushon at google.com Wed Nov 5 18:19:06 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 5 Nov 2014 10:19:06 -0800 Subject: NullPointerException in Infer.java In-Reply-To: <545A5D78.5090206@oracle.com> References: <545A5D78.5090206@oracle.com> Message-ID: On Wed, Nov 5, 2014 at 9:25 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > A new bug has been filed: Thanks Maurizio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Thu Nov 6 07:58:24 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Thu, 6 Nov 2014 08:58:24 +0100 Subject: RFR: 8062737: Sjavac creates unnecessarily many SjavacClient/PooledSjavac/SjavacImpl instances In-Reply-To: <20141103200520.GE492@e6430> References: <20141103200520.GE492@e6430> Message-ID: ok! On Mon, Nov 3, 2014 at 9:05 PM, Andreas Lundblad < andreas.lundblad at oracle.com> wrote: > Hi compiler-dev, > > Please review this small fix for JDK-8062737. > > Description: Sjavac (re)initializes 'sjavac' each compile iteration. This > should be done once before entering the loop. > > Link to bug report: https://bugs.openjdk.java.net/browse/JDK-8062737 > Link to webrev: http://cr.openjdk.java.net/~alundblad/8062737 > > Thanks, > Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Thu Nov 6 07:59:03 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Thu, 6 Nov 2014 08:59:03 +0100 Subject: RFR: 8062740: Since changeset 2686:56f8be952a5c test/tools/sjavac/DependencyCollection.java does no longer compile In-Reply-To: <20141103200110.GD492@e6430> References: <20141103200110.GD492@e6430> Message-ID: ok! On Mon, Nov 3, 2014 at 9:01 PM, Andreas Lundblad < andreas.lundblad at oracle.com> wrote: > Hi compiler-dev, > > Please review this fix for JDK-8062740. Patch inlined below: > > --------------------------------------------- > diff -r 10100ecb0c97 -r e98b2c43f2a3 > test/tools/sjavac/DependencyCollection.java > --- a/test/tools/sjavac/DependencyCollection.java Mon Nov 03 > 10:20:34 2014 +0100 > +++ b/test/tools/sjavac/DependencyCollection.java Mon Nov 03 > 13:03:10 2014 +0100 > @@ -32,6 +32,7 @@ > * @run main Wrapper DependencyCollection > */ > > +import java.io.IOException; > import java.io.PrintWriter; > import java.nio.file.Path; > import java.nio.file.Paths; > @@ -55,7 +56,7 @@ > > public class DependencyCollection { > > - public static void main(String[] args) { > + public static void main(String[] args) throws IOException { > Path src = Paths.get(ToolBox.testSrc, "test-input", "src"); > > JavaCompiler javac = ToolProvider.getSystemJavaCompiler(); > --------------------------------------------- > > Link to bug report: https://bugs.openjdk.java.net/browse/JDK-8062740 > > Thanks, > Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Nov 6 17:30:31 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 06 Nov 2014 09:30:31 -0800 Subject: javac compilation error when passing method reference to method accepting interface. In-Reply-To: References: Message-ID: <545BB037.9020006@oracle.com> Hi Tomasz, The bug you are referring to has already been fixed, please see [1]. The bits are not in any public release yet but you can build one from the development repos: for 8: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools for 9: http://hg.openjdk.java.net/jdk9/dev/langtools/ Thanks, Vicente [1] On 11/03/2014 03:15 AM, Tomasz Kowalczewski wrote: > Hi, > > please excuse my ignorance if this is a known bug, was discussed here > or is plain silly. > > I have a curious problem when calling a method with lambda or method > reference as an argument. This happens on several versions of Java 8 > including latest (u25). Test case is: > > package test; > > import java.util.LinkedHashMap; > import java.util.Map; > import java.util.concurrent.Callable; > > public class CompilationProblem { > > public void shouldCompile() { > toMap(() -> new LinkedHashMap()); // Compilation error > toMap(LinkedHashMap::new); // Compilation error > } > > public Map toMap(Func0> mapFactory) { > return null; > } > > interface Func0 extends Callable { > > public R call(); > } > } > > The errors are: > > Error:(10, 17) java: method toMap in class > pl.codewise.voluum.server.db.CompilationProblem cannot be applied to > given types; > required: pl.codewise.voluum.server.db.CompilationProblem.Func0 extends java.util.Map> > found: ()->new Li[...]Map() > reason: cannot infer type-variable(s) K,V > (argument mismatch; bad return type in lambda expression > java.util.LinkedHashMap cannot be converted to ? extends > java.util.Map) > > Error:(11, 22) java: incompatible types: no instance(s) of type > variable(s) K,V exist so that java.util.LinkedHashMap conforms to > ? extends java.util.Map > > This test case compiles if Func0 does not extend Callable. How does > Callable influence type inference here? What does it change? > > -- > Regards, > Tomasz Kowalczewski From vicente.romero at oracle.com Thu Nov 6 17:55:49 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 06 Nov 2014 09:55:49 -0800 Subject: javac compilation error when passing method reference to method accepting interface. In-Reply-To: <545BB037.9020006@oracle.com> References: <545BB037.9020006@oracle.com> Message-ID: <545BB625.1080509@oracle.com> Hi again, By [1] I meant: https://bugs.openjdk.java.net/browse/JDK-8044546 :) Thanks, Vicente On 11/06/2014 09:30 AM, Vicente-Arturo Romero-Zaldivar wrote: > Hi Tomasz, > > The bug you are referring to has already been fixed, please see [1]. > The bits are not in any public release yet but you can build one from > the development repos: > > for 8: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools > for 9: http://hg.openjdk.java.net/jdk9/dev/langtools/ > > Thanks, > Vicente > > [1] > > On 11/03/2014 03:15 AM, Tomasz Kowalczewski wrote: >> Hi, >> >> please excuse my ignorance if this is a known bug, was discussed here >> or is plain silly. >> >> I have a curious problem when calling a method with lambda or method >> reference as an argument. This happens on several versions of Java 8 >> including latest (u25). Test case is: >> >> package test; >> >> import java.util.LinkedHashMap; >> import java.util.Map; >> import java.util.concurrent.Callable; >> >> public class CompilationProblem { >> >> public void shouldCompile() { >> toMap(() -> new LinkedHashMap()); // Compilation error >> toMap(LinkedHashMap::new); // Compilation error >> } >> >> public Map toMap(Func0> >> mapFactory) { >> return null; >> } >> >> interface Func0 extends Callable { >> >> public R call(); >> } >> } >> >> The errors are: >> >> Error:(10, 17) java: method toMap in class >> pl.codewise.voluum.server.db.CompilationProblem cannot be applied to >> given types; >> required: pl.codewise.voluum.server.db.CompilationProblem.Func0> extends java.util.Map> >> found: ()->new Li[...]Map() >> reason: cannot infer type-variable(s) K,V >> (argument mismatch; bad return type in lambda expression >> java.util.LinkedHashMap cannot be converted to ? extends >> java.util.Map) >> >> Error:(11, 22) java: incompatible types: no instance(s) of type >> variable(s) K,V exist so that java.util.LinkedHashMap conforms >> to ? extends java.util.Map >> >> This test case compiles if Func0 does not extend Callable. How does >> Callable influence type inference here? What does it change? >> >> -- >> Regards, >> Tomasz Kowalczewski > From pooja.chopra at oracle.com Mon Nov 10 16:59:56 2014 From: pooja.chopra at oracle.com (pooja chopra) Date: Mon, 10 Nov 2014 22:29:56 +0530 Subject: [7u] Review Request: JDK-8064454 Fix type in langtools for tools/javac/innerClassFile/Driver.sh Message-ID: <5460EF0C.6090501@oracle.com> Hello, Please review a fix for the issue: 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails with exit code 1 Test bug fix. https://bugs.openjdk.java.net/browse/JDK-8064454 The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/ Thanks Pooja From andreas.lundblad at oracle.com Tue Nov 11 21:40:59 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Tue, 11 Nov 2014 22:40:59 +0100 Subject: RFR: 8059591: Give TaskListener methods empty default implementations Message-ID: <20141111214058.GA17789@e6430> Hi compiler-dev, I'd be very grateful if someone could review this (tiny) fix for JDK-8059591. Description: This patch adds empty default implementations for the com.sun.source.util.TaskListener methods. Link to CCC: http://ccc.us.oracle.com/8059591 Link to web review: http://cr.openjdk.java.net/~alundblad/8059591 Link to bug reports: http://bugs.openjdk.java.net/browse/JDK-8059591 -- Andreas From mehmet at hazelcast.com Thu Nov 13 12:59:27 2014 From: mehmet at hazelcast.com (Mehmet Dogan) Date: Thu, 13 Nov 2014 14:59:27 +0200 Subject: Java 8 javac wrong return type for a generic method Message-ID: Hi, I faced a weird compiler issue (or at least I looked weird to me) while compiling & running a unit test on Java8. It was running on Java 6 & 7 without a problem. Then I created a very basic sample to reproduce it locally. Test includes 3 interfaces, 1 implementation and 1 test class. *public interface ParentA {* * T process() throws Exception;* *}* *public interface ParentB {* * T process() throws Exception;* *}* *public interface Child extends ParentA, ParentB {* * // **everything works fine **when this line is uncommented * * // T process() throws Exception;* *}* *public class ChildImpl implements Child {* * @Override* * public T process() {* * return null;* * }* *}* *public class Test {* * public static void main(String[] args) throws Exception {* * Child child = new ChildImpl();* * String result = child.process();* * System.err.println(result);* * }* *}* 1 - When I compile these with javac 8 and run the main method in Test class, it fails with the following exception: *Exception in thread "main" java.lang.NoSuchMethodError: Child.process()Ljava/lang/String;* * at Test.main(Test.java:5)* 2 - When I uncomment overriding method definition in `*Child*` interface, then it works fine. *public interface Child extends ParentA, ParentB {* * T process() throws Exception;* *}* 3 - When I remove `*throws Exception*` declaration from `*process*` method, then it works fine again. Then I looked at the disassembled bytecode of the Test.class and saw in Java 6 and 7 versions there is an additional `checkcast` instruction after `Child.process()` method call. See; - *With Java8:* *public class Test {* * public Test();* * Code:* * 0: aload_0* * 1: invokespecial #1 // Method java/lang/Object."":()V* * 4: return* * public static void main(java.lang.String[]) throws java.lang.Exception;* * Code:* * 0: new #2 // class ChildImpl* * 3: dup* * 4: invokespecial #3 // Method ChildImpl."":()V* * 7: astore_1* * 8: aload_1* * 9: invokeinterface #4, 1 // InterfaceMethod Child.process:()Ljava/lang/String;* * 14: astore_2* * 15: getstatic #5 // Field java/lang/System.err:Ljava/io/PrintStream;* * 18: aload_2* * 19: invokevirtual #6 // Method java/io/PrintStream.println:(Ljava/lang/String;)V* * 22: return* *}* *- With Java7:* *Compiled from "Test.java"* *public class Test {* * public Test();* * Code:* * 0: aload_0* * 1: invokespecial #1 // Method java/lang/Object."":()V* * 4: return* * public static void main(java.lang.String[]) throws java.lang.Exception;* * Code:* * 0: new #2 // class ChildImpl* * 3: dup* * 4: invokespecial #3 // Method ChildImpl."":()V* * 7: astore_1* * 8: aload_1* * 9: invokeinterface #4, 1 // InterfaceMethod Child.process:()Ljava/lang/Object;* * 14: checkcast #5 // class java/lang/String* * 17: astore_2* * 18: getstatic #6 // Field java/lang/System.err:Ljava/io/PrintStream;* * 21: aload_2* * 22: invokevirtual #7 // Method java/io/PrintStream.println:(Ljava/lang/String;)V* * 25: return* *}* Javac 8 is expecting to call a method with return type of String (*InterfaceMethod Child.process:()Ljava/lang/String)*, but on Java 7 version is expecting a method with return type of Object (*InterfaceMethod Child.process:()Ljava/lang/Object*) which is expected because of type-erasure then it's checking type of returning value with `checkcast` instruction. Test environment: Centos 6.6 & OSX 10.10 javac 1.8.0_25 openjdk version "1.8.0_25" OpenJDK Runtime Environment (build 1.8.0_25-b17) OpenJDK 64-Bit Server VM (build 25.20-b23, mixed mode) javac 1.7.0_71 java version "1.7.0_71" OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) Is this an expected situation, is there something I'm understanding/using wrong? Or is this a bug/problem in Java 8 compiler? Thanks. *Mehmet Dogan*mehmet at hazelcast.com @mmdogan -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Nov 13 13:26:11 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 13 Nov 2014 13:26:11 +0000 Subject: Java 8 javac wrong return type for a generic method In-Reply-To: References: Message-ID: <5464B173.5010004@oracle.com> This is a javac bug - when multiple applicable abstract methods are found during overload, javac is supposed to return the one with the most specific return type; unfortunately, when javac merges the two signatures, it uses the 'instantiated' return type (String) instead of the bare one (T). This leads to the missing checkcast. I filed a new issue: https://bugs.openjdk.java.net/browse/JDK-8064803 Thanks for the detailed report. Maurizio On 13/11/14 12:59, Mehmet Dogan wrote: > Hi, > > I faced a weird compiler issue (or at least I looked weird to me) > while compiling & running a unit test on Java8. It was running on Java > 6 & 7 without a problem. Then I created a very basic sample to > reproduce it locally. > > Test includes 3 interfaces, 1 implementation and 1 test class. > > /public interface ParentA {/ > / T process() throws Exception;/ > /}/ > / > / > /public interface ParentB {/ > / T process() throws Exception;/ > /}/ > > /public interface Child extends ParentA, ParentB {/ > /* // *//*everything works fine *//*when this line is uncommented */ > / // T process() throws Exception;/ > /}/ > / > / > /public class ChildImpl implements Child {/ > / @Override/ > / public T process() {/ > / return null;/ > / }/ > /}/ > / > / > /public class Test {/ > / public static void main(String[] args) throws Exception {/ > / Child child = new ChildImpl();/ > / String result = child.process();/ > / System.err.println(result);/ > / }/ > /}/ > > > 1 - When I compile these with javac 8 and run the main method in Test > class, it fails with the following exception: > > /Exception in thread "main" java.lang.NoSuchMethodError: > Child.process()Ljava/lang/String;/ > /at Test.main(Test.java:5)/ > > > 2 - When I uncomment overriding method definition in `/Child/` > interface, then it works fine. > / > / > /public interface Child extends ParentA, ParentB {/ > / T process() throws Exception;/ > /}/ > > 3 - When I remove `/throws Exception/` declaration from `/process/` > method, then it works fine again. > > > Then I looked at the disassembled bytecode of the Test.class and saw > in Java 6 and 7 versions there is an additional `checkcast` > instruction after `Child.process()` method call. See; > > - *With Java8:* > > /public class Test {/ > / public Test();/ > / Code:/ > / 0: aload_0/ > / 1: invokespecial #1 // Method > java/lang/Object."":()V/ > / 4: return/ > / > / > / public static void main(java.lang.String[]) throws > java.lang.Exception;/ > / Code:/ > / 0: new #2 // class ChildImpl/ > / 3: dup/ > / 4: invokespecial #3 // Method > ChildImpl."":()V/ > / 7: astore_1/ > / 8: aload_1/ > /* 9: invokeinterface #4, 1 // InterfaceMethod > Child.process:()Ljava/lang/String;*/ > / 14: astore_2/ > / 15: getstatic #5 // Field > java/lang/System.err:Ljava/io/PrintStream;/ > / 18: aload_2/ > / 19: invokevirtual #6 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V/ > / 22: return/ > /}/ > > *- With Java7:* > / > / > /Compiled from "Test.java"/ > /public class Test {/ > / public Test();/ > / Code:/ > / 0: aload_0/ > / 1: invokespecial #1 // Method > java/lang/Object."":()V/ > / 4: return/ > / > / > / public static void main(java.lang.String[]) throws > java.lang.Exception;/ > / Code:/ > / 0: new #2 // class ChildImpl/ > / 3: dup/ > / 4: invokespecial #3 // Method > ChildImpl."":()V/ > / 7: astore_1/ > / 8: aload_1/ > /* 9: invokeinterface #4, 1 // InterfaceMethod > Child.process:()Ljava/lang/Object;*/ > /* 14: checkcast #5 // class java/lang/String*/ > / 17: astore_2/ > / 18: getstatic #6 // Field > java/lang/System.err:Ljava/io/PrintStream;/ > / 21: aload_2/ > / 22: invokevirtual #7 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V/ > / 25: return/ > /}/ > > > Javac 8 is expecting to call a method with return type of String > (/InterfaceMethod Child.process:()Ljava/lang/String)/, but on Java 7 > version is expecting a method with return type of Object > (/InterfaceMethod Child.process:()Ljava/lang/Object/) which is > expected because of type-erasure then it's checking type of returning > value with `checkcast` instruction. > > > Test environment: > > Centos 6.6 & OSX 10.10 > > javac 1.8.0_25 > openjdk version "1.8.0_25" > OpenJDK Runtime Environment (build 1.8.0_25-b17) > OpenJDK 64-Bit Server VM (build 25.20-b23, mixed mode) > > javac 1.7.0_71 > java version "1.7.0_71" > OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14) > OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) > > Is this an expected situation, is there something I'm > understanding/using wrong? Or is this a bug/problem in Java 8 compiler? > > Thanks. > > *Mehmet Dogan > *mehmet at hazelcast.com > @mmdogan -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.franck at oracle.com Thu Nov 13 13:40:09 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Thu, 13 Nov 2014 14:40:09 +0100 Subject: RFR: 8059591: Give TaskListener methods empty default implementations In-Reply-To: <20141111214058.GA17789@e6430> References: <20141111214058.GA17789@e6430> Message-ID: <20141113134009.GA16532@oracle.com> Looks good. cheers /Joel On 2014-11-11, Andreas Lundblad wrote: > Hi compiler-dev, > > I'd be very grateful if someone could review this (tiny) fix for JDK-8059591. > > Description: > This patch adds empty default implementations for the com.sun.source.util.TaskListener methods. > > Link to CCC: > http://ccc.us.oracle.com/8059591 > > Link to web review: > http://cr.openjdk.java.net/~alundblad/8059591 > > Link to bug reports: > http://bugs.openjdk.java.net/browse/JDK-8059591 > > -- Andreas From cushon at google.com Fri Nov 14 03:09:05 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 13 Nov 2014 19:09:05 -0800 Subject: Possible LVT regression with labelled block statements Message-ID: I found a possible LVT bug in javac8 that affects labelled break statements. It causes incorrect zero-length LVT entries to be emitted for locals that have non-zero live ranges. Here's a repro: === class Test { int m(boolean flag) { int myInt; label: { if (flag) { myInt = 1; } else { break label; } return myInt; } return -1; } } === With javac8, the code compiles to: === int m(boolean); descriptor: (Z)I flags: Code: stack=1, locals=3, args_size=2 0: iload_1 1: ifeq 8 4: iconst_1 5: istore_2 6: iload_2 7: ireturn 8: iconst_m1 9: ireturn LineNumberTable: line 6: 0 line 7: 4 line 12: 6 line 14: 8 LocalVariableTable: Start Length Slot Name Signature 6 0 2 myInt I 0 10 0 this LTest; 0 10 1 flag Z === My understanding is that the zero-length LVT entry for 'myInt' is incorrect. With earlier versions of javac (and also ecj) the entry's length is 2. The behaviour started occurring after the change that fixed JDK-8012868 [1][2], so this affects javac8 and 9. It reproduces with the latest version of javac9 (I tested @c286272a81dd). The issue was originally discovered because it affects joda time, specifically the local variable 'expectSeparators' in DateTimeFormatterBuilder [3]. [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4932bb04c4b8 [2] https://bugs.openjdk.java.net/browse/JDK-8012868 [3] https://github.com/JodaOrg/joda-time/blob/1379098f681f0d4d6f0a3403ab6727dc3437b6df/src/main/java/org/joda/time/format/DateTimeFormatterBuilder.java#L2132 Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Nov 14 03:22:26 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 13 Nov 2014 19:22:26 -0800 Subject: Possible LVT regression with labelled block statements In-Reply-To: References: Message-ID: <54657572.3070405@oracle.com> Hi Liam, Thanks a lot for the report and the reduced test case. I have created bug: https://bugs.openjdk.java.net/browse/JDK-8064857 to track this issue. Thanks, Vicente On 11/13/2014 07:09 PM, Liam Miller-Cushon wrote: > I found a possible LVT bug in javac8 that affects labelled break > statements. It causes incorrect zero-length LVT entries to be emitted > for locals that have non-zero live ranges. > > Here's a repro: > > === > class Test { > int m(boolean flag) { > int myInt; > label: > { > if (flag) { > myInt = 1; > } else { > break label; > } > > return myInt; > } > return -1; > } > } > === > > With javac8, the code compiles to: > > === > int m(boolean); > descriptor: (Z)I > flags: > Code: > stack=1, locals=3, args_size=2 > 0: iload_1 > 1: ifeq 8 > 4: iconst_1 > 5: istore_2 > 6: iload_2 > 7: ireturn > 8: iconst_m1 > 9: ireturn > LineNumberTable: > line 6: 0 > line 7: 4 > line 12: 6 > line 14: 8 > LocalVariableTable: > Start Length Slot Name Signature > 6 0 2 myInt I > 0 10 0 this LTest; > 0 10 1 flag Z > === > > My understanding is that the zero-length LVT entry for 'myInt' is > incorrect. With earlier versions of javac (and also ecj) the entry's > length is 2. > > The behaviour started occurring after the change that > fixed JDK-8012868 [1][2], so this affects javac8 and 9. It reproduces > with the latest version of javac9 (I tested @c286272a81dd). > > The issue was originally discovered because it affects joda time, > specifically the local variable 'expectSeparators' in > DateTimeFormatterBuilder [3]. > > [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/4932bb04c4b8 > [2] https://bugs.openjdk.java.net/browse/JDK-8012868 > [3] > https://github.com/JodaOrg/joda-time/blob/1379098f681f0d4d6f0a3403ab6727dc3437b6df/src/main/java/org/joda/time/format/DateTimeFormatterBuilder.java#L2132 > > Thanks, > Liam From cushon at google.com Fri Nov 14 03:34:34 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 13 Nov 2014 19:34:34 -0800 Subject: Possible LVT regression with labelled block statements In-Reply-To: <54657572.3070405@oracle.com> References: <54657572.3070405@oracle.com> Message-ID: On Thu, Nov 13, 2014 at 7:22 PM, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > I have created bug: https://bugs.openjdk.java.net/browse/JDK-8064857 to > track this issue. > Thanks Vicente! -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Fri Nov 14 18:30:38 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 14 Nov 2014 10:30:38 -0800 Subject: [PATCH]8058445: Javac throws exception when displaying info In-Reply-To: References: Message-ID: Shinya's message may not have been noticed; adding compiler-dev. On Thu, Nov 13, 2014 at 8:05 AM, bitter_fox wrote: > Hi, > I have a patch for "8058445: Javac throws exception when displaying info." > Could you review and merge my patch? > (Please ignore my patch when someone is already working for this issue) > > The cause is OptionHelper.GrumpyHelper#put throws IAE and it has not been > overrided. > So I override it and do not anything. > > webrev: http://cr.openjdk.java.net/~shinyafox/8058445/webrev.00/ > issue: https://bugs.openjdk.java.net/browse/JDK-8058445 > > Regards, > Shinya Yoshida(@bitter_fox) From jonathan.gibbons at oracle.com Sat Nov 15 01:01:25 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 14 Nov 2014 17:01:25 -0800 Subject: RFR: 8058445 | was Re: [PATCH]8058445: Javac throws exception when displaying info In-Reply-To: References: Message-ID: <5466A5E5.1090103@oracle.com> Shinya, Thanks for looking at this issue and submitting your patch. The intent of GrumpyHelper is that by default it *should* throw exceptions, and so it is not desirable to suppress that behavior in general. A better fix is to override the method in the anonymous class that is used when no args are given. In addition, changes should generally come with regression tests, unless there is a good reason not to. With those two points in mind, I have posted a revised patch for the consideration and review by javac Reviewers: webrev: http://cr.openjdk.java.net/~jjg/8058445/webrev.00 -- Jon On 11/14/2014 10:30 AM, Martin Buchholz wrote: > Shinya's message may not have been noticed; adding compiler-dev. > > On Thu, Nov 13, 2014 at 8:05 AM, bitter_fox wrote: >> Hi, >> I have a patch for "8058445: Javac throws exception when displaying info." >> Could you review and merge my patch? >> (Please ignore my patch when someone is already working for this issue) >> >> The cause is OptionHelper.GrumpyHelper#put throws IAE and it has not been >> overrided. >> So I override it and do not anything. >> >> webrev: http://cr.openjdk.java.net/~shinyafox/8058445/webrev.00/ >> issue: https://bugs.openjdk.java.net/browse/JDK-8058445 >> >> Regards, >> Shinya Yoshida(@bitter_fox) From cushon at google.com Sat Nov 15 01:16:49 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 14 Nov 2014 17:16:49 -0800 Subject: [PATCH] Diagnostic position fix for statement-bodied lambdas Message-ID: When parsing statement-bodied lambda expressions, javac currently uses the start position of the parameter list for the body. This patch fixes the parser to record the body's start position correctly. Example diagnostic before this change: Test.java:17: error: incompatible types: bad return type in lambda expression foo((x) -> { return ""; System.out.println(""); }); ^ After: Test.java:17: error: lambda body is neither value nor void compatible foo((x) -> { return ""; System.out.println(""); }); ^ Placing the caret at the parameter list may be deliberate, but it should be possible to do that without recording the body's start position incorrectly. Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # HG changeset patch # User cushon # Date 1416012777 28800 # Fri Nov 14 16:52:57 2014 -0800 # Node ID c8760b71c10ea1cd970be1e004b4b14a964695e5 # Parent 0b467b70ad82687eeafddfd36485fe52657d7fdd Fix diagnostic position of statement-bodied lambdas. Previously the start position of the lambda's parameter list was used for the body. 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 @@ -1680,7 +1680,7 @@ accept(ARROW); return token.kind == LBRACE ? - lambdaStatement(args, pos, pos) : + lambdaStatement(args, pos, token.pos) : lambdaExpression(args, pos); } diff --git a/test/tools/javac/lambda/MostSpecific09.out b/test/tools/javac/lambda/MostSpecific09.out --- a/test/tools/javac/lambda/MostSpecific09.out +++ b/test/tools/javac/lambda/MostSpecific09.out @@ -2,7 +2,7 @@ MostSpecific09.java:26:9: compiler.note.verbose.resolve.multi: foo, MostSpecific09, 0, BASIC, compiler.misc.type.none, compiler.misc.no.args,{(compiler.misc.applicable.method.found: 0, foo(MostSpecific09.I), null)} MostSpecific09.java:27:9: compiler.note.verbose.resolve.multi: foo, MostSpecific09, 0, BASIC, compiler.misc.type.none, compiler.misc.no.args,{(compiler.misc.applicable.method.found: 0, foo(MostSpecific09.J), null)} MostSpecific09.java:27:32: compiler.note.verbose.resolve.multi: println, java.io.PrintStream, 1, BASIC, java.lang.String, compiler.misc.no.args,{(compiler.misc.applicable.method.found: 0, println(java.lang.Object), null),(compiler.misc.applicable.method.found: 1, println(java.lang.String), null)} -MostSpecific09.java:28:13: compiler.err.lambda.body.neither.value.nor.void.compatible +MostSpecific09.java:28:20: compiler.err.lambda.body.neither.value.nor.void.compatible MostSpecific09.java:28:9: compiler.err.cant.apply.symbols: kindname.method, foo, @680,{(compiler.misc.inapplicable.method: kindname.method, MostSpecific09, foo(MostSpecific09.I), (compiler.misc.no.conforming.assignment.exists: (compiler.misc.incompatible.ret.type.in.lambda: (compiler.misc.missing.ret.val: java.lang.String)))),(compiler.misc.inapplicable.method: kindname.method, MostSpecific09, foo(MostSpecific09.J), (compiler.misc.no.conforming.assignment.exists: (compiler.misc.unexpected.ret.val)))} MostSpecific09.java:28:43: compiler.note.verbose.resolve.multi: println, java.io.PrintStream, 1, BASIC, java.lang.String, compiler.misc.no.args,{(compiler.misc.applicable.method.found: 0, println(java.lang.Object), null),(compiler.misc.applicable.method.found: 1, println(java.lang.String), null)} MostSpecific09.java:29:9: compiler.err.ref.ambiguous: foo, kindname.method, foo(MostSpecific09.I), MostSpecific09, kindname.method, foo(MostSpecific09.J), MostSpecific09 @@ -10,7 +10,7 @@ MostSpecific09.java:30:9: compiler.err.ref.ambiguous: foo, kindname.method, foo(MostSpecific09.I), MostSpecific09, kindname.method, foo(MostSpecific09.J), MostSpecific09 MostSpecific09.java:32:9: compiler.err.ref.ambiguous: foo, kindname.method, foo(MostSpecific09.I), MostSpecific09, kindname.method, foo(MostSpecific09.J), MostSpecific09 MostSpecific09.java:33:9: compiler.note.verbose.resolve.multi: foo, MostSpecific09, 0, BASIC, compiler.misc.type.none, compiler.misc.no.args,{(compiler.misc.applicable.method.found: 0, foo(MostSpecific09.I), null)} -MostSpecific09.java:42:13: compiler.err.lambda.body.neither.value.nor.void.compatible +MostSpecific09.java:42:20: compiler.err.lambda.body.neither.value.nor.void.compatible MostSpecific09.java:42:9: compiler.err.cant.apply.symbols: kindname.method, foo, @1129,{(compiler.misc.inapplicable.method: kindname.method, MostSpecific09, foo(MostSpecific09.I), (compiler.misc.no.conforming.assignment.exists: (compiler.misc.incompatible.ret.type.in.lambda: (compiler.misc.missing.ret.val: java.lang.String)))),(compiler.misc.inapplicable.method: kindname.method, MostSpecific09, foo(MostSpecific09.J), (compiler.misc.no.conforming.assignment.exists: (compiler.misc.unexpected.ret.val)))} MostSpecific09.java:46:23: compiler.note.verbose.resolve.multi: println, java.io.PrintStream, 1, BASIC, java.lang.String, compiler.misc.no.args,{(compiler.misc.applicable.method.found: 0, println(java.lang.Object), null),(compiler.misc.applicable.method.found: 1, println(java.lang.String), null)} MostSpecific09.java:49:9: compiler.note.verbose.resolve.multi: foo, MostSpecific09, 0, BASIC, compiler.misc.type.none, compiler.misc.no.args,{(compiler.misc.applicable.method.found: 0, foo(MostSpecific09.J), null)} From jonathan.gibbons at oracle.com Sat Nov 15 01:41:04 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 14 Nov 2014 17:41:04 -0800 Subject: RFR: 8058445 | was Re: [PATCH]8058445: Javac throws exception when displaying info In-Reply-To: <5466A5E5.1090103@oracle.com> References: <5466A5E5.1090103@oracle.com> Message-ID: <5466AF30.8050508@oracle.com> Vicente points out that I misread the original patch, so yes, Shinya, you did propose the correct patch :-) But it is still good to have a test as well. -- Jon On 11/14/2014 05:01 PM, Jonathan Gibbons wrote: > Shinya, > > Thanks for looking at this issue and submitting your patch. > > The intent of GrumpyHelper is that by default it *should* throw > exceptions, and so it is not desirable to suppress that behavior in > general. A better fix is to override the method in the anonymous > class that is used when no args are given. > > In addition, changes should generally come with regression tests, > unless there is a good reason not to. > > With those two points in mind, I have posted a revised patch for the > consideration and review by javac Reviewers: > webrev: http://cr.openjdk.java.net/~jjg/8058445/webrev.00 > > -- Jon > > > > On 11/14/2014 10:30 AM, Martin Buchholz wrote: >> Shinya's message may not have been noticed; adding compiler-dev. >> >> On Thu, Nov 13, 2014 at 8:05 AM, bitter_fox >> wrote: >>> Hi, >>> I have a patch for "8058445: Javac throws exception when displaying >>> info." >>> Could you review and merge my patch? >>> (Please ignore my patch when someone is already working for this issue) >>> >>> The cause is OptionHelper.GrumpyHelper#put throws IAE and it has not >>> been >>> overrided. >>> So I override it and do not anything. >>> >>> webrev: http://cr.openjdk.java.net/~shinyafox/8058445/webrev.00/ >>> issue: https://bugs.openjdk.java.net/browse/JDK-8058445 >>> >>> Regards, >>> Shinya Yoshida(@bitter_fox) > From bitterfoxc at gmail.com Sat Nov 15 02:22:42 2014 From: bitterfoxc at gmail.com (bitter_fox) Date: Sat, 15 Nov 2014 11:22:42 +0900 Subject: RFR: 8058445 | was Re: [PATCH]8058445: Javac throws exception when displaying info In-Reply-To: <5466AF30.8050508@oracle.com> References: <5466A5E5.1090103@oracle.com> <5466AF30.8050508@oracle.com> Message-ID: Hi, Jonathan. Thank you for your review and adding the test to my patch. The test looks good to me. Regards, Shinya Yoshida(@bitter_fox, shinyafox) 2014-11-15 10:41 GMT+09:00 Jonathan Gibbons : > Vicente points out that I misread the original patch, so yes, Shinya, you > did propose the correct patch :-) But it is still good to have a test as > well. > > -- Jon > > > On 11/14/2014 05:01 PM, Jonathan Gibbons wrote: > >> Shinya, >> >> Thanks for looking at this issue and submitting your patch. >> >> The intent of GrumpyHelper is that by default it *should* throw >> exceptions, and so it is not desirable to suppress that behavior in >> general. A better fix is to override the method in the anonymous class >> that is used when no args are given. >> >> In addition, changes should generally come with regression tests, unless >> there is a good reason not to. >> >> With those two points in mind, I have posted a revised patch for the >> consideration and review by javac Reviewers: >> webrev: http://cr.openjdk.java.net/~jjg/8058445/webrev.00 >> >> -- Jon >> >> >> >> On 11/14/2014 10:30 AM, Martin Buchholz wrote: >> >>> Shinya's message may not have been noticed; adding compiler-dev. >>> >>> On Thu, Nov 13, 2014 at 8:05 AM, bitter_fox >>> wrote: >>> >>>> Hi, >>>> I have a patch for "8058445: Javac throws exception when displaying >>>> info." >>>> Could you review and merge my patch? >>>> (Please ignore my patch when someone is already working for this issue) >>>> >>>> The cause is OptionHelper.GrumpyHelper#put throws IAE and it has not >>>> been >>>> overrided. >>>> So I override it and do not anything. >>>> >>>> webrev: http://cr.openjdk.java.net/~shinyafox/8058445/webrev.00/ >>>> issue: https://bugs.openjdk.java.net/browse/JDK-8058445 >>>> >>>> Regards, >>>> Shinya Yoshida(@bitter_fox) >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomasz.kowalczewski at gmail.com Mon Nov 17 09:00:29 2014 From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski) Date: Mon, 17 Nov 2014 10:00:29 +0100 Subject: javac compilation error when passing method reference to method accepting interface. In-Reply-To: <545BB625.1080509@oracle.com> References: <545BB037.9020006@oracle.com> <545BB625.1080509@oracle.com> Message-ID: Thanks for looking at the issue. I have downloaded latest langtools from jdk8u repo and it indeed fixes the problem. On Thu, Nov 6, 2014 at 6:55 PM, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > Hi again, > > By [1] I meant: https://bugs.openjdk.java.net/browse/JDK-8044546 :) > > Thanks, > Vicente > > > > On 11/06/2014 09:30 AM, Vicente-Arturo Romero-Zaldivar wrote: > >> Hi Tomasz, >> >> The bug you are referring to has already been fixed, please see [1]. The >> bits are not in any public release yet but you can build one from the >> development repos: >> >> for 8: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools >> for 9: http://hg.openjdk.java.net/jdk9/dev/langtools/ >> >> Thanks, >> Vicente >> >> [1] >> >> On 11/03/2014 03:15 AM, Tomasz Kowalczewski wrote: >> >>> Hi, >>> >>> please excuse my ignorance if this is a known bug, was discussed here or >>> is plain silly. >>> >>> I have a curious problem when calling a method with lambda or method >>> reference as an argument. This happens on several versions of Java 8 >>> including latest (u25). Test case is: >>> >>> package test; >>> >>> import java.util.LinkedHashMap; >>> import java.util.Map; >>> import java.util.concurrent.Callable; >>> >>> public class CompilationProblem { >>> >>> public void shouldCompile() { >>> toMap(() -> new LinkedHashMap()); // Compilation error >>> toMap(LinkedHashMap::new); // Compilation error >>> } >>> >>> public Map toMap(Func0> mapFactory) >>> { >>> return null; >>> } >>> >>> interface Func0 extends Callable { >>> >>> public R call(); >>> } >>> } >>> >>> The errors are: >>> >>> Error:(10, 17) java: method toMap in class pl.codewise.voluum.server.db.CompilationProblem >>> cannot be applied to given types; >>> required: pl.codewise.voluum.server.db.CompilationProblem.Func0>> extends java.util.Map> >>> found: ()->new Li[...]Map() >>> reason: cannot infer type-variable(s) K,V >>> (argument mismatch; bad return type in lambda expression >>> java.util.LinkedHashMap cannot be converted to ? extends >>> java.util.Map) >>> >>> Error:(11, 22) java: incompatible types: no instance(s) of type >>> variable(s) K,V exist so that java.util.LinkedHashMap conforms to ? >>> extends java.util.Map >>> >>> This test case compiles if Func0 does not extend Callable. How does >>> Callable influence type inference here? What does it change? >>> >>> -- >>> Regards, >>> Tomasz Kowalczewski >>> >> >> > -- Tomasz Kowalczewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Nov 17 19:11:38 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Mon, 17 Nov 2014 11:11:38 -0800 Subject: javac compilation error when passing method reference to method accepting interface. In-Reply-To: References: <545BB037.9020006@oracle.com> <545BB625.1080509@oracle.com> Message-ID: <546A486A.606@oracle.com> Hi Tomasz, Thanks for the follow-up. Vicente On 11/17/2014 01:00 AM, Tomasz Kowalczewski wrote: > Thanks for looking at the issue. I have downloaded latest langtools > from jdk8u repo and it indeed fixes the problem. > > > On Thu, Nov 6, 2014 at 6:55 PM, Vicente-Arturo Romero-Zaldivar > > wrote: > > Hi again, > > By [1] I meant: https://bugs.openjdk.java.net/browse/JDK-8044546 :) > > Thanks, > Vicente > > > > On 11/06/2014 09:30 AM, Vicente-Arturo Romero-Zaldivar wrote: > > Hi Tomasz, > > The bug you are referring to has already been fixed, please > see [1]. The bits are not in any public release yet but you > can build one from the development repos: > > for 8: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools > for 9: http://hg.openjdk.java.net/jdk9/dev/langtools/ > > Thanks, > Vicente > > [1] > > On 11/03/2014 03:15 AM, Tomasz Kowalczewski wrote: > > Hi, > > please excuse my ignorance if this is a known bug, was > discussed here or is plain silly. > > I have a curious problem when calling a method with lambda > or method reference as an argument. This happens on > several versions of Java 8 including latest (u25). Test > case is: > > package test; > > import java.util.LinkedHashMap; > import java.util.Map; > import java.util.concurrent.Callable; > > public class CompilationProblem { > > public void shouldCompile() { > toMap(() -> new LinkedHashMap()); // Compilation error > toMap(LinkedHashMap::new); // Compilation error > } > > public Map toMap(Func0 V>> mapFactory) { > return null; > } > > interface Func0 extends Callable { > > public R call(); > } > } > > The errors are: > > Error:(10, 17) java: method toMap in class > pl.codewise.voluum.server.db.CompilationProblem cannot be > applied to given types; > required: > pl.codewise.voluum.server.db.CompilationProblem.Func0 extends java.util.Map> > found: ()->new Li[...]Map() > reason: cannot infer type-variable(s) K,V > (argument mismatch; bad return type in lambda expression > java.util.LinkedHashMap cannot be converted to ? > extends java.util.Map) > > Error:(11, 22) java: incompatible types: no instance(s) of > type variable(s) K,V exist so that > java.util.LinkedHashMap conforms to ? extends > java.util.Map > > This test case compiles if Func0 does not extend Callable. > How does Callable influence type inference here? What does > it change? > > -- > Regards, > Tomasz Kowalczewski > > > > > > > -- > Tomasz Kowalczewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Nov 17 19:14:06 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Mon, 17 Nov 2014 11:14:06 -0800 Subject: [PATCH] Diagnostic position fix for statement-bodied lambdas In-Reply-To: References: Message-ID: <546A48FE.5060500@oracle.com> Hi Liam, I don't know of any reason to use the position of the arguments as the position of the lambda body. I will sponsor your patch, Thanks, Vicente On 11/14/2014 05:16 PM, Liam Miller-Cushon wrote: > When parsing statement-bodied lambda expressions, javac currently uses > the start position of the parameter list for the body. This patch > fixes the parser to record the body's start position correctly. > > Example diagnostic before this change: > > Test.java:17: error: incompatible types: bad return type in lambda > expression > foo((x) -> { return ""; System.out.println(""); }); > ^ > > After: > > Test.java:17: error: lambda body is neither value nor void compatible > foo((x) -> { return ""; System.out.println(""); }); > ^ > > Placing the caret at the parameter list may be deliberate, but it > should be possible to do that without recording the body's start > position incorrectly. > > Thanks, > Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdietl at gmail.com Mon Nov 17 19:34:43 2014 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 17 Nov 2014 14:34:43 -0500 Subject: JDK-8029012: parameter_index for type annotation not updated after outer.this added Message-ID: Hi Compiler people, I have a question about bug report: https://bugs.openjdk.java.net/browse/JDK-8029012 Which was pushed to JDK 9: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/aa9b6165ab12 and is proposed for JDK 8u40. I'm concerned that this change introduces a mismatch between the parameter index of a declaration annotation vs. a type annotation. The example in my comment from March 1st, 2014, in JDK 9 now produces a mismatching result for the two cases. I'm not sure why this change should be pushed to 8u40, as it will make the behavior inconsistent for different Java 8 versions. In particular, I just found this new bug report: https://bugs.openjdk.java.net/browse/JDK-8065132 Wouldn't it be better to only backport to 8u40 once the parameter index for type and declaration annotations is consistent again? Could somebody explain the rationale? Thanks! cu, WMD. -- http://www.google.com/profiles/wdietl From joel.franck at oracle.com Mon Nov 17 21:28:13 2014 From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=) Date: Mon, 17 Nov 2014 22:28:13 +0100 Subject: JDK-8029012: parameter_index for type annotation not updated after outer.this added In-Reply-To: References: Message-ID: Hi Werner, FYI I just JDK-8065132 today. Sorry if you raised this concern back in March. I think it is reasonable to backport both or none. cheers /Joel > On 17 Nov 2014, at 20:34, Werner Dietl wrote: > > Hi Compiler people, > > I have a question about bug report: > > https://bugs.openjdk.java.net/browse/JDK-8029012 > > Which was pushed to JDK 9: > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/aa9b6165ab12 > > and is proposed for JDK 8u40. > > I'm concerned that this change introduces a mismatch between the > parameter index of a declaration annotation vs. a type annotation. > The example in my comment from March 1st, 2014, in JDK 9 now produces > a mismatching result for the two cases. > > I'm not sure why this change should be pushed to 8u40, as it will make > the behavior inconsistent for different Java 8 versions. > In particular, I just found this new bug report: > > https://bugs.openjdk.java.net/browse/JDK-8065132 > > Wouldn't it be better to only backport to 8u40 once the parameter > index for type and declaration annotations is consistent again? > > Could somebody explain the rationale? > > Thanks! > cu, WMD. > > -- > http://www.google.com/profiles/wdietl From joel.franck at oracle.com Mon Nov 17 21:46:23 2014 From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=) Date: Mon, 17 Nov 2014 22:46:23 +0100 Subject: RFR: 8058445 | was Re: [PATCH]8058445: Javac throws exception when displaying info In-Reply-To: <5466A5E5.1090103@oracle.com> References: <5466A5E5.1090103@oracle.com> Message-ID: Hi, > On 15 Nov 2014, at 02:01, Jonathan Gibbons wrote: > > Shinya, > > Thanks for looking at this issue and submitting your patch. > > The intent of GrumpyHelper is that by default it *should* throw exceptions, and so it is not desirable to suppress that behavior in general. A better fix is to override the method in the anonymous class that is used when no args are given. > > In addition, changes should generally come with regression tests, unless there is a good reason not to. > > With those two points in mind, I have posted a revised patch for the consideration and review by javac Reviewers: > webrev: http://cr.openjdk.java.net/~jjg/8058445/webrev.00 > Looks good Jon. cheers /Joel From jonathan.gibbons at oracle.com Mon Nov 17 22:21:48 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 17 Nov 2014 14:21:48 -0800 Subject: RFR: 8058445 | was Re: [PATCH]8058445: Javac throws exception when displaying info In-Reply-To: References: <5466A5E5.1090103@oracle.com> Message-ID: <546A74FC.4080707@oracle.com> Thanks. -- Jon On 11/17/2014 01:46 PM, Joel Borggr?n-Franck wrote: > Hi, > >> On 15 Nov 2014, at 02:01, Jonathan Gibbons wrote: >> >> Shinya, >> >> Thanks for looking at this issue and submitting your patch. >> >> The intent of GrumpyHelper is that by default it *should* throw exceptions, and so it is not desirable to suppress that behavior in general. A better fix is to override the method in the anonymous class that is used when no args are given. >> >> In addition, changes should generally come with regression tests, unless there is a good reason not to. >> >> With those two points in mind, I have posted a revised patch for the consideration and review by javac Reviewers: >> webrev: http://cr.openjdk.java.net/~jjg/8058445/webrev.00 >> > Looks good Jon. > > cheers > /Joel > From joel.franck at oracle.com Tue Nov 18 10:41:47 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 18 Nov 2014 11:41:47 +0100 Subject: RFR: JDK-8062359: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass Message-ID: Hi, Here is a proposed fix for [1]: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass This is for 9 but I will propose an identical backport to 8u as well. Patch is very small: diff -r c2339b4749af src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Mon Nov 17 23:11:05 2014 -0800 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Tue Nov 18 10:23:57 2014 +0100 @@ -4486,14 +4486,16 @@ super.visitTypeTest(tree); } public void visitNewClass(JCNewClass tree) { - if (tree.clazz.hasTag(ANNOTATED_TYPE)) { - checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, - tree.clazz.type.tsym); - } - if (tree.def != null) { - checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); - } - if (tree.clazz.type != null) { + if (tree.clazz != null && tree.clazz.type != null) { + if (tree.clazz.hasTag(ANNOTATED_TYPE)) { + checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, + tree.clazz.type.tsym); + } + + if (tree.def != null) { + checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); + } + validateAnnotatedType(tree.clazz, tree.clazz.type); } super.visitNewClass(tree); ? 8< ? I can?t reproduce the issue, but as the initial report (CC:ed) wrote, and as nearby methods hint at, tree.clazz.type can be null which may NPE in the second if clause guarded by tree.def != null. My proposed fix is to add guards similar to visitTypeCast or visitTypeTest. There is no test since I can?t reproduce this, but the existing langtools regression tests pass, and I have run a jcov report that at least shows the method has good coverage by the existing tests. If anyone is able to reproduce this I would be glad if you tried out the patch. thanks in advance cheers /Joel [1] https://bugs.openjdk.java.net/browse/JDK-8062359 From jan.lahoda at oracle.com Tue Nov 18 13:36:12 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 18 Nov 2014 14:36:12 +0100 Subject: RFR: JDK-8062359: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass In-Reply-To: References: Message-ID: <546B4B4C.2060802@oracle.com> Hi, Is there a chance to get the actual javac options+list of files (in the given order) that get passed to javac when the NPE happens? Might be possible to reproduce with that? Thanks, Jan On 18.11.2014 11:41, Joel Borggr?n-Franck wrote: > Hi, > > Here is a proposed fix for [1]: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass > > This is for 9 but I will propose an identical backport to 8u as well. Patch is very small: > > diff -r c2339b4749af src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Mon Nov 17 23:11:05 2014 -0800 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Tue Nov 18 10:23:57 2014 +0100 > @@ -4486,14 +4486,16 @@ > super.visitTypeTest(tree); > } > public void visitNewClass(JCNewClass tree) { > - if (tree.clazz.hasTag(ANNOTATED_TYPE)) { > - checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, > - tree.clazz.type.tsym); > - } > - if (tree.def != null) { > - checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); > - } > - if (tree.clazz.type != null) { > + if (tree.clazz != null && tree.clazz.type != null) { > + if (tree.clazz.hasTag(ANNOTATED_TYPE)) { > + checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, > + tree.clazz.type.tsym); > + } > + > + if (tree.def != null) { > + checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); > + } > + > validateAnnotatedType(tree.clazz, tree.clazz.type); > } > super.visitNewClass(tree); > > ? 8< ? > > I can?t reproduce the issue, but as the initial report (CC:ed) wrote, and as nearby methods hint at, tree.clazz.type can be null which may NPE in the second if clause guarded by tree.def != null. > > My proposed fix is to add guards similar to visitTypeCast or visitTypeTest. There is no test since I can?t reproduce this, but the existing langtools regression tests pass, and I have run a jcov report that at least shows the method has good coverage by the existing tests. > > If anyone is able to reproduce this I would be glad if you tried out the patch. > > thanks in advance > > cheers > /Joel > > [1] https://bugs.openjdk.java.net/browse/JDK-8062359 > From joel.franck at oracle.com Wed Nov 19 12:26:28 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 19 Nov 2014 13:26:28 +0100 Subject: RFR: JDK-8062359: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass In-Reply-To: References: <546B4B4C.2060802@oracle.com> Message-ID: Reproduces for me now, thanks! cheers /Joel On 18 nov 2014, at 18:02, Michael Bayne wrote: > From joel.franck at oracle.com Wed Nov 19 16:13:40 2014 From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=) Date: Wed, 19 Nov 2014 17:13:40 +0100 Subject: RFR: JDK-8062359: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass In-Reply-To: References: Message-ID: <8DFF34CF-7C16-40E5-AAF9-AA5F8F764CE2@oracle.com> Hi, Thanks for the reproducer Michael. Jan minimized it and we now have both a test and a fix. Problem is when an anonymous inner class extends an unresolvable class an anonymous inner class inside it won?t get attributed. Long term we might fix this by trying harder to attribute the innermost class but a short term fix is to properly check that tree.clazz and tree.clazz.type aren?t null. Patch with test below and attached. cheers /Joel diff -r f62d01419621 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Wed Nov 19 13:46:04 2014 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Wed Nov 19 17:01:57 2014 +0100 @@ -4486,14 +4486,15 @@ super.visitTypeTest(tree); } public void visitNewClass(JCNewClass tree) { - if (tree.clazz.hasTag(ANNOTATED_TYPE)) { - checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, - tree.clazz.type.tsym); - } - if (tree.def != null) { - checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); - } - if (tree.clazz.type != null) { + if (tree.clazz != null && tree.clazz.type != null) { + if (tree.clazz.hasTag(ANNOTATED_TYPE)) { + checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, + tree.clazz.type.tsym); + } + if (tree.def != null) { + checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); + } + validateAnnotatedType(tree.clazz, tree.clazz.type); } super.visitNewClass(tree); diff -r f62d01419621 test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java Wed Nov 19 17:01:57 2014 +0100 @@ -0,0 +1,17 @@ +/* + * @test /nodynamiccopyright/ + * @bug 8062359 + * @summary NullPointerException in Attr when type-annotating an anonymous + * inner class in an unresolvable class + * @compile/fail/ref=UnresolvableClassNPEInAttrTest.out -XDrawDiagnostics UnresolvableClassNPEInAttrTest.java + */ + +public class UnresolvableClassNPEInAttrTest { + public static void main(String[] args) { + new Undefined() { + void test() { + new Object() {}; + } + }; + } +} diff -r f62d01419621 test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.out --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.out Wed Nov 19 17:01:57 2014 +0100 @@ -0,0 +1,2 @@ +UnresolvableClassNPEInAttrTest.java:11:13: compiler.err.cant.resolve.location: kindname.class, Undefined, , , (compiler.misc.location: kindname.class, UnresolvableClassNPEInAttrTest, null) +1 error -------------- next part -------------- A non-text attachment was scrubbed... Name: 8062359.patch Type: application/octet-stream Size: 2598 bytes Desc: not available URL: -------------- next part -------------- > On 18 Nov 2014, at 11:41, Joel Borggr?n-Franck wrote: > > Hi, > > Here is a proposed fix for [1]: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass > > This is for 9 but I will propose an identical backport to 8u as well. Patch is very small: > > [1] https://bugs.openjdk.java.net/browse/JDK-8062359 From jan.lahoda at oracle.com Thu Nov 20 17:16:07 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 20 Nov 2014 18:16:07 +0100 Subject: RFR: JDK-8062359: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass In-Reply-To: <8DFF34CF-7C16-40E5-AAF9-AA5F8F764CE2@oracle.com> References: <8DFF34CF-7C16-40E5-AAF9-AA5F8F764CE2@oracle.com> Message-ID: <546E21D7.6000701@oracle.com> Thanks Michael for the reproducible case. The tree.clazz.type null check seems reasonable as a short(er) term fix. I wonder if we need the tree.clazz null check? I am not sure under which circumstances tree.clazz could be null. Thanks, Jan On 19.11.2014 17:13, Joel Borggr?n-Franck wrote: > Hi, > > Thanks for the reproducer Michael. Jan minimized it and we now have both a test and a fix. > > Problem is when an anonymous inner class extends an unresolvable class an anonymous inner class inside it won?t get attributed. Long term we might fix this by trying harder to attribute the innermost class but a short term fix is to properly check that tree.clazz and tree.clazz.type aren?t null. > > Patch with test below and attached. > > cheers > /Joel > > diff -r f62d01419621 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Wed Nov 19 13:46:04 2014 +0100 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Wed Nov 19 17:01:57 2014 +0100 > @@ -4486,14 +4486,15 @@ > super.visitTypeTest(tree); > } > public void visitNewClass(JCNewClass tree) { > - if (tree.clazz.hasTag(ANNOTATED_TYPE)) { > - checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, > - tree.clazz.type.tsym); > - } > - if (tree.def != null) { > - checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); > - } > - if (tree.clazz.type != null) { > + if (tree.clazz != null && tree.clazz.type != null) { > + if (tree.clazz.hasTag(ANNOTATED_TYPE)) { > + checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, > + tree.clazz.type.tsym); > + } > + if (tree.def != null) { > + checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); > + } > + > validateAnnotatedType(tree.clazz, tree.clazz.type); > } > super.visitNewClass(tree); > diff -r f62d01419621 test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java Wed Nov 19 17:01:57 2014 +0100 > @@ -0,0 +1,17 @@ > +/* > + * @test /nodynamiccopyright/ > + * @bug 8062359 > + * @summary NullPointerException in Attr when type-annotating an anonymous > + * inner class in an unresolvable class > + * @compile/fail/ref=UnresolvableClassNPEInAttrTest.out -XDrawDiagnostics UnresolvableClassNPEInAttrTest.java > + */ > + > +public class UnresolvableClassNPEInAttrTest { > + public static void main(String[] args) { > + new Undefined() { > + void test() { > + new Object() {}; > + } > + }; > + } > +} > diff -r f62d01419621 test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.out > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.out Wed Nov 19 17:01:57 2014 +0100 > @@ -0,0 +1,2 @@ > +UnresolvableClassNPEInAttrTest.java:11:13: compiler.err.cant.resolve.location: kindname.class, Undefined, , , (compiler.misc.location: kindname.class, UnresolvableClassNPEInAttrTest, null) > +1 error > > > > > >> On 18 Nov 2014, at 11:41, Joel Borggr?n-Franck wrote: >> >> Hi, >> >> Here is a proposed fix for [1]: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass >> >> This is for 9 but I will propose an identical backport to 8u as well. Patch is very small: >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8062359 > > > From vicente.romero at oracle.com Thu Nov 20 18:31:39 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 20 Nov 2014 10:31:39 -0800 Subject: RFR: JDK-8062359: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass - accepted In-Reply-To: <8DFF34CF-7C16-40E5-AAF9-AA5F8F764CE2@oracle.com> References: <8DFF34CF-7C16-40E5-AAF9-AA5F8F764CE2@oracle.com> Message-ID: <546E338B.7020907@oracle.com> Hi, Thanks for the fix, accepted, Vicente On 11/19/2014 08:13 AM, Joel Borggr?n-Franck wrote: > Hi, > > Thanks for the reproducer Michael. Jan minimized it and we now have both a test and a fix. > > Problem is when an anonymous inner class extends an unresolvable class an anonymous inner class inside it won?t get attributed. Long term we might fix this by trying harder to attribute the innermost class but a short term fix is to properly check that tree.clazz and tree.clazz.type aren?t null. > > Patch with test below and attached. > > cheers > /Joel > > diff -r f62d01419621 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Wed Nov 19 13:46:04 2014 +0100 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Wed Nov 19 17:01:57 2014 +0100 > @@ -4486,14 +4486,15 @@ > super.visitTypeTest(tree); > } > public void visitNewClass(JCNewClass tree) { > - if (tree.clazz.hasTag(ANNOTATED_TYPE)) { > - checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, > - tree.clazz.type.tsym); > - } > - if (tree.def != null) { > - checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); > - } > - if (tree.clazz.type != null) { > + if (tree.clazz != null && tree.clazz.type != null) { > + if (tree.clazz.hasTag(ANNOTATED_TYPE)) { > + checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, > + tree.clazz.type.tsym); > + } > + if (tree.def != null) { > + checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); > + } > + > validateAnnotatedType(tree.clazz, tree.clazz.type); > } > super.visitNewClass(tree); > diff -r f62d01419621 test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java Wed Nov 19 17:01:57 2014 +0100 > @@ -0,0 +1,17 @@ > +/* > + * @test /nodynamiccopyright/ > + * @bug 8062359 > + * @summary NullPointerException in Attr when type-annotating an anonymous > + * inner class in an unresolvable class > + * @compile/fail/ref=UnresolvableClassNPEInAttrTest.out -XDrawDiagnostics UnresolvableClassNPEInAttrTest.java > + */ > + > +public class UnresolvableClassNPEInAttrTest { > + public static void main(String[] args) { > + new Undefined() { > + void test() { > + new Object() {}; > + } > + }; > + } > +} > diff -r f62d01419621 test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.out > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.out Wed Nov 19 17:01:57 2014 +0100 > @@ -0,0 +1,2 @@ > +UnresolvableClassNPEInAttrTest.java:11:13: compiler.err.cant.resolve.location: kindname.class, Undefined, , , (compiler.misc.location: kindname.class, UnresolvableClassNPEInAttrTest, null) > +1 error > > > > >> On 18 Nov 2014, at 11:41, Joel Borggr?n-Franck wrote: >> >> Hi, >> >> Here is a proposed fix for [1]: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass >> >> This is for 9 but I will propose an identical backport to 8u as well. Patch is very small: >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8062359 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Nov 20 22:14:26 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Nov 2014 14:14:26 -0800 Subject: RFR: 8058445 | was Re: [PATCH]8058445: Javac throws exception when displaying info In-Reply-To: <546A74FC.4080707@oracle.com> References: <5466A5E5.1090103@oracle.com> <546A74FC.4080707@oracle.com> Message-ID: <546E67C2.4040500@oracle.com> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a073e36e4001 On 11/17/2014 02:21 PM, Jonathan Gibbons wrote: > Thanks. > > -- Jon > > On 11/17/2014 01:46 PM, Joel Borggr?n-Franck wrote: >> Hi, >> >>> On 15 Nov 2014, at 02:01, Jonathan Gibbons >>> wrote: >>> >>> Shinya, >>> >>> Thanks for looking at this issue and submitting your patch. >>> >>> The intent of GrumpyHelper is that by default it *should* throw >>> exceptions, and so it is not desirable to suppress that behavior in >>> general. A better fix is to override the method in the anonymous >>> class that is used when no args are given. >>> >>> In addition, changes should generally come with regression tests, >>> unless there is a good reason not to. >>> >>> With those two points in mind, I have posted a revised patch for the >>> consideration and review by javac Reviewers: >>> webrev: http://cr.openjdk.java.net/~jjg/8058445/webrev.00 >>> >> Looks good Jon. >> >> cheers >> /Joel >> > From joel.franck at oracle.com Fri Nov 21 10:38:37 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 21 Nov 2014 11:38:37 +0100 Subject: RFR: JDK-8062359: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass In-Reply-To: <546E21D7.6000701@oracle.com> References: <8DFF34CF-7C16-40E5-AAF9-AA5F8F764CE2@oracle.com> <546E21D7.6000701@oracle.com> Message-ID: <6A4B9A7B-052A-418A-9BCF-B4586AE09BE1@oracle.com> Thanks for the reviews. I don?t think clazz can be null either, but I?ll keep it just in case. This visitor will probably be rewritten in the anno-pipeline project, and I think we can run it after postattr. cheers /Joel On 20 nov 2014, at 18:16, Jan Lahoda wrote: > Thanks Michael for the reproducible case. > > The tree.clazz.type null check seems reasonable as a short(er) term fix. I wonder if we need the tree.clazz null check? I am not sure under which circumstances tree.clazz could be null. > > Thanks, > Jan > > On 19.11.2014 17:13, Joel Borggr?n-Franck wrote: >> Hi, >> >> Thanks for the reproducer Michael. Jan minimized it and we now have both a test and a fix. >> >> Problem is when an anonymous inner class extends an unresolvable class an anonymous inner class inside it won?t get attributed. Long term we might fix this by trying harder to attribute the innermost class but a short term fix is to properly check that tree.clazz and tree.clazz.type aren?t null. >> >> Patch with test below and attached. >> >> cheers >> /Joel >> >> diff -r f62d01419621 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Wed Nov 19 13:46:04 2014 +0100 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Wed Nov 19 17:01:57 2014 +0100 >> @@ -4486,14 +4486,15 @@ >> super.visitTypeTest(tree); >> } >> public void visitNewClass(JCNewClass tree) { >> - if (tree.clazz.hasTag(ANNOTATED_TYPE)) { >> - checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, >> - tree.clazz.type.tsym); >> - } >> - if (tree.def != null) { >> - checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); >> - } >> - if (tree.clazz.type != null) { >> + if (tree.clazz != null && tree.clazz.type != null) { >> + if (tree.clazz.hasTag(ANNOTATED_TYPE)) { >> + checkForDeclarationAnnotations(((JCAnnotatedType) tree.clazz).annotations, >> + tree.clazz.type.tsym); >> + } >> + if (tree.def != null) { >> + checkForDeclarationAnnotations(tree.def.mods.annotations, tree.clazz.type.tsym); >> + } >> + >> validateAnnotatedType(tree.clazz, tree.clazz.type); >> } >> super.visitNewClass(tree); >> diff -r f62d01419621 test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java Wed Nov 19 17:01:57 2014 +0100 >> @@ -0,0 +1,17 @@ >> +/* >> + * @test /nodynamiccopyright/ >> + * @bug 8062359 >> + * @summary NullPointerException in Attr when type-annotating an anonymous >> + * inner class in an unresolvable class >> + * @compile/fail/ref=UnresolvableClassNPEInAttrTest.out -XDrawDiagnostics UnresolvableClassNPEInAttrTest.java >> + */ >> + >> +public class UnresolvableClassNPEInAttrTest { >> + public static void main(String[] args) { >> + new Undefined() { >> + void test() { >> + new Object() {}; >> + } >> + }; >> + } >> +} >> diff -r f62d01419621 test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.out >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/test/tools/javac/8062359/UnresolvableClassNPEInAttrTest.out Wed Nov 19 17:01:57 2014 +0100 >> @@ -0,0 +1,2 @@ >> +UnresolvableClassNPEInAttrTest.java:11:13: compiler.err.cant.resolve.location: kindname.class, Undefined, , , (compiler.misc.location: kindname.class, UnresolvableClassNPEInAttrTest, null) >> +1 error >> >> >> >> >> >>> On 18 Nov 2014, at 11:41, Joel Borggr?n-Franck wrote: >>> >>> Hi, >>> >>> Here is a proposed fix for [1]: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass >>> >>> This is for 9 but I will propose an identical backport to 8u as well. Patch is very small: >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8062359 >> >> >> From vicente.romero at oracle.com Mon Nov 24 19:04:12 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Mon, 24 Nov 2014 11:04:12 -0800 Subject: [PATCH] Diagnostic position fix for statement-bodied lambdas In-Reply-To: <546A48FE.5060500@oracle.com> References: <546A48FE.5060500@oracle.com> Message-ID: <5473812C.5040601@oracle.com> Hi Liam, I have created this bug entry: https://bugs.openjdk.java.net/browse/JDK-8065800 to track this issue. Thanks, Vicente On 11/17/2014 11:14 AM, Vicente-Arturo Romero-Zaldivar wrote: > Hi Liam, > > I don't know of any reason to use the position of the arguments as the > position of the lambda body. I will sponsor your patch, > > Thanks, > Vicente > > On 11/14/2014 05:16 PM, Liam Miller-Cushon wrote: >> When parsing statement-bodied lambda expressions, javac currently >> uses the start position of the parameter list for the body. This >> patch fixes the parser to record the body's start position correctly. >> >> Example diagnostic before this change: >> >> Test.java:17: error: incompatible types: bad return type in lambda >> expression >> foo((x) -> { return ""; System.out.println(""); }); >> ^ >> >> After: >> >> Test.java:17: error: lambda body is neither value nor void compatible >> foo((x) -> { return ""; System.out.println(""); }); >> ^ >> >> Placing the caret at the parameter list may be deliberate, but it >> should be possible to do that without recording the body's start >> position incorrectly. >> >> Thanks, >> Liam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Mon Nov 24 19:37:24 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 24 Nov 2014 11:37:24 -0800 Subject: issue with fix for JDK-8064464 Message-ID: The fix for JDK-8064464 [1] [2] prevents the following code from compiling (it works fine with 8u25 and 7u67). Is this deliberate? abstract class Test { abstract T e(); abstract int f(); void m(boolean flag) { String.valueOf(flag ? f() : this.e()); } } $ javac Test.java Test.java:5: error: reference to valueOf is ambiguous String.valueOf(flag ? f() : this.e()); ^ both method valueOf(Object) in String and method valueOf(int) in String match [1] https://bugs.openjdk.java.net/browse/JDK-8064464 [2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/601e08b62ba8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Nov 24 22:01:39 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 24 Nov 2014 22:01:39 +0000 Subject: issue with fix for JDK-8064464 In-Reply-To: References: Message-ID: <5473AAC3.4080404@oracle.com> Hi Liam, the JLS defines an operand of a conditional expression to be numeric/boolean in case it is a method call with the following wording: "A method invocation expression (?15.12) for which the chosen most specific method (?15.12.2.5) has return type boolean or Boolean. *Note that, for a generic method, this is the type **/before/**instantiating the method's type arguments.*" (oddly, the statement in bold only appears in the section on boolean conditionals, and not in the one about numeric conditionals, but I believe that's a mistake - i.e. the same statement should be present on both). This seems to suggest that your example should not compile, as the uninstantiated method return type would be T, which is not a numeric type. However, this seems like a case where the analysis could be improved a bit - as far as I recall, this rule is mostly there to prevent excessive speculative type-checking during classification of the conditional expression; so it seems like taking into account explicit type parameters could be doable (although maybe tricky to specify). I'll leave this with Dan for further evaluation. Thanks Maurizio On 24/11/14 19:37, Liam Miller-Cushon wrote: > The fix for JDK-8064464 [1] [2] prevents the following code from > compiling (it works fine with 8u25 and 7u67). Is this deliberate? > > abstract class Test { > abstract T e(); > abstract int f(); > void m(boolean flag) { > String.valueOf(flag ? f() : this.e()); > } > } > > $ javac Test.java > Test.java:5: error: reference to valueOf is ambiguous > String.valueOf(flag ? f() : this.e()); > ^ > both method valueOf(Object) in String and method valueOf(int) in > String match > > [1] https://bugs.openjdk.java.net/browse/JDK-8064464 > [2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/601e08b62ba8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Nov 26 00:46:13 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 25 Nov 2014 16:46:13 -0800 Subject: issue with fix for JDK-8064464 In-Reply-To: <5473AAC3.4080404@oracle.com> References: <5473AAC3.4080404@oracle.com> Message-ID: Hi Maurizio, Thanks for investigating. For what it's worth, the amount of code affected by this change appears to be very small. On Mon, Nov 24, 2014 at 2:01 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi Liam, > the JLS defines an operand of a conditional expression to be > numeric/boolean in case it is a method call with the following wording: > > "A method invocation expression (?15.12) for which the chosen most > specific method (?15.12.2.5) has return type boolean or Boolean. > *Note that, for a generic method, this is the type **before** > instantiating the method's type arguments.*" > > (oddly, the statement in bold only appears in the section on boolean > conditionals, and not in the one about numeric conditionals, but I believe > that's a mistake - i.e. the same statement should be present on both). > > This seems to suggest that your example should not compile, as the > uninstantiated method return type would be T, which is not a numeric type. > > However, this seems like a case where the analysis could be improved a bit > - as far as I recall, this rule is mostly there to prevent excessive > speculative type-checking during classification of the conditional > expression; so it seems like taking into account explicit type parameters > could be doable (although maybe tricky to specify). I'll leave this with > Dan for further evaluation. > > Thanks > Maurizio > > > > On 24/11/14 19:37, Liam Miller-Cushon wrote: > > The fix for JDK-8064464 [1] [2] prevents the following code from compiling > (it works fine with 8u25 and 7u67). Is this deliberate? > > abstract class Test { > abstract T e(); > abstract int f(); > void m(boolean flag) { > String.valueOf(flag ? f() : this.e()); > } > } > > $ javac Test.java > Test.java:5: error: reference to valueOf is ambiguous > String.valueOf(flag ? f() : this.e()); > ^ > both method valueOf(Object) in String and method valueOf(int) in String > match > > [1] https://bugs.openjdk.java.net/browse/JDK-8064464 > [2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/601e08b62ba8 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Nov 26 00:54:31 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 25 Nov 2014 16:54:31 -0800 Subject: LVT issue related to JDK-8047719 Message-ID: An LVT entry is no longer emitted for 'foo' in the following code. The behaviour changed after the fix for JDK-8047719 [1]. Is this a bug? class Test { { String foo = null; } } Before: LocalVariableTable: Start Length Slot Name Signature 6 0 1 foo Ljava/lang/String; 0 7 0 this LTest; After: LocalVariableTable: Start Length Slot Name Signature 0 7 0 this LTest; [1] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Nov 26 01:19:59 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 25 Nov 2014 17:19:59 -0800 Subject: LVT issue related to JDK-8047719 In-Reply-To: References: Message-ID: <54752ABF.1000307@oracle.com> The patch for https://bugs.openjdk.java.net/browse/JDK-8064857, still under review, should fix this issue too. Thanks, Vicente On 11/25/2014 04:54 PM, Liam Miller-Cushon wrote: > An LVT entry is no longer emitted for 'foo' in the following code. The > behaviour changed after the fix for JDK-8047719 [1]. Is this a bug? > > class Test { > { > String foo = null; > } > } > > Before: > LocalVariableTable: > Start Length Slot Name Signature > 6 0 1 foo Ljava/lang/String; > 0 7 0 this LTest; > > After: > LocalVariableTable: > Start Length Slot Name Signature > 0 7 0 this LTest; > > [1] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb From cushon at google.com Wed Nov 26 01:59:58 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 25 Nov 2014 17:59:58 -0800 Subject: LVT issue related to JDK-8047719 In-Reply-To: <54752ABF.1000307@oracle.com> References: <54752ABF.1000307@oracle.com> Message-ID: Thanks Vicente, I'll try out the patch once it lands. On Tue, Nov 25, 2014 at 5:19 PM, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > The patch for https://bugs.openjdk.java.net/browse/JDK-8064857, still > under review, should fix this issue too. > > Thanks, > Vicente > > > On 11/25/2014 04:54 PM, Liam Miller-Cushon wrote: > >> An LVT entry is no longer emitted for 'foo' in the following code. The >> behaviour changed after the fix for JDK-8047719 [1]. Is this a bug? >> >> class Test { >> { >> String foo = null; >> } >> } >> >> Before: >> LocalVariableTable: >> Start Length Slot Name Signature >> 6 0 1 foo Ljava/lang/String; >> 0 7 0 this LTest; >> >> After: >> LocalVariableTable: >> Start Length Slot Name Signature >> 0 7 0 this LTest; >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitterfoxc at gmail.com Wed Nov 26 19:28:59 2014 From: bitterfoxc at gmail.com (bitter_fox) Date: Thu, 27 Nov 2014 04:28:59 +0900 Subject: RFR: 8065988: Duplicated error messages for "no source file" in javac Message-ID: Hi, Please review my patch for 8065988. I couldn't write the test. Could you write the test for this issue? webrev is here: http://cr.openjdk.java.net/~shinyafox/8065988/webrev.00/ bugs is here: https://bugs.openjdk.java.net/browse/JDK-8065988 Regards, Shinya Yoshida(@bitter_fox, shinyafox) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Nov 26 19:31:23 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Nov 2014 11:31:23 -0800 Subject: RFR: 8065988: Duplicated error messages for "no source file" in javac In-Reply-To: References: Message-ID: <54762A8B.5020202@oracle.com> On 11/26/2014 11:28 AM, bitter_fox wrote: > Hi, > Please review my patch for 8065988. > > I couldn't write the test. > Could you write the test for this issue? > > webrev is here: > http://cr.openjdk.java.net/~shinyafox/8065988/webrev.00/ > > > bugs is here: > https://bugs.openjdk.java.net/browse/JDK-8065988 > > Regards, > Shinya Yoshida(@bitter_fox, shinyafox) I'll take a look and see about a test. -- Jon From jonathan.gibbons at oracle.com Wed Nov 26 19:44:06 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Nov 2014 11:44:06 -0800 Subject: RFR: 8065988: Duplicated error messages for "no source file" in javac In-Reply-To: References: Message-ID: <54762D86.10707@oracle.com> On 11/26/2014 11:28 AM, bitter_fox wrote: > Hi, > Please review my patch for 8065988. > > I couldn't write the test. > Could you write the test for this issue? > > webrev is here: > http://cr.openjdk.java.net/~shinyafox/8065988/webrev.00/ > > > bugs is here: > https://bugs.openjdk.java.net/browse/JDK-8065988 > > Regards, > Shinya Yoshida(@bitter_fox, shinyafox) Shinya, I've read through your patch, but I'd be looking to understand why you need to pass back and use a boolean result from Arguments.init rather than use the existing mechanism of checking log.nerrors. -- Jon From bitterfoxc at gmail.com Wed Nov 26 19:59:56 2014 From: bitterfoxc at gmail.com (bitter_fox) Date: Thu, 27 Nov 2014 04:59:56 +0900 Subject: RFR: 8065988: Duplicated error messages for "no source file" in javac In-Reply-To: <54762D86.10707@oracle.com> References: <54762D86.10707@oracle.com> Message-ID: Hi, Jonathan. Because log.nerror is never incremented by printing "file not found" error. The error printed in Argument#error: case ILLEGAL_ARGUMENT: { String msg = log.localize(PrefixKind.JAVAC, key, args); throw new PropagatedException(new IllegalArgumentException(msg)); } It calls Log#localize, and it doesn't increment log.nerrors. So in this case, I think log.nerrors won't work well. Regards, Shinya Yoshida(@bitter_fox, shinyafox) 2014-11-27 4:44 GMT+09:00 Jonathan Gibbons : > On 11/26/2014 11:28 AM, bitter_fox wrote: > >> Hi, >> Please review my patch for 8065988. >> >> I couldn't write the test. >> Could you write the test for this issue? >> >> webrev is here: >> http://cr.openjdk.java.net/~shinyafox/8065988/webrev.00/ < >> http://cr.openjdk.java.net/%7Eshinyafox/8065988/webrev.00/> >> >> bugs is here: >> https://bugs.openjdk.java.net/browse/JDK-8065988 >> >> Regards, >> Shinya Yoshida(@bitter_fox, shinyafox) >> > > Shinya, > > I've read through your patch, but I'd be looking to understand why you > need to pass back and use a boolean result from Arguments.init rather than > use the existing mechanism of checking log.nerrors. > > -- Jon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitterfoxc at gmail.com Wed Nov 26 20:25:10 2014 From: bitterfoxc at gmail.com (bitter_fox) Date: Thu, 27 Nov 2014 05:25:10 +0900 Subject: RFR: 8065988: Duplicated error messages for "no source file" in javac In-Reply-To: References: <54762D86.10707@oracle.com> Message-ID: Another fix is here: http://cr.openjdk.java.net/~shinyafox/8065988/webrev.01/ increment log.nerrors in Argument#error. I don't know which is better, but it looks beautiful. 2014-11-27 4:59 GMT+09:00 bitter_fox : > Hi, Jonathan. > > Because log.nerror is never incremented by printing "file not found" error. > > The error printed in Argument#error: > case ILLEGAL_ARGUMENT: { > String msg = log.localize(PrefixKind.JAVAC, key, args); > throw new PropagatedException(new > IllegalArgumentException(msg)); > } > > It calls Log#localize, and it doesn't increment log.nerrors. > > So in this case, I think log.nerrors won't work well. > > Regards, > Shinya Yoshida(@bitter_fox, shinyafox) > > > 2014-11-27 4:44 GMT+09:00 Jonathan Gibbons : > >> On 11/26/2014 11:28 AM, bitter_fox wrote: >> >>> Hi, >>> Please review my patch for 8065988. >>> >>> I couldn't write the test. >>> Could you write the test for this issue? >>> >>> webrev is here: >>> http://cr.openjdk.java.net/~shinyafox/8065988/webrev.00/ < >>> http://cr.openjdk.java.net/%7Eshinyafox/8065988/webrev.00/> >>> >>> bugs is here: >>> https://bugs.openjdk.java.net/browse/JDK-8065988 >>> >>> Regards, >>> Shinya Yoshida(@bitter_fox, shinyafox) >>> >> >> Shinya, >> >> I've read through your patch, but I'd be looking to understand why you >> need to pass back and use a boolean result from Arguments.init rather than >> use the existing mechanism of checking log.nerrors. >> >> -- Jon >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Nov 26 21:26:26 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Nov 2014 13:26:26 -0800 Subject: RFR: 8065988: Duplicated error messages for "no source file" in javac In-Reply-To: References: <54762D86.10707@oracle.com> Message-ID: <54764582.7070109@oracle.com> Shinya, It would be better to just do the increment in the "case LOG:" case, when the message is actually reported to the log. In the other two arms of the switch statement, an exception is thrown instead of reporting anything to the log. -- Jon On 11/26/2014 12:25 PM, bitter_fox wrote: > Another fix is here: > http://cr.openjdk.java.net/~shinyafox/8065988/webrev.01/ > > > increment log.nerrors in Argument#error. > > I don't know which is better, but it looks beautiful. > > > 2014-11-27 4:59 GMT+09:00 bitter_fox >: > > Hi, Jonathan. > > Because log.nerror is never incremented by printing "file not > found" error. > > The error printed in Argument#error: > case ILLEGAL_ARGUMENT: { > String msg = log.localize(PrefixKind.JAVAC, key, > args); > throw new PropagatedException(new > IllegalArgumentException(msg)); > } > > It calls Log#localize, and it doesn't increment log.nerrors. > > So in this case, I think log.nerrors won't work well. > > Regards, > Shinya Yoshida(@bitter_fox, shinyafox) > > > 2014-11-27 4:44 GMT+09:00 Jonathan Gibbons > >: > > On 11/26/2014 11:28 AM, bitter_fox wrote: > > Hi, > Please review my patch for 8065988. > > I couldn't write the test. > Could you write the test for this issue? > > webrev is here: > http://cr.openjdk.java.net/~shinyafox/8065988/webrev.00/ > > > > bugs is here: > https://bugs.openjdk.java.net/browse/JDK-8065988 > > Regards, > Shinya Yoshida(@bitter_fox, shinyafox) > > > Shinya, > > I've read through your patch, but I'd be looking to understand > why you need to pass back and use a boolean result from > Arguments.init rather than use the existing mechanism of > checking log.nerrors. > > -- Jon > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Thu Nov 27 01:26:18 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 27 Nov 2014 02:26:18 +0100 Subject: RFR: 8054717: SJavac should track changes in the public apis of classpath classes! Message-ID: <20141127012617.GA17122@e6430> Hi compiler-dev, Here's a patch for JDK-8054717 which makes sjavac detect modifications of dependencies on the class path. Description: Change 1: Dependencies now tracked on class level rather than package level Change 2: Changes in classpath classes now detected How the sjavac recompilation logic works: 1. Taint files that A) have new mod times B) depend on classpath classes with new public apis 2. Compile tanited packages 3. For those classes whose public api changed, taint their dependents 4. Repeat from step 2 until no files are tainted Motivation for Change 1: In order to solve step 1B above, sjavac needs to look up the pub api of a classpath dependency. If all we have to work with is package dependencies, this is unnecesarily complicated. If we, on the other hand, have a fully qualified class name, we can simply look up the class symbol through the ClassFinder. Class level dependency tracking also caters for less recompilation: If A only depends on pkg.B, it should not need to be recompiled if the pub api of pkg.C is updated. Note that the previous decision of compiling only full packages still stands. Left for future work: - Optimization: Modtime detection classpath dependents to avoid unnecessary pub api lookup (JDK-8065996) - The recompilation logic and dependency tracking should be done on the level of compilation units (JDK-8065995) - Logic for dealing with ambiguous imports due to incremental change in the code (JDK-8065997) Tests: - All langtools tests pass - Building the JDK works - JPRT -bo works fine Minor remarks: - I had to mark the (Java)FileObjectWithLocation as @Trusted to avoid having javac wrap the file objects (and make the location information inaccessible). - Public APIs, previously stored in strings and/or list of strings, is now stored as a proper PubApi class - PubApiExtractor.java corresponds to what Fredrik called Compile.java in his verison of the patch - The javac_state file is larger than before. java.base has the largest state file and it's on 7 MB. Should writing/parsing of this file turn out to take considerable amount of time, I have a couple of ideas to trim it down. Link to web review: http://cr.openjdk.java.net/~alundblad/8054717 Link to bug report: http://bugs.openjdk.java.net/browse/JDK-8054717 -- Andreas Lundblad From bitterfoxc at gmail.com Thu Nov 27 02:29:04 2014 From: bitterfoxc at gmail.com (bitter_fox) Date: Thu, 27 Nov 2014 11:29:04 +0900 Subject: RFR: 8065988: Duplicated error messages for "no source file" in javac In-Reply-To: <54764582.7070109@oracle.com> References: <54762D86.10707@oracle.com> <54764582.7070109@oracle.com> Message-ID: Jonathan, Thank you for your review. Retry is here: http://cr.openjdk.java.net/~shinyafox/8065988/webrev.02/ Regards, Shinya Yoshida(@bitter_fox, shinyafox) 2014-11-27 6:26 GMT+09:00 Jonathan Gibbons : > Shinya, > > It would be better to just do the increment in the "case LOG:" case, when > the message is actually reported to the log. In the other two arms of the > switch statement, an exception is thrown instead of reporting anything to > the log. > > -- Jon > > > > On 11/26/2014 12:25 PM, bitter_fox wrote: > > Another fix is here: > http://cr.openjdk.java.net/~shinyafox/8065988/webrev.01/ > > increment log.nerrors in Argument#error. > > I don't know which is better, but it looks beautiful. > > > 2014-11-27 4:59 GMT+09:00 bitter_fox : > >> Hi, Jonathan. >> >> Because log.nerror is never incremented by printing "file not found" >> error. >> >> The error printed in Argument#error: >> case ILLEGAL_ARGUMENT: { >> String msg = log.localize(PrefixKind.JAVAC, key, args); >> throw new PropagatedException(new >> IllegalArgumentException(msg)); >> } >> >> It calls Log#localize, and it doesn't increment log.nerrors. >> >> So in this case, I think log.nerrors won't work well. >> >> Regards, >> Shinya Yoshida(@bitter_fox, shinyafox) >> >> >> 2014-11-27 4:44 GMT+09:00 Jonathan Gibbons : >> >>> On 11/26/2014 11:28 AM, bitter_fox wrote: >>> >>>> Hi, >>>> Please review my patch for 8065988. >>>> >>>> I couldn't write the test. >>>> Could you write the test for this issue? >>>> >>>> webrev is here: >>>> http://cr.openjdk.java.net/~shinyafox/8065988/webrev.00/ < >>>> http://cr.openjdk.java.net/%7Eshinyafox/8065988/webrev.00/> >>>> >>>> bugs is here: >>>> https://bugs.openjdk.java.net/browse/JDK-8065988 >>>> >>>> Regards, >>>> Shinya Yoshida(@bitter_fox, shinyafox) >>>> >>> >>> Shinya, >>> >>> I've read through your patch, but I'd be looking to understand why you >>> need to pass back and use a boolean result from Arguments.init rather than >>> use the existing mechanism of checking log.nerrors. >>> >>> -- Jon >>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Nov 27 02:47:55 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Nov 2014 18:47:55 -0800 Subject: RFR: 8065988: Duplicated error messages for "no source file" in javac In-Reply-To: References: <54762D86.10707@oracle.com> <54764582.7070109@oracle.com> Message-ID: <547690DB.1030108@oracle.com> Thank you. We're headed into a holiday weekend here in the US, so I may not get back to this before next week. -- Jon On 11/26/2014 06:29 PM, bitter_fox wrote: > Jonathan, > > Thank you for your review. > Retry is here: > http://cr.openjdk.java.net/~shinyafox/8065988/webrev.02/ > > > Regards, > Shinya Yoshida(@bitter_fox, shinyafox) > > > 2014-11-27 6:26 GMT+09:00 Jonathan Gibbons > >: > > Shinya, > > It would be better to just do the increment in the "case LOG:" > case, when the message is actually reported to the log. In the > other two arms of the switch statement, an exception is thrown > instead of reporting anything to the log. > > -- Jon > > > > On 11/26/2014 12:25 PM, bitter_fox wrote: >> Another fix is here: >> http://cr.openjdk.java.net/~shinyafox/8065988/webrev.01/ >> >> >> increment log.nerrors in Argument#error. >> >> I don't know which is better, but it looks beautiful. >> >> >> 2014-11-27 4:59 GMT+09:00 bitter_fox > >: >> >> Hi, Jonathan. >> >> Because log.nerror is never incremented by printing "file not >> found" error. >> >> The error printed in Argument#error: >> case ILLEGAL_ARGUMENT: { >> String msg = log.localize(PrefixKind.JAVAC, >> key, args); >> throw new PropagatedException(new >> IllegalArgumentException(msg)); >> } >> >> It calls Log#localize, and it doesn't increment log.nerrors. >> >> So in this case, I think log.nerrors won't work well. >> >> Regards, >> Shinya Yoshida(@bitter_fox, shinyafox) >> >> >> 2014-11-27 4:44 GMT+09:00 Jonathan Gibbons >> > >: >> >> On 11/26/2014 11:28 AM, bitter_fox wrote: >> >> Hi, >> Please review my patch for 8065988. >> >> I couldn't write the test. >> Could you write the test for this issue? >> >> webrev is here: >> http://cr.openjdk.java.net/~shinyafox/8065988/webrev.00/ >> >> >> >> bugs is here: >> https://bugs.openjdk.java.net/browse/JDK-8065988 >> >> Regards, >> Shinya Yoshida(@bitter_fox, shinyafox) >> >> >> Shinya, >> >> I've read through your patch, but I'd be looking to >> understand why you need to pass back and use a boolean >> result from Arguments.init rather than use the existing >> mechanism of checking log.nerrors. >> >> -- Jon >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Thu Nov 27 11:03:47 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 27 Nov 2014 12:03:47 +0100 Subject: RFR: 8066000: Sjavac TaskListeners should not provide empty implementations Message-ID: <20141127110346.GA17814@e6430> Hi compiler-dev, Please review this (trivial) fix for JDK-8066000. Description: Since JDK-8059591 the sjavac TaskListeners do no longer need to override the 'started' method. Link to web review: http://cr.openjdk.java.net/~alundblad/8066000 Link to bug reports: http://bugs.openjdk.java.net/browse/JDK-8066000 -- Andreas Lundblad From mdb at samskivert.com Tue Nov 18 17:02:52 2014 From: mdb at samskivert.com (Michael Bayne) Date: Tue, 18 Nov 2014 17:02:52 -0000 Subject: RFR: JDK-8062359: javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass In-Reply-To: <546B4B4C.2060802@oracle.com> References: <546B4B4C.2060802@oracle.com> Message-ID: On Tue, Nov 18, 2014 at 5:36 AM, Jan Lahoda wrote: > Is there a chance to get the actual javac options+list of files (in the > given order) that get passed to javac when the NPE happens? Might be > possible to reproduce with that? > I haven't been able to reproduce it from the command line, but attached is a standalone program that does the job. % javac -classpath /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/lib/tools.jar AttrNPE.java % java -classpath .:/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/lib/tools.jar AttrNPE [various missing class errors ommitted] Exception in thread "main" java.lang.NullPointerException at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitNewClass(Attr.java:4524) at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1516) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57) at com.sun.tools.javac.tree.TreeScanner.visitApply(TreeScanner.java:200) at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.tree.TreeScanner.visitReturn(TreeScanner.java:185) at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1384) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57) at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitBlock(Attr.java:4557) at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:909) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitMethodDef(Attr.java:4496) at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:778) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:4552) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:693) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.tree.TreeScanner.visitNewClass(TreeScanner.java:208) at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitNewClass(Attr.java:4529) at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1516) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:4505) at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:852) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:4552) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:693) at com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:4451) at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:4375) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4252) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4201) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4201) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4205) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4201) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4201) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4201) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4201) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4181) at com.sun.tools.javac.comp.Attr.visitClassDef(Attr.java:892) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:693) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:607) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:676) at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:4342) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4252) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4181) at com.sun.tools.javac.comp.Attr.attrib(Attr.java:4156) at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1248) at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1221) at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:364) at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:344) at AttrNPE.main(AttrNPE.java:38) -- mdb at samskivert.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AttrNPE.java Type: application/octet-stream Size: 1661 bytes Desc: not available URL: