From jonathan.gibbons at oracle.com Wed Oct 1 00:04:21 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 30 Sep 2014 17:04:21 -0700 Subject: Best way to get com.sun.source.doctree.DocTree? In-Reply-To: References: Message-ID: <542B4505.1050603@oracle.com> On 09/30/2014 04:06 PM, Harry Terkelsen wrote: > Hi compiler devs, > > I would like to use the DocTree API for JavaDoc comments but I don't > see any way to get a DocTree from a JavaDoc comment? > > Is there any way to simply parse a JavaDoc comment, given as a String, > along with the start and end positions in the original source, and get > back a DocTree with source positions properly set? In other words, is > it possible to write this method: > > DocTree parseDocTree(String comment, int pos, int endPos); > > If that is not possible, I see that I can go from TreePath -> > DocCommentTree with DocTrees#getDocCommentTree(TreePath) but I'm > assuming this is only for JavaDoc comments that are attached to > top-level program elements. Is this the only way to get DocTrees? > > Thanks! > Harry The only public supported method is the one you found, DocTrees#getDocCommentTree(TreePath) I'm not sure why you would want the method you are asking for (to parse an arbitrary string as a comment.) It would be somewhat more interesting to ask if there was a "comment" token that you could parse into a DocTree, and yes, that does exist inside javac, although it is not exposed publicly at this time. Look for DocCommentParser. -- Jon From jonathan.gibbons at oracle.com Wed Oct 1 00:57:25 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 30 Sep 2014 17:57:25 -0700 Subject: Javac Tree API suggestions to more closely model source code In-Reply-To: <542A9DAB.9090904@oracle.com> References: <542A9DAB.9090904@oracle.com> Message-ID: <542B5175.7060606@oracle.com> Harry, Jan, It is true that the AST as presented through the com.sun.source API does not fully represent the original input stream -- even allowing for the transformations that occur within the parser, such as noted in JDK-8024098. This is unlikely to change any time soon, and it is a standard response that some of the missing information can be inferred from other sources, like the original source text, or lexer tokens. But it is also true that the javac or the com.sun.source API does not provide anything in between source text and an AST. It would be interesting to explore what more could be provided in this general area. -- Jon On 09/30/2014 05:10 AM, Jan Lahoda wrote: > Hello Harry, > > Thanks for your feedback! > > On 30.9.2014 03:19, Harry Terkelsen wrote: >> Hi Javac compiler devs, >> >> I am writing a Java formatter that makes use of the com.sun.source.tree >> API as well as the Javac lexer. I see that there is some interest in >> making the AST more closely model the actual source code >> (https://bugs.openjdk.java.net/browse/JDK-8024098). My formatter only >> changes the whitespace in between tokens, and so must have a completely >> accurate view of the original source code. Since I've written a pretty >> large application with the Tree API that must have an accurate picture >> of the original code, I have compiled a list of difficulties I had with >> the AST/lexer: >> >> >> Bugs: >> The lexer com.sun.tools.javac.parser.JavaTokenizer has very useful >> protected methods processComment(), processWhitespace(), and >> processLineTerminator() which can be overridden for lexers that care >> about preserving comments and whitespace. However, none of these 3 >> useful methods are called immediately before the EOF. For example: >> >> class A {} //comment >> >> processComment() will not be called in this case (nor will >> processWhitespace() for the space before the comment). > > I see the processComment is not called when the (line) comment is the > very last token of the input, but processWhitespace() and > processLineTerminator() seem to be called? > > The processComment is skipped presumably to avoid unnecessary > processing, as the JavaTokenizer attaches the comments to the > following important token, and for comment at the very end of the > input there will never be a token to which it should be attached. I'll > investigate if this can be changed. > > Please note that JavaTokenizer is not a (supported/public) API. > >> >> Major pain points: >> The AST represents multivariable declarations ("int x, y;") as two >> separate variable declaration statements. This forced my to preprocess >> all statement lists, and combine consecutive variable declarations into >> one if SourcePositions#getStartPosition() was the same for the type node >> of the consecutive variable declarations. > > Yes, I believe this is a known problem. I've added a note into > JDK-8024098. > >> >> The ModifiersTree has pretty much no relationship to the original source >> code. Implicit non-annotation modifiers are added to the tree by the >> parser. Repeated modifiers are ignored. There is no way to tell the >> original order of the modifiers. For annotations, you know the original >> order they came in, but you don't know how they are interspersed with >> the modifiers. > > While I understand why you need this information, my personal > inclination would be that this should not be part of the AST as such, > but should ideally be inferred from other sources (lexer tokens). > >> >> Enum constants are desugared into variable declarations (with added >> implicit modifiers). Enum constants are represented as a VariableTree >> with the RHS being a NewClassTree, but you have to know which parts of >> the NewClassTree to pick out to reconstruct the original source of the >> enum constant. The only way to differentiate between an enum constant >> and an actual variable declaration inside the enum body is to cast to >> JCTree, which feels very hacky: >> JCVariableDecl v = (JCVariableDecl) node; >> return (v.mods.flags & ENUM) != 0; > > Yes, too early desugaring of enums is a known problem (see JDK-8024098). > >> >> Unary expressions involving literals are sometimes combined into just a >> literal, and sometimes they aren't. I haven't looked into this very >> deeply, but sometimes unary expressions with numeric literals will be >> represented as just a numeric literal, for instance "-1" will sometimes >> be UnaryTree and sometimes be LiteralTree. If it is LiteralTree the >> source position will be wrong, it will not include the "-". I guess this >> is to overcome the problem with -2147483648. > > Yes, -2147483648 is the problem. Sorry, but I don't expect that > - would be changed to an > UnaryTree+LiteralTree. I checked the positions for "int i = -1" (and a > few similar cases), and the positions seemed reasonable to me. Is > there a sample code where the positions are wrong? > >> >> >> Moderate pain points: >> Class, Enum, Interface, and annotation type declarations are all >> represented with ClassTree. Since the Kind is set for these it turns out >> not to be that big of a problem to disambiguate. > > Sorry, I don't expect this would be changed. The Kind is the correct > way to distinguish between the class, enum, interface and annotation > type. (As a side note, instanceof is not a reliable way to check the > actual type of the tree - Tree.Kind should be used to correctly detect > the nature of the given tree). > >> >> Cannot tell if an argument VariableTree is varargs. This required >> casting to JCTree, which feels hacky: >> JCModifiers mods = (JCModifiers) node.getModifiers(); >> return (mods.flags & VARARGS) != 0; >> >> >> Minor pain points (small concrete syntax things): > > Overall, I would incline to not including things like this in the AST > as such. Ideally, there would be a way to infer them from other sources. > >> No difference between @Annotation() and @Annotation > > Comparing the end positions of "@Annotation()" and "Annotation" may > allow to distinguish between "@Annotation()" and "@Annotation". > >> Cannot tell if there is a trailing comma in array literal >> Cannot tell if there is trailing comma or semicolon after enum constants >> Cannot tell where array brackets are on variable declarations: int[] x >> vs int x[], int[] foo() vs int foo()[] >> >> >> Hope this helps! > > Thanks! > > Jan > >> Harry From cushon at google.com Wed Oct 1 01:17:18 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 30 Sep 2014 18:17:18 -0700 Subject: crash with -Xjcov and union types In-Reply-To: References: Message-ID: Thanks Joel. I discovered this while using -Xjcov to force end positions to be collected. I realize there are better ways to do that, but it's probably still worth fixing. On Tue, Sep 30, 2014 at 1:38 AM, Joel Borggr?n-Franck < joel.franck at oracle.com> wrote: > Hi Liam, > > On 25 Sep 2014, at 23:57, Liam Miller-Cushon wrote: > > > I'm seeing crashes with -Xjcov enabled while compiling code with union > types. This seems to affect javac 7 through 9. I've attached a possible > fix, and a jtreg test for the crash. > > > > Repro: > > > > Thanks for the report and fix! I have filed > https://bugs.openjdk.java.net/browse/JDK-8059453 > > I don?t know enough about -Xjcov to review and commit your fix right now, > but I?ll try to make this happen soon. > > cheers > /Joel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Oct 1 01:35:05 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 30 Sep 2014 18:35:05 -0700 Subject: crash with -Xjcov and union types In-Reply-To: References: Message-ID: <542B5A49.2020000@oracle.com> What were you doing that required end positions, or more specifically, how were you doing it? Normally end positions get enabled when you start using javac API, so I'm surprised you needed to explore other means, like -Xjcov. That being said, I agree its worth fixing. -- Jon On 09/30/2014 06:17 PM, Liam Miller-Cushon wrote: > Thanks Joel. I discovered this while using -Xjcov to force end > positions to be collected. I realize there are better ways to do that, > but it's probably still worth fixing. > > On Tue, Sep 30, 2014 at 1:38 AM, Joel Borggr?n-Franck > > wrote: > > Hi Liam, > > On 25 Sep 2014, at 23:57, Liam Miller-Cushon > wrote: > > > I'm seeing crashes with -Xjcov enabled while compiling code with > union types. This seems to affect javac 7 through 9. I've attached > a possible fix, and a jtreg test for the crash. > > > > Repro: > > > > Thanks for the report and fix! I have filed > https://bugs.openjdk.java.net/browse/JDK-8059453 > > I don?t know enough about -Xjcov to review and commit your fix > right now, but I?ll try to make this happen soon. > > cheers > /Joel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Oct 1 01:58:29 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 30 Sep 2014 18:58:29 -0700 Subject: crash with -Xjcov and union types In-Reply-To: <542B5A49.2020000@oracle.com> References: <542B5A49.2020000@oracle.com> Message-ID: On Tue, Sep 30, 2014 at 6:35 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > What were you doing that required end positions, or more specifically, how > were you doing it? For historical reasons that code is bypassing the API. I'm planning to migrate it to the plug-in mechanism once we can drop javac 7 support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhs at edg.com Mon Oct 6 13:22:38 2014 From: jhs at edg.com (John Spicer) Date: Mon, 6 Oct 2014 09:22:38 -0400 Subject: Exact/inexact method reference difference Message-ID: <450AA02C-DCF4-4745-A5AF-AD758C8928D5@edg.com> I'm forwarding this question from a member of our development team. Thanks, John. Take this example: @FunctionalInterface interface I1 { void f(Integer i); } @FunctionalInterface interface I2 { void f(String s); } class Y { void m1(Integer i) {} void m2(Integer... i) {} } class X { void g(I1 i) {} void g(I2 i) {} void f(Y y) { g(y::m1); // Okay (exact method reference) g(y::m2); // Ambiguous (inexact method reference) } } What in the JLS is causing this difference? According to 15.12.2.1, when determining the list of "potentially applicable" methods for the method invocation(s) of g, one must consider whether there is "at least one potentially applicable method" for the method reference to be "potentially compatible". The first question is: according to the JLS, are both I1 and I2 "potentially compatible" with Y::m1 and Y::m2? If so, then in both the g(y::m1) and g(y::m2) method invocation cases, there will be two "potentially applicable" methods. 15.12.2.1 seems like it might benefit from some clarification in this area: - 15.12.2.1 was originally written for method invocations and talks about arguments to method invocations. 15.13.1 refers to 15.12.2.1 for the method reference case, and in that case, there are no arguments. - 15.12.2.1 lists the conditions for an expression to be "potentially compatible" with a target type, but that seems only relevant for poly expressions yet the term "potentially compatible" seems to be used for all expressions. Once the set of potentially applicable methods has been chosen, the inexact method reference is deemed not "pertinent to applicability" (15.12.2.2), so we end up with an ambiguous method invocation (which matches javac's behavior), but what about the exact method reference case? As part of 15.12.2.2, y::m1 is tested to see if it "is compatible in a strict invocation context" with both I1 and I2. That leads to 15.13.2, but that section doesn't seem to differentiate at all based on the parameters of I1::f and I2::f and their compatibility with Y::m1. Hence the second question: what states that I1::f is compatible with Y::m1 and I2::f isn't? From ryushi at gmail.com Sun Oct 5 10:57:12 2014 From: ryushi at gmail.com (taichi sato) Date: Sun, 5 Oct 2014 19:57:12 +0900 Subject: Possible Bug in javac resolving method references. Message-ID: Hi, I wrote code the below. https://gist.github.com/taichi/f676381bd148bd497106 javac says me below src\example\Main.java:13: error: reference to of is ambiguous Consumers.of(Main::exec); ^ both method of(OutputStreamConsumer) in Consumers and method of(WriterConsumer) in Consumers match src\example\Main.java:13: error: method of in interface Consumers cannot be applied to given types; Consumers.of(Main::exec); ^ required: OutputStreamConsumer found: Main::exec reason: argument mismatch; invalid method reference no suitable method found for exec(Object,OutputStream) method Main.exec(Object) is not applicable (actual and formal argument lists differ in length) method Main.exec(Object,Appendable) is not applicable (argument mismatch; OutputStream cannot be converted to Appendable) 2 errors i think this is bug because eclipse jdt compiler can compile the code and * first exec method has return type and one argument, OutputStreamConsumer and WriterConsumer require 2 argument and no return value so this is not ambiguous. i think compiler should pick a second exec method. * OutputStreamConsumer receives OutputStream, not Appendable. so compiler should pick WriterConsumer my envrionment is below * javac 1.8.0_20 * eclipse 4.4.0 thanks Taichi -------------- next part -------------- An HTML attachment was scrubbed... URL: From dawid.weiss at gmail.com Tue Oct 7 07:21:54 2014 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Tue, 7 Oct 2014 09:21:54 +0200 Subject: Backport of the "missing clinit attribute" javac error to 1.7? Message-ID: Hello compiler folks! I've encountered the (known and resolved in 1.8) problem with javac failing on annotations with static final fields requiring complex initialization. The failure manifests itself on the latest 1.7 with (edited): [ERROR] /.../MyClass.java:[186,17] annotation foo.MyAnnotation is missing value for the attribute This seems to be: https://bugs.openjdk.java.net/browse/JDK-8013485 Are there any chances of backporting this patch to 1.7? ECJ compiles such code without a glitch and so does 1.8 javac, of course. Dawid From javac at benjiweber.co.uk Wed Oct 8 14:58:00 2014 From: javac at benjiweber.co.uk (Benji Weber) Date: Wed, 8 Oct 2014 15:58:00 +0100 Subject: Javac NPE Message-ID: Hi All, There is an NPE in javac (8u20) that I am running into regularly. It's quite a pain because it takes a considerable amount of time to track down the offending code each time it occurs. I filed a bug report with a simple test case, but after a few weeks in the aether it appeared in JIRA as closed - not an issue. Any ideas why? https://bugs.openjdk.java.net/browse/JDK-8059511 The comments suggest it is related to this other bug https://bugs.openjdk.java.net/browse/JDK-8058921 - which was closed due to lack of a test case, but I provided a short and complete testcase with my report. Do you think it is indeed a bug? How can I progress this now? I can't see a way of creating a JIRA login to comment on the issues. Is it only open to Oracle employees? Many Thanks -- benji -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Oct 8 18:03:28 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 8 Oct 2014 11:03:28 -0700 Subject: AssertionError during LVT generation with javac 8u20 Message-ID: It looks like the fix for JDK-8037937 introduced a different LVT-related AssertionError. The crash bisects down to http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/372fd7283bf0 Repro: === Test.java === public class Test { void m(Object[] xs) { { Object[] ys; int i; for (Object x : xs) { } if (xs != null) { i = 0; } } } } === $ javac -g Test.java An exception has occurred in the compiler (1.8.0_20). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.AssertionError at com.sun.tools.javac.util.Assert.error(Assert.java:126) at com.sun.tools.javac.util.Assert.check(Assert.java:45) at com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1189) at com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1110) at com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1602) at com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1692) at com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1620) at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:746) at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1572) at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1536) at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Oct 8 21:01:33 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 08 Oct 2014 14:01:33 -0700 Subject: AssertionError during LVT generation with javac 8u20 In-Reply-To: References: Message-ID: <5435A62D.4050303@oracle.com> Hi Liam, Thanks for your mail and for the reduced test case. The issue you are reporting has already been fixed in JDK 9 [1] and JDK 8udev [2]. This was targeted by the fix for bug [3] also backported into 8udev see [4]. The corresponding changeset can be found at [5]. Thanks, Vicente [1] http://hg.openjdk.java.net/jdk9/dev/ [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ [3] https://bugs.openjdk.java.net/browse/JDK-8047719 [4] https://bugs.openjdk.java.net/browse/JDK-8048587 [5] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb On 10/08/2014 11:03 AM, Liam Miller-Cushon wrote: > It looks like the fix for JDK-8037937 introduced a different > LVT-related AssertionError. The crash bisects down to > http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/372fd7283bf0 > > Repro: > > === Test.java === > public class Test { > void m(Object[] xs) { > { > Object[] ys; > int i; > > for (Object x : xs) { > } > > if (xs != null) { > i = 0; > } > } > } > } > === > > $ javac -g Test.java > An exception has occurred in the compiler (1.8.0_20). Please file a > bug at the Java Developer Connection > (http://java.sun.com/webapps/bugreport) after checking the Bug Parade > for duplicates. Include your program and the following diagnostic in > your report. Thank you. > java.lang.AssertionError > at com.sun.tools.javac.util.Assert.error(Assert.java:126) > at com.sun.tools.javac.util.Assert.check(Assert.java:45) > at com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1189) > at com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1110) > at com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1602) > at > com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1692) > at com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1620) > at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:746) > at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1572) > at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1536) > at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:56) > at com.sun.tools.javac.Main.main(Main.java:42) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Wed Oct 8 22:58:20 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 8 Oct 2014 16:58:20 -0600 Subject: Possible Bug in javac resolving method references. In-Reply-To: References: Message-ID: <6490FDB8-7D27-4E29-8D33-DB0E78773AA7@oracle.com> I think javac is behaving correctly. To clarify what's going on, there are two methods that must be resolved: 'of' and 'exec'. Since the target type of 'Main::exec' can, in general, influence the resolution of 'exec', the compiler must resolve 'of' _first_. The resolution of 'of' is allowed to use a little bit of readily-available information about 'Main::exec', but not much. Specifically, 'Main::exec' is categorized as an "inexact" method reference, because it is overloaded (JLS 15.13.1). For simplicity, all inexact method references are treated the same when they appear as arguments to another method: an 'of' candidate is "potentially-applicable" if the method reference is "potentially compatible with" a targeted functional interface type (15.12.2.1). After that, the argument is not considered "pertinent to applicability", so no further checking is done prior to overload resolution (15.12.2.2). Putting it simply, the types appearing in the signature of the 'exec' methods are irrelevant to the resolution of 'Consumers.of'. So: Is 'Main::exec' potentially compatible with WriterConsumer? Yes, WriterConsumer has 2 arguments, and a Main.exec method exists that takes 2 arguments. Is 'Main::exec' potentially compatible with OutputStreamConsumer? Yes, OutputStreamConsumer has 2 arguments, and a Main.exec method exists that takes 2 arguments. Are 'Consumers.of(OutputStreamConsumer)' and 'Consumers.of(WriterConsumer)' potentially-applicable? Yes. Are both methods applicable? Again, yes, because there are no arguments that we can type-check during overload resolution. Hence, ambiguity error. One can imagine a world in which a method reference is "exact" if the named method is overloaded, but all candidate target types (OutputStreamConsumer, WriterConsumer) have the same arity, corresponding to only one referenced method ('Main.exec(Object,Appendable)'). And if the method reference were exact, its types could be used for disambiguation. But this is not the way it was specified (and is more complex then we'd like, even if it might more closely match a reader's intuition). The second error ("cannot be applied") is unhelpful, and might be a problem with javac's error reporting, if somebody wants to investigate that. ?Dan On Oct 5, 2014, at 4:57 AM, taichi sato wrote: > Hi, I wrote code the below. > > https://gist.github.com/taichi/f676381bd148bd497106 > > javac says me below > > src\example\Main.java:13: error: reference to of is ambiguous > Consumers.of(Main::exec); > ^ > both method of(OutputStreamConsumer) in Consumers and method of(WriterConsumer) in Consumers match > src\example\Main.java:13: error: method of in interface Consumers cannot be applied to given types; > Consumers.of(Main::exec); > ^ > required: OutputStreamConsumer > found: Main::exec > reason: argument mismatch; invalid method reference > no suitable method found for exec(Object,OutputStream) > method Main.exec(Object) is not applicable > (actual and formal argument lists differ in length) > method Main.exec(Object,Appendable) is not applicable > (argument mismatch; OutputStream cannot be converted to Appendable) > 2 errors > > i think this is bug because eclipse jdt compiler can compile the code and > > * first exec method has return type and one argument, > OutputStreamConsumer and WriterConsumer require 2 argument and no return value > so this is not ambiguous. i think compiler should pick a second exec method. > * OutputStreamConsumer receives OutputStream, not Appendable. > so compiler should pick WriterConsumer > > my envrionment is below > > * javac 1.8.0_20 > * eclipse 4.4.0 > > thanks > > Taichi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu Oct 9 00:55:38 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 8 Oct 2014 17:55:38 -0700 Subject: AssertionError during LVT generation with javac 8u20 In-Reply-To: <5435A62D.4050303@oracle.com> References: <5435A62D.4050303@oracle.com> Message-ID: Thanks Vicente, I meant to test against JDK 9 but clearly did not. Sorry for the duplicate. It turns out that I actually ran into JDK-8058708, and while trying to make a smaller test case I produced a repro for JDK-8047719 instead. This patch fixed the issue we were seeing: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/rev/31d2a837676f On Wed, Oct 8, 2014 at 2:01 PM, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > Hi Liam, > > Thanks for your mail and for the reduced test case. The issue you are > reporting has already been fixed in JDK 9 [1] and JDK 8udev [2]. This was > targeted by the fix for bug [3] also backported into 8udev see [4]. The > corresponding changeset can be found at [5]. > > Thanks, > Vicente > > [1] http://hg.openjdk.java.net/jdk9/dev/ > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ > [3] https://bugs.openjdk.java.net/browse/JDK-8047719 > [4] https://bugs.openjdk.java.net/browse/JDK-8048587 > [5] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb > > > On 10/08/2014 11:03 AM, Liam Miller-Cushon wrote: > > It looks like the fix for JDK-8037937 introduced a different LVT-related > AssertionError. The crash bisects down to > http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/372fd7283bf0 > > Repro: > > === Test.java === > public class Test { > void m(Object[] xs) { > { > Object[] ys; > int i; > > for (Object x : xs) { > } > > if (xs != null) { > i = 0; > } > } > } > } > === > > $ javac -g Test.java > An exception has occurred in the compiler (1.8.0_20). Please file a bug at > the Java Developer Connection (http://java.sun.com/webapps/bugreport) > after checking the Bug Parade for duplicates. Include your program and the > following diagnostic in your report. Thank you. > java.lang.AssertionError > at com.sun.tools.javac.util.Assert.error(Assert.java:126) > at com.sun.tools.javac.util.Assert.check(Assert.java:45) > at com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1189) > at com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1110) > at > com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1602) > at > com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1692) > at com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1620) > at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:746) > at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1572) > at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1536) > at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:56) > at com.sun.tools.javac.Main.main(Main.java:42) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Oct 9 01:14:04 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 08 Oct 2014 18:14:04 -0700 Subject: AssertionError during LVT generation with javac 8u20 In-Reply-To: References: <5435A62D.4050303@oracle.com> Message-ID: <5435E15C.4050804@oracle.com> Hi Liam, On 10/08/2014 05:55 PM, Liam Miller-Cushon wrote: > Thanks Vicente, I meant to test against JDK 9 but clearly did not. > Sorry for the duplicate. np > > It turns out that I actually ran into JDK-8058708, and while trying to > make a smaller test case I produced a repro for JDK-8047719 instead. > This patch fixed the issue we were seeing: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/rev/31d2a837676f Some background on LVT generation bugs: Actually there have been some LVT generation bugs lately. Most of them corner cases that may appear in large projects, at least this is my feeling. We have tried to detect, and create regression tests, for most of these special cases. We have left assertions for those that may leak, even when this might provoke a crash but anyway a wrong LVT will provoke a crash sooner or later. So we really appreciate LVT generation bug reports, as in other areas of course. Thanks, Vicente > > On Wed, Oct 8, 2014 at 2:01 PM, Vicente-Arturo Romero-Zaldivar > > wrote: > > Hi Liam, > > Thanks for your mail and for the reduced test case. The issue you > are reporting has already been fixed in JDK 9 [1] and JDK 8udev > [2]. This was targeted by the fix for bug [3] also backported into > 8udev see [4]. The corresponding changeset can be found at [5]. > > Thanks, > Vicente > > [1] http://hg.openjdk.java.net/jdk9/dev/ > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ > [3] https://bugs.openjdk.java.net/browse/JDK-8047719 > [4] https://bugs.openjdk.java.net/browse/JDK-8048587 > [5] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb > > > On 10/08/2014 11:03 AM, Liam Miller-Cushon wrote: >> It looks like the fix for JDK-8037937 introduced a different >> LVT-related AssertionError. The crash bisects down to >> http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/372fd7283bf0 >> >> Repro: >> >> === Test.java === >> public class Test { >> void m(Object[] xs) { >> { >> Object[] ys; >> int i; >> >> for (Object x : xs) { >> } >> >> if (xs != null) { >> i = 0; >> } >> } >> } >> } >> === >> >> $ javac -g Test.java >> An exception has occurred in the compiler (1.8.0_20). Please file >> a bug at the Java Developer Connection >> (http://java.sun.com/webapps/bugreport) after checking the Bug >> Parade for duplicates. Include your program and the following >> diagnostic in your report. Thank you. >> java.lang.AssertionError >> at com.sun.tools.javac.util.Assert.error(Assert.java:126) >> at com.sun.tools.javac.util.Assert.check(Assert.java:45) >> at >> com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1189) >> at >> com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1110) >> at >> com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1602) >> at >> com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1692) >> at >> com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1620) >> at >> com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:746) >> at >> com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1572) >> at >> com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1536) >> at >> com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901) >> at >> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) >> at com.sun.tools.javac.main.Main.compile(Main.java:523) >> at com.sun.tools.javac.main.Main.compile(Main.java:381) >> at com.sun.tools.javac.main.Main.compile(Main.java:370) >> at com.sun.tools.javac.main.Main.compile(Main.java:361) >> at com.sun.tools.javac.Main.compile(Main.java:56) >> at com.sun.tools.javac.Main.main(Main.java:42) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu Oct 9 03:25:15 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 8 Oct 2014 20:25:15 -0700 Subject: AssertionError during LVT generation with javac 8u20 In-Reply-To: <5435E15C.4050804@oracle.com> References: <5435A62D.4050303@oracle.com> <5435E15C.4050804@oracle.com> Message-ID: Thanks for the background. Leaving assertions and failing fast sounds good to me. I'll be sure to pass along any more issues we see (after confirming you haven't fixed them already, of course.) Liam On Wed, Oct 8, 2014 at 6:14 PM, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > Hi Liam, > > On 10/08/2014 05:55 PM, Liam Miller-Cushon wrote: > > Thanks Vicente, I meant to test against JDK 9 but clearly did not. Sorry > for the duplicate. > > > np > > > It turns out that I actually ran into JDK-8058708, and while trying to > make a smaller test case I produced a repro for JDK-8047719 instead. This > patch fixed the issue we were seeing: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/rev/31d2a837676f > > > Some background on LVT generation bugs: > > Actually there have been some LVT generation bugs lately. Most of them > corner cases that may appear in large projects, at least this is my > feeling. We have tried to detect, and create regression tests, for most of > these special cases. We have left assertions for those that may leak, even > when this might provoke a crash but anyway a wrong LVT will provoke a crash > sooner or later. So we really appreciate LVT generation bug reports, as in > other areas of course. > > Thanks, > Vicente > > > > On Wed, Oct 8, 2014 at 2:01 PM, Vicente-Arturo Romero-Zaldivar < > vicente.romero at oracle.com> wrote: > >> Hi Liam, >> >> Thanks for your mail and for the reduced test case. The issue you are >> reporting has already been fixed in JDK 9 [1] and JDK 8udev [2]. This was >> targeted by the fix for bug [3] also backported into 8udev see [4]. The >> corresponding changeset can be found at [5]. >> >> Thanks, >> Vicente >> >> [1] http://hg.openjdk.java.net/jdk9/dev/ >> [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8047719 >> [4] https://bugs.openjdk.java.net/browse/JDK-8048587 >> [5] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb >> >> >> On 10/08/2014 11:03 AM, Liam Miller-Cushon wrote: >> >> It looks like the fix for JDK-8037937 introduced a different LVT-related >> AssertionError. The crash bisects down to >> http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/372fd7283bf0 >> >> Repro: >> >> === Test.java === >> public class Test { >> void m(Object[] xs) { >> { >> Object[] ys; >> int i; >> >> for (Object x : xs) { >> } >> >> if (xs != null) { >> i = 0; >> } >> } >> } >> } >> === >> >> $ javac -g Test.java >> An exception has occurred in the compiler (1.8.0_20). Please file a bug >> at the Java Developer Connection (http://java.sun.com/webapps/bugreport) >> after checking the Bug Parade for duplicates. Include your program and the >> following diagnostic in your report. Thank you. >> java.lang.AssertionError >> at com.sun.tools.javac.util.Assert.error(Assert.java:126) >> at com.sun.tools.javac.util.Assert.check(Assert.java:45) >> at com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1189) >> at >> com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1110) >> at >> com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1602) >> at >> com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1692) >> at com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1620) >> at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:746) >> at >> com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1572) >> at >> com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1536) >> at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901) >> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) >> at com.sun.tools.javac.main.Main.compile(Main.java:523) >> at com.sun.tools.javac.main.Main.compile(Main.java:381) >> at com.sun.tools.javac.main.Main.compile(Main.java:370) >> at com.sun.tools.javac.main.Main.compile(Main.java:361) >> at com.sun.tools.javac.Main.compile(Main.java:56) >> at com.sun.tools.javac.Main.main(Main.java:42) >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Oct 9 17:18:51 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 09 Oct 2014 10:18:51 -0700 Subject: AssertionError during LVT generation with javac 8u20 In-Reply-To: References: <5435A62D.4050303@oracle.com> <5435E15C.4050804@oracle.com> Message-ID: <5436C37B.7070208@oracle.com> On 10/08/2014 08:25 PM, Liam Miller-Cushon wrote: > Thanks for the background. Leaving assertions and failing fast sounds > good to me. I'll be sure to pass along any more issues we see (after > confirming you haven't fixed them already, of course.) Thanks in advance! Vicente > > Liam > > On Wed, Oct 8, 2014 at 6:14 PM, Vicente-Arturo Romero-Zaldivar > > wrote: > > Hi Liam, > > On 10/08/2014 05:55 PM, Liam Miller-Cushon wrote: >> Thanks Vicente, I meant to test against JDK 9 but clearly did >> not. Sorry for the duplicate. > > np > >> >> It turns out that I actually ran into JDK-8058708, and while >> trying to make a smaller test case I produced a repro for >> JDK-8047719 instead. This patch fixed the issue we were seeing: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/rev/31d2a837676f > > Some background on LVT generation bugs: > > Actually there have been some LVT generation bugs lately. Most of > them corner cases that may appear in large projects, at least this > is my feeling. We have tried to detect, and create regression > tests, for most of these special cases. We have left assertions > for those that may leak, even when this might provoke a crash but > anyway a wrong LVT will provoke a crash sooner or later. So we > really appreciate LVT generation bug reports, as in other areas of > course. > > Thanks, > Vicente > > >> >> On Wed, Oct 8, 2014 at 2:01 PM, Vicente-Arturo Romero-Zaldivar >> > wrote: >> >> Hi Liam, >> >> Thanks for your mail and for the reduced test case. The issue >> you are reporting has already been fixed in JDK 9 [1] and JDK >> 8udev [2]. This was targeted by the fix for bug [3] also >> backported into 8udev see [4]. The corresponding changeset >> can be found at [5]. >> >> Thanks, >> Vicente >> >> [1] http://hg.openjdk.java.net/jdk9/dev/ >> [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8047719 >> [4] https://bugs.openjdk.java.net/browse/JDK-8048587 >> [5] >> http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb >> >> >> On 10/08/2014 11:03 AM, Liam Miller-Cushon wrote: >>> It looks like the fix for JDK-8037937 introduced a different >>> LVT-related AssertionError. The crash bisects down to >>> http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/372fd7283bf0 >>> >>> >>> Repro: >>> >>> === Test.java === >>> public class Test { >>> void m(Object[] xs) { >>> { >>> Object[] ys; >>> int i; >>> >>> for (Object x : xs) { >>> } >>> >>> if (xs != null) { >>> i = 0; >>> } >>> } >>> } >>> } >>> === >>> >>> $ javac -g Test.java >>> An exception has occurred in the compiler (1.8.0_20). Please >>> file a bug at the Java Developer Connection >>> (http://java.sun.com/webapps/bugreport) after checking the >>> Bug Parade for duplicates. Include your program and the >>> following diagnostic in your report. Thank you. >>> java.lang.AssertionError >>> at com.sun.tools.javac.util.Assert.error(Assert.java:126) >>> at com.sun.tools.javac.util.Assert.check(Assert.java:45) >>> at >>> com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1189) >>> at >>> com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1110) >>> at >>> com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1602) >>> at >>> com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1692) >>> at >>> com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1620) >>> at >>> com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:746) >>> at >>> com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1572) >>> at >>> com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1536) >>> at >>> com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901) >>> at >>> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) >>> at com.sun.tools.javac.main.Main.compile(Main.java:523) >>> at com.sun.tools.javac.main.Main.compile(Main.java:381) >>> at com.sun.tools.javac.main.Main.compile(Main.java:370) >>> at com.sun.tools.javac.main.Main.compile(Main.java:361) >>> at com.sun.tools.javac.Main.compile(Main.java:56) >>> at com.sun.tools.javac.Main.main(Main.java:42) >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Oct 14 00:46:26 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 Oct 2014 17:46:26 -0700 Subject: Fwd: Unable to compile code using generics under 8u20 but builds under 8u05 In-Reply-To: References: Message-ID: <543C7262.4060104@oracle.com> -------- Forwarded Message -------- Subject: Unable to compile code using generics under 8u20 but builds under 8u05 Date: Mon, 13 Oct 2014 13:47:31 +0100 From: Will May To: jdk8u-dev at openjdk.java.net Hi all, I've got a piece of code which will compile fine on JDK 8u05 but fails to compile [1] on JDK 8u20; a minimal test case is at the bottom of this email. I know that there were changes around generic wildcards in 8u20 but does anyone know if 8u05 is bugged and it has been fixed or if 8u20 is now bugged? For reference, the two bugs that I found were fixed around generic wildcards were 8042338 [2] and 8042803 [3]. Cheers, Will. 1 The error message is "incompatible types: java.util.function.Consumer cannot be converted to java.util.function.Consumer" 2 https://bugs.openjdk.java.net/browse/JDK-8042338 3 https://bugs.openjdk.java.net/browse/JDK-8042803 import java.util.List; import java.util.function.Consumer; public class Temp { public void doWithList(final List list) { list.stream().forEach(consumer(System.out::println)); } @FunctionalInterface public static interface ExceptionThrowingConsumer { void accept(T input) throws Exception; } public static Consumer consumer(ExceptionThrowingConsumer consumer) { return i -> { try { consumer.accept(i); } catch (Exception e) { throw new RuntimeException(e); } }; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Oct 14 09:44:14 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 14 Oct 2014 10:44:14 +0100 Subject: Fwd: Unable to compile code using generics under 8u20 but builds under 8u05 In-Reply-To: <543C7262.4060104@oracle.com> References: <543C7262.4060104@oracle.com> Message-ID: <543CF06E.9070301@oracle.com> Hi, we know about this regression - this problem has been exposed by the following (correct) fix: https://bugs.openjdk.java.net/browse/JDK-8044546 which uncovered an underlying unsoundness during wildcards containment test. We made several attempts at fixing the issue, but in the end we deemed the full fix too risky for 8. Vicente has worked around the problem in 8u40: https://bugs.openjdk.java.net/browse/JDK-8051402 I can confirm that the code in the example compiles fine with the 8u40 compiler. Thanks Maurizio On 14/10/14 01:46, Jonathan Gibbons wrote: > > > > -------- Forwarded Message -------- > Subject: Unable to compile code using generics under 8u20 but builds > under 8u05 > Date: Mon, 13 Oct 2014 13:47:31 +0100 > From: Will May > To: jdk8u-dev at openjdk.java.net > > > > Hi all, > > I've got a piece of code which will compile fine on JDK 8u05 but fails to > compile [1] on JDK 8u20; a minimal test case is at the bottom of this email. > > I know that there were changes around generic wildcards in 8u20 but does > anyone know if 8u05 is bugged and it has been fixed or if 8u20 is now > bugged? > > For reference, the two bugs that I found were fixed around generic > wildcards were 8042338 [2] and 8042803 [3]. > > Cheers, > > Will. > > 1 The error message is "incompatible types: > java.util.function.Consumer cannot be converted to > java.util.function.Consumer" > 2https://bugs.openjdk.java.net/browse/JDK-8042338 > 3https://bugs.openjdk.java.net/browse/JDK-8042803 > > import java.util.List; > import java.util.function.Consumer; > > public class Temp { > > public void doWithList(final List list) { > list.stream().forEach(consumer(System.out::println)); > } > > @FunctionalInterface > public static interface ExceptionThrowingConsumer { > void accept(T input) throws Exception; > } > > public static Consumer consumer(ExceptionThrowingConsumer > consumer) { > return i -> { > try { > consumer.accept(i); > } catch (Exception e) { > throw new RuntimeException(e); > } > }; > } > > } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Wed Oct 15 12:59:24 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 15 Oct 2014 14:59:24 +0200 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way Message-ID: <20141015125923.GB5897@e6430> Hi compiler-dev, Please review this patch which addresses JDK-8042088. - Description: This patch is a refactoring and cleanup of the code that spawns the external process for running the sjavac server. Since the fix of JDK-8048457 a server is never spawned as a separate thread. (background=false -> Direct use of SjavacImpl, background=true -> Server in separate JVM). This patch removes the (now dead) code that spawns the server in a thread. The patch also fixes a small race condition in PortFile. Tested: - All langtool tests pass - make images runs without errors - Giving a bad launch command (sjavac=...) results in correct error message - Bad server executable (that never writes values to the port file) results in correct error message - Link to webrev: http://cr.openjdk.java.net/~alundblad/8042088/webrev.02/ - Links to bug report: https://bugs.openjdk.java.net/browse/JDK-8042088 -- Andreas From mark.reinhold at oracle.com Thu Oct 16 00:32:49 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 15 Oct 2014 17:32:49 -0700 (PDT) Subject: JEP 211: Elide Deprecation Warnings on Import Statements Message-ID: <20141016003249.4DED93DE3F@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/211 - Mark From mark.reinhold at oracle.com Thu Oct 16 00:55:26 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 15 Oct 2014 17:55:26 -0700 (PDT) Subject: JEP 213: Milling Project Coin Message-ID: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/213 - Mark From the.rob.leland at gmail.com Thu Oct 16 01:05:43 2014 From: the.rob.leland at gmail.com (Rob Leland) Date: Wed, 15 Oct 2014 21:05:43 -0400 Subject: JEP 213: Milling Project Coin In-Reply-To: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> References: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> Message-ID: Is there a JDK issue filed somewhere that discusses #4 Remove underscore .... Since its sure to draw some push back. All other issues have such a reference. On Oct 15, 2014 8:56 PM, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/213 > > - Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benji at benjiweber.co.uk Wed Oct 8 11:47:57 2014 From: benji at benjiweber.co.uk (Benji Weber) Date: Wed, 8 Oct 2014 12:47:57 +0100 Subject: Javac NPE Message-ID: Hi All, There is an NPE in javac (8u20) that I am running into regularly. It's quite a pain because it takes a considerable amount of time to track down the offending code each time it occurs. I filed a bug report with a simple test case, but after a few weeks in the aether it appeared in JIRA as closed - not an issue. Any ideas why? https://bugs.openjdk.java.net/browse/JDK-8059511 The comments suggest it is related to this other bug https://bugs.openjdk.java.net/browse/JDK-8058921 - which was closed due to lack of a test case, but I provided a short and complete testcase with my report. Do you think it is indeed a bug? How can I progress this now? I can't see a way of creating a JIRA login to comment on the issues. Is it only open to Oracle employees? Many Thanks -- benji -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Thu Oct 16 01:31:52 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Oct 2014 20:31:52 -0500 Subject: JEP 213: Milling Project Coin In-Reply-To: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> References: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> Message-ID: <543F2008.8000300@redhat.com> On 10/15/2014 07:55 PM, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/213 I've said it before and I'll say it again. Removing _ is a bad idea. There are several frameworks which already use it for its brevity; it (along with $) represents one of only two single-character symbol identifiers available without venturing into Unicode. If a special identifier is required for some purpose, why not introduce #? -- - DML From fweimer at redhat.com Thu Oct 16 08:44:47 2014 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 16 Oct 2014 10:44:47 +0200 Subject: JEP 211: Elide Deprecation Warnings on Import Statements In-Reply-To: <20141016003249.4DED93DE3F@eggemoggin.niobe.net> References: <20141016003249.4DED93DE3F@eggemoggin.niobe.net> Message-ID: <543F857F.9050008@redhat.com> On 10/16/2014 02:32 AM, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/211 Would it make sense to suppress then warning on an import statement only if (a) there are uses of this import statement and (b) all these uses are annotated with @Deprecated? Or is this too complicated and we should rely on the existing unused-import warning? -- Florian Weimer / Red Hat Product Security From scolebourne at joda.org Thu Oct 16 10:17:40 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 16 Oct 2014 11:17:40 +0100 Subject: JEP 213: Milling Project Coin In-Reply-To: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> References: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> Message-ID: Just to note that given the underscore removal is listed here (a Java 8 change, not a coin one), it seems fair to ask what has happened to two other descoped items from Java 8 - "package" as an explicit scope, and private methods in interfaces. Stephen On 16 October 2014 01:55, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/213 > > - Mark From joe.darcy at oracle.com Thu Oct 16 16:27:42 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Oct 2014 09:27:42 -0700 Subject: JEP 211: Elide Deprecation Warnings on Import Statements In-Reply-To: <543F857F.9050008@redhat.com> References: <20141016003249.4DED93DE3F@eggemoggin.niobe.net> <543F857F.9050008@redhat.com> Message-ID: <543FF1FE.5010106@oracle.com> On 10/16/2014 1:44 AM, Florian Weimer wrote: > On 10/16/2014 02:32 AM, mark.reinhold at oracle.com wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/211 > > Would it make sense to suppress then warning on an import statement > only if (a) there are uses of this import statement and (b) all these > uses are annotated with @Deprecated? > > Or is this too complicated and we should rely on the existing > unused-import warning? > I believe relying on existing unused imports warnings is sufficient in this case. Cheers, -Joe From mark.reinhold at oracle.com Thu Oct 16 16:44:43 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Oct 2014 09:44:43 -0700 (PDT) Subject: JEP 215: Tiered Attribution for javac Message-ID: <20141016164443.8ACF33E297@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/215 - Mark From mark.reinhold at oracle.com Thu Oct 16 17:20:19 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Oct 2014 10:20:19 -0700 (PDT) Subject: JEP 216: Process Import Statements Correctly Message-ID: <20141016172019.EC62A3E2AA@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/216 - Mark From eaftan at google.com Thu Oct 16 17:32:02 2014 From: eaftan at google.com (Eddie Aftandilian) Date: Thu, 16 Oct 2014 10:32:02 -0700 Subject: JEP 216: Process Import Statements Correctly In-Reply-To: <20141016172019.EC62A3E2AA@eggemoggin.niobe.net> References: <20141016172019.EC62A3E2AA@eggemoggin.niobe.net> Message-ID: FWIW, at Google we get a bug report for this roughly once a month. It would be great to have it fixed. On Thu, Oct 16, 2014 at 10:20 AM, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/216 > > - Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Oct 16 22:03:39 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Oct 2014 15:03:39 -0700 (PDT) Subject: JEP 217: Annotations Pipeline 2.0 Message-ID: <20141016220339.8C2853E373@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/217 - Mark From paul.sandoz at oracle.com Fri Oct 17 09:37:08 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 17 Oct 2014 11:37:08 +0200 Subject: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> Message-ID: <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Hi, [Including compiler-dev, i am not on that list so please CC me if replying to just that list] I dropped this, then JVMLS got in the way... then J1 got in the way.... so i better get to this before Devoxx gets in the way... Richard, thanks for your continued patience. In the interim Richard made a slight tweak to the patch and some tests were updated to avoid casts: http://cr.openjdk.java.net/~rwarburton/buffer-overrides-3/ This looks good. Reviewed! BUT in the interim some warnings were enabled and now javac fails to compile: /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/util/BaseFileManager.java:245: warning: [cast] redundant cast to CharBuffer return (CharBuffer)CharBuffer.allocate(1).flip(); ^ /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/util/BaseFileManager.java:329: warning: [cast] redundant cast to ByteBuffer put((ByteBuffer)result.flip()); ^ /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/util/BaseFileManager.java:336: warning: [cast] redundant cast to ByteBuffer return (ByteBuffer)result.flip(); ^ /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/util/BaseFileManager.java:352: warning: [cast] redundant cast to ByteBuffer ? (ByteBuffer)cached.clear() ^ /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java:81: warning: [cast] redundant cast to CharBuffer return ((CharBuffer)buffer.compact().flip()).array(); ^ error: warnings found and -Werror specified So Richard has a patch for that too: http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch This is required because in the bootstrap compilation phase a JDK without the co-variant overrides can be used. So the current solution is to suppress the warnings. Reviews from langtools gurus are very much appreciated. Ideally it would be nice to push all this under one issue, is that possible? If not i will have to create another issue and of course push to langtools before jdk. A internal CCC is also underway. Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Alan.Bateman at oracle.com Fri Oct 17 09:56:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Oct 2014 10:56:00 +0100 Subject: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Message-ID: <5440E7B0.6040706@oracle.com> On 17/10/2014 10:37, Paul Sandoz wrote: > Hi, > > [Including compiler-dev, i am not on that list so please CC me if replying to just that list] > > I dropped this, then JVMLS got in the way... then J1 got in the way.... so i better get to this before Devoxx gets in the way... Richard, thanks for your continued patience. > > In the interim Richard made a slight tweak to the patch and some tests were updated to avoid casts: > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-3/ > > This looks good. Reviewed! I've previously reviewed the changes the buffer changes and it looked good. The additional updates to drop casts in usages and tests also looks good. -Alan From eaftan at google.com Fri Oct 17 17:35:21 2014 From: eaftan at google.com (Eddie Aftandilian) Date: Fri, 17 Oct 2014 10:35:21 -0700 Subject: JEP 211: Elide Deprecation Warnings on Import Statements In-Reply-To: <543FF1FE.5010106@oracle.com> References: <20141016003249.4DED93DE3F@eggemoggin.niobe.net> <543F857F.9050008@redhat.com> <543FF1FE.5010106@oracle.com> Message-ID: I wanted to pass along something that Kevin Bourrillion pointed out: I've now realized it's less simple than this. Javac doesn't seem to > propagate deprecation status down the containment tree. That is, for > example, deprecating a class doesn't cause members of the class to be > treated as deprecated. So in code like the following, the imports are > actually the *only* things generating a warning! > package z; > import static z.Bar.a; > import z.Bar.B; > class Foo { > public static void main(String[] args) { > a(); // expect a warning > B b = null; // expect a warning > b = new B(); // expect a warning > b.c(); // expect a warning > } > void foo(B b) {} // expect a warning > B bar() { return null; } // expect a warning > } > @Deprecated // should cascade to all members > class Bar { > public static void a() {} > public static class B { > public static void c() {} > } > } > So now I think that if they only elide the warnings from imports but don't > fix this as well, it would actually be worse than doing nothing, as this > code above would start compiling cleanly. > Yet just making deprecation propagate could cause a huge upsurge in the > number of warnings people get, so I don't know what the right answer is. On Thu, Oct 16, 2014 at 9:27 AM, Joe Darcy wrote: > On 10/16/2014 1:44 AM, Florian Weimer wrote: > >> On 10/16/2014 02:32 AM, mark.reinhold at oracle.com wrote: >> >>> New JEP Candidate: http://openjdk.java.net/jeps/211 >>> >> >> Would it make sense to suppress then warning on an import statement only >> if (a) there are uses of this import statement and (b) all these uses are >> annotated with @Deprecated? >> >> Or is this too complicated and we should rely on the existing >> unused-import warning? >> >> > I believe relying on existing unused imports warnings is sufficient in > this case. > > Cheers, > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Oct 17 18:07:41 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 17 Oct 2014 11:07:41 -0700 Subject: JEP 216: Process Import Statements Correctly In-Reply-To: References: <20141016172019.EC62A3E2AA@eggemoggin.niobe.net> Message-ID: <54415AED.7090101@oracle.com> Please send us related bug reports :) Thanks, Vicente On 10/16/2014 10:32 AM, Eddie Aftandilian wrote: > FWIW, at Google we get a bug report for this roughly once a month. It > would be great to have it fixed. > > On Thu, Oct 16, 2014 at 10:20 AM, > wrote: > > New JEP Candidate: http://openjdk.java.net/jeps/216 > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Oct 17 18:14:04 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 17 Oct 2014 11:14:04 -0700 Subject: Javac NPE In-Reply-To: References: Message-ID: <54415C6C.3010004@oracle.com> Hi Benji, I closed the bug because it couldn't be reproduced with last javac code for 8 and 9 (http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools and http://hg.openjdk.java.net/jdk9/dev/langtools/). If you can still reproduce the bug with any of these repos please notify it to us. Thanks, Vicente On 10/08/2014 04:47 AM, Benji Weber wrote: > Hi All, > > There is an NPE in javac (8u20) that I am running into regularly. It's > quite a pain because it takes a considerable amount of time to track > down the offending code each time it occurs. > > I filed a bug report with a simple test case, but after a few weeks in > the aether it appeared in JIRA as closed - not an issue. Any ideas why? > > https://bugs.openjdk.java.net/browse/JDK-8059511 > > The comments suggest it is related to this other bug > https://bugs.openjdk.java.net/browse/JDK-8058921 - which was closed > due to lack of a test case, but I provided a short and complete > testcase with my report. > > Do you think it is indeed a bug? How can I progress this now? I can't > see a way of creating a JIRA login to comment on the issues. Is it > only open to Oracle employees? > > Many Thanks > > -- > benji From vicente.romero at oracle.com Fri Oct 17 18:23:55 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 17 Oct 2014 11:23:55 -0700 Subject: Backport of the "missing clinit attribute" javac error to 1.7? In-Reply-To: References: Message-ID: <54415EBB.4070302@oracle.com> Hi Dawid, Thanks for your mail. We will check if the bug can be backported. You can always create a bug report for javac 7. For this case I have created a backport entry [1] to track this issue. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8061361 On 10/07/2014 12:21 AM, Dawid Weiss wrote: > Hello compiler folks! > > I've encountered the (known and resolved in 1.8) problem with javac > failing on annotations with static final fields requiring complex > initialization. The failure manifests itself on the latest 1.7 with > (edited): > > [ERROR] /.../MyClass.java:[186,17] annotation foo.MyAnnotation is > missing value for the attribute > > This seems to be: > > https://bugs.openjdk.java.net/browse/JDK-8013485 > > Are there any chances of backporting this patch to 1.7? ECJ compiles > such code without a glitch and so does 1.8 javac, of course. > > Dawid From dawid.weiss at gmail.com Fri Oct 17 18:50:32 2014 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 17 Oct 2014 20:50:32 +0200 Subject: Backport of the "missing clinit attribute" javac error to 1.7? In-Reply-To: <54415EBB.4070302@oracle.com> References: <54415EBB.4070302@oracle.com> Message-ID: Thanks, I appreciate it, Vicente. Dawid On Fri, Oct 17, 2014 at 8:23 PM, Vicente-Arturo Romero-Zaldivar wrote: > Hi Dawid, > > Thanks for your mail. We will check if the bug can be backported. You can > always create a bug report for javac 7. For this case I have created a > backport entry [1] to track this issue. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8061361 > > > On 10/07/2014 12:21 AM, Dawid Weiss wrote: >> >> Hello compiler folks! >> >> I've encountered the (known and resolved in 1.8) problem with javac >> failing on annotations with static final fields requiring complex >> initialization. The failure manifests itself on the latest 1.7 with >> (edited): >> >> [ERROR] /.../MyClass.java:[186,17] annotation foo.MyAnnotation is >> missing value for the attribute >> >> This seems to be: >> >> https://bugs.openjdk.java.net/browse/JDK-8013485 >> >> Are there any chances of backporting this patch to 1.7? ECJ compiles >> such code without a glitch and so does 1.8 javac, of course. >> >> Dawid > > From brian.goetz at oracle.com Fri Oct 17 19:36:42 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 17 Oct 2014 15:36:42 -0400 Subject: JEP 213: Milling Project Coin In-Reply-To: References: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> Message-ID: <54416FCA.2040407@oracle.com> This is merely a follow-through on a decision that was made as part of JSR-335, Lambda Expressions for the Java Language. In 8, warnings were issued when such identifiers were used, that say "this will go away in 9." (Try it with an 8 build, you'll see.) This is merely the follow-through to that decision (since we couldn't do it all in one go in 8.) On 10/15/2014 9:05 PM, Rob Leland wrote: > Is there a JDK issue filed somewhere that discusses #4 Remove underscore > .... Since its sure to draw some push back. > > All other issues have such a reference. > > On Oct 15, 2014 8:56 PM, > wrote: > > New JEP Candidate: http://openjdk.java.net/jeps/213 > > - Mark > From brian.goetz at oracle.com Fri Oct 17 19:39:01 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 17 Oct 2014 15:39:01 -0400 Subject: JEP 213: Milling Project Coin In-Reply-To: References: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> Message-ID: <54417055.6070704@oracle.com> Unlike the other two you site, the underscore removal was *not* descoped from 8. It is simply the case that the full change could not be completed in a single version, since we had to do warnings for one full version before removing the feature (which was done in 8.) On 10/16/2014 6:17 AM, Stephen Colebourne wrote: > Just to note that given the underscore removal is listed here (a Java > 8 change, not a coin one), it seems fair to ask what has happened to > two other descoped items from Java 8 - "package" as an explicit scope, > and private methods in interfaces. > > Stephen > > > On 16 October 2014 01:55, wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/213 >> >> - Mark From alex.buckley at oracle.com Fri Oct 17 21:50:35 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 17 Oct 2014 14:50:35 -0700 Subject: JEP 211: Elide Deprecation Warnings on Import Statements In-Reply-To: References: <20141016003249.4DED93DE3F@eggemoggin.niobe.net> <543F857F.9050008@redhat.com> <543FF1FE.5010106@oracle.com> Message-ID: <54418F2B.9090202@oracle.com> Great feedback. I think the import of non-deprecated static members of a deprecated type should continue to generate warnings, so that the use-by-simple-name of the imported static members continues to _not_ generate warnings. It looks like we want to distinguish: import z.Bar; // No warning please, because simple uses of Bar get warnings (unless suppressed). from: import [static] z.Bar.$MEMBER; // Warning please, because simple uses of $MEMBER don't get warnings. That is possible by sharpening the proposed spec change from: * The use is within an import statement. to: * The use is within an import statement that imports the type or member whose declaration is annotated with @Deprecated. To be clear, 'import z.Bar.B;' contains a use of the deprecated type Bar, and the use is NOT within an import statement importing the @Deprecated Bar, so the warning is NOT turned off. For completeness, suppose B's declaration is made @Deprecated, and Bar's declaration is still @Deprecated. 'import z.Bar.B;' contains a use of the deprecated type Bar, and the logic above still applies (warning NOT turned off) ... it also contains a use of the deprecated member B within an import statement importing that very member B, so the warning IS turned off. But don't worry - now that B's declaration is @Deprecated, the simple name 'B' throughout Foo will give a warning. Alex On 10/17/2014 10:35 AM, Eddie Aftandilian wrote: > I wanted to pass along something that Kevin Bourrillion pointed out: > > I've now realized it's less simple than this. Javac doesn't seem to > propagate deprecation status down the containment tree. That is, > for example, deprecating a class doesn't cause members of the class > to be treated as deprecated. So in code like the following, the > imports are actually the /only/ things generating a warning! > > package z; > import static z.Bar.a; > import z.Bar.B; > class Foo { > public static void main(String[] args) { > a(); // expect a warning > B b = null; // expect a warning > b = new B(); // expect a warning > b.c(); // expect a warning > } > void foo(B b) {} // expect a warning > B bar() { return null; } // expect a warning > } > @Deprecated // should cascade to all members > class Bar { > public static void a() {} > public static class B { > public static void c() {} > } > } > > So now I think that if they only elide the warnings from imports but > don't fix this as well, it would actually be worse than doing > nothing, as this code above would start compiling cleanly. > Yet just making deprecation propagate could cause a huge upsurge in > the number of warnings people get, so I don't know what the right > answer is. > > > On Thu, Oct 16, 2014 at 9:27 AM, Joe Darcy > wrote: > > On 10/16/2014 1:44 AM, Florian Weimer wrote: > > On 10/16/2014 02:32 AM, mark.reinhold at oracle.com > wrote: > > New JEP Candidate: http://openjdk.java.net/jeps/__211 > > > > Would it make sense to suppress then warning on an import > statement only if (a) there are uses of this import statement > and (b) all these uses are annotated with @Deprecated? > > Or is this too complicated and we should rely on the existing > unused-import warning? > > > I believe relying on existing unused imports warnings is sufficient > in this case. > > Cheers, > > -Joe > > From benji at benjiweber.co.uk Fri Oct 17 19:06:23 2014 From: benji at benjiweber.co.uk (Benji Weber) Date: Fri, 17 Oct 2014 20:06:23 +0100 Subject: Javac NPE In-Reply-To: <54415C6C.3010004@oracle.com> References: <54415C6C.3010004@oracle.com> Message-ID: Hi Vicente, Thanks. I was just confused by the statuses. Bug does indeed seem to be fixed in the latest u40-ea snapshot (although still present in u25) -- benji On 17 October 2014 19:14, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > Hi Benji, > > I closed the bug because it couldn't be reproduced with last javac code > for 8 and 9 (http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools and > http://hg.openjdk.java.net/jdk9/dev/langtools/). If you can still > reproduce the bug with any of these repos please notify it to us. > > Thanks, > Vicente > > > On 10/08/2014 04:47 AM, Benji Weber wrote: > >> Hi All, >> >> There is an NPE in javac (8u20) that I am running into regularly. It's >> quite a pain because it takes a considerable amount of time to track down >> the offending code each time it occurs. >> >> I filed a bug report with a simple test case, but after a few weeks in >> the aether it appeared in JIRA as closed - not an issue. Any ideas why? >> >> https://bugs.openjdk.java.net/browse/JDK-8059511 >> >> The comments suggest it is related to this other bug >> https://bugs.openjdk.java.net/browse/JDK-8058921 - which was closed due >> to lack of a test case, but I provided a short and complete testcase with >> my report. >> >> Do you think it is indeed a bug? How can I progress this now? I can't see >> a way of creating a JIRA login to comment on the issues. Is it only open to >> Oracle employees? >> >> Many Thanks >> >> -- >> benji >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javac at benjiweber.co.uk Sat Oct 18 08:01:18 2014 From: javac at benjiweber.co.uk (Benji Weber) Date: Sat, 18 Oct 2014 09:01:18 +0100 Subject: JEP 213: Milling Project Coin In-Reply-To: <54416FCA.2040407@oracle.com> References: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> <54416FCA.2040407@oracle.com> Message-ID: Is it worth reconsidering? Underscore as a variable name has become significantly more useful since the release of 8. For example We can now do partial application. Function plusFive = Partially.apply(Math::addExact, _, 5); int seven = plusFive.apply(2); We can now do pattern matching. args.match() .when(arg("--help", _), arg -> this.printHelp(arg.value())) .when(arg("--lang", _), arg -> this.setLanguage(arg.value())) Of course we could use a different variable name other than underscore to represent a wildcard, but underscore is already widely understood as a placeholder in this context, due to its use in Scala, Haskell and others. Removing _ means it will only be useful for what the language developers have been able to think of/implement, rather than what any library developers can implement, and restricted to the language release schedule. -- benji On 17 October 2014 20:36, Brian Goetz wrote: > This is merely a follow-through on a decision that was made as part of > JSR-335, Lambda Expressions for the Java Language. In 8, warnings were > issued when such identifiers were used, that say "this will go away in 9." > (Try it with an 8 build, you'll see.) This is merely the follow-through to > that decision (since we couldn't do it all in one go in 8.) > > On 10/15/2014 9:05 PM, Rob Leland wrote: > >> Is there a JDK issue filed somewhere that discusses #4 Remove underscore >> .... Since its sure to draw some push back. >> >> All other issues have such a reference. >> >> On Oct 15, 2014 8:56 PM, > > wrote: >> >> New JEP Candidate: http://openjdk.java.net/jeps/213 >> >> - Mark >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sat Oct 18 13:24:01 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 18 Oct 2014 09:24:01 -0400 Subject: JEP 213: Milling Project Coin In-Reply-To: References: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> <54416FCA.2040407@oracle.com> Message-ID: <544269F1.7090506@oracle.com> > Is it worth reconsidering? No, this decision is made, and I see no compelling reason to reconsider -- and the points you make here are not new input (in fact, many the points you make were central to the decision to remove it!) I'll just say that most of the reasons we have for for removing it are completely aligned with your motivations for wanting to keeping it -- we have bigger, better plans for _, that are more consistent with how it is used in other languages, but that are inconsistent with its use as an identifier. If we could have outlawed it as an identifier outright in 8, we could have done some of these things in 8 -- but we couldn't, so there's a window where you have to live with less now to get more later. Sorry. From javac at benjiweber.co.uk Sat Oct 18 13:26:16 2014 From: javac at benjiweber.co.uk (Benji Weber) Date: Sat, 18 Oct 2014 14:26:16 +0100 Subject: JEP 213: Milling Project Coin In-Reply-To: <544269F1.7090506@oracle.com> References: <20141016005526.E9EC23DE49@eggemoggin.niobe.net> <54416FCA.2040407@oracle.com> <544269F1.7090506@oracle.com> Message-ID: OK. Thanks for explaining :) On 18 Oct 2014 14:24, "Brian Goetz" wrote: > Is it worth reconsidering? >> > > No, this decision is made, and I see no compelling reason to reconsider -- > and the points you make here are not new input (in fact, many the points > you make were central to the decision to remove it!) > > I'll just say that most of the reasons we have for for removing it are > completely aligned with your motivations for wanting to keeping it -- we > have bigger, better plans for _, that are more consistent with how it is > used in other languages, but that are inconsistent with its use as an > identifier. > > If we could have outlawed it as an identifier outright in 8, we could have > done some of these things in 8 -- but we couldn't, so there's a window > where you have to live with less now to get more later. Sorry. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Sat Oct 18 18:10:32 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Sat, 18 Oct 2014 20:10:32 +0200 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way In-Reply-To: <20141015125923.GB5897@e6430> References: <20141015125923.GB5897@e6430> Message-ID: Looks good! On Wed, Oct 15, 2014 at 2:59 PM, Andreas Lundblad < andreas.lundblad at oracle.com> wrote: > Hi compiler-dev, > > Please review this patch which addresses JDK-8042088. > > - Description: > This patch is a refactoring and cleanup of the code that spawns the > external process for running the sjavac server. > > Since the fix of JDK-8048457 a server is never spawned as a separate > thread. (background=false -> Direct use of SjavacImpl, background=true -> > Server in separate JVM). This patch removes the (now dead) code that spawns > the server in a thread. > > The patch also fixes a small race condition in PortFile. > > Tested: > - All langtool tests pass > - make images runs without errors > - Giving a bad launch command (sjavac=...) results in correct error message > - Bad server executable (that never writes values to the port file) > results in correct error message > > - Link to webrev: > http://cr.openjdk.java.net/~alundblad/8042088/webrev.02/ > > - Links to bug report: > https://bugs.openjdk.java.net/browse/JDK-8042088 > > -- Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Mon Oct 20 20:23:37 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 20 Oct 2014 13:23:37 -0700 Subject: Issue with symbol completion failures during the final round of annotation processing Message-ID: I encountered an issue that causes symbol completion failures to be ignored during the final round of annotation processing. A diagnostic is printed to stderr, but the compilation still finishes with a 0 exit code. Is this a known issue? It affects javac 6, 7, and 8. It does not affect javac 9, probably thanks to JDK-8038455. Here's the repro: $ javac -cp $JAVA_HOME/lib/tools.jar CompletionFailureProcessor.java $ javac -cp $JAVA_HOME/lib/tools.jar:. -processor CompletionFailureProcessor Test.java error: cannot access Test Consult the following stack trace for details. com.sun.tools.javac.code.Symbol$CompletionFailure: ... $ echo $? 0 === Test.java === class Test {} === === CompletionFailureProcessor.java === import java.util.Set; import javax.annotation.processing.AbstractProcessor; import javax.annotation.processing.RoundEnvironment; import javax.annotation.processing.SupportedAnnotationTypes; import javax.lang.model.SourceVersion; import javax.lang.model.element.Element; import javax.lang.model.element.TypeElement; import com.sun.tools.javac.code.Symbol; @SupportedAnnotationTypes("*") public class CompletionFailureProcessor extends AbstractProcessor { public SourceVersion getSupportedSourceVersion() { return SourceVersion.latest(); } Element element; @Override public boolean process(Set annotations, RoundEnvironment roundEnv) { if (roundEnv.getRootElements().isEmpty()) { // last round has no root elements throw new Symbol.CompletionFailure((Symbol) element, ""); } else { // save an element for constructing the CompletionFailure next round element = roundEnv.getRootElements().iterator().next(); } return false; } } === -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Tue Oct 21 22:19:31 2014 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Wed, 22 Oct 2014 00:19:31 +0200 Subject: Generated constructor returns from line number of other method Message-ID: Hi, Given a class containing a method switching on an enum, like this: 1: public class WeirdConstructorLinenumber 2: { 3: public void consider(java.math.RoundingMode mode) { 4: switch ( mode ) {} 5: } 6: } javac generates a default constructor as expected. But the generated constructor returns from line 4 (which really belongs to the "consider" method). I could only make this happen by having my consider method switc on an enum. If I remove the switch or switch on something different, like an int, the constructor is generated with a single line and returns at line 1 as expected. Could this be a javac bug? Or is there something I'm just completely missing? $ javac WeirdConstructorLinenumber.java $ javap -c -l -classpath . WeirdConstructorLinenumber Compiled from "WeirdConstructorLinenumber.java" public class WeirdConstructorLinenumber { public WeirdConstructorLinenumber(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."":()V 4: return LineNumberTable: line 1: 0 line 4: 4 [...] } Thanks, Eirik Bj?rsn?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Oct 21 22:52:12 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 21 Oct 2014 15:52:12 -0700 Subject: Generated constructor returns from line number of other method In-Reply-To: References: Message-ID: <5446E39C.9070101@oracle.com> It's rather odd that an method corresponding to a default constructor has a LineNumberTable attribute in the first place. After all, the default constructor doesn't correspond to any lines of code in the original source file. The fact that 's LineNumberTable attribute changes based on the body of another method is even more odd. Alex On 10/21/2014 3:19 PM, Eirik Bj?rsn?s wrote: > Hi, > > Given a class containing a method switching on an enum, like this: > > 1: public class WeirdConstructorLinenumber > 2: { > 3: public void consider(java.math.RoundingMode mode) { > 4: switch ( mode ) {} > 5: } > 6: } > > javac generates a default constructor as expected. > > But the generated constructor returns from line 4 (which really belongs > to the "consider" method). > > I could only make this happen by having my consider method switc on an > enum. If I remove the switch or switch on something different, like an > int, the constructor is generated with a single line and returns at line > 1 as expected. > > Could this be a javac bug? Or is there something I'm just completely > missing? > > $ javac WeirdConstructorLinenumber.java > $ javap -c -l -classpath . WeirdConstructorLinenumber > Compiled from "WeirdConstructorLinenumber.java" > public class WeirdConstructorLinenumber { > public WeirdConstructorLinenumber(); > Code: > 0: aload_0 > 1: invokespecial #1 // Method > java/lang/Object."":()V > 4: return > LineNumberTable: > line 1: 0 > line 4: 4 > > [...] > } > > > Thanks, > Eirik Bj?rsn?s > From eaftan at google.com Wed Oct 22 00:50:18 2014 From: eaftan at google.com (Eddie Aftandilian) Date: Tue, 21 Oct 2014 17:50:18 -0700 Subject: JEP 216: Process Import Statements Correctly In-Reply-To: <54415AED.7090101@oracle.com> References: <20141016172019.EC62A3E2AA@eggemoggin.niobe.net> <54415AED.7090101@oracle.com> Message-ID: We received another bug report a few days ago. I've minimized it and attached it to this email. When I try to compile this code, I get a "symbol not found" error. If I comment out the static import in the package1/ClientImpl.java file, then it compiles. I can reproduce with javac 1.7.0 and 1.8.0_05. % javac package1/ClientImpl.java package1/ClientImpl.java:10: error: cannot find symbol static class TransactionImpl implements Transaction { ^ symbol: class Transaction location: class ClientImpl package1/ClientImpl.java:18: error: method does not override or implement a method from a supertype @Override ^ 2 errors On Fri, Oct 17, 2014 at 11:07 AM, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > Please send us related bug reports :) > > Thanks, > Vicente > > > On 10/16/2014 10:32 AM, Eddie Aftandilian wrote: > > FWIW, at Google we get a bug report for this roughly once a month. It > would be great to have it fixed. > > On Thu, Oct 16, 2014 at 10:20 AM, wrote: > >> New JEP Candidate: http://openjdk.java.net/jeps/216 >> >> - Mark >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jep_216_repro.tar.gz Type: application/x-gzip Size: 458 bytes Desc: not available URL: From vicente.romero at oracle.com Wed Oct 22 00:58:07 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 21 Oct 2014 17:58:07 -0700 Subject: JEP 216: Process Import Statements Correctly In-Reply-To: References: <20141016172019.EC62A3E2AA@eggemoggin.niobe.net> <54415AED.7090101@oracle.com> Message-ID: <5447011F.60804@oracle.com> Hi Eddie, Thanks a lot for the bug report, Vicente On 10/21/2014 05:50 PM, Eddie Aftandilian wrote: > We received another bug report a few days ago. I've minimized it and > attached it to this email. When I try to compile this code, I get a > "symbol not found" error. If I comment out the static import in the > package1/ClientImpl.java file, then it compiles. I can reproduce with > javac 1.7.0 and 1.8.0_05. > > % javac package1/ClientImpl.java > package1/ClientImpl.java:10: error: cannot find symbol > static class TransactionImpl implements Transaction { > ^ > symbol: class Transaction > location: class ClientImpl > package1/ClientImpl.java:18: error: method does not override or > implement a method from a supertype > @Override > ^ > 2 errors > > On Fri, Oct 17, 2014 at 11:07 AM, Vicente-Arturo Romero-Zaldivar > > wrote: > > Please send us related bug reports :) > > Thanks, > Vicente > > > On 10/16/2014 10:32 AM, Eddie Aftandilian wrote: >> FWIW, at Google we get a bug report for this roughly once a >> month. It would be great to have it fixed. >> >> On Thu, Oct 16, 2014 at 10:20 AM, > > wrote: >> >> New JEP Candidate: http://openjdk.java.net/jeps/216 >> >> - Mark >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Wed Oct 22 06:31:24 2014 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Wed, 22 Oct 2014 08:31:24 +0200 Subject: Generated constructor returns from line number of other method In-Reply-To: <5446E39C.9070101@oracle.com> References: <5446E39C.9070101@oracle.com> Message-ID: If it's even more odd that rather odd, might we even call it a bug? :-) I noticed that javac also generates a class WeirdConstructorLinenumber$1 containing a which initialises an int[] switch map: class no.kantega.labs.revoc.demo.WeirdConstructorLinenumber$1 { static final int[] $SwitchMap$java$math$RoundingMode; static {}; Code: 0: invokestatic #1 // Method java/math/RoundingMode.values:()[Ljava/math/RoundingMode; 3: arraylength 4: newarray int 6: putstatic #2 // Field $SwitchMap$java$math$RoundingMode:[I 9: return LineNumberTable: line 8: 0 } Looks like for some reason the line number for the "leaks" over to the of the enclosing class. I first noticed this issue when working on a code coverage tool. For performance reasons, the tool instruments line number instructions not by their actual line numbers, but with the count of the first time a line number occurs in the byte code for that class. The odd line number in shifted the line count by one which caused line counts for a method to spill over to the next method in the class. I imagine other source-aware tools such as code coverage tools, static analysis tools or even debuggers might be affected by this. Eirik. On Wed, Oct 22, 2014 at 12:52 AM, Alex Buckley wrote: > > It's rather odd that an method corresponding to a default constructor has a LineNumberTable attribute in the first place. After all, the default constructor doesn't correspond to any lines of code in the original source file. > > The fact that 's LineNumberTable attribute changes based on the body of another method is even more odd. > > Alex > > > On 10/21/2014 3:19 PM, Eirik Bj?rsn?s wrote: >> >> Hi, >> >> Given a class containing a method switching on an enum, like this: >> >> 1: public class WeirdConstructorLinenumber >> 2: { >> 3: public void consider(java.math.RoundingMode mode) { >> 4: switch ( mode ) {} >> 5: } >> 6: } >> >> javac generates a default constructor as expected. >> >> But the generated constructor returns from line 4 (which really belongs >> to the "consider" method). >> >> I could only make this happen by having my consider method switc on an >> enum. If I remove the switch or switch on something different, like an >> int, the constructor is generated with a single line and returns at line >> 1 as expected. >> >> Could this be a javac bug? Or is there something I'm just completely >> missing? >> >> $ javac WeirdConstructorLinenumber.java >> $ javap -c -l -classpath . WeirdConstructorLinenumber >> Compiled from "WeirdConstructorLinenumber.java" >> public class WeirdConstructorLinenumber { >> public WeirdConstructorLinenumber(); >> Code: >> 0: aload_0 >> 1: invokespecial #1 // Method >> java/lang/Object."":()V >> 4: return >> LineNumberTable: >> line 1: 0 >> line 4: 4 >> >> [...] >> } >> >> >> Thanks, >> Eirik Bj?rsn?s >> From maurizio.cimadamore at oracle.com Wed Oct 22 09:52:56 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 22 Oct 2014 10:52:56 +0100 Subject: Generated constructor returns from line number of other method In-Reply-To: References: <5446E39C.9070101@oracle.com> Message-ID: <54477E78.2080304@oracle.com> Hi Eirik, this is definitively a javac issue; I isolated the problem to the following test case: class Test { static class Empty { } } which generates the following LineNumberTable for the default constructor: LineNumberTable: line 1: 0 line 2: 4 However, if the static nested class is commented out, the following LineNumberTable is obtained: LineNumberTable: line 1: 0 The problem seems to be caused by the fact that, during code translation (Lower), javac replaces nested class declarations with empty blocks which are then mistakenly confused by a subsequent code generation step for instance initializers (!!) - this means that the generated code would look like: class Test { { } // <------------- Test() { super(); } } And then, after initializer normalization, it becomes: class Test { Test() { super(); { } <------------ } } That's wrong, as the empty block does not correspond to a static instance initializer, but, rather, to a compile-time artifact and should therefore be skipped. I filed this: https://bugs.openjdk.java.net/browse/JDK-8061778 to keep track of this issue. Thanks for the report. Maurizio On 22/10/14 07:31, Eirik Bj?rsn?s wrote: > If it's even more odd that rather odd, might we even call it a bug? :-) > > I noticed that javac also generates a class > WeirdConstructorLinenumber$1 containing a which initialises > an int[] switch map: > > class no.kantega.labs.revoc.demo.WeirdConstructorLinenumber$1 { > static final int[] $SwitchMap$java$math$RoundingMode; > > static {}; > Code: > 0: invokestatic #1 // Method > java/math/RoundingMode.values:()[Ljava/math/RoundingMode; > 3: arraylength > 4: newarray int > 6: putstatic #2 // Field > $SwitchMap$java$math$RoundingMode:[I > 9: return > LineNumberTable: > line 8: 0 > } > > Looks like for some reason the line number for the "leaks" > over to the of the enclosing class. > > I first noticed this issue when working on a code coverage tool. For > performance reasons, the tool instruments line number instructions not > by their actual line numbers, but with the count of the first time a > line number occurs in the byte code for that class. The odd line > number in shifted the line count by one which caused line > counts for a method to spill over to the next method in the class. > > I imagine other source-aware tools such as code coverage tools, static > analysis tools or even debuggers might be affected by this. > > Eirik. > > > > On Wed, Oct 22, 2014 at 12:52 AM, Alex Buckley wrote: >> It's rather odd that an method corresponding to a default constructor has a LineNumberTable attribute in the first place. After all, the default constructor doesn't correspond to any lines of code in the original source file. >> >> The fact that 's LineNumberTable attribute changes based on the body of another method is even more odd. >> >> Alex >> >> >> On 10/21/2014 3:19 PM, Eirik Bj?rsn?s wrote: >>> Hi, >>> >>> Given a class containing a method switching on an enum, like this: >>> >>> 1: public class WeirdConstructorLinenumber >>> 2: { >>> 3: public void consider(java.math.RoundingMode mode) { >>> 4: switch ( mode ) {} >>> 5: } >>> 6: } >>> >>> javac generates a default constructor as expected. >>> >>> But the generated constructor returns from line 4 (which really belongs >>> to the "consider" method). >>> >>> I could only make this happen by having my consider method switc on an >>> enum. If I remove the switch or switch on something different, like an >>> int, the constructor is generated with a single line and returns at line >>> 1 as expected. >>> >>> Could this be a javac bug? Or is there something I'm just completely >>> missing? >>> >>> $ javac WeirdConstructorLinenumber.java >>> $ javap -c -l -classpath . WeirdConstructorLinenumber >>> Compiled from "WeirdConstructorLinenumber.java" >>> public class WeirdConstructorLinenumber { >>> public WeirdConstructorLinenumber(); >>> Code: >>> 0: aload_0 >>> 1: invokespecial #1 // Method >>> java/lang/Object."":()V >>> 4: return >>> LineNumberTable: >>> line 1: 0 >>> line 4: 4 >>> >>> [...] >>> } >>> >>> >>> Thanks, >>> Eirik Bj?rsn?s >>> From jan.lahoda at oracle.com Wed Oct 22 14:08:38 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 22 Oct 2014 16:08:38 +0200 Subject: JEP 216: Process Import Statements Correctly In-Reply-To: References: <20141016172019.EC62A3E2AA@eggemoggin.niobe.net> <54415AED.7090101@oracle.com> Message-ID: <5447BA66.9080909@oracle.com> Hi Eddie, Thanks a lot for the report. It is similar to JDK-7101822 but slightly different (as "Transaction" gets into the Scope by subclassing rather than by import). The internal cause is similar: TranscationImpl is being "member resolved" before its enclosing environment is fully finished. Reports like this (will) help validate the fix approach, thanks for it! If you have other/different cases, I'd be happy to hear them. Thanks a lot, Jan On 22.10.2014 02:50, Eddie Aftandilian wrote: > We received another bug report a few days ago. I've minimized it and > attached it to this email. When I try to compile this code, I get a > "symbol not found" error. If I comment out the static import in the > package1/ClientImpl.java file, then it compiles. I can reproduce with > javac 1.7.0 and 1.8.0_05. > > % javac package1/ClientImpl.java > package1/ClientImpl.java:10: error: cannot find symbol > static class TransactionImpl implements Transaction { > ^ > symbol: class Transaction > location: class ClientImpl > package1/ClientImpl.java:18: error: method does not override or > implement a method from a supertype > @Override > ^ > 2 errors > > On Fri, Oct 17, 2014 at 11:07 AM, Vicente-Arturo Romero-Zaldivar > > wrote: > > Please send us related bug reports :) > > Thanks, > Vicente > > > On 10/16/2014 10:32 AM, Eddie Aftandilian wrote: >> FWIW, at Google we get a bug report for this roughly once a >> month. It would be great to have it fixed. >> >> On Thu, Oct 16, 2014 at 10:20 AM, > > wrote: >> >> New JEP Candidate: http://openjdk.java.net/jeps/216 >> >> - Mark >> >> > > From vicente.romero at oracle.com Wed Oct 22 21:30:48 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 22 Oct 2014 14:30:48 -0700 Subject: evaluation for bug: https://bugs.openjdk.java.net/browse/JDK-8059921 Message-ID: <54482208.9010700@oracle.com> Hi Alex, I would like to know your opinion about the bug in the subject. The related code is: interface T2 { int f = 0; } interface T extends T2 { int f = 0; } class X implements T { int i = T.super.f; } The reporter considers that JLS 15.11.2 doesn't mention interfaces explicitly and that for this reason this is a bug. Should the spec be read more generally, thus including interfaces? Thanks, Vicente From alex.buckley at oracle.com Thu Oct 23 00:24:27 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Oct 2014 17:24:27 -0700 Subject: evaluation for bug: https://bugs.openjdk.java.net/browse/JDK-8059921 In-Reply-To: <54482208.9010700@oracle.com> References: <54482208.9010700@oracle.com> Message-ID: <54484ABB.8000806@oracle.com> On 10/22/2014 2:30 PM, Vicente-Arturo Romero-Zaldivar wrote: > I would like to know your opinion about the bug in the subject. The > related code is: > > interface T2 { int f = 0; } > > interface T extends T2 { int f = 0; } > > class X implements T { > int i = T.super.f; > } > > The reporter considers that JLS 15.11.2 doesn't mention interfaces > explicitly and that for this reason this is a bug. Should the spec be > read more generally, thus including interfaces? No. The code shouldn't compile. The T.super.f construct is only for accessing fields of a lexically enclosing superclass. The goal is to allow access to instance variables which would otherwise be hidden. (It's also possible to access static variables too, but that's a side effect of how field access works generally.) This goal is not relevant to superinterfaces, as they have no instance variables to be hidden - you can always access their fields (static variables) via qualified names. Alex From vicente.romero at oracle.com Thu Oct 23 00:30:46 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 22 Oct 2014 17:30:46 -0700 Subject: evaluation for bug: https://bugs.openjdk.java.net/browse/JDK-8059921 In-Reply-To: <54484ABB.8000806@oracle.com> References: <54482208.9010700@oracle.com> <54484ABB.8000806@oracle.com> Message-ID: <54484C36.2020400@oracle.com> Hi Alex, Thanks for your evaluation, Vicente On 10/22/2014 05:24 PM, Alex Buckley wrote: > On 10/22/2014 2:30 PM, Vicente-Arturo Romero-Zaldivar wrote: >> I would like to know your opinion about the bug in the subject. The >> related code is: >> >> interface T2 { int f = 0; } >> >> interface T extends T2 { int f = 0; } >> >> class X implements T { >> int i = T.super.f; >> } >> >> The reporter considers that JLS 15.11.2 doesn't mention interfaces >> explicitly and that for this reason this is a bug. Should the spec be >> read more generally, thus including interfaces? > > No. The code shouldn't compile. > > The T.super.f construct is only for accessing fields of a lexically > enclosing superclass. The goal is to allow access to instance > variables which would otherwise be hidden. (It's also possible to > access static variables too, but that's a side effect of how field > access works generally.) This goal is not relevant to superinterfaces, > as they have no instance variables to be hidden - you can always > access their fields (static variables) via qualified names. > > Alex From joel.franck at oracle.com Fri Oct 24 08:41:24 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 24 Oct 2014 10:41:24 +0200 Subject: Backport of the "missing clinit attribute" javac error to 1.7? In-Reply-To: References: Message-ID: <20141024084124.GC4891@oracle.com> Hi Dawid, Sorry for the delay, can you post a reproducer? It would be interesting to see the declaration of Foo and MyAnnotation. cheers /Joel On 2014-10-07, Dawid Weiss wrote: > Hello compiler folks! > > I've encountered the (known and resolved in 1.8) problem with javac > failing on annotations with static final fields requiring complex > initialization. The failure manifests itself on the latest 1.7 with > (edited): > > [ERROR] /.../MyClass.java:[186,17] annotation foo.MyAnnotation is > missing value for the attribute > > This seems to be: > > https://bugs.openjdk.java.net/browse/JDK-8013485 > > Are there any chances of backporting this patch to 1.7? ECJ compiles > such code without a glitch and so does 1.8 javac, of course. > > Dawid From dawid.weiss at gmail.com Fri Oct 24 09:00:48 2014 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 24 Oct 2014 11:00:48 +0200 Subject: Backport of the "missing clinit attribute" javac error to 1.7? In-Reply-To: <20141024084124.GC4891@oracle.com> References: <20141024084124.GC4891@oracle.com> Message-ID: Hi Joel! Sure, here it is: https://github.com/dweiss/ann-clinit It's really simple -- the annotation has a field that requires a static initializer (imports omitted for brevity): public @interface Ann { public static String FOO = new String("Foo"); } and the class that's using it is simply annotated: @Ann public class Main { } When you try to compile it (javac 1.7.0_40), the output is: C:\carrot2\gh.dweiss\ann-clinit>javac *.java Main.java:2: error: annotation Ann is missing value for the attribute @Ann ^ 1 error Dawid On Fri, Oct 24, 2014 at 10:41 AM, Joel Borggren-Franck wrote: > Hi Dawid, > > Sorry for the delay, can you post a reproducer? It would be interesting > to see the declaration of Foo and MyAnnotation. > > cheers > /Joel > > On 2014-10-07, Dawid Weiss wrote: >> Hello compiler folks! >> >> I've encountered the (known and resolved in 1.8) problem with javac >> failing on annotations with static final fields requiring complex >> initialization. The failure manifests itself on the latest 1.7 with >> (edited): >> >> [ERROR] /.../MyClass.java:[186,17] annotation foo.MyAnnotation is >> missing value for the attribute >> >> This seems to be: >> >> https://bugs.openjdk.java.net/browse/JDK-8013485 >> >> Are there any chances of backporting this patch to 1.7? ECJ compiles >> such code without a glitch and so does 1.8 javac, of course. >> >> Dawid From joel.franck at oracle.com Fri Oct 24 12:32:32 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 24 Oct 2014 14:32:32 +0200 Subject: crash with -Xjcov and union types In-Reply-To: References: Message-ID: <20141024123232.GD4891@oracle.com> Hi again, There is a method for visiting a List in CRTable, using that you can rewrite the method to: + @Override + public void visitTypeUnion(JCTypeUnion tree) { + SourceRange sr = new SourceRange(startPos(tree), endPos(tree)); + sr.mergeWith(csp(tree.alternatives)); + result = sr; + } A bit cleaner IMHO and should work the same. Works for you? cheers /Joel On 2014-09-25, Liam Miller-Cushon wrote: > I'm seeing crashes with -Xjcov enabled while compiling code with union > types. This seems to affect javac 7 through 9. I've attached a possible > fix, and a jtreg test for the crash. > > > Repro: > > > === Test.java === > > class Test { > > void m() { > > try { > > return; > > } catch (IllegalStateException | IllegalArgumentException e) { > > } > > } > > } > > === > > > $ javac Test.java > > ... > > An exception has occurred in the compiler (1.8.0_20). Please file a bug at > the Java Developer Connection (http://java.sun.com/webapps/bugreport) > after checking the Bug Parade for duplicates. Include your program and the > following diagnostic in your report. Thank you. > > java.lang.AssertionError > > at com.sun.tools.javac.util.Assert.error(Assert.java:126) > > at > com.sun.tools.javac.jvm.CRTable$SourceComputer.visitTree(CRTable.java:529) > > at com.sun.tools.javac.tree.JCTree$Visitor.visitTypeUnion(JCTree.java:2577) > > ... > # HG changeset patch > # User cushon > # Date 1411681109 25200 > # Node ID ea73aee87ad23ecca9eb6c3133ba66807367d790 > # Parent 3c7c7485fab732143c30f4bf71a7ab8411763380 > Fix -Xjcov crash with union types. > > diff -r 3c7c7485fab7 -r ea73aee87ad2 src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/CRTable.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/CRTable.java Thu Sep 25 13:54:45 2014 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/CRTable.java Thu Sep 25 14:38:29 2014 -0700 > @@ -517,6 +517,15 @@ > result = sr; > } > > + @Override > + public void visitTypeUnion(JCTypeUnion tree) { > + SourceRange sr = new SourceRange(startPos(tree), endPos(tree)); > + for (JCTree alternative : tree.alternatives) { > + sr.mergeWith(csp(alternative)); > + } > + result = sr; > + } > + > public void visitWildcard(JCWildcard tree) { > result = null; > } > diff -r 3c7c7485fab7 -r ea73aee87ad2 test/tools/javac/options/XjcovUnionType.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/options/XjcovUnionType.java Thu Sep 25 14:38:29 2014 -0700 > @@ -0,0 +1,38 @@ > +/* > + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 1234567 > + * @summary -Xjcov causes crash with union types > + * @compile -Xjcov XjcovUnionType.java > + */ > + > +public class XjcovUnionType { > + public static void main(String[] args) { > + try { > + return; > + } catch (IllegalStateException | IllegalArgumentException e) { > + } > + } > +} From cushon at google.com Fri Oct 24 22:46:27 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 24 Oct 2014 15:46:27 -0700 Subject: crash with -Xjcov and union types In-Reply-To: <20141024123232.GD4891@oracle.com> References: <20141024123232.GD4891@oracle.com> Message-ID: On Fri, Oct 24, 2014 at 5:32 AM, Joel Borggren-Franck < joel.franck at oracle.com> wrote: > A bit cleaner IMHO and should work the same. Works for you? Looks good to me. Thanks Joel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliasvasylenko at gmail.com Sun Oct 26 22:53:32 2014 From: eliasvasylenko at gmail.com (elias vasylenko) Date: Sun, 26 Oct 2014 22:53:32 +0000 Subject: JEP proposal: Improved variance for generic classes and interfaces Message-ID: Hi Dan, Hope this proposal gains traction, I'm definitely an enthusiastic supporter. (And apologies if this isn't appended to the appropriate thread, I just joined the mailing list so I don't have the original email to reply to.) Just a quick question/suggestion: it seems like a handy side-effect of the proposed changes is the potential for relaxation of the limitation on reimplementation of interfaces with different generic parametrisations, and I'm wondering if you've considered this. For example, it should be possible to allow something like this: class Foo implements Predicate {} class Bar extends Foo implements Predicate {} Since declaration-site variance guarantees compatibility of the overriding parametrisation. Of course we can't technically override test(Integer) with test(Number)... but from an outsiders perspective I don't see this as incompatible with current language design philosophy... At any rate, covariance should be more straightforward I'm sure this would have come up if it hasn't already, but I couldn't find any explicit mention of it. Regards, Elias Vasylenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Mon Oct 27 09:12:11 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 27 Oct 2014 10:12:11 +0100 Subject: Request for review/advice from langtools team Re: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Message-ID: Hi, Can someone from langtools kindly chime in with how to move this forward? https://bugs.openjdk.java.net/browse/JDK-4774077 http://cr.openjdk.java.net/~rwarburton/buffer-overrides-3/ http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch On Oct 17, 2014, at 11:37 AM, Paul Sandoz wrote: > Hi, > > [Including compiler-dev, i am not on that list so please CC me if replying to just that list] > > ... > So Richard has a patch for that too: > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch > > This is required because in the bootstrap compilation phase a JDK without the co-variant overrides can be used. So the current solution is to suppress the warnings. Reviews from langtools gurus are very much appreciated. > ? > Ideally it would be nice to push all this under one issue, is that possible? If not i will have to create another issue and of course push to langtools before jdk. > > A internal CCC is also underway. > This has be approved, with the comment that "@since 1.9" should be added to the doc of the new methods, which i have done in my copy of the patch. Thanks, Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From richard.warburton at gmail.com Mon Oct 27 20:44:29 2014 From: richard.warburton at gmail.com (Richard Warburton) Date: Mon, 27 Oct 2014 20:44:29 +0000 Subject: Possible javac bug around final and covariant overrides In-Reply-To: <536BD955.7070904@oracle.com> References: <53567039.2090103@redhat.com> <536BD955.7070904@oracle.com> Message-ID: Hi, IMO this is a bug. I have filed https://bugs.openjdk.java.net/ > browse/JDK-8042785 to track it. > > Thanks for your report, > Can I request a clarification for what's happened with this issue? It looks like the following has happened: 1. The reported bug was fixed 2. There was a the fix, caused a regression elsewhere. 3. The fix was deleted. 4. The bug was closed with a claim the bug was unverified. Perhaps I'm misunderstanding something here, but if the fix was reverted then that means that the bug still remains an issue. regards, Richard Warburton http://insightfullogic.com @RichardWarburto -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhs at edg.com Mon Oct 27 20:53:41 2014 From: jhs at edg.com (John Spicer) Date: Mon, 27 Oct 2014 16:53:41 -0400 Subject: Throws clause of default constructor Message-ID: <0FE04E01-F69B-449D-A6BD-0A17D4542009@edg.com> This case gets an error with javac 7 and javac 8 with -source 1.7, but is accepted by javac 8 in normal mode. I wasn't able to find the JLS change that corresponds to this. Any pointers would be appreciated. Thanks, John. class A { A() throws T {} } class B extends A {} From vicente.romero at oracle.com Mon Oct 27 20:57:54 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Mon, 27 Oct 2014 13:57:54 -0700 Subject: Possible javac bug around final and covariant overrides In-Reply-To: References: <53567039.2090103@redhat.com> <536BD955.7070904@oracle.com> Message-ID: <544EB1D2.1080507@oracle.com> On 10/27/2014 01:44 PM, Richard Warburton wrote: > Hi, > > IMO this is a bug. I have filed > https://bugs.openjdk.java.net/browse/JDK-8042785 to track it. > > Thanks for your report, > > > Can I request a clarification for what's happened with this issue? It > looks like the following has happened: > > 1. The reported bug was fixed > 2. There was a the fix, caused a regression elsewhere. > 3. The fix was deleted. > 4. The bug was closed with a claim the bug was unverified. 5. a new bug (https://bugs.openjdk.java.net/browse/JDK-8044734) was created as a follow-up 6. we are keeping track of this. Thanks, Vicente > > Perhaps I'm misunderstanding something here, but if the fix was > reverted then that means that the bug still remains an issue. > > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon Oct 27 21:43:50 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 27 Oct 2014 14:43:50 -0700 Subject: Throws clause of default constructor In-Reply-To: <0FE04E01-F69B-449D-A6BD-0A17D4542009@edg.com> References: <0FE04E01-F69B-449D-A6BD-0A17D4542009@edg.com> Message-ID: <544EBC96.8010509@oracle.com> Looks like a javac bug when the thrown type is a type variable. If A's ctor is simply "A() throws Throwable {}", then JDK8 javac reports the error for B's default ctor regardless of -source version. But make A's ctor generic and throw the type variable, and JDK8 javac only reports the error for B with -source 1.7 and below. In fact, javac cares whether T extends {Throwable,Exception} versus a subclass of Exception. If T extends a checked exception type like java.io.IOException, then JDK8 javac actually reports the error for B regardless of -source version. (All this on JDK8u25.) Alex On 10/27/2014 1:53 PM, John Spicer wrote: > This case gets an error with javac 7 and javac 8 with -source 1.7, but is accepted by javac 8 in normal mode. > > I wasn't able to find the JLS change that corresponds to this. > > Any pointers would be appreciated. > > Thanks, > > John. > > class A { > A() throws T {} > } > > class B extends A {} > From daniel.smith at oracle.com Mon Oct 27 22:52:35 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 27 Oct 2014 16:52:35 -0600 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: References: Message-ID: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> > On Oct 26, 2014, at 4:53 PM, elias vasylenko wrote: > > Just a quick question/suggestion: it seems like a handy side-effect of the proposed changes is the potential for relaxation of the limitation on reimplementation of interfaces with different generic parametrisations, and I'm wondering if you've considered this. > > For example, it should be possible to allow something like this: > > class Foo implements Predicate {} > > class Bar extends Foo implements Predicate {} > > Since declaration-site variance guarantees compatibility of the overriding parametrisation. Of course we can't technically override test(Integer) with test(Number)... but from an outsiders perspective I don't see this as incompatible with current language design philosophy... At any rate, covariance should be more straightforward > > I'm sure this would have come up if it hasn't already, but I couldn't find any explicit mention of it. That's a good idea, and not something we've looked into yet. Thanks for the suggestion. ?Dan From forax at univ-mlv.fr Mon Oct 27 23:03:24 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 28 Oct 2014 00:03:24 +0100 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> References: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> Message-ID: <544ECF3C.1000008@univ-mlv.fr> On 10/27/2014 11:52 PM, Dan Smith wrote: >> On Oct 26, 2014, at 4:53 PM, elias vasylenko wrote: >> >> Just a quick question/suggestion: it seems like a handy side-effect of the proposed changes is the potential for relaxation of the limitation on reimplementation of interfaces with different generic parametrisations, and I'm wondering if you've considered this. >> >> For example, it should be possible to allow something like this: >> >> class Foo implements Predicate {} >> >> class Bar extends Foo implements Predicate {} >> >> Since declaration-site variance guarantees compatibility of the overriding parametrisation. Of course we can't technically override test(Integer) with test(Number)... but from an outsiders perspective I don't see this as incompatible with current language design philosophy... At any rate, covariance should be more straightforward >> >> I'm sure this would have come up if it hasn't already, but I couldn't find any explicit mention of it. > That's a good idea, and not something we've looked into yet. Thanks for the suggestion. > > ?Dan The problem here is not a typing problem but an erasure problem, both Predicate and Predicate require to generate a bridge method but both test(Integer) and test(Number) have the same erasure test(Object). So it's not possible without full reification to implement that bridge. cheers, R?mi From daniel.smith at oracle.com Mon Oct 27 23:37:40 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 27 Oct 2014 17:37:40 -0600 Subject: Throws clause of default constructor In-Reply-To: <544EBC96.8010509@oracle.com> References: <0FE04E01-F69B-449D-A6BD-0A17D4542009@edg.com> <544EBC96.8010509@oracle.com> Message-ID: <30874745-5BFB-440B-B0DF-C35DC99D37DE@oracle.com> Ah, this is an interesting side-effect of improving inference for 'throws' type variables. First, here are the relevant rules about the default constructor of B (JLS 8.8.9): "The default constructor has no throws clauses" "the default constructor simply invokes the superclass constructor with no arguments" "It is a compile-time error if a default constructor is implicitly declared but the superclass does not have an accessible constructor that takes no arguments and has no throws clause." Taken literally, that last sentence means this is, trivially, an illegal program. But I don't think javac has ever taken it literally -- if I declare a superclass constructor that 'throws RuntimeException', no error occurs in 7 or 8. Here's a bug report for that: https://bugs.openjdk.java.net/browse/JDK-8062234 Given that 'throws RuntimeException' is okay, note that the typing of the implicit 'super()' call in B's default constructor changed between 7 and 8. In 7, inference determined that T:=Throwable. In 8, inference determines that T:=RuntimeException. (See JLS 18.4.) So the change in errors is due to a change in inference, and is expected behavior. ?Dan > On Oct 27, 2014, at 3:43 PM, Alex Buckley wrote: > > Looks like a javac bug when the thrown type is a type variable. > > If A's ctor is simply "A() throws Throwable {}", then JDK8 javac reports the error for B's default ctor regardless of -source version. > > But make A's ctor generic and throw the type variable, and JDK8 javac only reports the error for B with -source 1.7 and below. > > In fact, javac cares whether T extends {Throwable,Exception} versus a subclass of Exception. If T extends a checked exception type like java.io.IOException, then JDK8 javac actually reports the error for B regardless of -source version. > > (All this on JDK8u25.) > > Alex > > On 10/27/2014 1:53 PM, John Spicer wrote: >> This case gets an error with javac 7 and javac 8 with -source 1.7, but is accepted by javac 8 in normal mode. >> >> I wasn't able to find the JLS change that corresponds to this. >> >> Any pointers would be appreciated. >> >> Thanks, >> >> John. >> >> class A { >> A() throws T {} >> } >> >> class B extends A {} >> From daniel.smith at oracle.com Mon Oct 27 23:40:52 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 27 Oct 2014 17:40:52 -0600 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: <544ECF3C.1000008@univ-mlv.fr> References: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> <544ECF3C.1000008@univ-mlv.fr> Message-ID: > On Oct 27, 2014, at 5:03 PM, Remi Forax wrote: > > > On 10/27/2014 11:52 PM, Dan Smith wrote: >>> On Oct 26, 2014, at 4:53 PM, elias vasylenko wrote: >>> >>> Just a quick question/suggestion: it seems like a handy side-effect of the proposed changes is the potential for relaxation of the limitation on reimplementation of interfaces with different generic parametrisations, and I'm wondering if you've considered this. >>> >>> For example, it should be possible to allow something like this: >>> >>> class Foo implements Predicate {} >>> >>> class Bar extends Foo implements Predicate {} >>> >>> Since declaration-site variance guarantees compatibility of the overriding parametrisation. Of course we can't technically override test(Integer) with test(Number)... but from an outsiders perspective I don't see this as incompatible with current language design philosophy... At any rate, covariance should be more straightforward >>> >>> I'm sure this would have come up if it hasn't already, but I couldn't find any explicit mention of it. >> That's a good idea, and not something we've looked into yet. Thanks for the suggestion. >> >> ?Dan > > The problem here is not a typing problem but an erasure problem, both Predicate and Predicate require to generate a bridge method but both test(Integer) and test(Number) have the same erasure test(Object). So it's not possible without full reification to implement that bridge. Haven't thought much about this, but can't the compiler just generate all the necessary signatures in Bar? test(Number)Z: user's implementation test(Integer)Z: bridge to test(Number)Z test(Object)Z: bridge to test(Number)Z ?Dan From eliasvasylenko at gmail.com Tue Oct 28 00:19:00 2014 From: eliasvasylenko at gmail.com (elias vasylenko) Date: Tue, 28 Oct 2014 00:19:00 +0000 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: <544ECF3C.1000008@univ-mlv.fr> References: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> <544ECF3C.1000008@univ-mlv.fr> Message-ID: Ah, good point. Covariance is still easy to have without any such fuss, so far as I can see, but having the one without the other is no good. I still think this at least bears further consideration. There could still be a solution in allowing contravariant overriding in this particular instance, i.e. having the user only need to implement test(Number) and having the bridge method just call that... since conceptually test(Integer) *should* have effectively been a bridge method *itself* to test(Number) anyway. If anything, it would be better this way regardless of the erasure issue imo, since it's just more strongly enforcing contravariance relationship encoded by the Predicate syntax. There are still problems, since of course suddenly allowing contravariant overrides in one specific scenario creates situations which behave inconsistently with people's current expectations e.g.: class Foo implements Predicate { public boolean test(Integer value) {return false;} } class Bar extends Foo implements Predicate { public boolean test(Number value) {return true;} } foo.test((Integer) i); // returns true instead of false when invoked on an instance of Foo! Now that we have default methods we couldn't even just limit the feature to interfaces to avoid the problem. The only remotely tenable solution would be to force users to explicitly override test(Integer) with a method which does nothing but forward the invocation to test(Number). This would solve the erasure/bridge ambiguity, as well as the general ban on contravariant overrides, but still isn't ideal just because it feels a bit clunky... Syntax to explicitly mark a method as a 'forwarding' method without having to specify a body would help, but that is clearly outside the scope of this proposal, and a no-go unless it could be justified in and of itself as worth the added language complexity... Any thoughts? Have I talked myself out of this? Are there other problems I've missed in rambling on which make this moot, or does that about cover it? Cheers, Eli On 27 October 2014 23:03, Remi Forax wrote: > > On 10/27/2014 11:52 PM, Dan Smith wrote: > >> On Oct 26, 2014, at 4:53 PM, elias vasylenko >>> wrote: >>> >>> Just a quick question/suggestion: it seems like a handy side-effect of >>> the proposed changes is the potential for relaxation of the limitation on >>> reimplementation of interfaces with different generic parametrisations, and >>> I'm wondering if you've considered this. >>> >>> For example, it should be possible to allow something like this: >>> >>> class Foo implements Predicate {} >>> >>> class Bar extends Foo implements Predicate {} >>> >>> Since declaration-site variance guarantees compatibility of the >>> overriding parametrisation. Of course we can't technically override >>> test(Integer) with test(Number)... but from an outsiders perspective I >>> don't see this as incompatible with current language design philosophy... >>> At any rate, covariance should be more straightforward >>> >>> I'm sure this would have come up if it hasn't already, but I couldn't >>> find any explicit mention of it. >>> >> That's a good idea, and not something we've looked into yet. Thanks for >> the suggestion. >> >> ?Dan >> > > The problem here is not a typing problem but an erasure problem, both > Predicate and Predicate require to generate a bridge > method but both test(Integer) and test(Number) have the same erasure > test(Object). So it's not possible without full reification to implement > that bridge. > > cheers, > R?mi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Oct 28 00:20:07 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 27 Oct 2014 17:20:07 -0700 Subject: Throws clause of default constructor In-Reply-To: <30874745-5BFB-440B-B0DF-C35DC99D37DE@oracle.com> References: <0FE04E01-F69B-449D-A6BD-0A17D4542009@edg.com> <544EBC96.8010509@oracle.com> <30874745-5BFB-440B-B0DF-C35DC99D37DE@oracle.com> Message-ID: <544EE137.2040805@oracle.com> JLS9 would benefit from informative text about why "no throws clause" turned into "a throws clause pertaining to unchecked exceptions only". For this reason, it would be good to elucidate "the rule is stricter than necessary" in JDK-8062234 itself. The 8.8.9 text should also formulate the body of the default ctor more precisely than "Otherwise, the default constructor simply invokes the superclass constructor with no arguments." As you indicate in JDK-8062234, we need to speak precisely about the superclass ctor invocation that's performed. One more thing. Consider the relationship of B's default ctor to A's explicit ctor: the presence of a throws clause is a first-order interaction, and the genericity of that clause is a second-order interaction. A third-order interaction is when B isn't a top-level class but rather an anonymous class extending A. Then, B has a default ctor per 15.9.5.1 - the spec of the body is OK, and the spec of the implicitly generated throws clause is still "correct" (no need to make a fuss about RuntimeException here), but is there a fourth-order interaction yet lurking? Alex On 10/27/2014 4:37 PM, Dan Smith wrote: > Ah, this is an interesting side-effect of improving inference for 'throws' type variables. > > First, here are the relevant rules about the default constructor of B (JLS 8.8.9): > > "The default constructor has no throws clauses" > > "the default constructor simply invokes the superclass constructor with no arguments" > > "It is a compile-time error if a default constructor is implicitly declared but the superclass does not have an accessible constructor that takes no arguments and has no throws clause." > > Taken literally, that last sentence means this is, trivially, an illegal program. But I don't think javac has ever taken it literally -- if I declare a superclass constructor that 'throws RuntimeException', no error occurs in 7 or 8. > > Here's a bug report for that: > https://bugs.openjdk.java.net/browse/JDK-8062234 > > Given that 'throws RuntimeException' is okay, note that the typing of the implicit 'super()' call in B's default constructor changed between 7 and 8. In 7, inference determined that T:=Throwable. In 8, inference determines that T:=RuntimeException. (See JLS 18.4.) > > So the change in errors is due to a change in inference, and is expected behavior. > > ?Dan > >> On Oct 27, 2014, at 3:43 PM, Alex Buckley wrote: >> >> Looks like a javac bug when the thrown type is a type variable. >> >> If A's ctor is simply "A() throws Throwable {}", then JDK8 javac reports the error for B's default ctor regardless of -source version. >> >> But make A's ctor generic and throw the type variable, and JDK8 javac only reports the error for B with -source 1.7 and below. >> >> In fact, javac cares whether T extends {Throwable,Exception} versus a subclass of Exception. If T extends a checked exception type like java.io.IOException, then JDK8 javac actually reports the error for B regardless of -source version. >> >> (All this on JDK8u25.) >> >> Alex >> >> On 10/27/2014 1:53 PM, John Spicer wrote: >>> This case gets an error with javac 7 and javac 8 with -source 1.7, but is accepted by javac 8 in normal mode. >>> >>> I wasn't able to find the JLS change that corresponds to this. >>> >>> Any pointers would be appreciated. >>> >>> Thanks, >>> >>> John. >>> >>> class A { >>> A() throws T {} >>> } >>> >>> class B extends A {} >>> > From forax at univ-mlv.fr Tue Oct 28 01:10:49 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 28 Oct 2014 02:10:49 +0100 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: References: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> <544ECF3C.1000008@univ-mlv.fr> Message-ID: <544EED19.7090800@univ-mlv.fr> On 10/28/2014 12:40 AM, Dan Smith wrote: >> On Oct 27, 2014, at 5:03 PM, Remi Forax wrote: >> >> >> On 10/27/2014 11:52 PM, Dan Smith wrote: >>>> On Oct 26, 2014, at 4:53 PM, elias vasylenko wrote: >>>> >>>> Just a quick question/suggestion: it seems like a handy side-effect of the proposed changes is the potential for relaxation of the limitation on reimplementation of interfaces with different generic parametrisations, and I'm wondering if you've considered this. >>>> >>>> For example, it should be possible to allow something like this: >>>> >>>> class Foo implements Predicate {} >>>> >>>> class Bar extends Foo implements Predicate {} >>>> >>>> Since declaration-site variance guarantees compatibility of the overriding parametrisation. Of course we can't technically override test(Integer) with test(Number)... but from an outsiders perspective I don't see this as incompatible with current language design philosophy... At any rate, covariance should be more straightforward >>>> >>>> I'm sure this would have come up if it hasn't already, but I couldn't find any explicit mention of it. >>> That's a good idea, and not something we've looked into yet. Thanks for the suggestion. >>> >>> ?Dan >> The problem here is not a typing problem but an erasure problem, both Predicate and Predicate require to generate a bridge method but both test(Integer) and test(Number) have the same erasure test(Object). So it's not possible without full reification to implement that bridge. > Haven't thought much about this, but can't the compiler just generate all the necessary signatures in Bar? > test(Number)Z: user's implementation > test(Integer)Z: bridge to test(Number)Z > test(Object)Z: bridge to test(Number)Z > > ?Dan see the example given by Elias, Foo requires a user defined implementation of test(Integer) and it's not obvious to me why Bar should override this method with a bridge, i.e. a bridge can override a user defined method (for the VM) only if the method called by the bridge override the user define method (for Java the language). R?mi From eliasvasylenko at gmail.com Tue Oct 28 01:21:46 2014 From: eliasvasylenko at gmail.com (elias vasylenko) Date: Tue, 28 Oct 2014 01:21:46 +0000 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: References: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> <544ECF3C.1000008@univ-mlv.fr> Message-ID: Am I correct that to just have the bridge method call the 'overriding' method would give the following behaviour?: Bar bar; Integer i; // ... bar.test(i); // false ((Foo) bar).test(i); // false ((Predicate) bar).test(i); // true I can see why this is undesirable, but fwiw I'd be okay with it... On 28 Oct 2014 00:19, "elias vasylenko" wrote: > Ah, good point. Covariance is still easy to have without any such fuss, so > far as I can see, but having the one without the other is no good. > > I still think this at least bears further consideration. There could still > be a solution in allowing contravariant overriding in this particular > instance, i.e. having the user only need to implement test(Number) and > having the bridge method just call that... since conceptually test(Integer) > *should* have effectively been a bridge method *itself* to test(Number) > anyway. If anything, it would be better this way regardless of the erasure > issue imo, since it's just more strongly enforcing contravariance > relationship encoded by the Predicate syntax. > > There are still problems, since of course suddenly allowing contravariant > overrides in one specific scenario creates situations which behave > inconsistently with people's current expectations e.g.: > > class Foo implements Predicate { > public boolean test(Integer value) {return false;} > } > > class Bar extends Foo implements Predicate { > public boolean test(Number value) {return true;} > } > > foo.test((Integer) i); // returns true instead of false when invoked > on an instance of Foo! > > Now that we have default methods we couldn't even just limit the feature > to interfaces to avoid the problem. > > The only remotely tenable solution would be to force users to explicitly > override test(Integer) with a method which does nothing but forward the > invocation to test(Number). This would solve the erasure/bridge ambiguity, > as well as the general ban on contravariant overrides, but still isn't > ideal just because it feels a bit clunky... Syntax to explicitly mark a > method as a 'forwarding' method without having to specify a body would > help, but that is clearly outside the scope of this proposal, and a no-go > unless it could be justified in and of itself as worth the added language > complexity... > > Any thoughts? Have I talked myself out of this? Are there other problems > I've missed in rambling on which make this moot, or does that about cover > it? > > Cheers, > > Eli > > On 27 October 2014 23:03, Remi Forax wrote: > >> >> On 10/27/2014 11:52 PM, Dan Smith wrote: >> >>> On Oct 26, 2014, at 4:53 PM, elias vasylenko >>>> wrote: >>>> >>>> Just a quick question/suggestion: it seems like a handy side-effect of >>>> the proposed changes is the potential for relaxation of the limitation on >>>> reimplementation of interfaces with different generic parametrisations, and >>>> I'm wondering if you've considered this. >>>> >>>> For example, it should be possible to allow something like this: >>>> >>>> class Foo implements Predicate {} >>>> >>>> class Bar extends Foo implements Predicate {} >>>> >>>> Since declaration-site variance guarantees compatibility of the >>>> overriding parametrisation. Of course we can't technically override >>>> test(Integer) with test(Number)... but from an outsiders perspective I >>>> don't see this as incompatible with current language design philosophy... >>>> At any rate, covariance should be more straightforward >>>> >>>> I'm sure this would have come up if it hasn't already, but I couldn't >>>> find any explicit mention of it. >>>> >>> That's a good idea, and not something we've looked into yet. Thanks for >>> the suggestion. >>> >>> ?Dan >>> >> >> The problem here is not a typing problem but an erasure problem, both >> Predicate and Predicate require to generate a bridge >> method but both test(Integer) and test(Number) have the same erasure >> test(Object). So it's not possible without full reification to implement >> that bridge. >> >> cheers, >> R?mi >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue Oct 28 03:49:18 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 27 Oct 2014 20:49:18 -0700 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: References: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> <544ECF3C.1000008@univ-mlv.fr> Message-ID: <0E0CF19C-12F9-4CFA-9D60-E58CDE064FFB@oracle.com> On Oct 27, 2014, at 4:40 PM, Dan Smith wrote: > Haven't thought much about this, but can't the compiler just generate all the necessary signatures in Bar? > test(Number)Z: user's implementation > test(Integer)Z: bridge to test(Number)Z > test(Object)Z: bridge to test(Number)Z If we can really go there, perhaps we can bridge int to Integer and vice versa. And then int to long too. And varargs. Slippery slope... ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Tue Oct 28 05:44:42 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 27 Oct 2014 23:44:42 -0600 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: References: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> <544ECF3C.1000008@univ-mlv.fr> Message-ID: <90E77CBF-0614-4A34-A380-431FDFC20656@oracle.com> > On Oct 27, 2014, at 6:19 PM, elias vasylenko wrote: > > There are still problems, since of course suddenly allowing contravariant overrides in one specific scenario creates situations which behave inconsistently with people's current expectations e.g.: > > class Foo implements Predicate { > public boolean test(Integer value) {return false;} > } > > class Bar extends Foo implements Predicate { > public boolean test(Number value) {return true;} > } > > foo.test((Integer) i); // returns true instead of false when invoked on an instance of Foo! I don't see what's wrong with just claiming Bar.test overrides Foo.test. It would take some work to sort out the details of such a rule, but that seems to me like the clear explanation of what's "really" going on in this program. If the programmer is upset because they really want two unrelated methods, I'm not sympathetic because the program would be malformed anyway -- a class can't have two unrelated methods that both override the same supertype method (this is enforced by 8.4.8.3, and makes sense because what would you expect when you called 'test(Object)'?). ?Dan From joel.franck at oracle.com Tue Oct 28 09:05:58 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Tue, 28 Oct 2014 10:05:58 +0100 Subject: RFR 8u: 8054448: (ann) Cannot reference field of inner class in an anonymous class Message-ID: <20141028090558.GA25013@oracle.com> Hi Can I get a review of the 8u backport of: 8054448: (ann) Cannot reference field of inner class in an anonymous class. Webrev: http://cr.openjdk.java.net/~jfranck/8054448/ Bug: https://bugs.openjdk.java.net/browse/JDK-8054448 The fix is to delay annotations handling until the scope for the innermost nested class is completely filled in. cheers /Joel From joel.franck at oracle.com Tue Oct 28 09:43:10 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 28 Oct 2014 10:43:10 +0100 Subject: crash with -Xjcov and union types In-Reply-To: References: <20141024123232.GD4891@oracle.com> Message-ID: Fix pushed, thanks for the patch. cheers /Joel On 25 okt 2014, at 00:46, Liam Miller-Cushon wrote: > On Fri, Oct 24, 2014 at 5:32 AM, Joel Borggren-Franck wrote: > A bit cleaner IMHO and should work the same. Works for you? > > Looks good to me. Thanks Joel. From maurizio.cimadamore at oracle.com Tue Oct 28 10:26:09 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 Oct 2014 10:26:09 +0000 Subject: RFR 8u: 8054448: (ann) Cannot reference field of inner class in an anonymous class In-Reply-To: <20141028090558.GA25013@oracle.com> References: <20141028090558.GA25013@oracle.com> Message-ID: <544F6F41.7060707@oracle.com> Looks good to me Maurizio On 28/10/14 09:05, Joel Borggren-Franck wrote: > Hi > > Can I get a review of the 8u backport of: 8054448: (ann) Cannot > reference field of inner class in an anonymous class. > > Webrev: http://cr.openjdk.java.net/~jfranck/8054448/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8054448 > > The fix is to delay annotations handling until the scope for the > innermost nested class is completely filled in. > > cheers > /Joel From eliasvasylenko at gmail.com Tue Oct 28 11:28:24 2014 From: eliasvasylenko at gmail.com (elias vasylenko) Date: Tue, 28 Oct 2014 11:28:24 +0000 Subject: JEP proposal: Improved variance for generic classes and interfaces In-Reply-To: <90E77CBF-0614-4A34-A380-431FDFC20656@oracle.com> References: <0C664877-D141-461C-B075-AEB6B902206E@oracle.com> <544ECF3C.1000008@univ-mlv.fr> <90E77CBF-0614-4A34-A380-431FDFC20656@oracle.com> Message-ID: > If the programmer is upset because they really want two unrelated methods, I'm not sympathetic because the program would be malformed anyway -- a class can't have two unrelated methods that both override the same supertype method (this is enforced by 8.4.8.3, and makes sense because what would you expect when you called 'test(Object)'?). I think I tend to agree with this. Seems like the behaviour would also be consistent for something like the following, where the erased signature of the overridden 'multitest' would be identical in Foo and Bar anyway: public interface Predicate { boolean test(T t); default boolean multitest(Collection t) {/*...*/} } On 28 October 2014 05:44, Dan Smith wrote: > > On Oct 27, 2014, at 6:19 PM, elias vasylenko > wrote: > > > > There are still problems, since of course suddenly allowing > contravariant overrides in one specific scenario creates situations which > behave inconsistently with people's current expectations e.g.: > > > > class Foo implements Predicate { > > public boolean test(Integer value) {return false;} > > } > > > > class Bar extends Foo implements Predicate { > > public boolean test(Number value) {return true;} > > } > > > > foo.test((Integer) i); // returns true instead of false when invoked > on an instance of Foo! > > I don't see what's wrong with just claiming Bar.test overrides Foo.test. > It would take some work to sort out the details of such a rule, but that > seems to me like the clear explanation of what's "really" going on in this > program. > > If the programmer is upset because they really want two unrelated methods, > I'm not sympathetic because the program would be malformed anyway -- a > class can't have two unrelated methods that both override the same > supertype method (this is enforced by 8.4.8.3, and makes sense because what > would you expect when you called 'test(Object)'?). > > ?Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.franck at oracle.com Tue Oct 28 12:59:43 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 28 Oct 2014 13:59:43 +0100 Subject: Request for review/advice from langtools team Re: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Message-ID: Hi Paul, Sorry for the delay. So if I understand this correctly, we get 4 warnings (and because of -Werror a build failure) in langtools when compiling vs Jdk 9, but need the casts because we bootstrap with Jdk 8. Looks good to me but I would prefer if you filed a bug on me for Jdk 10 for removing the SuppressWarnings and added comments pointing to the bug after the @SuppressWarnings annotations. That way I will remember to clean this up when we bootstrap with Jdk 9. cheers /Joel On 27 okt 2014, at 10:12, Paul Sandoz wrote: > Hi, > > Can someone from langtools kindly chime in with how to move this forward? > > https://bugs.openjdk.java.net/browse/JDK-4774077 > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-3/ > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch > > > On Oct 17, 2014, at 11:37 AM, Paul Sandoz wrote: > >> Hi, >> >> [Including compiler-dev, i am not on that list so please CC me if replying to just that list] >> >> > ... > > >> So Richard has a patch for that too: >> >> http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch >> >> This is required because in the bootstrap compilation phase a JDK without the co-variant overrides can be used. So the current solution is to suppress the warnings. Reviews from langtools gurus are very much appreciated. >> > > ? > > >> Ideally it would be nice to push all this under one issue, is that possible? If not i will have to create another issue and of course push to langtools before jdk. >> >> A internal CCC is also underway. >> > > This has be approved, with the comment that "@since 1.9" should be added to the doc of the new methods, which i have done in my copy of the patch. > > Thanks, > Paul. From paul.sandoz at oracle.com Wed Oct 29 08:51:37 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 Oct 2014 09:51:37 +0100 Subject: Request for review/advice from langtools team Re: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Message-ID: On Oct 28, 2014, at 1:59 PM, Joel Borggr?n-Franck wrote: > Hi Paul, > > Sorry for the delay. > > So if I understand this correctly, we get 4 warnings (and because of -Werror a build failure) in langtools when compiling vs Jdk 9, but need the casts because we bootstrap with Jdk 8. > Yes. > Looks good to me but I would prefer if you filed a bug on me for Jdk 10 for removing the SuppressWarnings and added comments pointing to the bug after the @SuppressWarnings annotations. That way I will remember to clean this up when we bootstrap with Jdk 9. > Ok, after i push i will log a new P4 bug and assign it to you. Thanks, Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From richard.warburton at gmail.com Wed Oct 29 12:27:04 2014 From: richard.warburton at gmail.com (Richard Warburton) Date: Wed, 29 Oct 2014 12:27:04 +0000 Subject: Possible javac bug around final and covariant overrides In-Reply-To: <544EB1D2.1080507@oracle.com> References: <53567039.2090103@redhat.com> <536BD955.7070904@oracle.com> <544EB1D2.1080507@oracle.com> Message-ID: Hi, Thanks for clarifying. Most appreciated. regards, Richard On 27 Oct 2014 20:57, "Vicente-Arturo Romero-Zaldivar" < vicente.romero at oracle.com> wrote: > On 10/27/2014 01:44 PM, Richard Warburton wrote: > > Hi, > > IMO this is a bug. I have filed >> https://bugs.openjdk.java.net/browse/JDK-8042785 to track it. >> >> Thanks for your report, >> > > Can I request a clarification for what's happened with this issue? It > looks like the following has happened: > > 1. The reported bug was fixed > 2. There was a the fix, caused a regression elsewhere. > 3. The fix was deleted. > 4. The bug was closed with a claim the bug was unverified. > > > 5. a new bug (https://bugs.openjdk.java.net/browse/JDK-8044734) was > created as a follow-up > 6. we are keeping track of this. > > Thanks, > Vicente > > > Perhaps I'm misunderstanding something here, but if the fix was reverted > then that means that the bug still remains an issue. > > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Oct 30 21:56:10 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Oct 2014 14:56:10 -0700 (PDT) Subject: JEP 222: Java Read-Eval-Print Loop (REPL) Message-ID: <20141030215610.77D2B3FFFB@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/222 - Mark From martijnverburg at gmail.com Fri Oct 31 09:05:48 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 31 Oct 2014 09:05:48 +0000 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: Hi all, Although I personally won't find much use for this, I'm really pleased to see this coming in to aid education and the teaching of Java for future generations. So, thanks! Martijn On 30 October 2014 21:56, wrote: > http://openjdk.java.net/jeps/222 Cheers, Martijn -------------- next part -------------- An HTML attachment was scrubbed... URL: