From srikanth.adayapalam at oracle.com Wed Jan 6 06:54:41 2016 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Wed, 06 Jan 2016 12:24:41 +0530 Subject: RFR: JDK-8146533: javac: No line numbers in compilation error Message-ID: <568CBA31.3020804@oracle.com> Hello ! Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8146533 made available at http://cr.openjdk.java.net/~sadayapalam/JDK-8146533/webrev.00/ This is basically an 8u76 candidate backport of an identical fix made for JDK9 via https://bugs.openjdk.java.net/browse/JDK-8145466 Reason for the review request being, the patch from JDK 9 does not mechanically apply as is after path shuffling. However, manual application does not call for any new changes. All relevant tests are grreen. Thanks! Srikanth. From maurizio.cimadamore at oracle.com Wed Jan 6 15:11:51 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 6 Jan 2016 15:11:51 +0000 Subject: RFR: JDK-8146533: javac: No line numbers in compilation error In-Reply-To: <568CBA31.3020804@oracle.com> References: <568CBA31.3020804@oracle.com> Message-ID: <568D2EB7.6020007@oracle.com> Looks good! Maurizio On 06/01/16 06:54, Srikanth wrote: > > Hello ! > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8146533 > made available at > http://cr.openjdk.java.net/~sadayapalam/JDK-8146533/webrev.00/ > > This is basically an 8u76 candidate backport of an identical fix made > for JDK9 > via https://bugs.openjdk.java.net/browse/JDK-8145466 > > Reason for the review request being, the patch from JDK 9 does not > mechanically > apply as is after path shuffling. However, manual application does not > call for any > new changes. > > All relevant tests are grreen. > > Thanks! > Srikanth. > From rob.mckenna at oracle.com Wed Jan 6 15:18:05 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 6 Jan 2016 15:18:05 +0000 Subject: Questions about JDK-8136353 "ClassValue preventing class unloading" In-Reply-To: References: Message-ID: <568D302D.4020001@oracle.com> I think this is better suited for compiler-dev. -Rob On 06/01/16 14:56, Craig Andrews wrote: > I apologize for contacting this list - I'm sure this isn't the "right > way" to contact the OpenJDK project, but I'm not clear what the "right > way" is. > > I'm hoping to raise https://bugs.openjdk.java.net/browse/JDK-8136353 > "ClassValue preventing class unloading" as I believe it's a significant > issue in ClassValue which is a blocker for its use in dynamic languages > (which is primiarly why ClassValue was introduced). I think the P5 > priority set on the bug now is way too low, perhaps you could consider > raising the priority? > > The source code in the issue description is incorrect; it doesn't > compile. Could you please attach the working test cases to the issue, so > future testers and developers can reproduce the problem? Here are links > to the 2 source code files: > https://issues.apache.org/jira/secure/attachment/12765900/CVTest.java > https://issues.apache.org/jira/secure/attachment/12765901/MyClassValue.java > (which of course should be directly attached to the openjdk issue > tracker issue, and not hyperlinked to the Groovy tracker) > > And to reproduce the issue, run: > $ javac MyClassValue.java && javac CVTest.java && mkdir -p t && jar cvf > t/t.jar MyClassValue*.class && rm MyClassValue*.class && > JAVA_OPTS=-Xmx4m java CVTest > and wait for the an error to occur, which is: > Exception in thread "main" java.lang.OutOfMemoryError: Compressed class > space > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:759) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:152) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:470) > at java.net.URLClassLoader.access$100(URLClassLoader.java:76) > at java.net.URLClassLoader$1.run(URLClassLoader.java:371) > at java.net.URLClassLoader$1.run(URLClassLoader.java:365) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:364) > at java.lang.ClassLoader.loadClass(ClassLoader.java:423) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > at CVTest.main(CVTest.java:12) > > The bug is reproducible on all JDK 8 and 9 builds (I tested up to JDK 9 > build 99). > > Based on my understanding of the situation from my research in the > Groovy bug that discovered the issue ( > https://issues.apache.org/jira/browse/GROOVY-6704 ) and some work > another person did with the YourKit profiler ( > https://www.yourkit.com/forum/viewtopic.php?f=3&t=12658 ), I suspect > that the fix for https://bugs.openjdk.java.net/browse/JDK-8032606 > "ClassValue.ClassValueMap.type is unused" is relevant; I think the > problem lies in the java.lang.Class.classValueMap implementation. > > Thank you, > ~Craig Andrews From Alan.Bateman at oracle.com Thu Jan 7 11:15:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jan 2016 11:15:35 +0000 Subject: 8049422: Remove @jdk.Exported Message-ID: <568E48D7.5030006@oracle.com> It's time to remove @jdk.Exported. As background, this annotation was introduced by JEP 179 in JDK 8 to document the supportness of JDK-specific APIs. It will become redundant and confusing once we bring the module system into JDK 9. The proposal in JEP 261 is to remove it and it seems saner to remove this in jdk9/dev in advance rather than trying to carry this in jigsaw/jake. The webrevs (top, jdk, langtools and nashorn repos) are here: http://cr.openjdk.java.net/~alanb/8049422/ The changes are trivial with all usages removed with find src -name "*.java" -exec sed -i '/@jdk.Exported/d' {} \; Skimming the .patch files should be enough to check for any blunders. The only "real" changes are the hg rm of Exported.java in the jdk repo, and the updates to modules.xml and the package list for the javadoc build in the top-level repo Note that jdeps has already been changed to not use this annotation so there are no jdeps changes required, only residual comments in one test. I think I got everything. Joe Darcy created this annotation and knows this removal is coming, I'll at least wait for Joe to review before pushing this change. -Alan. From daniel.fuchs at oracle.com Thu Jan 7 13:24:35 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 Jan 2016 14:24:35 +0100 Subject: 8049422: Remove @jdk.Exported In-Reply-To: <568E48D7.5030006@oracle.com> References: <568E48D7.5030006@oracle.com> Message-ID: <568E6713.8010509@oracle.com> Hi Alan, I looked at the jdk/ changes - these look good to me. I didn't spot any error in the sed result ;-) best regards, -- daniel On 07/01/16 12:15, Alan Bateman wrote: > > It's time to remove @jdk.Exported. > > As background, this annotation was introduced by JEP 179 in JDK 8 to > document the supportness of JDK-specific APIs. It will become redundant > and confusing once we bring the module system into JDK 9. The proposal > in JEP 261 is to remove it and it seems saner to remove this in jdk9/dev > in advance rather than trying to carry this in jigsaw/jake. > > The webrevs (top, jdk, langtools and nashorn repos) are here: > http://cr.openjdk.java.net/~alanb/8049422/ > > The changes are trivial with all usages removed with > find src -name "*.java" -exec sed -i '/@jdk.Exported/d' {} \; > > Skimming the .patch files should be enough to check for any blunders. > > The only "real" changes are the hg rm of Exported.java in the jdk repo, > and the updates to modules.xml and the package list for the javadoc > build in the top-level repo > > Note that jdeps has already been changed to not use this annotation so > there are no jdeps changes required, only residual comments in one test. > > I think I got everything. Joe Darcy created this annotation and knows > this removal is coming, I'll at least wait for Joe to review before > pushing this change. > > -Alan. From mandy.chung at oracle.com Thu Jan 7 18:42:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Jan 2016 10:42:02 -0800 Subject: 8049422: Remove @jdk.Exported In-Reply-To: <568E48D7.5030006@oracle.com> References: <568E48D7.5030006@oracle.com> Message-ID: <9A76AF15-A631-4524-A10F-3BD2C1666A08@oracle.com> > On Jan 7, 2016, at 3:15 AM, Alan Bateman wrote: > > > It's time to remove @jdk.Exported. > > As background, this annotation was introduced by JEP 179 in JDK 8 to document the supportness of JDK-specific APIs. It will become redundant and confusing once we bring the module system into JDK 9. The proposal in JEP 261 is to remove it and it seems saner to remove this in jdk9/dev in advance rather than trying to carry this in jigsaw/jake. > > The webrevs (top, jdk, langtools and nashorn repos) are here: > http://cr.openjdk.java.net/~alanb/8049422/ I looked through this change and I think you got everything. Removing @jdk.Exported is okay. Supported JDK-specific API is currently documented in modules.xml as an interim solution and it will be replaced the module definitions when the module system is in. Mandy From joe.darcy at oracle.com Fri Jan 8 03:12:44 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 07 Jan 2016 19:12:44 -0800 Subject: 8049422: Remove @jdk.Exported In-Reply-To: <568E48D7.5030006@oracle.com> References: <568E48D7.5030006@oracle.com> Message-ID: <568F292C.3030807@oracle.com> Looks fine Alan; cheers, -Joe On 1/7/2016 3:15 AM, Alan Bateman wrote: > > It's time to remove @jdk.Exported. > > As background, this annotation was introduced by JEP 179 in JDK 8 to > document the supportness of JDK-specific APIs. It will become > redundant and confusing once we bring the module system into JDK 9. > The proposal in JEP 261 is to remove it and it seems saner to remove > this in jdk9/dev in advance rather than trying to carry this in > jigsaw/jake. > > The webrevs (top, jdk, langtools and nashorn repos) are here: > http://cr.openjdk.java.net/~alanb/8049422/ > > The changes are trivial with all usages removed with > find src -name "*.java" -exec sed -i '/@jdk.Exported/d' {} \; > > Skimming the .patch files should be enough to check for any blunders. > > The only "real" changes are the hg rm of Exported.java in the jdk > repo, and the updates to modules.xml and the package list for the > javadoc build in the top-level repo > > Note that jdeps has already been changed to not use this annotation so > there are no jdeps changes required, only residual comments in one test. > > I think I got everything. Joe Darcy created this annotation and knows > this removal is coming, I'll at least wait for Joe to review before > pushing this change. > > -Alan. From chris.hegarty at oracle.com Fri Jan 8 06:08:35 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Jan 2016 06:08:35 +0000 Subject: 8049422: Remove @jdk.Exported In-Reply-To: <568E48D7.5030006@oracle.com> References: <568E48D7.5030006@oracle.com> Message-ID: <0E23E72E-8360-4CBB-BC5A-610FC94CD2F4@oracle.com> On 7 Jan 2016, at 11:15, Alan Bateman wrote: > > It's time to remove @jdk.Exported. > > As background, this annotation was introduced by JEP 179 in JDK 8 to document the supportness of JDK-specific APIs. It will become redundant and confusing once we bring the module system into JDK 9. The proposal in JEP 261 is to remove it and it seems saner to remove this in jdk9/dev in advance rather than trying to carry this in jigsaw/jake. > > The webrevs (top, jdk, langtools and nashorn repos) are here: > http://cr.openjdk.java.net/~alanb/8049422/ The change looks good to me Alan. -Chris. > The changes are trivial with all usages removed with > find src -name "*.java" -exec sed -i '/@jdk.Exported/d' {} \; > > Skimming the .patch files should be enough to check for any blunders. > > The only "real" changes are the hg rm of Exported.java in the jdk repo, and the updates to modules.xml and the package list for the javadoc build in the top-level repo > > Note that jdeps has already been changed to not use this annotation so there are no jdeps changes required, only residual comments in one test. > > I think I got everything. Joe Darcy created this annotation and knows this removal is coming, I'll at least wait for Joe to review before pushing this change. > > -Alan. From joe.darcy at oracle.com Sat Jan 9 00:30:19 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 8 Jan 2016 16:30:19 -0800 Subject: JDK 9 RFR of JDK-8146724:Problem list jdk/internal/jimage/JImageReadTest.java Message-ID: <5690549B.2060700@oracle.com> Hello, Please review the patch below to problem list jdk/internal/jimage/JImageReadTest.java The test has been consistently failing across platforms since the push for JDK-8144226 Sjavac's handling of include/exclude patterns is buggy, redundant and inconsistent Correcting the actual test failing is being tracked under JDK-8146712 jdk/internal/jimage/JImageReadTest.java fails on all platforms Thanks, -Joe diff -r dc56076a794a test/ProblemList.txt --- a/test/ProblemList.txt Fri Jan 08 14:06:17 2016 -0800 +++ b/test/ProblemList.txt Fri Jan 08 16:27:53 2016 -0800 @@ -384,6 +384,13 @@ ############################################################################ +# core_tools + +# 8146712 +jdk/internal/jimage/JImageReadTest.java generic-all + +############################################################################ + # svc_tools # 8031482 From jonathan.gibbons at oracle.com Sat Jan 9 02:08:38 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 08 Jan 2016 18:08:38 -0800 Subject: JDK 9 RFR of JDK-8146724:Problem list jdk/internal/jimage/JImageReadTest.java In-Reply-To: <5690549B.2060700@oracle.com> References: <5690549B.2060700@oracle.com> Message-ID: <56906BA6.4080203@oracle.com> Approved. -- Jon On 01/08/2016 04:30 PM, joe darcy wrote: > Hello, > > Please review the patch below to problem list > > jdk/internal/jimage/JImageReadTest.java > > The test has been consistently failing across platforms since the push > for > > JDK-8144226 Sjavac's handling of include/exclude patterns is > buggy, redundant and inconsistent > > Correcting the actual test failing is being tracked under > > JDK-8146712 jdk/internal/jimage/JImageReadTest.java fails on all > platforms > > Thanks, > > -Joe > > diff -r dc56076a794a test/ProblemList.txt > --- a/test/ProblemList.txt Fri Jan 08 14:06:17 2016 -0800 > +++ b/test/ProblemList.txt Fri Jan 08 16:27:53 2016 -0800 > @@ -384,6 +384,13 @@ > > ############################################################################ > > > +# core_tools > + > +# 8146712 > +jdk/internal/jimage/JImageReadTest.java generic-all > + > +############################################################################ > > + > # svc_tools > > # 8031482 From anthony.vanelverdinghe at gmail.com Sun Jan 10 10:34:58 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Sun, 10 Jan 2016 11:34:58 +0100 Subject: Proposal to enhance the basic try-with-resources translation Message-ID: <569233D2.3010806@gmail.com> Hi I would like to propose an enhanced translation for the basic try-with-resources statement ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.20.3.1 ), such that: - there's a possibility that #suppressedExc suppresses #primaryExc, governed by the following precedence rule: Error > RuntimeException > checked Exception So e.g. if #suppressedExc is an Error and #primaryExc is an IOException, then it's the Error that will be thrown with the IOException as its suppressed Throwable. The motivation for this, is allowing Errors and RuntimeExceptions to "blow up" the program. In my experience, it's rare for exception-handling code to check the suppressed Throwables and act accordingly. So this effectively means that suppressed Errors / RuntimeExceptions are typically handled the same way as their suppressing (checked) exceptions. - any Throwables that may occur during an invocation of addSuppressed are ignored The motivation here, is guaranteeing that exception information is never lost. Currently it's possible (though very unlikely, I admit) that an OutOfMemoryError occurs at that point (e.g. due to the creation of the ArrayList). In this case, both #primaryExc and #suppressedExc are lost, and it might be very hard to find out what went wrong. In order to implement this translation, I'd propose a new instance method on Throwable: public void withSuppressed(AutoCloseable resource) The motivation for this method, is that it's useful in itself. Moreover, it helps to simplify the translation & results in a smaller bytecode footprint than the current translation. In short, the method closes the resource argument and behaves as described above. A possible implementation is: public void withSuppressed(AutoCloseable resource) { try { resource.close(); } catch (RuntimeException e) { try { if (this instanceof Error || this instanceof RuntimeException) { addSuppressed(e); } else { e.addSuppressed(this); throw e; } } catch (Throwable ignored) { } } catch (Exception e) { try { addSuppressed(e); } catch (Throwable ignored) { } } catch (Error e) { try { if (this instanceof Error) { addSuppressed(e); } else { e.addSuppressed(this); throw e; } } catch (Throwable ignored) { } } } The updated translation for the basic try-with-resources statement would then become as follows: { final {VariableModifierNoFinal} R Identifier = Expression; Throwable #primaryExc = null; try ResourceSpecification_tail Block catch (Throwable #t) { #primaryExc = #t; throw #t; } finally { if (Identifier != null) { if (#primaryExc != null) { #primaryExc.withSuppressed(Identifier); } else { Identifier.close(); } } } } What are your thoughts on this proposal? Kind regards, Anthony From alex.buckley at oracle.com Mon Jan 11 18:12:51 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 11 Jan 2016 10:12:51 -0800 Subject: Proposal to enhance the basic try-with-resources translation In-Reply-To: <569233D2.3010806@gmail.com> References: <569233D2.3010806@gmail.com> Message-ID: <5693F0A3.9000800@oracle.com> On 1/10/2016 2:34 AM, Anthony Vanelverdinghe wrote: > I would like to propose an enhanced translation for the basic > try-with-resources statement ( > https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.20.3.1 > ), such that: > > - there's a possibility that #suppressedExc suppresses #primaryExc, > governed by the following precedence rule: Error > RuntimeException > > checked Exception > So e.g. if #suppressedExc is an Error and #primaryExc is an IOException, > then it's the Error that will be thrown with the IOException as its > suppressed Throwable. The motivation for this, is allowing Errors and > RuntimeExceptions to "blow up" the program. In my experience, it's rare > for exception-handling code to check the suppressed Throwables and act > accordingly. So this effectively means that suppressed Errors / > RuntimeExceptions are typically handled the same way as their > suppressing (checked) exceptions. The intent of suppressed exceptions was precisely that exceptions from resource closing do not blow up the program, and should be viewed as subsidiary to an exception thrown by the try block. As such, this is not an enhanced translation of try-with-resources, but rather a redesign. It is not behaviorally compatible with Java SE 7/8. Alex From andrej.golovnin at gmail.com Tue Jan 12 21:11:17 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Tue, 12 Jan 2016 22:11:17 +0100 Subject: Possible regression bug in the compiler. Message-ID: <90A0E199-A59C-49A0-A556-61B74EE060E7@gmail.com> Hi all, consider following example: interface Value { } class ValueHolder implements Value { } class Model { Model(T v) { System.out.println("Called constructor with generics"); } Model(Value v) { System.out.println("Called constructor with interface"); } public static void main(String... argv) { ValueHolder holder = new ValueHolder(); Model m0 = new Model<>(holder); Model m1 = new Model(holder); } } When I compile and execute it with Java 7, then it outputs: Called constructor with generics Called constructor with generics When I compile and execute it with Java 8 and Java 9, then I get this output: Called constructor with interface Called constructor with generics In Java 7 the compiler chooses in both cases, with the diamond operand and with the provided type parameter, the constructor with generics. In Java 8 and 9 only when I provide the type parameter. Is it a bug or desired change? From my standpoint of view there should be no difference, if I use the diamond operand or not. Best regards, Andrej Golovnin From maurizio.cimadamore at oracle.com Wed Jan 13 14:28:40 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 13 Jan 2016 14:28:40 +0000 Subject: Possible regression bug in the compiler. In-Reply-To: <90A0E199-A59C-49A0-A556-61B74EE060E7@gmail.com> References: <90A0E199-A59C-49A0-A556-61B74EE060E7@gmail.com> Message-ID: <56965F18.70809@oracle.com> Hi, I've take a deep look at this; I'm inclined to believe that it was an issue in JDK 7 that was later addressed in 8 and 9. The way diamond works (as specified in the JLS), is that for each constructor, we derive a generic method - in the case of your Model class, the following methods will be derived: m(Z z) //this corresponds to Model(T v) m(Value v) //this corresponds to Model(Value) Now, both methods are clearly applicable with a ValueHolder argument. So the question is - which is most specific? Following the process in the JLS, the most specific method should be m(Value) - because: * you can call m(Z) with a Value argument * you cannot call m(Value) with a Z argument [where Z is _not_ treated as an inference variable] So, m(Value) is most specific, and therefore, its associated constructor - Model(Value) is the one selected for the instance creation expression. That said, I understand where you are coming from, and I do find this a bit surprising - after all the inferred type for the instance creation expression is Model, and the type Model has two constructors: Model(ValueHolder) Model(Value) of which the former seems clearly the most specific (and is in fact selected in the absence of diamond). So, the key difference with diamond, is that the most specific selection occurs _ahead_ of inference variable instantiation - therefore the compiler doesn't have enough info to realize that Model(T) is truly most specific. This behavior can be also reproduced without diamond: interface Value { } class ValueHolder implements Value { } class Model { static Model make(Z z) { System.err.println("Class"); return null; } static Model make(Value v) { System.err.println("Interface"); return null; } public static void main(String... argv) { ValueHolder holder = new ValueHolder(); Model m0 = Model.make(holder); } } Which prints 'Interface'. That said, I will leave this with our spec experts - to determine as to whether something has to be tweaked here. Thanks Maurizio On 12/01/16 21:11, Andrej Golovnin wrote: > Hi all, > > consider following example: > > interface Value { > } > > class ValueHolder implements Value { > } > > class Model { > > Model(T v) { > System.out.println("Called constructor with generics"); > } > > Model(Value v) { > System.out.println("Called constructor with interface"); > } > > public static void main(String... argv) { > ValueHolder holder = new ValueHolder(); > Model m0 = new Model<>(holder); > Model m1 = new Model(holder); > } > > } > > When I compile and execute it with Java 7, then it outputs: > > Called constructor with generics > Called constructor with generics > > When I compile and execute it with Java 8 and Java 9, then I get this output: > > Called constructor with interface > Called constructor with generics > > In Java 7 the compiler chooses in both cases, with the diamond > operand and with the provided type parameter, the constructor with generics. > In Java 8 and 9 only when I provide the type parameter. > > Is it a bug or desired change? > From my standpoint of view there should be no difference, > if I use the diamond operand or not. > > Best regards, > Andrej Golovnin From andrej.golovnin at gmail.com Wed Jan 13 21:17:05 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 13 Jan 2016 22:17:05 +0100 Subject: Possible regression bug in the compiler. In-Reply-To: <56965F18.70809@oracle.com> References: <90A0E199-A59C-49A0-A556-61B74EE060E7@gmail.com> <56965F18.70809@oracle.com> Message-ID: Hi Maurizio, thank you very much for taking time to look at it and for the detailed explanation! The most frustrating part of this problem is that you notice it only at runtime because the compiler does not raise a warning or an error. Anyway we have changed now our code to avoid this problem. Thanks and best regards, Andrej Golovnin > On 13.01.2016, at 15:28, Maurizio Cimadamore wrote: > > Hi, > I've take a deep look at this; I'm inclined to believe that it was an issue in JDK 7 that was later addressed in 8 and 9. > > The way diamond works (as specified in the JLS), is that for each constructor, we derive a generic method - in the case of your Model class, the following methods will be derived: > > m(Z z) //this corresponds to Model(T v) > m(Value v) //this corresponds to Model(Value) > > Now, both methods are clearly applicable with a ValueHolder argument. So the question is - which is most specific? > > Following the process in the JLS, the most specific method should be m(Value) - because: > > * you can call m(Z) with a Value argument > * you cannot call m(Value) with a Z argument [where Z is _not_ treated as an inference variable] > > So, m(Value) is most specific, and therefore, its associated constructor - Model(Value) is the one selected for the instance creation expression. > > That said, I understand where you are coming from, and I do find this a bit surprising - after all the inferred type for the instance creation expression is Model, and the type Model has two constructors: > > Model(ValueHolder) > Model(Value) > > of which the former seems clearly the most specific (and is in fact selected in the absence of diamond). > > So, the key difference with diamond, is that the most specific selection occurs _ahead_ of inference variable instantiation - therefore the compiler doesn't have enough info to realize that Model(T) is truly most specific. > > This behavior can be also reproduced without diamond: > > interface Value { > } > > class ValueHolder implements Value { > } > > class Model { > static Model make(Z z) { System.err.println("Class"); return null; } > static Model make(Value v) { System.err.println("Interface"); return null; } > > public static void main(String... argv) { > ValueHolder holder = new ValueHolder(); > Model m0 = Model.make(holder); > } > } > > Which prints 'Interface'. > > > That said, I will leave this with our spec experts - to determine as to whether something has to be tweaked here. > > Thanks > Maurizio > > On 12/01/16 21:11, Andrej Golovnin wrote: >> Hi all, >> >> consider following example: >> >> interface Value { >> } >> >> class ValueHolder implements Value { >> } >> >> class Model { >> >> Model(T v) { >> System.out.println("Called constructor with generics"); >> } >> >> Model(Value v) { >> System.out.println("Called constructor with interface"); >> } >> >> public static void main(String... argv) { >> ValueHolder holder = new ValueHolder(); >> Model m0 = new Model<>(holder); >> Model m1 = new Model(holder); >> } >> >> } >> >> When I compile and execute it with Java 7, then it outputs: >> >> Called constructor with generics >> Called constructor with generics >> >> When I compile and execute it with Java 8 and Java 9, then I get this output: >> >> Called constructor with interface >> Called constructor with generics >> >> In Java 7 the compiler chooses in both cases, with the diamond >> operand and with the provided type parameter, the constructor with generics. >> In Java 8 and 9 only when I provide the type parameter. >> >> Is it a bug or desired change? >> From my standpoint of view there should be no difference, >> if I use the diamond operand or not. >> >> Best regards, >> Andrej Golovnin > From cushon at google.com Fri Jan 15 19:48:26 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 15 Jan 2016 11:48:26 -0800 Subject: Change in inference behaviour after JDK-8078093 Message-ID: It reproduces in jdk9-dev at head, and bisects to the fix for JDK-8078093 [1][2]. Earlier versions of javac do not report the error. Is this a bug? === Test.java === abstract class Test { interface One {} interface Two { I get(); } interface Three {} interface Four {} , L extends Three> Four f(Class raw, E destination) { return g(raw, destination.get()); } abstract , L extends Three> Four g( Class labelClass, I destinationId); } === $ javac Test.java error: incompatible types: inference variable I has incompatible bounds return g(raw, destination.get()); ^ equality constraints: CAP#1 lower bounds: One where I,E,L are type-variables: I extends One declared in method g(Class,I) E extends Two declared in method g(Class,I) L extends Three declared in method g(Class,I) where CAP#1 is a fresh type-variable: CAP#1 extends One from capture of ? 1 error [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/286fc9270404 [2] https://bugs.openjdk.java.net/browse/JDK-8078093 -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Jan 15 20:03:04 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 15 Jan 2016 21:03:04 +0100 (CET) Subject: backport JDK-8130506 to 8 ? In-Reply-To: <1971833120.2290573.1452886198252.JavaMail.zimbra@u-pem.fr> Message-ID: <1181486545.2292046.1452888184841.JavaMail.zimbra@u-pem.fr> Hi guys, the code I use to demonstrate how to create your own dynamically typed language on top of the JVM now triggers JDK-8130506 [1] :( i think the bug could have appear last year but last year none of my students was using IntelliJ IDEA, so the bug stay hidden. I wonder if the corresponding patch could be backported to 8, or maybe Attila and me are the only one to call MethodHandle.invoke inside a lambda ? cheers, R?mi [1] https://bugs.openjdk.java.net/browse/JDK-8130506 From jonathan.gibbons at oracle.com Fri Jan 15 20:52:36 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 15 Jan 2016 12:52:36 -0800 Subject: backport JDK-8130506 to 8 ? In-Reply-To: <1181486545.2292046.1452888184841.JavaMail.zimbra@u-pem.fr> References: <1181486545.2292046.1452888184841.JavaMail.zimbra@u-pem.fr> Message-ID: <56995C14.4030509@oracle.com> R?mi, There's maybe 3 parts to this: 1. Is it conceptually reasonable to backport the fix 2. Is it a relatively easy backport (i.e. does the fix for 9 apply reasonably easily, or do we need a different fix, specific to 8) 3. Making it happen If folk can weigh in on 1 and 2, and the answer to both questions is "yes", we can make 3 happen easily enough. -- Jon On 01/15/2016 12:03 PM, Remi Forax wrote: > Hi guys, > the code I use to demonstrate how to create your own dynamically typed language on top of the JVM now triggers JDK-8130506 [1] :( > i think the bug could have appear last year but last year none of my students was using IntelliJ IDEA, so the bug stay hidden. > > I wonder if the corresponding patch could be backported to 8, or maybe Attila and me are the only one to call MethodHandle.invoke inside a lambda ? > > cheers, > R?mi > > [1] https://bugs.openjdk.java.net/browse/JDK-8130506 From maurizio.cimadamore at oracle.com Fri Jan 15 22:25:16 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Jan 2016 22:25:16 +0000 Subject: Change in inference behaviour after JDK-8078093 In-Reply-To: References: Message-ID: <569971CC.5090305@oracle.com> Hi Liam, it's likely a regression in handling of unchecked calls introduced by that fix. On a closer look, the problem seems to be caused by the fact that the code in Attr::checkMethod reuses the same Warner object (a problem that keeps biting us :-() - as the new code shares more state than the previous speculative-based implementation, the compiler ends up resetting the Warner when checking 'destination.get()' so that the compiler loses track of the fact that it had already encountered an unchecked warning during the applicability check of the first argument (Class <: Class) - subsequently, the call is not flagged as unchecked, and a spurious inference error is then thrown. I will fix it. Filed: https://bugs.openjdk.java.net/browse/JDK-8147493 Thanks Maurizio On 15/01/16 19:48, Liam Miller-Cushon wrote: > It reproduces in jdk9-dev at head, and bisects to the fix for > JDK-8078093 [1][2]. Earlier versions of javac do not report the error. > Is this a bug? > > === Test.java === > abstract class Test { > interface One {} > interface Two { I get(); } > interface Three {} > interface Four {} > > , L extends Three> Four f(Class raw, E > destination) { > return g(raw, destination.get()); > } > > abstract , L extends Three> > Four g( > Class labelClass, I destinationId); > } > === > > $ javac Test.java > error: incompatible types: inference variable I has incompatible bounds > return g(raw, destination.get()); > ^ > equality constraints: CAP#1 > lower bounds: One > where I,E,L are type-variables: > I extends One declared in method g(Class,I) > E extends Two declared in method g(Class,I) > L extends Three declared in method g(Class,I) > where CAP#1 is a fresh type-variable: > CAP#1 extends One from capture of ? > 1 error > > [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/286fc9270404 > [2] https://bugs.openjdk.java.net/browse/JDK-8078093 From cushon at google.com Sat Jan 16 01:20:41 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 15 Jan 2016 17:20:41 -0800 Subject: Change in inference behaviour after JDK-8078093 In-Reply-To: <569971CC.5090305@oracle.com> References: <569971CC.5090305@oracle.com> Message-ID: Thanks Maurizio! For what it's worth, it looks like this only affects a very small amount of code. On Fri, Jan 15, 2016 at 2:25 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi Liam, > it's likely a regression in handling of unchecked calls introduced by that > fix. > > On a closer look, the problem seems to be caused by the fact that the code > in Attr::checkMethod reuses the same Warner object (a problem that keeps > biting us :-() - as the new code shares more state than the previous > speculative-based implementation, the compiler ends up resetting the Warner > when checking 'destination.get()' so that the compiler loses track of the > fact that it had already encountered an unchecked warning during the > applicability check of the first argument (Class <: Class) - > subsequently, the call is not flagged as unchecked, and a spurious > inference error is then thrown. > > I will fix it. > > Filed: https://bugs.openjdk.java.net/browse/JDK-8147493 > > Thanks > Maurizio > > > On 15/01/16 19:48, Liam Miller-Cushon wrote: > >> It reproduces in jdk9-dev at head, and bisects to the fix for JDK-8078093 >> [1][2]. Earlier versions of javac do not report the error. Is this a bug? >> >> === Test.java === >> abstract class Test { >> interface One {} >> interface Two { I get(); } >> interface Three {} >> interface Four {} >> >> , L extends Three> Four f(Class raw, E >> destination) { >> return g(raw, destination.get()); >> } >> >> abstract , L extends Three> Four >> g( >> Class labelClass, I destinationId); >> } >> === >> >> $ javac Test.java >> error: incompatible types: inference variable I has incompatible bounds >> return g(raw, destination.get()); >> ^ >> equality constraints: CAP#1 >> lower bounds: One >> where I,E,L are type-variables: >> I extends One declared in method g(Class,I) >> E extends Two declared in method g(Class,I) >> L extends Three declared in method g(Class,I) >> where CAP#1 is a fresh type-variable: >> CAP#1 extends One from capture of ? >> 1 error >> >> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/286fc9270404 >> [2] https://bugs.openjdk.java.net/browse/JDK-8078093 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sat Jan 16 17:47:35 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 16 Jan 2016 18:47:35 +0100 (CET) Subject: backport JDK-8130506 to 8 ? In-Reply-To: <56995C14.4030509@oracle.com> References: <1181486545.2292046.1452888184841.JavaMail.zimbra@u-pem.fr> <56995C14.4030509@oracle.com> Message-ID: <1420766947.2526153.1452966455361.JavaMail.zimbra@u-pem.fr> answsers inlined, ----- Mail original ----- > De: "Jonathan Gibbons" > ?: compiler-dev at openjdk.java.net > Envoy?: Vendredi 15 Janvier 2016 21:52:36 > Objet: Re: backport JDK-8130506 to 8 ? > > R?mi, Hi Jon, > > There's maybe 3 parts to this: > > 1. Is it conceptually reasonable to backport the fix You can not do a methodHandle.invoke() inside a lambda in 8, so it's reasonable to backport the fix. Now, there are not a lot of people that uses java.lang.invoke API and the fact that the workaround is easy, replace the lambda by an inner class, backporting the fix may not worth it. > 2. Is it a relatively easy backport (i.e. does the fix for 9 apply reasonably > easily, or do we need a different fix, specific to 8) I believe the patch applies cleanly (minus the line number). > 3. Making it happen > > If folk can weigh in on 1 and 2, and the answer to both questions is "yes", > we can make 3 happen easily enough. > > -- Jon R?mi > > > > On 01/15/2016 12:03 PM, Remi Forax wrote: > > Hi guys, > > the code I use to demonstrate how to create your own dynamically typed > > language on top of the JVM now triggers JDK-8130506 [1] :( > > i think the bug could have appear last year but last year none of my > > students was using IntelliJ IDEA, so the bug stay hidden. > > > > I wonder if the corresponding patch could be backported to 8, or maybe > > Attila and me are the only one to call MethodHandle.invoke inside a lambda > > ? > > > > cheers, > > R?mi > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8130506 > > From maurizio.cimadamore at oracle.com Sat Jan 16 21:30:51 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 16 Jan 2016 21:30:51 +0000 Subject: backport JDK-8130506 to 8 ? In-Reply-To: <1420766947.2526153.1452966455361.JavaMail.zimbra@u-pem.fr> References: <1181486545.2292046.1452888184841.JavaMail.zimbra@u-pem.fr> <56995C14.4030509@oracle.com> <1420766947.2526153.1452966455361.JavaMail.zimbra@u-pem.fr> Message-ID: <569AB68B.20705@oracle.com> I will leave the definitive answer to Srikanth, but from the looks of it, the patch seems trivial, so it doesn't seem crazy to backport it. Maurizio On 16/01/16 17:47, Remi Forax wrote: > answsers inlined, > > ----- Mail original ----- >> De: "Jonathan Gibbons" >> ?: compiler-dev at openjdk.java.net >> Envoy?: Vendredi 15 Janvier 2016 21:52:36 >> Objet: Re: backport JDK-8130506 to 8 ? >> >> R?mi, > Hi Jon, > >> There's maybe 3 parts to this: >> >> 1. Is it conceptually reasonable to backport the fix > You can not do a methodHandle.invoke() inside a lambda in 8, so it's reasonable to backport the fix. > Now, there are not a lot of people that uses java.lang.invoke API and the fact that the workaround is easy, > replace the lambda by an inner class, backporting the fix may not worth it. > >> 2. Is it a relatively easy backport (i.e. does the fix for 9 apply reasonably >> easily, or do we need a different fix, specific to 8) > I believe the patch applies cleanly (minus the line number). > >> 3. Making it happen >> >> If folk can weigh in on 1 and 2, and the answer to both questions is "yes", >> we can make 3 happen easily enough. >> >> -- Jon > R?mi > >> >> >> On 01/15/2016 12:03 PM, Remi Forax wrote: >>> Hi guys, >>> the code I use to demonstrate how to create your own dynamically typed >>> language on top of the JVM now triggers JDK-8130506 [1] :( >>> i think the bug could have appear last year but last year none of my >>> students was using IntelliJ IDEA, so the bug stay hidden. >>> >>> I wonder if the corresponding patch could be backported to 8, or maybe >>> Attila and me are the only one to call MethodHandle.invoke inside a lambda >>> ? >>> >>> cheers, >>> R?mi >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8130506 >> From cushon at google.com Sun Jan 17 00:48:54 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Sat, 16 Jan 2016 16:48:54 -0800 Subject: Change in inference behaviour after JDK-8078093 In-Reply-To: References: <569971CC.5090305@oracle.com> Message-ID: I found a couple of other changes related to the fix for JDK-8078093 that might be distinct problems. I reported the first one as JI-9028659, but thought it was worth mentioning here also: 1) This is another unchecked invocation, but now it looks like target type inference isn't being performed on `f(null)`. abstract class Test { abstract A f(A t); abstract Class g(Class x, String y); abstract void h(C t); void m(Class raw) { h(g(raw, f(null))); } } Test.java:8: error: method g in class Test cannot be applied to given types; h(g(raw, f(null))); ^ required: Class,String found: Class,Object reason: cannot infer type-variable(s) B (argument mismatch; Object cannot be converted to String) where B is a type-variable: B extends Object declared in method g(Class,String) 2) abstract class Test { interface I { void t(O clazz); } abstract I a(Class clazz); abstract B b(Class t); abstract C c(C a); Object f(Iterable xs) { return c(c(new Object() { void g(Class clazz) { a(clazz).t(b(clazz)); } })); } } Test.java:11: error: method t in interface I cannot be applied to given types; a(clazz).t(b(clazz)); ^ required: T#1 found: T#1 reason: argument mismatch; inference variable B has incompatible bounds equality constraints: T#2 upper bounds: T#1,Object where T#1,O,B,T#2 are type-variables: T#1 extends Object declared in method g(Class) O extends Object declared in interface I B extends Object declared in method b(Class) T#2 extends Object declared in method g(Class) On Fri, Jan 15, 2016 at 5:20 PM, Liam Miller-Cushon wrote: > Thanks Maurizio! For what it's worth, it looks like this only affects a > very small amount of code. > > On Fri, Jan 15, 2016 at 2:25 PM, Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Hi Liam, >> it's likely a regression in handling of unchecked calls introduced by >> that fix. >> >> On a closer look, the problem seems to be caused by the fact that the >> code in Attr::checkMethod reuses the same Warner object (a problem that >> keeps biting us :-() - as the new code shares more state than the previous >> speculative-based implementation, the compiler ends up resetting the Warner >> when checking 'destination.get()' so that the compiler loses track of the >> fact that it had already encountered an unchecked warning during the >> applicability check of the first argument (Class <: Class) - >> subsequently, the call is not flagged as unchecked, and a spurious >> inference error is then thrown. >> >> I will fix it. >> >> Filed: https://bugs.openjdk.java.net/browse/JDK-8147493 >> >> Thanks >> Maurizio >> >> >> On 15/01/16 19:48, Liam Miller-Cushon wrote: >> >>> It reproduces in jdk9-dev at head, and bisects to the fix for >>> JDK-8078093 [1][2]. Earlier versions of javac do not report the error. Is >>> this a bug? >>> >>> === Test.java === >>> abstract class Test { >>> interface One {} >>> interface Two { I get(); } >>> interface Three {} >>> interface Four {} >>> >>> , L extends Three> Four f(Class raw, E >>> destination) { >>> return g(raw, destination.get()); >>> } >>> >>> abstract , L extends Three> Four >>> g( >>> Class labelClass, I destinationId); >>> } >>> === >>> >>> $ javac Test.java >>> error: incompatible types: inference variable I has incompatible bounds >>> return g(raw, destination.get()); >>> ^ >>> equality constraints: CAP#1 >>> lower bounds: One >>> where I,E,L are type-variables: >>> I extends One declared in method g(Class,I) >>> E extends Two declared in method g(Class,I) >>> L extends Three declared in method g(Class,I) >>> where CAP#1 is a fresh type-variable: >>> CAP#1 extends One from capture of ? >>> 1 error >>> >>> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/286fc9270404 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8078093 >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Mon Jan 18 04:40:36 2016 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 18 Jan 2016 10:10:36 +0530 Subject: backport JDK-8130506 to 8 ? In-Reply-To: <569AB68B.20705@oracle.com> References: <1181486545.2292046.1452888184841.JavaMail.zimbra@u-pem.fr> <56995C14.4030509@oracle.com> <1420766947.2526153.1452966455361.JavaMail.zimbra@u-pem.fr> <569AB68B.20705@oracle.com> Message-ID: <569C6CC4.9020108@oracle.com> The fix is straightforward and applies cleanly after path shuffling. The workaround of having to use inner classes in lieu of lambda seems painful relative to the ease of backport. I'll organize this. Thanks! Srikanth On Sunday 17 January 2016 03:00 AM, Maurizio Cimadamore wrote: > I will leave the definitive answer to Srikanth, but from the looks of > it, the patch seems trivial, so it doesn't seem crazy to backport it. > > Maurizio > > On 16/01/16 17:47, Remi Forax wrote: >> answsers inlined, >> >> ----- Mail original ----- >>> De: "Jonathan Gibbons" >>> ?: compiler-dev at openjdk.java.net >>> Envoy?: Vendredi 15 Janvier 2016 21:52:36 >>> Objet: Re: backport JDK-8130506 to 8 ? >>> >>> R?mi, >> Hi Jon, >> >>> There's maybe 3 parts to this: >>> >>> 1. Is it conceptually reasonable to backport the fix >> You can not do a methodHandle.invoke() inside a lambda in 8, so it's >> reasonable to backport the fix. >> Now, there are not a lot of people that uses java.lang.invoke API and >> the fact that the workaround is easy, >> replace the lambda by an inner class, backporting the fix may not >> worth it. >> >>> 2. Is it a relatively easy backport (i.e. does the fix for 9 apply >>> reasonably >>> easily, or do we need a different fix, specific to 8) >> I believe the patch applies cleanly (minus the line number). >> >>> 3. Making it happen >>> >>> If folk can weigh in on 1 and 2, and the answer to both questions is >>> "yes", >>> we can make 3 happen easily enough. >>> >>> -- Jon >> R?mi >> >>> >>> >>> On 01/15/2016 12:03 PM, Remi Forax wrote: >>>> Hi guys, >>>> the code I use to demonstrate how to create your own dynamically typed >>>> language on top of the JVM now triggers JDK-8130506 [1] :( >>>> i think the bug could have appear last year but last year none of my >>>> students was using IntelliJ IDEA, so the bug stay hidden. >>>> >>>> I wonder if the corresponding patch could be backported to 8, or maybe >>>> Attila and me are the only one to call MethodHandle.invoke inside a >>>> lambda >>>> ? >>>> >>>> cheers, >>>> R?mi >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8130506 >>> > From srikanth.adayapalam at oracle.com Mon Jan 18 06:52:33 2016 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 18 Jan 2016 12:22:33 +0530 Subject: Questions about type annotation on type casts. In-Reply-To: <566B3D5D.1050005@oracle.com> References: <5668FD3D.5050403@oracle.com> <566A1800.1010104@oracle.com> <5E729BF9-AB1B-4C7F-ACAC-10EE5108F922@oracle.com> <566B3D5D.1050005@oracle.com> Message-ID: <569C8BB1.9080002@oracle.com> On Saturday 12 December 2015 02:47 AM, Alex Buckley wrote: > On 12/11/2015 12:47 PM, John Rose wrote: >> On Dec 10, 2015, at 4:25 PM, Alex Buckley > > wrote: >>> For the "(@T int)10" expression above, it would be the ldc that pushes >>> 10. For "(float)1", it would be the fconst_1. For an auto-unbox like >>> "int x = (int)new Integer(1);", it would be the invokevirtual on >>> Integer.intValue(). >>> >>> In effect, I'm recommending the offset of the last instruction of the >>> chunk of code generated to evaluate the expression being cast. >>> However, if javac prefers to record the offset of first instruction, I >>> would not complain. >> >> There is something especially useful about pointing at the bytecode (or >> one of the bytecodes) that creates the finished expression value (or at >> least moves it somewhere: astore, areturn, etc). >> >> By contrast, some earlier instruction which begins to execute the whole >> expression is not securely related to the value whose type has been >> annotated. Loose language about "chunk of code" makes me nervous that >> we might get dangling annotations. >> >> For example, if I annotate the first instruction of the whole expression >> `(@T int)a[i++]`, the annotation reader will see a logically unrelated >> operation on `i`. Surely pointing `@T` at `i++` is worse than merely a >> QOI problem. The meaning of `@T` might be "I know this is an even >> number", and there's no way to get from the `i` bytecode to see the >> `a[i++]`, and a reader might erroneously conclude that the programmer is >> saying `i` is an even number. > > Especially since this expression would produce the same bytecode: > > a[(@T int)i++] > > This might be a "big" QOI problem, but it's still "just" QOI, since > there's no compiler spec which javac is breaking. > > I suspect that javac "realizes" quite early that it doesn't need an > explicit instruction to implement the cast operator; and is aware that > the instruction stream for the expression being cast might be > complicated; and so is unwilling to hang on to @T throughout the > stream's generation; and so gets @T off its plate by recording the > most-eager offset, not the most-accurate. If most-accurate would > require a major rewrite of some javac phase, then it's probably > justified. Srikanth, please advise. Sorry for the delayed response on this: (1) The computation of the byte code offset for the type annotation, (2) the emission of byte codes for the expression being typecast (3) the determination whether a checkcast is required in the class file or not and (d) the emission of checkcast if required - all happen in the same phase (codegen) in the same order in which they are enumerated here, all in a span of half a dozen lines of code that is amenable for reordering in a seemingly straightforward manner. ATM, the computation of the annotation offset precedes translation of expression being typecast resulting in the big QOI problem called out earlier. By computing the offset just after translation of the expression, the offset would point to the checkcast instruction when present and when absent would point to the offset where the checkcast expression would have been had it not been optimized away - i.e pointing to the earliest offset where the fully finished expression value is at the top of stack. This appears to me to a better arrangement than what we have at present. Also note that we have the same eager offset computation issue with instanceof - I don't see the compilers optimizing away instanceof instructions as of now though. Thanks! Srikanth > > Alex From forax at univ-mlv.fr Mon Jan 18 07:55:02 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 18 Jan 2016 08:55:02 +0100 (CET) Subject: backport JDK-8130506 to 8 ? In-Reply-To: <569C6CC4.9020108@oracle.com> References: <1181486545.2292046.1452888184841.JavaMail.zimbra@u-pem.fr> <56995C14.4030509@oracle.com> <1420766947.2526153.1452966455361.JavaMail.zimbra@u-pem.fr> <569AB68B.20705@oracle.com> <569C6CC4.9020108@oracle.com> Message-ID: <712644641.30402.1453103702420.JavaMail.zimbra@u-pem.fr> Thanks Srikanth. R?mi ----- Mail original ----- > De: "Srikanth" > ?: compiler-dev at openjdk.java.net > Envoy?: Lundi 18 Janvier 2016 05:40:36 > Objet: Re: backport JDK-8130506 to 8 ? > > The fix is straightforward and applies cleanly after path shuffling. The > workaround of having > to use inner classes in lieu of lambda seems painful relative to the > ease of backport. > > I'll organize this. > > Thanks! > Srikanth > > On Sunday 17 January 2016 03:00 AM, Maurizio Cimadamore wrote: > > I will leave the definitive answer to Srikanth, but from the looks of > > it, the patch seems trivial, so it doesn't seem crazy to backport it. > > > > Maurizio > > > > On 16/01/16 17:47, Remi Forax wrote: > >> answsers inlined, > >> > >> ----- Mail original ----- > >>> De: "Jonathan Gibbons" > >>> ?: compiler-dev at openjdk.java.net > >>> Envoy?: Vendredi 15 Janvier 2016 21:52:36 > >>> Objet: Re: backport JDK-8130506 to 8 ? > >>> > >>> R?mi, > >> Hi Jon, > >> > >>> There's maybe 3 parts to this: > >>> > >>> 1. Is it conceptually reasonable to backport the fix > >> You can not do a methodHandle.invoke() inside a lambda in 8, so it's > >> reasonable to backport the fix. > >> Now, there are not a lot of people that uses java.lang.invoke API and > >> the fact that the workaround is easy, > >> replace the lambda by an inner class, backporting the fix may not > >> worth it. > >> > >>> 2. Is it a relatively easy backport (i.e. does the fix for 9 apply > >>> reasonably > >>> easily, or do we need a different fix, specific to 8) > >> I believe the patch applies cleanly (minus the line number). > >> > >>> 3. Making it happen > >>> > >>> If folk can weigh in on 1 and 2, and the answer to both questions is > >>> "yes", > >>> we can make 3 happen easily enough. > >>> > >>> -- Jon > >> R?mi > >> > >>> > >>> > >>> On 01/15/2016 12:03 PM, Remi Forax wrote: > >>>> Hi guys, > >>>> the code I use to demonstrate how to create your own dynamically typed > >>>> language on top of the JVM now triggers JDK-8130506 [1] :( > >>>> i think the bug could have appear last year but last year none of my > >>>> students was using IntelliJ IDEA, so the bug stay hidden. > >>>> > >>>> I wonder if the corresponding patch could be backported to 8, or maybe > >>>> Attila and me are the only one to call MethodHandle.invoke inside a > >>>> lambda > >>>> ? > >>>> > >>>> cheers, > >>>> R?mi > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8130506 > >>> > > > > From john.r.rose at oracle.com Mon Jan 18 08:29:44 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 18 Jan 2016 00:29:44 -0800 Subject: Questions about type annotation on type casts. In-Reply-To: <569C8BB1.9080002@oracle.com> References: <5668FD3D.5050403@oracle.com> <566A1800.1010104@oracle.com> <5E729BF9-AB1B-4C7F-ACAC-10EE5108F922@oracle.com> <566B3D5D.1050005@oracle.com> <569C8BB1.9080002@oracle.com> Message-ID: On Jan 17, 2016, at 10:52 PM, Srikanth wrote: > > By computing the offset just after translation of the expression, the offset would point to the checkcast instruction > when present and when absent would point to the offset where the checkcast expression would have been had it not been optimized > away - i.e pointing to the earliest offset where the fully finished expression value is at the top of stack. > > This appears to me to a better arrangement than what we have at present. > > Also note that we have the same eager offset computation issue with instanceof - I don't see the compilers optimizing away > instanceof instructions as of now though. That sounds good. One could think of the optimized checkcast as a zero-length opcode that leaves TOS unchanged. If instanceof is optimized, it will turn into an iconst_[01]. That would be the instruction to point at, I suppose. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jan 18 12:10:07 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 18 Jan 2016 12:10:07 +0000 Subject: Change in inference behaviour after JDK-8078093 In-Reply-To: References: <569971CC.5090305@oracle.com> Message-ID: <569CD61F.7000806@oracle.com> Thanks for the extra examples; the first one has the same underlying cause and is fixed by the patch I was working at. The second failure is more subtle, and has to due with javac erroneously caching the results of attribution inside nested class definitions that will be thrown away - as a result we get spurious constraints mentioning two sets of inference variables. I filed another bug for this: https://bugs.openjdk.java.net/browse/JDK-8147546 Maurizio On 17/01/16 00:48, Liam Miller-Cushon wrote: > I found a couple of other changes related to the fix for JDK-8078093 > that might be distinct problems. I reported the first one as > JI-9028659, but thought it was worth mentioning here also: > > 1) This is another unchecked invocation, but now it looks like target > type inference isn't being performed on `f(null)`. > > abstract class Test { > > abstract A f(A t); > abstract Class g(Class x, String y); > abstract void h(C t); > > void m(Class raw) { > h(g(raw, f(null))); > } > } > > Test.java:8: error: method g in class Test cannot be applied to given > types; > h(g(raw, f(null))); > ^ > required: Class,String > found: Class,Object > reason: cannot infer type-variable(s) B > (argument mismatch; Object cannot be converted to String) > where B is a type-variable: > B extends Object declared in method g(Class,String) > > 2) > > abstract class Test { > > interface I { void t(O clazz); } > abstract I a(Class clazz); > abstract B b(Class t); > abstract C c(C a); > > Object f(Iterable xs) { > return c(c(new Object() { > void g(Class clazz) { > a(clazz).t(b(clazz)); > } > })); > } > } > > Test.java:11: error: method t in interface I cannot be applied to > given types; > a(clazz).t(b(clazz)); > ^ > required: T#1 > found: T#1 > reason: argument mismatch; inference variable B has incompatible bounds > equality constraints: T#2 > upper bounds: T#1,Object > where T#1,O,B,T#2 are type-variables: > T#1 extends Object declared in method g(Class) > O extends Object declared in interface I > B extends Object declared in method b(Class) > T#2 extends Object declared in method g(Class) > > On Fri, Jan 15, 2016 at 5:20 PM, Liam Miller-Cushon > wrote: > > Thanks Maurizio! For what it's worth, it looks like this only > affects a very small amount of code. > > On Fri, Jan 15, 2016 at 2:25 PM, Maurizio Cimadamore > > wrote: > > Hi Liam, > it's likely a regression in handling of unchecked calls > introduced by that fix. > > On a closer look, the problem seems to be caused by the fact > that the code in Attr::checkMethod reuses the same Warner > object (a problem that keeps biting us :-() - as the new code > shares more state than the previous speculative-based > implementation, the compiler ends up resetting the Warner when > checking 'destination.get()' so that the compiler loses track > of the fact that it had already encountered an unchecked > warning during the applicability check of the first argument > (Class <: Class) - subsequently, the call is not flagged as > unchecked, and a spurious inference error is then thrown. > > I will fix it. > > Filed: https://bugs.openjdk.java.net/browse/JDK-8147493 > > Thanks > Maurizio > > > On 15/01/16 19:48, Liam Miller-Cushon wrote: > > It reproduces in jdk9-dev at head, and bisects to the fix > for JDK-8078093 [1][2]. Earlier versions of javac do not > report the error. Is this a bug? > > === Test.java === > abstract class Test { > interface One {} > interface Two { I get(); } > interface Three {} > interface Four {} > > , L extends Three> Four f(Class > raw, E destination) { > return g(raw, destination.get()); > } > > abstract , L extends > Three> Four g( > Class labelClass, I destinationId); > } > === > > $ javac Test.java > error: incompatible types: inference variable I has > incompatible bounds > return g(raw, destination.get()); > ^ > equality constraints: CAP#1 > lower bounds: One > where I,E,L are type-variables: > I extends One declared in method g(Class,I) > E extends Two declared in method g(Class,I) > L extends Three declared in method g(Class,I) > where CAP#1 is a fresh type-variable: > CAP#1 extends One from capture of ? > 1 error > > [1] > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/286fc9270404 > [2] https://bugs.openjdk.java.net/browse/JDK-8078093 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Jan 20 00:10:30 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 19 Jan 2016 16:10:30 -0800 (PST) Subject: Questions about type annotation on type casts. Message-ID: I agree that the delayed offset computation is good. A consideration is the JVMS 4.7.20 target_info item which "denotes precisely which type in a declaration or expression is annotated": - For an annotated type in a cast expression, we're in good shape. The offset is deliberately not specified in terms of a concrete 'checkcast' but rather in looser terms: "the bytecode instruction corresponding to the cast expression". (http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.20.1-100-J) - For an annotation type in an instanceof expression, we're in less good shape. We never imagined that 'instanceof' or 'new' expressions in the language would be optimized, so the offset is specified to assume those bytecodes exist. (http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.20.1-100-I) It would be proper to file a specification/vm bug to loosen "the instanceof bytecode instruction corresponding to the instanceof expression" by dropping the first 'instanceof'. Alex ----- Original Message ----- From: john.r.rose at oracle.com To: srikanth.adayapalam at oracle.com Cc: compiler-dev at openjdk.java.net Sent: Monday, January 18, 2016 12:31:13 AM GMT -08:00 US/Canada Pacific Subject: Re: Questions about type annotation on type casts. On Jan 17, 2016, at 10:52 PM, Srikanth < srikanth.adayapalam at oracle.com > wrote: By computing the offset just after translation of the expression, the offset would point to the checkcast instruction when present and when absent would point to the offset where the checkcast expression would have been had it not been optimized away - i.e pointing to the earliest offset where the fully finished expression value is at the top of stack. This appears to me to a better arrangement than what we have at present. Also note that we have the same eager offset computation issue with instanceof - I don't see the compilers optimizing away instanceof instructions as of now though. That sounds good. One could think of the optimized checkcast as a zero-length opcode that leaves TOS unchanged. If instanceof is optimized, it will turn into an iconst_[01]. That would be the instruction to point at, I suppose. ? John From cushon at google.com Wed Jan 20 00:49:13 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 19 Jan 2016 16:49:13 -0800 Subject: -XD-relax doesn't work Message-ID: I think that -XD-relax has been broken since JDK8. My understanding is that it was added in the jsr14 era, so maybe it should just be removed? The fix is: diff -r 6149fc30cd71 src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java Thu Jan 14 12:03:24 2016 -0800 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java Tue Jan 19 16:34:56 2016 -0800 @@ -1281,6 +1281,7 @@ return; if (relax) { + compileStates.put(env, CompileState.FLOW); results.add(env); return; } Repro: $ cat Test.java class Test {} $ javac -XD-relax Test.java An exception has occurred in the compiler (1.9.0-internal). Please file a bug against the Java compiler via the Java bug reporting page ( http://bugreport.java.com) after checking the Bug Database ( http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.AssertionError: The current compile state [ATTR] of class Test is previous to FLOW at com.sun.tools.javac.util.Assert.error(Assert.java:162) at com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:937) at com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:512) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:744) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:491) at com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:977) at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1455) at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1326) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:871) at com.sun.tools.javac.main.Main.compile(Main.java:257) at com.sun.tools.javac.main.Main.compile(Main.java:142) at com.sun.tools.javac.Main.compile(Main.java:55) at com.sun.tools.javac.Main.main(Main.java:41) -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jan 20 01:03:43 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 20 Jan 2016 01:03:43 +0000 Subject: -XD-relax doesn't work In-Reply-To: References: Message-ID: <569EDCEF.20805@oracle.com> Thanks I'll add that to the list of flags to cleanup :-) Maurizio On 20/01/16 00:49, Liam Miller-Cushon wrote: > I think that -XD-relax has been broken since JDK8. My understanding is > that it was added in the jsr14 era, so maybe it should just be removed? > > The fix is: > > diff -r 6149fc30cd71 > src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java > Thu Jan 14 12:03:24 2016 -0800 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java > Tue Jan 19 16:34:56 2016 -0800 > @@ -1281,6 +1281,7 @@ > return; > > if (relax) { > + compileStates.put(env, CompileState.FLOW); > results.add(env); > return; > } > > Repro: > > $ cat Test.java > class Test {} > $ javac -XD-relax Test.java > An exception has occurred in the compiler (1.9.0-internal). Please > file a bug against the Java compiler via the Java bug reporting page > (http://bugreport.java.com) after checking the Bug Database > (http://bugs.java.com) for duplicates. Include your program and the > following diagnostic in your report. Thank you. > java.lang.AssertionError: The current compile state [ATTR] of class > Test is previous to FLOW > at com.sun.tools.javac.util.Assert.error(Assert.java:162) > at > com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:937) > at > com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:512) > at > com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:744) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at > com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:491) > at > com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:977) > at > com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1455) > at > com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1326) > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:871) > at com.sun.tools.javac.main.Main.compile(Main.java:257) > at com.sun.tools.javac.main.Main.compile(Main.java:142) > at com.sun.tools.javac.Main.compile(Main.java:55) > at com.sun.tools.javac.Main.main(Main.java:41) From cushon at google.com Wed Jan 20 01:31:52 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 19 Jan 2016 17:31:52 -0800 Subject: -XD-relax doesn't work In-Reply-To: <569EDCEF.20805@oracle.com> References: <569EDCEF.20805@oracle.com> Message-ID: Thanks, I'll avoid using it :) On Tue, Jan 19, 2016 at 5:03 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Thanks > I'll add that to the list of flags to cleanup :-) > > Maurizio > > > On 20/01/16 00:49, Liam Miller-Cushon wrote: > >> I think that -XD-relax has been broken since JDK8. My understanding is >> that it was added in the jsr14 era, so maybe it should just be removed? >> >> The fix is: >> >> diff -r 6149fc30cd71 >> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java >> Thu Jan 14 12:03:24 2016 -0800 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java >> Tue Jan 19 16:34:56 2016 -0800 >> @@ -1281,6 +1281,7 @@ >> return; >> >> if (relax) { >> + compileStates.put(env, CompileState.FLOW); >> results.add(env); >> return; >> } >> >> Repro: >> >> $ cat Test.java >> class Test {} >> $ javac -XD-relax Test.java >> An exception has occurred in the compiler (1.9.0-internal). Please file a >> bug against the Java compiler via the Java bug reporting page ( >> http://bugreport.java.com) after checking the Bug Database ( >> http://bugs.java.com) for duplicates. Include your program and the >> following diagnostic in your report. Thank you. >> java.lang.AssertionError: The current compile state [ATTR] of class Test >> is previous to FLOW >> at com.sun.tools.javac.util.Assert.error(Assert.java:162) >> at >> com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:937) >> at >> com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:512) >> at >> com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:744) >> at >> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) >> at >> com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:491) >> at >> com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:977) >> at >> com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1455) >> at >> com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1326) >> at >> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:871) >> at com.sun.tools.javac.main.Main.compile(Main.java:257) >> at com.sun.tools.javac.main.Main.compile(Main.java:142) >> at com.sun.tools.javac.Main.compile(Main.java:55) >> at com.sun.tools.javac.Main.main(Main.java:41) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jan 20 10:29:59 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 20 Jan 2016 10:29:59 +0000 Subject: -XD-relax doesn't work In-Reply-To: References: <569EDCEF.20805@oracle.com> Message-ID: <569F61A7.1080200@oracle.com> On 20/01/16 01:31, Liam Miller-Cushon wrote: > Thanks, I'll avoid using it :) > Meta-question - what were you using it for? Maurizio > On Tue, Jan 19, 2016 at 5:03 PM, Maurizio Cimadamore > > wrote: > > Thanks > I'll add that to the list of flags to cleanup :-) > > Maurizio > > > On 20/01/16 00:49, Liam Miller-Cushon wrote: > > I think that -XD-relax has been broken since JDK8. My > understanding is that it was added in the jsr14 era, so maybe > it should just be removed? > > The fix is: > > diff -r 6149fc30cd71 > src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java > Thu Jan 14 12:03:24 2016 -0800 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java > Tue Jan 19 16:34:56 2016 -0800 > @@ -1281,6 +1281,7 @@ > return; > > if (relax) { > + compileStates.put(env, CompileState.FLOW); > results.add(env); > return; > } > > Repro: > > $ cat Test.java > class Test {} > $ javac -XD-relax Test.java > An exception has occurred in the compiler (1.9.0-internal). > Please file a bug against the Java compiler via the Java bug > reporting page (http://bugreport.java.com) after checking the > Bug Database (http://bugs.java.com) for duplicates. Include > your program and the following diagnostic in your report. > Thank you. > java.lang.AssertionError: The current compile state [ATTR] of > class Test is previous to FLOW > at com.sun.tools.javac.util.Assert.error(Assert.java:162) > at > com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:937) > at > com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:512) > at > com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:744) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at > com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:491) > at > com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:977) > at > com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1455) > at > com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1326) > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:871) > at com.sun.tools.javac.main.Main.compile(Main.java:257) > at com.sun.tools.javac.main.Main.compile(Main.java:142) > at com.sun.tools.javac.Main.compile(Main.java:55) > at com.sun.tools.javac.Main.main(Main.java:41) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jan 20 13:47:59 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Jan 2016 21:47:59 +0800 Subject: Interface with a Builder with a Factory and inheritance Message-ID: <0FD239D5-20D6-4E38-A5E0-44B8ADB4DAEE@oracle.com> I am working on an Interface with a Builder with a Factory, and involving inheritance. The actual case can be viewed here [1], but I've distilled everything below in a single file. I've never written something with so many <> symbols. Although the code works, I am not sure if those ?s are used correctly, and there is still a warning $ javac -Xlint A1.java A1.java:4: warning: [unchecked] unchecked cast B2 BImpl = (B2)f.getB(); ^ required: B2 found: B where CAP#1,CAP#2 are fresh type-variables: CAP#1 extends I from capture of ? extends I CAP#2 extends B from capture of ? extends B 1 warning $ java A1 How can I make this warning going away? Thanks Max -- public class A1 { public static void main(String[] args) throws Exception { F f = new Impl(); B2 BImpl = (B2)f.getB(); I2 dad = BImpl.setName("N").setColor("C").build(null); I2 son = BImpl.setName("n").setColor("c").build(dad); System.out.println(dad); System.out.println(son); } // Base interface and builder interface I { String name(); } interface B > { T setName(String s); S build(S parent); } // Extended interface and builder interface I2 extends I { String color(); } interface B2> extends B { T setColor(String s); } // Builder factory interface interface F { B > getB(); } // Implementation static class Impl implements F { static class C implements I2 { String color, name; public String color() { return color; } C(String name, String color) { this.color = color; this.name = name; } public String name() { return name; } public String toString() { return "<" + name + "," + color + ">"; } } static class BImpl implements B2 { String color; String name; public BImpl setColor(String s) { this.color = s; return this; } public BImpl setName(String s) { this.name = s; return this; } public I2 build(I2 parent) { if (parent == null) { return new C(name, color); } else { return new C(parent.name() + name, parent.color() + color); } } } public B > getB() { return new BImpl(); } } } [1] http://cr.openjdk.java.net/~weijun/8058778/webrev.09/specdiff/java/security/cert/package-summary.html From maurizio.cimadamore at oracle.com Wed Jan 20 14:10:46 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 20 Jan 2016 14:10:46 +0000 Subject: Interface with a Builder with a Factory and inheritance In-Reply-To: <0FD239D5-20D6-4E38-A5E0-44B8ADB4DAEE@oracle.com> References: <0FD239D5-20D6-4E38-A5E0-44B8ADB4DAEE@oracle.com> Message-ID: <569F9566.7020700@oracle.com> So, there's a short answer and a long answer :-) The short answer is to simply add this line: @SuppressWarnings("unchecked") before the variable declaration - as in: @SuppressWarnings("unchecked") B2 BImpl = (B2)f.getB(); This should help in removing the warning. That said, I think this warning also reveals a potential design issue in your classes; without diving too much in the details of your code, I note that you want factories for B - where B is a generic class with two type-variable. Unfortunately the factory interface is very simple, and does not fully reflect those constraints - i.e. an instance of F can return any B, regardless of the parameterization; I don't think that's correct. I think that instead of: interface F { B > getB(); } You might want something more precise, like: interface F { B getB(); } And then, Impl would become as follows: static class Impl implements F { ... @Override public B2 getB() { return new BImpl(); } } And the code that now is throwing a warning would simply become: B2 BImpl = f.getB(); //no cast needed I'm not saying that this is 100% the code you want - but I'm trying to point out how it could be made more precise when it comes to types. Maurizio On 20/01/16 13:47, Wang Weijun wrote: > I am working on an Interface with a Builder with a Factory, and involving inheritance. The actual case can be viewed here [1], but I've distilled everything below in a single file. > > I've never written something with so many <> symbols. Although the code works, I am not sure if those ?s are used correctly, and there is still a warning > > $ javac -Xlint A1.java > A1.java:4: warning: [unchecked] unchecked cast > B2 BImpl = (B2)f.getB(); > ^ > required: B2 > found: B > where CAP#1,CAP#2 are fresh type-variables: > CAP#1 extends I from capture of ? extends I > CAP#2 extends B from capture of ? extends B > 1 warning > $ java A1 > > > > How can I make this warning going away? > > Thanks > Max > > -- > > public class A1 { > public static void main(String[] args) throws Exception { > F f = new Impl(); > B2 BImpl = (B2)f.getB(); > I2 dad = BImpl.setName("N").setColor("C").build(null); > I2 son = BImpl.setName("n").setColor("c").build(dad); > System.out.println(dad); > System.out.println(son); > } > > // Base interface and builder > interface I { String name(); } > interface B > { > T setName(String s); > S build(S parent); > } > > // Extended interface and builder > interface I2 extends I { String color(); } > interface B2> extends B { > T setColor(String s); > } > > // Builder factory interface > interface F { > B > getB(); > } > > // Implementation > static class Impl implements F { > static class C implements I2 { > String color, name; > > public String color() { > return color; > } > > C(String name, String color) { > this.color = color; > this.name = name; > } > > public String name() { > return name; > } > > public String toString() { > return "<" + name + "," + color + ">"; > } > } > > static class BImpl implements B2 { > String color; > String name; > > public BImpl setColor(String s) { > this.color = s; > return this; > } > > public BImpl setName(String s) { > this.name = s; > return this; > } > > public I2 build(I2 parent) { > if (parent == null) { > return new C(name, color); > } else { > return new C(parent.name() + name, parent.color() + color); > } > } > } > > public B > getB() { > return new BImpl(); > } > } > } > > [1] http://cr.openjdk.java.net/~weijun/8058778/webrev.09/specdiff/java/security/cert/package-summary.html From weijun.wang at oracle.com Wed Jan 20 14:44:36 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Jan 2016 22:44:36 +0800 Subject: Interface with a Builder with a Factory and inheritance In-Reply-To: <569F9566.7020700@oracle.com> References: <0FD239D5-20D6-4E38-A5E0-44B8ADB4DAEE@oracle.com> <569F9566.7020700@oracle.com> Message-ID: Cool! > On Jan 20, 2016, at 10:10 PM, Maurizio Cimadamore wrote: > > You might want something more precise, like: > > interface F > { > B getB(); > } > > > And then, Impl would become as follows: > > static class Impl implements F { > ... > @Override > public B2 getB() { > return new BImpl(); > } > > } > > And the code that now is throwing a warning would simply become: > > B2 BImpl = f.getB(); //no cast needed I see an error A1.java:4: error: incompatible types: B cannot be converted to B2 B2 BImpl = f.getB(); ^ where CAP#1 is a fresh type-variable: CAP#1 extends B from capture of ? 1 error But you remind me I should write interface F> { T getB(); } static class Impl implements F> { public B2 getB() { return new BImpl(); } } F> f = new Impl(); B2 BImpl = f.getB(); and now there is no warning. (I still think those ?s are evil) That said, my current work is adding B/B2/getB to existing APIs, and F was an old non-generics class. So maybe your short answer is best for me. Thanks Max > > > I'm not saying that this is 100% the code you want - but I'm trying to point out how it could be made more precise when it comes to types. > > Maurizio From erik.joelsson at oracle.com Thu Jan 21 10:19:39 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Jan 2016 11:19:39 +0100 Subject: RFR: JDK-8147930: Langtools test Makefile still requires special make in Cygwin Message-ID: <56A0B0BB.8020904@oracle.com> The langtools test Makefile doesn't work in Cygwin with the default make. It still expects the specially built gnu make which handles ':' in path names and particularly in rule declarations. The cause of the failure is JCK_HOME, which on Windows defaults to a string starting with "J:/". Bug: https://bugs.openjdk.java.net/browse/JDK-8147930 Patch: diff -r 1fd828240c4d test/Makefile --- a/test/Makefile +++ b/test/Makefile @@ -412,7 +412,15 @@ fi # Check to make sure these directories exist -check-jck: $(JCK_HOME) $(PRODUCT_HOME) +check-jck: + if [ ! -d '$(JCK_HOME)' ]; then \ + echo "JCK_HOME $(JCK_HOME) missing" ; \ + $(EXIT) 1 ; \ + fi + if [ ! -d '$(PRODUCT_HOME)' ]; then \ + echo "PRODUCT_HOME $(PRODUCT_HOME) missing" ; \ + $(EXIT) 1 ; \ + fi all-summary: FRC @if [ -n "`find $(TEST_OUTPUT_DIR) -name status.txt`" ]; then /Erik From magnus.ihse.bursie at oracle.com Thu Jan 21 10:44:35 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 Jan 2016 11:44:35 +0100 Subject: RFR: JDK-8147930: Langtools test Makefile still requires special make in Cygwin In-Reply-To: <56A0B0BB.8020904@oracle.com> References: <56A0B0BB.8020904@oracle.com> Message-ID: <56A0B693.3070801@oracle.com> On 2016-01-21 11:19, Erik Joelsson wrote: > The langtools test Makefile doesn't work in Cygwin with the default > make. It still expects the specially built gnu make which handles ':' > in path names and particularly in rule declarations. > > The cause of the failure is JCK_HOME, which on Windows defaults to a > string starting with "J:/". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147930 > Patch: > diff -r 1fd828240c4d test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -412,7 +412,15 @@ > fi > > # Check to make sure these directories exist > -check-jck: $(JCK_HOME) $(PRODUCT_HOME) > +check-jck: > + if [ ! -d '$(JCK_HOME)' ]; then \ > + echo "JCK_HOME $(JCK_HOME) missing" ; \ > + $(EXIT) 1 ; \ > + fi > + if [ ! -d '$(PRODUCT_HOME)' ]; then \ > + echo "PRODUCT_HOME $(PRODUCT_HOME) missing" ; \ > + $(EXIT) 1 ; \ > + fi > > all-summary: FRC > @if [ -n "`find $(TEST_OUTPUT_DIR) -name status.txt`" ]; then Looks good to me. Messy thing, those windows paths. :( /Magnus > > > /Erik From john.r.rose at oracle.com Fri Jan 22 00:16:28 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 21 Jan 2016 16:16:28 -0800 Subject: constant references in enums Message-ID: <5CA0DFDA-5D97-4767-BE51-CD596B506C0E@oracle.com> Here's a little puzzler: Should this code compile, or is the forward reference illegal? enum FooE { FOOV(FOOC); // ?? error: illegal forward reference FooE(int k) {} public static final int FOOC = 42; // a constant variable // look, JLS 8.9.2 says "...unless the field is a constant variable" } (I.e., should I file a bug if it fails to compile?) Thanks, ? John From maurizio.cimadamore at oracle.com Fri Jan 22 00:41:47 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 22 Jan 2016 00:41:47 +0000 Subject: constant references in enums In-Reply-To: <5CA0DFDA-5D97-4767-BE51-CD596B506C0E@oracle.com> References: <5CA0DFDA-5D97-4767-BE51-CD596B506C0E@oracle.com> Message-ID: <56A17ACB.8050106@oracle.com> If it helps - this is rejected too: class FooE { static FooE fe = new FooE(FOOC); // ?? error: illegal forward reference FooE(int k) {} public static final int FOOC = 42; // a constant variable } But - this isn't: class FooE { static FooE fe = new FooE(*FooE.*FOOC); // ?? error: illegal forward reference FooE(int k) {} public static final int FOOC = 42; // a constant variable // look, JLS 8.9.2 says "...unless the field is a constant variable" } And I know this is not a bug - i.e. the spec says that fully qualified names are allowed to forward references (see 8.3.3). So, I'm assuming that, since javac desugars away enums at parsing time (by translating them into classes similar to the one above), it ends up generating illegal code in your specific case. Or maybe the spec should be rectified to do something consistent in both cases. Btw - if you add 'FooE.' your examples compiles too :-) Maurizio On 22/01/16 00:16, John Rose wrote: > enum FooE { > FOOV(FOOC); // ?? error: illegal forward reference > FooE(int k) {} > public static final int FOOC = 42; // a constant variable > // look, JLS 8.9.2 says "...unless the field is a constant variable" > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jan 22 00:51:07 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 22 Jan 2016 00:51:07 +0000 Subject: constant references in enums In-Reply-To: <56A17ACB.8050106@oracle.com> References: <5CA0DFDA-5D97-4767-BE51-CD596B506C0E@oracle.com> <56A17ACB.8050106@oracle.com> Message-ID: <56A17CFB.3090102@oracle.com> My bad - the section you quote refers to a different scenario: enum Foo { BAR; static int e = 0; //non constant final static int ce = 42; //constant //8.9.2: It is a compile-time error to reference a static field of an enum type from... // instance variable initializer expression int field1 = e; int field2 = ce; // instance initializers { int i1 = e; int i2 = ce; } //constructors Foo() { int i1 = e; int i2 = ce; } } So, in your case the access is occurring from another *static* variable initializer, so 8.9.2 does not apply. Which I think means that the same rules for ordinary classes apply - meaning that forward reference for statics is only allowed with fully qualified name. So it is consistent. And it is not a bug. Let's wait from some spec guru to chime in. Maurizio On 22/01/16 00:41, Maurizio Cimadamore wrote: > If it helps - this is rejected too: > > class FooE { > static FooE fe = new FooE(FOOC); // ?? error: illegal forward > reference > FooE(int k) {} > public static final int FOOC = 42; // a constant variable > } > > But - this isn't: > > class FooE { > static FooE fe = new FooE(*FooE.*FOOC); // ?? error: illegal > forward reference > FooE(int k) {} > public static final int FOOC = 42; // a constant variable > // look, JLS 8.9.2 says "...unless the field is a constant > variable" > } > > And I know this is not a bug - i.e. the spec says that fully qualified > names are allowed to forward references (see 8.3.3). > > So, I'm assuming that, since javac desugars away enums at parsing time > (by translating them into classes similar to the one above), it ends > up generating illegal code in your specific case. Or maybe the spec > should be rectified to do something consistent in both cases. > > Btw - if you add 'FooE.' your examples compiles too :-) > > Maurizio > > On 22/01/16 00:16, John Rose wrote: >> enum FooE { >> FOOV(FOOC); // ?? error: illegal forward reference >> FooE(int k) {} >> public static final int FOOC = 42; // a constant variable >> // look, JLS 8.9.2 says "...unless the field is a constant variable" >> } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jan 22 00:52:17 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 22 Jan 2016 00:52:17 +0000 Subject: constant references in enums In-Reply-To: <56A17CFB.3090102@oracle.com> References: <5CA0DFDA-5D97-4767-BE51-CD596B506C0E@oracle.com> <56A17ACB.8050106@oracle.com> <56A17CFB.3090102@oracle.com> Message-ID: <56A17D41.3080905@oracle.com> Compiler output for my last example: Main.java:48: error: illegal reference to static field from initializer int field1 = e; ^ Main.java:52: error: illegal reference to static field from initializer int i1 = e; ^ Main.java:57: error: illegal reference to static field from initializer int i1 = e; ^ 3 errors As you can see, static reference from instance context is only allowed when the static is also a constant - as per 8.9.2. Maurizio On 22/01/16 00:51, Maurizio Cimadamore wrote: > My bad - the section you quote refers to a different scenario: > > enum Foo { > BAR; > > static int e = 0; //non constant > final static int ce = 42; //constant > > //8.9.2: It is a compile-time error to reference a static field of > an enum type from... > > // instance variable initializer expression > int field1 = e; > int field2 = ce; > > // instance initializers > { > int i1 = e; > int i2 = ce; > } > > //constructors > Foo() { > int i1 = e; > int i2 = ce; > } > } > > So, in your case the access is occurring from another *static* > variable initializer, so 8.9.2 does not apply. Which I think means > that the same rules for ordinary classes apply - meaning that forward > reference for statics is only allowed with fully qualified name. So it > is consistent. And it is not a bug. Let's wait from some spec guru to > chime in. > > Maurizio > > On 22/01/16 00:41, Maurizio Cimadamore wrote: >> If it helps - this is rejected too: >> >> class FooE { >> static FooE fe = new FooE(FOOC); // ?? error: illegal >> forward reference >> FooE(int k) {} >> public static final int FOOC = 42; // a constant variable >> } >> >> But - this isn't: >> >> class FooE { >> static FooE fe = new FooE(*FooE.*FOOC); // ?? error: illegal >> forward reference >> FooE(int k) {} >> public static final int FOOC = 42; // a constant variable >> // look, JLS 8.9.2 says "...unless the field is a constant >> variable" >> } >> >> And I know this is not a bug - i.e. the spec says that fully >> qualified names are allowed to forward references (see 8.3.3). >> >> So, I'm assuming that, since javac desugars away enums at parsing >> time (by translating them into classes similar to the one above), it >> ends up generating illegal code in your specific case. Or maybe the >> spec should be rectified to do something consistent in both cases. >> >> Btw - if you add 'FooE.' your examples compiles too :-) >> >> Maurizio >> >> On 22/01/16 00:16, John Rose wrote: >>> enum FooE { >>> FOOV(FOOC); // ?? error: illegal forward reference >>> FooE(int k) {} >>> public static final int FOOC = 42; // a constant variable >>> // look, JLS 8.9.2 says "...unless the field is a constant variable" >>> } >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Fri Jan 22 09:31:04 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 22 Jan 2016 12:31:04 +0300 Subject: JEP 280 (Indify String Concat) integration Message-ID: <56A1F6D8.9070808@oracle.com> Hi, I think it is time to integrate JEP 280 ("Indify String Concat") into JDK 9: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, the code reviews and pre-integration checks come clean. In theory, we would like to integrate with some "optimal" concat strategy switched by default, but we have to wait for some Hotspot compiler changes to settle before we can make that call. (Notably, https://bugs.openjdk.java.net/browse/JDK-8136469). So, I would like to proceed in two parts: Part 1: Integrate all code changes, but keep the concatenation strategy to be the same "naive" StringBuilder.append chains. In other words, we are emitting string concat indy, but always link in the naive StringBuilder.append code. Part 2: (After HS changes settle in) Re-run performance tests, and switch to a more optimal concatenation strategy. This amounts to one-liner change in a default value for Java property. Thoughts? I would like relevant Project Leads / Reviewers (langtools and jdk) to OKay the integration. FTR, the webrevs: http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From paul.sandoz at oracle.com Fri Jan 22 09:46:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 Jan 2016 10:46:14 +0100 Subject: JEP 280 (Indify String Concat) integration In-Reply-To: <56A1F6D8.9070808@oracle.com> References: <56A1F6D8.9070808@oracle.com> Message-ID: <2A6DF001-3692-49C6-BEDA-4D80023B8B47@oracle.com> Looks a fine approach to me. Getting code in earlier and tested, even initially under the less optimal strategy, is good in terms of exposure. Paul. > On 22 Jan 2016, at 10:31, Aleksey Shipilev wrote: > > Hi, > > I think it is time to integrate JEP 280 ("Indify String Concat") into JDK 9: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks come clean. In theory, we would like to integrate > with some "optimal" concat strategy switched by default, but we have to > wait for some Hotspot compiler changes to settle before we can make that > call. (Notably, https://bugs.openjdk.java.net/browse/JDK-8136469). > > So, I would like to proceed in two parts: > > Part 1: Integrate all code changes, but keep the concatenation strategy > to be the same "naive" StringBuilder.append chains. In other words, we > are emitting string concat indy, but always link in the naive > StringBuilder.append code. > > Part 2: (After HS changes settle in) Re-run performance tests, and > switch to a more optimal concatenation strategy. This amounts to > one-liner change in a default value for Java property. > > Thoughts? I would like relevant Project Leads / Reviewers (langtools and > jdk) to OKay the integration. > > FTR, the webrevs: > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > Thanks, > -Aleksey > -------------- 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 forax at univ-mlv.fr Fri Jan 22 13:27:54 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 22 Jan 2016 14:27:54 +0100 (CET) Subject: JEP 280 (Indify String Concat) integration In-Reply-To: <2A6DF001-3692-49C6-BEDA-4D80023B8B47@oracle.com> References: <56A1F6D8.9070808@oracle.com> <2A6DF001-3692-49C6-BEDA-4D80023B8B47@oracle.com> Message-ID: <2103539321.1927034.1453469274765.JavaMail.zimbra@u-pem.fr> Yes, it's time to integrate that code, thumb up ! BTW, once the second part will be done, varargs calls should be the next target, see https://bugs.openjdk.java.net/browse/JDK-8013269. R?mi ----- Mail original ----- > De: "Paul Sandoz" > Cc: compiler-dev at openjdk.java.net, "Java Core Libs" > Envoy?: Vendredi 22 Janvier 2016 10:46:14 > Objet: Re: JEP 280 (Indify String Concat) integration > > Looks a fine approach to me. > > Getting code in earlier and tested, even initially under the less optimal > strategy, is good in terms of exposure. > > Paul. > > > On 22 Jan 2016, at 10:31, Aleksey Shipilev > > wrote: > > > > Hi, > > > > I think it is time to integrate JEP 280 ("Indify String Concat") into JDK > > 9: > > http://openjdk.java.net/jeps/280 > > > > The JEP is Targeted, the CCC is approved, the code reviews and > > pre-integration checks come clean. In theory, we would like to integrate > > with some "optimal" concat strategy switched by default, but we have to > > wait for some Hotspot compiler changes to settle before we can make that > > call. (Notably, https://bugs.openjdk.java.net/browse/JDK-8136469). > > > > So, I would like to proceed in two parts: > > > > Part 1: Integrate all code changes, but keep the concatenation strategy > > to be the same "naive" StringBuilder.append chains. In other words, we > > are emitting string concat indy, but always link in the naive > > StringBuilder.append code. > > > > Part 2: (After HS changes settle in) Re-run performance tests, and > > switch to a more optimal concatenation strategy. This amounts to > > one-liner change in a default value for Java property. > > > > Thoughts? I would like relevant Project Leads / Reviewers (langtools and > > jdk) to OKay the integration. > > > > FTR, the webrevs: > > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > > > Thanks, > > -Aleksey > > > > From peter.levart at gmail.com Fri Jan 22 14:44:41 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 22 Jan 2016 15:44:41 +0100 Subject: JEP 280 (Indify String Concat) integration In-Reply-To: <56A1F6D8.9070808@oracle.com> References: <56A1F6D8.9070808@oracle.com> Message-ID: <56A24059.5030206@gmail.com> Hi Aleksey, Good work. Nice to see this integrated. If StringConcatException ever gets thrown, will it propagate out of the concatenation expression execution? If yes, then it should probably be an unchecked exception, right? Regards, Peter On 01/22/2016 10:31 AM, Aleksey Shipilev wrote: > Hi, > > I think it is time to integrate JEP 280 ("Indify String Concat") into JDK 9: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks come clean. In theory, we would like to integrate > with some "optimal" concat strategy switched by default, but we have to > wait for some Hotspot compiler changes to settle before we can make that > call. (Notably, https://bugs.openjdk.java.net/browse/JDK-8136469). > > So, I would like to proceed in two parts: > > Part 1: Integrate all code changes, but keep the concatenation strategy > to be the same "naive" StringBuilder.append chains. In other words, we > are emitting string concat indy, but always link in the naive > StringBuilder.append code. > > Part 2: (After HS changes settle in) Re-run performance tests, and > switch to a more optimal concatenation strategy. This amounts to > one-liner change in a default value for Java property. > > Thoughts? I would like relevant Project Leads / Reviewers (langtools and > jdk) to OKay the integration. > > FTR, the webrevs: > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Fri Jan 22 17:37:29 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 22 Jan 2016 20:37:29 +0300 Subject: JEP 280 (Indify String Concat) integration In-Reply-To: <56A24059.5030206@gmail.com> References: <56A1F6D8.9070808@oracle.com> <56A24059.5030206@gmail.com> Message-ID: <56A268D9.3040504@oracle.com> On 01/22/2016 05:44 PM, Peter Levart wrote: > If StringConcatException ever gets thrown, will it propagate out of the > concatenation expression execution? If yes, then it should probably be > an unchecked exception, right? StringConcatException is modeled after LambdaConversionException: it covers the linkage invariants, and it is thrown from bootstrap method only. When BSM throws, call site initialization fails with BootstrapMethodError, having this exception as the cause. Therefore, I see no particular reason in making that exception unchecked. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From john.r.rose at oracle.com Fri Jan 22 20:12:19 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 22 Jan 2016 12:12:19 -0800 Subject: constant references in enums In-Reply-To: <56A17D41.3080905@oracle.com> References: <5CA0DFDA-5D97-4767-BE51-CD596B506C0E@oracle.com> <56A17ACB.8050106@oracle.com> <56A17CFB.3090102@oracle.com> <56A17D41.3080905@oracle.com> Message-ID: That all makes sense; it's consistent, although it makes me a little sad. Enums should be able to define their own bit-fiddly constants and use them to construct themselves, and the qualified expr is the way to do so. I was confused about the status of the sugary expression "FOOE(FOOV)". I guess it is a constructor invocation from a static initializer, but the spec doesn't really categorize it, clearly enough to predict what should happen. FTR, the use case comes from a Vector API POC: > enum LaneType implements Impl.EnumWorkaround { > ILLEGAL((byte)0,0), // sentinel for error reporting > Z0(Z,0), Z1(Z,1), Z2(Z,2), Z4(Z,4), // zero-bit = void, one-bit, etc. > // (signed,unsigned,float) x (2**{0,1,2,3,4)b) > U1(U,1), U2(U,2), U4(U,4), U8(U,8), U16(U,16), > S1(S,1), S2(S,2), S4(S,4), S8(S,8), S16(S,16), > F1(F,1), F2(F,2), F4(F,4), F8(F,8), F16(F,16); > > /* JLS: "It is a compile-time error to reference a static field > * of an enum type from constructors, instance initializers, > * or instance variable initializer expressions of the enum > * type, unless the field is a constant variable (4.12.4)." > * So the following should work, but appears to be broken: > */ > //private static final byte Z = 0x1, U = 0x2, S = 0x4, F = 0x08; > private static final int BIT_SIZE_SHIFT = 4, BYTE_SIZE = 8; > > private int flags; > LaneType(byte flags, int size) { > int bitSize = (flags & Z) == 0 ? (size * BYTE_SIZE) : size; > assert((flags & (-1 << BIT_SIZE_SHIFT)) == 0); > this.flags = flags | (bitSize << BIT_SIZE_SHIFT); > } > public int bitSize() { return flags >> BIT_SIZE_SHIFT; } > public int byteSize() { return bitSize() / BYTE_SIZE; } > public boolean isUnsigned() { return (flags & U) != 0; } > public boolean isSigned() { return (flags & S) != 0; } > public boolean isFloat() { return (flags & F) != 0; } > } Ref: http://mail.openjdk.java.net/pipermail/panama-dev/2016-January/000288.html ? John On Jan 21, 2016, at 4:52 PM, Maurizio Cimadamore wrote: > > Compiler output for my last example: > > Main.java:48: error: illegal reference to static field from initializer > int field1 = e; > ^ > Main.java:52: error: illegal reference to static field from initializer > int i1 = e; > ^ > Main.java:57: error: illegal reference to static field from initializer > int i1 = e; > ^ > 3 errors > > > As you can see, static reference from instance context is only allowed when the static is also a constant - as per 8.9.2. > > Maurizio > > On 22/01/16 00:51, Maurizio Cimadamore wrote: >> My bad - the section you quote refers to a different scenario: >> >> enum Foo { >> BAR; >> >> static int e = 0; //non constant >> final static int ce = 42; //constant >> >> //8.9.2: It is a compile-time error to reference a static field of an enum type from... >> >> // instance variable initializer expression >> int field1 = e; >> int field2 = ce; >> >> // instance initializers >> { >> int i1 = e; >> int i2 = ce; >> } >> >> //constructors >> Foo() { >> int i1 = e; >> int i2 = ce; >> } >> } >> >> So, in your case the access is occurring from another *static* variable initializer, so 8.9.2 does not apply. Which I think means that the same rules for ordinary classes apply - meaning that forward reference for statics is only allowed with fully qualified name. So it is consistent. And it is not a bug. Let's wait from some spec guru to chime in. >> >> Maurizio >> >> On 22/01/16 00:41, Maurizio Cimadamore wrote: >>> If it helps - this is rejected too: >>> >>> class FooE { >>> static FooE fe = new FooE(FOOC); // ?? error: illegal forward reference >>> FooE(int k) {} >>> public static final int FOOC = 42; // a constant variable >>> } >>> >>> But - this isn't: >>> >>> class FooE { >>> static FooE fe = new FooE(FooE.FOOC); // ?? error: illegal forward reference >>> FooE(int k) {} >>> public static final int FOOC = 42; // a constant variable >>> // look, JLS 8.9.2 says "...unless the field is a constant variable" >>> } >>> >>> And I know this is not a bug - i.e. the spec says that fully qualified names are allowed to forward references (see 8.3.3). >>> >>> So, I'm assuming that, since javac desugars away enums at parsing time (by translating them into classes similar to the one above), it ends up generating illegal code in your specific case. Or maybe the spec should be rectified to do something consistent in both cases. >>> >>> Btw - if you add 'FooE.' your examples compiles too :-) >>> >>> Maurizio >>> >>> On 22/01/16 00:16, John Rose wrote: >>>> enum FooE { >>>> FOOV(FOOC); // ?? error: illegal forward reference >>>> FooE(int k) {} >>>> public static final int FOOC = 42; // a constant variable >>>> // look, JLS 8.9.2 says "...unless the field is a constant variable" >>>> } >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Jan 22 21:20:42 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 22 Jan 2016 13:20:42 -0800 Subject: JEP 280 (Indify String Concat) integration In-Reply-To: <56A268D9.3040504@oracle.com> References: <56A1F6D8.9070808@oracle.com> <56A24059.5030206@gmail.com> <56A268D9.3040504@oracle.com> Message-ID: <56A29D2A.1050604@oracle.com> On 1/22/2016 9:37 AM, Aleksey Shipilev wrote: > On 01/22/2016 05:44 PM, Peter Levart wrote: >> If StringConcatException ever gets thrown, will it propagate out of the >> concatenation expression execution? If yes, then it should probably be >> an unchecked exception, right? > > StringConcatException is modeled after LambdaConversionException: it > covers the linkage invariants, and it is thrown from bootstrap method > only. When BSM throws, call site initialization fails with > BootstrapMethodError, having this exception as the cause. Therefore, I > see no particular reason in making that exception unchecked. In other words, StringConcatException will never (from the POV of the Java program) be the reason why evaluation of a string concat expression fails. The Java program would never catch StringConcatException if it was an unchecked exception class (since the JVM wraps SCE in BSME) ... and the Java program could never write 'catch (StringConcatException e)' if it was a checked exception class. So, there is no need to mention it in JLS 15.6. Instead, the reason why evaluation fails may be a BootstrapMethodError. This is already anticipated by "Various linkage and virtual machine errors may also occur during the evaluation of an expression." The Java program is free to write 'catch BootstrapMethodError' if it wishes, and occasionally the catch block will execute. Alex From alex.buckley at oracle.com Fri Jan 22 22:38:42 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 22 Jan 2016 14:38:42 -0800 Subject: constant references in enums In-Reply-To: References: <5CA0DFDA-5D97-4767-BE51-CD596B506C0E@oracle.com> <56A17ACB.8050106@oracle.com> <56A17CFB.3090102@oracle.com> <56A17D41.3080905@oracle.com> Message-ID: <56A2AF72.4060807@oracle.com> Yes, the 8.3.3 rule doesn't have a special case for forward references to class variables _which are constant variables_, so FOOE(FOOV) is illegal prior to the declaration of FOOV. (And it's impossible to declare the ordinary static field FOOV "first".) A special case might appear desirable, but then we'd be setting up for (so would have to disallow) circular references: static final int x = y+1; static final int y = x+1; As to readability of the spec, an enum constants like FOOE(FOOV) has always been specified by translation to a public static final field. JSR 201 said "Each such field is initialized to the enum constant that corresponds to it." I sharpened this very slightly in JLS8 to "The field has a variable initializer consisting of c [c is the enum constant]" but I recall not wanting to commit to "The field has a variable initializer consisting of 'new E(/c_arglist/)'." because compilers don't need to agree on the signature of an enum constructor. (See the related note in 8.9.2.) As such, your complaint that the JLS doesn't specify the class variable initializer for FOOE well enough to predict the meaning of FOOV is valid. A possible fix is to have 8.9.3 reiterate the useful info from 8.9.1: "An enum constant may be followed by arguments, which are passed to the constructor of the enum when the constant is created during class initialization as described later in this section." Alex On 1/22/2016 12:12 PM, John Rose wrote: > That all makes sense; it's consistent, although it makes me a little sad. > Enums should be able to define their own bit-fiddly constants and use > them to construct themselves, and the qualified expr is the way to do so. > > I was confused about the status of the sugary expression "FOOE(FOOV)". > I guess it is a constructor invocation from a static initializer, but > the spec > doesn't really categorize it, clearly enough to predict what should happen. > > FTR, the use case comes from a Vector API POC: > >> enum LaneType implements Impl.EnumWorkaround { >> ILLEGAL((byte)0,0), // sentinel for error reporting >> Z0(Z,0), Z1(Z,1), Z2(Z,2), Z4(Z,4), // zero-bit = void, >> one-bit, etc. >> // (signed,unsigned,float) x (2**{0,1,2,3,4)b) >> U1(U,1), U2(U,2), U4(U,4), U8(U,8), U16(U,16), >> S1(S,1), S2(S,2), S4(S,4), S8(S,8), S16(S,16), >> F1(F,1), F2(F,2), F4(F,4), F8(F,8), F16(F,16); >> >> /* JLS: "It is a compile-time error to reference a static field >> * of an enum type from constructors, instance initializers, >> * or instance variable initializer expressions of the enum >> * type, unless the field is a constant variable (4.12.4)." >> * So the following should work, but appears to be broken: >> */ >> //private static final byte Z = 0x1, U = 0x2, S = 0x4, F = 0x08; >> private static final int BIT_SIZE_SHIFT = 4, BYTE_SIZE = 8; >> >> private int flags; >> LaneType(byte flags, int size) { >> int bitSize = (flags & Z) == 0 ? (size * BYTE_SIZE) : size; >> assert((flags & (-1 << BIT_SIZE_SHIFT)) == 0); >> this.flags = flags | (bitSize << BIT_SIZE_SHIFT); >> } >> public int bitSize() { return flags >> BIT_SIZE_SHIFT; } >> public int byteSize() { return bitSize() / BYTE_SIZE; } >> public boolean isUnsigned() { return (flags & U) != 0; } >> public boolean isSigned() { return (flags & S) != 0; } >> public boolean isFloat() { return (flags & F) != 0; } >> } > > Ref: > http://mail.openjdk.java.net/pipermail/panama-dev/2016-January/000288.html > > > ? John > > On Jan 21, 2016, at 4:52 PM, Maurizio Cimadamore > > > wrote: >> >> Compiler output for my last example: >> >> Main.java:48: error: illegal reference to static field from initializer >> int field1 = e; >> ^ >> Main.java:52: error: illegal reference to static field from initializer >> int i1 = e; >> ^ >> Main.java:57: error: illegal reference to static field from initializer >> int i1 = e; >> ^ >> 3 errors >> >> >> As you can see, static reference from instance context is only allowed >> when the static is also a constant - as per 8.9.2. >> >> Maurizio >> >> On 22/01/16 00:51, Maurizio Cimadamore wrote: >>> My bad - the section you quote refers to a different scenario: >>> >>> enum Foo { >>> BAR; >>> >>> static int e = 0; //non constant >>> final static int ce = 42; //constant >>> >>> //8.9.2: It is a compile-time error to reference a static field >>> of an enum type from... >>> >>> // instance variable initializer expression >>> int field1 = e; >>> int field2 = ce; >>> >>> // instance initializers >>> { >>> int i1 = e; >>> int i2 = ce; >>> } >>> >>> //constructors >>> Foo() { >>> int i1 = e; >>> int i2 = ce; >>> } >>> } >>> >>> So, in your case the access is occurring from another *static* >>> variable initializer, so 8.9.2 does not apply. Which I think means >>> that the same rules for ordinary classes apply - meaning that forward >>> reference for statics is only allowed with fully qualified name. So >>> it is consistent. And it is not a bug. Let's wait from some spec guru >>> to chime in. >>> >>> Maurizio >>> >>> On 22/01/16 00:41, Maurizio Cimadamore wrote: >>>> If it helps - this is rejected too: >>>> >>>> class FooE { >>>> static FooE fe = new FooE(FOOC); // ?? error: illegal >>>> forward reference >>>> FooE(int k) {} >>>> public static final int FOOC = 42; // a constant variable >>>> } >>>> >>>> But - this isn't: >>>> >>>> class FooE { >>>> static FooE fe = new FooE(*FooE.*FOOC); // ?? error: >>>> illegal forward reference >>>> FooE(int k) {} >>>> public static final int FOOC = 42; // a constant variable >>>> // look, JLS 8.9.2 says "...unless the field is a constant >>>> variable" >>>> } >>>> >>>> And I know this is not a bug - i.e. the spec says that fully >>>> qualified names are allowed to forward references (see 8.3.3). >>>> >>>> So, I'm assuming that, since javac desugars away enums at parsing >>>> time (by translating them into classes similar to the one above), it >>>> ends up generating illegal code in your specific case. Or maybe the >>>> spec should be rectified to do something consistent in both cases. >>>> >>>> Btw - if you add 'FooE.' your examples compiles too :-) >>>> >>>> Maurizio >>>> >>>> On 22/01/16 00:16, John Rose wrote: >>>>> enum FooE { >>>>> FOOV(FOOC); // ?? error: illegal forward reference >>>>> FooE(int k) {} >>>>> public static final int FOOC = 42; // a constant variable >>>>> // look, JLS 8.9.2 says "...unless the field is a constant variable" >>>>> } >>>> >>> >> > From victorwssilva at gmail.com Sat Jan 23 22:11:42 2016 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Sat, 23 Jan 2016 20:11:42 -0200 Subject: Javac gets confused with type-inference and crashes with StackOverflowError Message-ID: Hi, I got a problem with the javac 1.8.0_72 compiler, which resulted in it crashing with a StackOverflowError (so it is obviosuly a compiler bug). After some work investigating it, I produced this minimal testcase which reproduces the problem: public class JavaBug { public JavaBug() { TestZ r = null; Crazy x = r.m3("X"); r.m1(r.m4(r.m2(x, r.m3("a")), t -> "x"), r.m3("a")); } } interface Crazy { } interface TestZ { public Crazy m1(Crazy... d); public Crazy> m2(Crazy e, Crazy f); public Crazy m3(A g); public Crazy m4(Crazy h, java.util.function.Function i); } I know that I should report this over the bugs.java.com site. However, my internet is terribly bad and slow today due to some networking problem on my side and I couldn't post it there. This javac bug is specially annoying when saving the file with Netbeans 8.1 - The result is that the IDE simply hangs unresponsive forever and I am forced to kill it in the OS. Netbeans should behave gracefully even in the event of the compiler crashing miserably, so there is some Netbeans bug also. I know that this is not the place to report bugs in Netbeans, but I don't know how/where to report bugs in Netbeans and would take some time and effort to find it by myself (specially with my internet connection), and I know that many people in this mailing list would be able to report to them easily and quickly. Victor Williams Stafusa da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Sun Jan 24 21:46:02 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sun, 24 Jan 2016 21:46:02 +0000 Subject: Javac gets confused with type-inference and crashes with StackOverflowError In-Reply-To: References: Message-ID: <56A5461A.2000206@oracle.com> Hi Victor, thanks for the report; I did some testing and it seems to be a duplicate (although with slightly different stack trace) of this: https://bugs.openjdk.java.net/browse/JDK-8130304 There was an issue in the Tarjan implementation for computing topological sort of inference variables; when the bug occurred, inference would fail in unexpected ways; in your example it seems like the output of the topological sorted inference graph still contained loops (which should never occur) - hence the SSO. Unfortunately the Tarjan classes changed a bit during 9, the backport might be hard. We will take a look to see if the fix can be backported safely. Thanks Maurizio On 23/01/16 22:11, Victor Williams Stafusa da Silva wrote: > public class JavaBug { > > public JavaBug() { > TestZ r = null; > Crazy x = r.m3("X"); > r.m1(r.m4(r.m2(x, r.m3("a")), t -> "x"), r.m3("a")); > } > } > > interface Crazy { > } > > interface TestZ { > public Crazy m1(Crazy... d); > public Crazy> m2(Crazy e, Crazy C> f); > public Crazy m3(A g); > public Crazy m4(Crazy h, > java.util.function.Function i); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Jan 25 19:12:16 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 25 Jan 2016 20:12:16 +0100 Subject: RFR (XS): 8147949: NetBeans cannot open langtools repository because of the reserved work "aux" Message-ID: <56A67390.6030106@oracle.com> Hello, As reported in the bug: https://bugs.openjdk.java.net/browse/JDK-8147949 The NetBeans' project for langtools contains references to directory named "aux", which is causing problems on Windows. On a closer look, the "aux" references shouldn't be needed, so I propose to remove them altogether. Webrev: http://cr.openjdk.java.net/~jlahoda/8147949/webrev.00/index.html Thanks, Jan From cushon at google.com Tue Jan 26 04:00:07 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 25 Jan 2016 20:00:07 -0800 Subject: -XD-relax doesn't work In-Reply-To: <569F61A7.1080200@oracle.com> References: <569EDCEF.20805@oracle.com> <569F61A7.1080200@oracle.com> Message-ID: It was a build performance experiment. Disabling flow analysis allows compilation to succeed even if the parser drops method bodies, class initializers, and non-const field initializers, and the output still works as a compile-time classpath. So if there's a long chain of libraries that depend on each other, compiling "source stubs" first makes the critical path a bit faster and allows more of the full compilations to be done in parallel. On Wed, Jan 20, 2016 at 2:29 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > > On 20/01/16 01:31, Liam Miller-Cushon wrote: > > Thanks, I'll avoid using it :) > > Meta-question - what were you using it for? > > Maurizio > > On Tue, Jan 19, 2016 at 5:03 PM, Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Thanks >> I'll add that to the list of flags to cleanup :-) >> >> Maurizio >> >> >> On 20/01/16 00:49, Liam Miller-Cushon wrote: >> >>> I think that -XD-relax has been broken since JDK8. My understanding is >>> that it was added in the jsr14 era, so maybe it should just be removed? >>> >>> The fix is: >>> >>> diff -r 6149fc30cd71 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java >>> --- >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java >>> Thu Jan 14 12:03:24 2016 -0800 >>> +++ >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java >>> Tue Jan 19 16:34:56 2016 -0800 >>> @@ -1281,6 +1281,7 @@ >>> return; >>> >>> if (relax) { >>> + compileStates.put(env, CompileState.FLOW); >>> results.add(env); >>> return; >>> } >>> >>> Repro: >>> >>> $ cat Test.java >>> class Test {} >>> $ javac -XD-relax Test.java >>> An exception has occurred in the compiler (1.9.0-internal). Please file >>> a bug against the Java compiler via the Java bug reporting page ( >>> http://bugreport.java.com) after checking >>> the Bug Database (http://bugs.java.com) for duplicates. Include your >>> program and the following diagnostic in your report. Thank you. >>> java.lang.AssertionError: The current compile state [ATTR] of class Test >>> is previous to FLOW >>> at com.sun.tools.javac.util.Assert.error(Assert.java:162) >>> at >>> com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:937) >>> at >>> com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:512) >>> at >>> com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:744) >>> at >>> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) >>> at >>> com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:491) >>> at >>> com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:977) >>> at >>> com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1455) >>> at >>> com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1326) >>> at >>> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:871) >>> at com.sun.tools.javac.main.Main.compile(Main.java:257) >>> at com.sun.tools.javac.main.Main.compile(Main.java:142) >>> at com.sun.tools.javac.Main.compile(Main.java:55) >>> at com.sun.tools.javac.Main.main(Main.java:41) >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 26 04:03:14 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 25 Jan 2016 20:03:14 -0800 Subject: change in inference of unchecked calls after JDK-8147493 Message-ID: The fix for JDK-8147493 (regression when type-checking unchecked method calls) prevents the following code from compiling. It is accepted by 8, and earlier versions of 9-dev. The return type of w(...) is now being inferred as S>. Shouldn't the unchecked call cause return types to be erased? abstract class Test { interface R {} interface Q {} interface T { Q n(R r); } abstract T isA(Class t); abstract S w(T t); interface S { S t(T value); } void f(T t, Q q) { w(t.n(isA(R.class))).t(q); } } error: incompatible types: Q cannot be converted to Q w(t.n(isA(R.class))).t(q); ^ Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From subhamoyroy20 at gmail.com Tue Jan 26 05:48:11 2016 From: subhamoyroy20 at gmail.com (Subhamoy Roy) Date: Tue, 26 Jan 2016 11:18:11 +0530 Subject: I want to learn compiler design concepts. HELP me !!! Message-ID: Sir, I am Subhamoy Roy,currently pursuing B.Tech on computer science,I want to write a basic compiler for my college academic project,so I want to learn compiler design concepts deeply ,I also want to contribute to java compiler in mere future,but don't know how to start and build a whole compiler,so please guide me,and provide me step-by-step information on how to learn compiler design concepts,build compiler,how to contribute to OracleJDK / OpenJDK java compiler,please provide me good books and other resources. Sir,please help me fulfilling my dreams,I am eagerly waiting for your reply.I am ready to follow your advice,so feel free to communicate with me.Thank you in advance. Thanking you, Subhamoy Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Jan 26 10:18:42 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Jan 2016 10:18:42 +0000 Subject: change in inference of unchecked calls after JDK-8147493 In-Reply-To: References: Message-ID: <56A74802.9050507@oracle.com> I will look into this. Thanks. Maurizio On 26/01/16 04:03, Liam Miller-Cushon wrote: > The fix for JDK-8147493 (regression when type-checking unchecked > method calls) prevents the following code from compiling. It is > accepted by 8, and earlier versions of 9-dev. The return type of > w(...) is now being inferred as S>. Shouldn't the unchecked > call cause return types to be erased? > > abstract class Test { > > interface R {} > interface Q {} > interface T { Q n(R r); } > abstract T isA(Class t); > abstract S w(T t); > interface S { S t(T value); } > > void f(T t, Q q) { > w(t.n(isA(R.class))).t(q); > } > } > > > error: incompatible types: Q cannot be converted to Q > w(t.n(isA(R.class))).t(q); > ^ > > Thanks, > Liam From maurizio.cimadamore at oracle.com Tue Jan 26 12:36:10 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Jan 2016 12:36:10 +0000 Subject: change in inference of unchecked calls after JDK-8147493 In-Reply-To: <56A74802.9050507@oracle.com> References: <56A74802.9050507@oracle.com> Message-ID: <56A7683A.9030002@oracle.com> On 26/01/16 10:18, Maurizio Cimadamore wrote: > I will look into this. Thanks. Update: I believe this problem has been there for a long time, but the fact that unchecked conversion were not propagated correctly allowed this program to compile (in fact, if you check with an earlier JDK 8 build, there are some spurious unchecked warnings generated as a result). I believe the program should be accepted - I've alpha-renamed type-variables in your example to make matters a bit clearer: abstract class Test { interface R {} interface Q {} interface T { Q n(R r); } abstract I isA(Class t); abstract S w(W t); interface S { S t(X value); } void f(T t, Q q) { w(t.n(isA(R.class))).t(q); } } The big issue occurs when we call 't.n' - performing applicability inference of its argument means evaluating the expression constraint isA() -> R, and such a constraint should be evaluated by performing invocation type inference (18.5.2). According to 18.5.2, given that isA() returns a bare inference variable ('I') and given that this inference variable has an equality constraints (R) and given that there's no paramaterization of the target type R such that R <: R, eager instantiation of 'I' should occur. Then, following 18.5.2 we should set up a type compatibility constraints of the kind R -> R, and that kind of compatibility constraint clearly generates an unchecked warning (as per 18.2.2). So, popping back, we have found an unchecked warning while proving applicability of 't.n'. This should mean that invocation type-inference for 't.n' we should effectively erase the return type: "If unchecked conversion was necessary for the method to be applicable during constraint set reduction in ?18.5.1 , the constraint formula ?|R| ? T? is reduced and incorporated with B_2 ." Which should mean W = |Q|, and then W's member 't' should have a type (Q)S, which should be compatible with Q. In terms of the implementation, javac loses the unchecked warning that is generated when evaluating isA() -> R; this means that the method call is not treated as unchecked. I've filed: https://bugs.openjdk.java.net/browse/JDK-8148213 Maurizio > > Maurizio > > On 26/01/16 04:03, Liam Miller-Cushon wrote: >> The fix for JDK-8147493 (regression when type-checking unchecked >> method calls) prevents the following code from compiling. It is >> accepted by 8, and earlier versions of 9-dev. The return type of >> w(...) is now being inferred as S>. Shouldn't the unchecked >> call cause return types to be erased? >> >> abstract class Test { >> >> interface R {} >> interface Q {} >> interface T { Q n(R r); } >> abstract T isA(Class t); >> abstract S w(T t); >> interface S { S t(T value); } >> >> void f(T t, Q q) { >> w(t.n(isA(R.class))).t(q); >> } >> } >> >> >> error: incompatible types: Q cannot be converted to Q >> w(t.n(isA(R.class))).t(q); >> ^ >> >> Thanks, >> Liam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 26 20:09:36 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 26 Jan 2016 12:09:36 -0800 Subject: change in inference of unchecked calls after JDK-8147493 In-Reply-To: <56A7683A.9030002@oracle.com> References: <56A74802.9050507@oracle.com> <56A7683A.9030002@oracle.com> Message-ID: Thanks for the quick investigation. I wondered if this was related to JDK-8135087 / JDK-6791481, but if the root cause is losing track of the unchecked warning then it sounds like the similarity is superficial. On Tue, Jan 26, 2016 at 4:36 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > > On 26/01/16 10:18, Maurizio Cimadamore wrote: > > I will look into this. Thanks. > > Update: I believe this problem has been there for a long time, but the > fact that unchecked conversion were not propagated correctly allowed this > program to compile (in fact, if you check with an earlier JDK 8 build, > there are some spurious unchecked warnings generated as a result). > > I believe the program should be accepted - I've alpha-renamed > type-variables in your example to make matters a bit clearer: > > abstract class Test { > > interface R {} > interface Q {} > interface T { Q n(R r); } > abstract I isA(Class t); > abstract S w(W t); > interface S { S t(X value); } > > void f(T t, Q q) { > w(t.n(isA(R.class))).t(q); > } > } > > The big issue occurs when we call 't.n' - performing applicability > inference of its argument means evaluating the expression constraint isA() > -> R, and such a constraint should be evaluated by performing invocation > type inference (18.5.2). > > According to 18.5.2, given that isA() returns a bare inference variable > ('I') and given that this inference variable has an equality constraints > (R) and given that there's no paramaterization of the target type R such > that R <: R, eager instantiation of 'I' should occur. > > Then, following 18.5.2 we should set up a type compatibility constraints > of the kind R -> R, and that kind of compatibility constraint clearly > generates an unchecked warning (as per 18.2.2). So, popping back, we have > found an unchecked warning while proving applicability of 't.n'. This > should mean that invocation type-inference for 't.n' we should effectively > erase the return type: > > "If unchecked conversion was necessary for the method to be applicable > during constraint set reduction in ?18.5.1 > , > the constraint formula ?|R| ? T? is reduced and incorporated with B2." > > Which should mean W = |Q|, and then W's member 't' should have a type > (Q)S, which should be compatible with Q. > > > > In terms of the implementation, javac loses the unchecked warning that is > generated when evaluating isA() -> R; this means that the method call is > not treated as unchecked. > > I've filed: https://bugs.openjdk.java.net/browse/JDK-8148213 > > Maurizio > > > Maurizio > > On 26/01/16 04:03, Liam Miller-Cushon wrote: > > The fix for JDK-8147493 (regression when type-checking unchecked method > calls) prevents the following code from compiling. It is accepted by 8, and > earlier versions of 9-dev. The return type of w(...) is now being inferred > as S>. Shouldn't the unchecked call cause return types to be > erased? > > abstract class Test { > > interface R {} > interface Q {} > interface T { Q n(R r); } > abstract T isA(Class t); > abstract S w(T t); > interface S { S t(T value); } > > void f(T t, Q q) { > w(t.n(isA(R.class))).t(q); > } > } > > > error: incompatible types: Q cannot be converted to Q > w(t.n(isA(R.class))).t(q); > ^ > > Thanks, > Liam > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Jan 26 21:35:58 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Jan 2016 21:35:58 +0000 Subject: change in inference of unchecked calls after JDK-8147493 In-Reply-To: References: <56A74802.9050507@oracle.com> <56A7683A.9030002@oracle.com> Message-ID: <56A7E6BE.1030608@oracle.com> On 26/01/16 20:09, Liam Miller-Cushon wrote: > Thanks for the quick investigation. I wondered if this was related to > JDK-8135087 / JDK-6791481, but if the root cause is losing track of > the unchecked warning then it sounds like the similarity is superficial. No, although you are right that these are problems with similar surface area. In this case the issue is that when some eager instantiation occurs during 18.5.2, we ignore it, and leave uninstantiated types in the method types; those types will eventually be replaced correctly - but it will be too late to issue an unchecked warning, as the enclosing context will already have completed resolution/inference, so any unchecked warning will have no effect w.r.t. erasing return types there. I did a simple experiment with this slightly tweaked source: abstract class Test { interface R {} interface Q {} interface T { Q n(R r); } abstract *R* isA(Class t); abstract S w(W t); interface S { S t(X value); } void f(T t, Q q) { w(t.n(isA(R.class))).t(q); } } Where the return type of isA() is manifestly raw. In this case javac has no issues. In your case the problem is a combination of eager instantiation and delayed checks which then causes the warning to be late to the overload party. Ideally the logic for the check deferral should be smart enough to execute checks as soon as possible, so as not to miss events - but in reality we only go back and look at deferred checks at specific points in time (i.e. when all variables in a context are solved), which is sometimes too late. Maurizio > > On Tue, Jan 26, 2016 at 4:36 AM, Maurizio Cimadamore > > wrote: > > > > On 26/01/16 10:18, Maurizio Cimadamore wrote: >> I will look into this. Thanks. > Update: I believe this problem has been there for a long time, but > the fact that unchecked conversion were not propagated correctly > allowed this program to compile (in fact, if you check with an > earlier JDK 8 build, there are some spurious unchecked warnings > generated as a result). > > I believe the program should be accepted - I've alpha-renamed > type-variables in your example to make matters a bit clearer: > > abstract class Test { > > interface R {} > interface Q {} > interface T { Q n(R r); } > abstract I isA(Class t); > abstract S w(W t); > interface S { S t(X value); } > > void f(T t, Q q) { > w(t.n(isA(R.class))).t(q); > } > } > > The big issue occurs when we call 't.n' - performing applicability > inference of its argument means evaluating the expression > constraint isA() -> R, and such a constraint should be > evaluated by performing invocation type inference (18.5.2). > > According to 18.5.2, given that isA() returns a bare inference > variable ('I') and given that this inference variable has an > equality constraints (R) and given that there's no > paramaterization of the target type R such that R <: R, > eager instantiation of 'I' should occur. > > Then, following 18.5.2 we should set up a type compatibility > constraints of the kind R -> R, and that kind of compatibility > constraint clearly generates an unchecked warning (as per 18.2.2). > So, popping back, we have found an unchecked warning while proving > applicability of 't.n'. This should mean that invocation > type-inference for 't.n' we should effectively erase the return type: > > "If unchecked conversion was necessary for the method to be > applicable during constraint set reduction in ?18.5.1 > , > the constraint formula ?|R| ? T? is reduced and incorporated with > B_2 ." > > Which should mean W = |Q|, and then W's member 't' should have > a type (Q)S, which should be compatible with Q. > > > > In terms of the implementation, javac loses the unchecked warning > that is generated when evaluating isA() -> R; this means that > the method call is not treated as unchecked. > > I've filed: https://bugs.openjdk.java.net/browse/JDK-8148213 > > Maurizio >> >> Maurizio >> >> On 26/01/16 04:03, Liam Miller-Cushon wrote: >>> The fix for JDK-8147493 (regression when type-checking unchecked >>> method calls) prevents the following code from compiling. It is >>> accepted by 8, and earlier versions of 9-dev. The return type of >>> w(...) is now being inferred as S>. Shouldn't the >>> unchecked call cause return types to be erased? >>> >>> abstract class Test { >>> >>> interface R {} >>> interface Q {} >>> interface T { Q n(R r); } >>> abstract T isA(Class t); >>> abstract S w(T t); >>> interface S { S t(T value); } >>> >>> void f(T t, Q q) { >>> w(t.n(isA(R.class))).t(q); >>> } >>> } >>> >>> >>> error: incompatible types: Q cannot be converted to >>> Q >>> w(t.n(isA(R.class))).t(q); >>> ^ >>> >>> Thanks, >>> Liam >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Wed Jan 27 09:24:38 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Jan 2016 12:24:38 +0300 Subject: JEP 280 (Indify String Concat) integration In-Reply-To: <56A29D2A.1050604@oracle.com> References: <56A1F6D8.9070808@oracle.com> <56A24059.5030206@gmail.com> <56A268D9.3040504@oracle.com> <56A29D2A.1050604@oracle.com> Message-ID: <56A88CD6.9000508@oracle.com> On 01/23/2016 12:20 AM, Alex Buckley wrote: > On 1/22/2016 9:37 AM, Aleksey Shipilev wrote: >> On 01/22/2016 05:44 PM, Peter Levart wrote: >>> If StringConcatException ever gets thrown, will it propagate out of the >>> concatenation expression execution? If yes, then it should probably be >>> an unchecked exception, right? >> >> StringConcatException is modeled after LambdaConversionException: it >> covers the linkage invariants, and it is thrown from bootstrap method >> only. When BSM throws, call site initialization fails with >> BootstrapMethodError, having this exception as the cause. Therefore, I >> see no particular reason in making that exception unchecked. > > In other words, StringConcatException will never (from the POV of the > Java program) be the reason why evaluation of a string concat expression > fails. The Java program would never catch StringConcatException if it > was an unchecked exception class (since the JVM wraps SCE in BSME) ... > and the Java program could never write 'catch (StringConcatException e)' > if it was a checked exception class. So, there is no need to mention it > in JLS 15.6. Yes, exactly, thanks Alex! Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From martijnverburg at gmail.com Wed Jan 27 11:50:07 2016 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 27 Jan 2016 11:50:07 +0000 Subject: I want to learn compiler design concepts. HELP me !!! In-Reply-To: References: Message-ID: Hi Subhamoy, Welcome to OpenJDK. The compiler-dev list is for discussing implementation details of the javac compiler. It is unfortunately the wrong place to gain an education about compiler design and theory! I'd recommend starting with Computer Science courses at your local or online university or one of the many free online courses offered by the likes of Coursera: https://www.coursera.org/course/compilers Cheers, Martijn On 26 January 2016 at 05:48, Subhamoy Roy wrote: > Sir, > I am Subhamoy Roy,currently pursuing B.Tech on computer science,I want to > write a basic compiler for my college academic project,so I want to learn > compiler design concepts deeply ,I also want to contribute to java compiler > in mere future,but don't know how to start and build a whole compiler,so > please guide me,and provide me step-by-step information on how to learn > compiler design concepts,build compiler,how to contribute to OracleJDK / > OpenJDK java compiler,please provide me good books and other resources. > Sir,please help me fulfilling my dreams,I am eagerly waiting for your > reply.I am ready to follow your advice,so feel free to communicate with > me.Thank you in advance. > Thanking you, > Subhamoy Roy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Wed Jan 27 13:55:48 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Jan 2016 16:55:48 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) Message-ID: <56A8CC64.3080500@oracle.com> Hi again, This is a formal pre-integration review thread for JEP 280 ("Indify String Concatenation") integration: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, the code reviews and pre-integration checks are clean. Code changes are happening simultaneously in four components: a) (M) javac changes that emit indy: http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ b) (L) JDK changes with StringConcatFactory and friends, plus fixing the regression tests that do not expect additional indys: http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ c) (XS) Build changes that force emitting the "legacy" inline StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is expected): http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ d) (XS) HotSpot changes that fix a GC regression test that now allocates some metaspace from within the test methods having a string concatenation: http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ These changes were already reviewed by multiple people, and so I would like to keep the comments only for serious breaking issues at this point. (Note that this thread cross-posts over several mailing lists: bike-shedding discussion would get multiplied a lot!) Formal acknowledgements from Reviewers would be appreciated. Pending no show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tsachev at gmail.com Wed Jan 27 13:59:26 2016 From: tsachev at gmail.com (Vladimir Tsanev) Date: Wed, 27 Jan 2016 15:59:26 +0200 Subject: Serializable interface with default method Message-ID: Hi I have a simple interface that extends Serializable. import java.io.Serializable; public interface MyInterface extends Serializable {} When I try to add a default method to it like this: import java.io.Serializable; public interface MyInterface extends Serializable { default void foo() {} } And compile with with -Xlint javac -Xlint MyInterface.java I get following warning MyInterface.java:3: warning: [serial] serializable class MyInterface has no definition of serialVersionUID public interface MyInterface extends Serializable { ^ 1 warning It seems that for some reason the compiler thinks that MyInteface is a class, while it is not. I found two possible workarounds. 1) To add @SuppressWarnings("serial") on the interface. import java.io.Serializable; @SuppressWarnings("serial") public interface MyInterface extends Serializable { default void foo() {} } 2) To add serialVersionUID constant in the interface. import java.io.Serializable; public interface MyInterface extends Serializable { long serialVersionUID = 42L; default void foo() {} } While I can live with 1) it is annoying to add a redundant annotation. 2) is pretty ugly because I do not want to add *public* constants to my interface, that I do not need. I couldn't find anything in java.io.Serializable javadoc related to interfaces with default values. This seems like a bug to me. Is there another good reason for this warning, that I miss? Regards, Vlado -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Wed Jan 27 16:31:21 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jan 2016 17:31:21 +0100 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <7E17DDBD-9795-49FA-B83B-DF0F93C13374@oracle.com> I think it quite reasonable to push everything to jdk9/dev. Paul. > On 27 Jan 2016, at 14:55, Aleksey Shipilev wrote: > > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > -------------- 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 vladimir.x.ivanov at oracle.com Wed Jan 27 16:47:22 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 27 Jan 2016 19:47:22 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56A8F49A.4050503@oracle.com> JDK changes looks good! Best regards, Vladimir Ivanov On 1/27/16 4:55 PM, Aleksey Shipilev wrote: > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From alex.buckley at oracle.com Wed Jan 27 23:12:37 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 27 Jan 2016 15:12:37 -0800 Subject: constant references in enums In-Reply-To: <56A2AF72.4060807@oracle.com> References: <5CA0DFDA-5D97-4767-BE51-CD596B506C0E@oracle.com> <56A17ACB.8050106@oracle.com> <56A17CFB.3090102@oracle.com> <56A17D41.3080905@oracle.com> <56A2AF72.4060807@oracle.com> Message-ID: <56A94EE5.2040809@oracle.com> On 1/22/2016 2:38 PM, Alex Buckley wrote: > As to readability of the spec, an enum constants like FOOE(FOOV) has > always been specified by translation to a public static final field. JSR > 201 said "Each such field is initialized to the enum constant that > corresponds to it." I sharpened this very slightly in JLS8 to "The field > has a variable initializer consisting of c [c is the enum constant]" but > I recall not wanting to commit to "The field has a variable initializer > consisting of 'new E(/c_arglist/)'." because compilers don't need to > agree on the signature of an enum constructor. (See the related note in > 8.9.2.) > > As such, your complaint that the JLS doesn't specify the class variable > initializer for FOOE well enough to predict the meaning of FOOV is > valid. A possible fix is to have 8.9.3 reiterate the useful info from > 8.9.1: "An enum constant may be followed by arguments, which are passed > to the constructor of the enum when the constant is created during class > initialization as described later in this section." https://bugs.openjdk.java.net/browse/JDK-8148419 Alex From maurizio.cimadamore at oracle.com Thu Jan 28 16:34:36 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2016 16:34:36 +0000 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56AA431C.4010008@oracle.com> Langtools changes look fine to me (as discussed on previous review thread). Thanks! Maurizio On 27/01/16 13:55, Aleksey Shipilev wrote: > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From joel.borggren.franck at gmail.com Thu Jan 28 18:45:05 2016 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Thu, 28 Jan 2016 19:45:05 +0100 Subject: Bug in encoding type annotations for supertype_targets Message-ID: Hello, While working on the core reflection code for type annotation I discovered what I believe is a javac bug. It looks like javac omits the type_path structure for nested types in supertype and implemets targets. In the example below, when looking at GenericSub in javap I get this encoding of @Foo: RuntimeVisibleTypeAnnotations: 0: #18(): CLASS_EXTENDS, type_index=-1, location=[TYPE_ARGUMENT(0)] as expected, but when looking at either Impl or SubInner I get: RuntimeVisibleTypeAnnotations: 0: #15(): CLASS_EXTENDS, type_index=0 or RuntimeVisibleTypeAnnotations: 0: #14(): CLASS_EXTENDS, type_index=-1 Note the missing type_path (location in javap) for the nesting, which I think table Table 4.7.20.2-E in the vm spec implies. I can file a bug if you want me to. cheers /Joel --- 8< --- import java.lang.annotation.*; import java.util.*; import java.lang.reflect.*; /* * @test */ public class LostTypePath {} class Super {} class Sub extends @Foo Super {} class Generic {} class GenericSub extends Generic<@Foo B> {} class Outer { public static class Inner {}} class SubInner extends Outer . @Foo Inner {} interface IOuter { public interface IInner {}} class Impl implements IOuter . @Foo IInner {} @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) @interface Foo {} From alex.buckley at oracle.com Thu Jan 28 19:35:49 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 28 Jan 2016 11:35:49 -0800 Subject: Bug in encoding type annotations for supertype_targets In-Reply-To: References: Message-ID: <56AA6D95.1040200@oracle.com> Hi Joel, On 1/28/2016 10:45 AM, Joel Borggr?n-Franck wrote: > While working on the core reflection code for type annotation I > discovered what I believe is a javac bug. It looks like javac omits > the type_path structure for nested types in supertype and implemets > targets. In the example below, when looking at GenericSub in javap I > get this encoding of @Foo: > > RuntimeVisibleTypeAnnotations: > 0: #18(): CLASS_EXTENDS, type_index=-1, location=[TYPE_ARGUMENT(0)] > > as expected, but when looking at either Impl or SubInner I get: > > RuntimeVisibleTypeAnnotations: > 0: #15(): CLASS_EXTENDS, type_index=0 > > or > > RuntimeVisibleTypeAnnotations: > 0: #14(): CLASS_EXTENDS, type_index=-1 > > Note the missing type_path (location in javap) for the nesting, which > I think table Table 4.7.20.2-E in the vm spec implies. > > I can file a bug if you want me to. I agree that the "Outer . @Foo Inner"-style terms are legal, and should have a target_path item generated. To be precise, the supertype_target item belongs to the target_info item, not the target_path item. supertype_target encodes which type is of interest among the one or more types specified after 'extends'/'implements'. All your sample programs have exactly one type in their 'extends'/'implements' clauses, so I'd be fairly confident that supertype_target is correct. What is more likely to be wrong is (as you say) the target_path item which encodes the "structural" location of a type annotation within a nested/parameterized/array type. The type_index items are surprising too. type_index is not about the location of a type annotation, but about the annotation itself ("@Foo"). It encodes the constant pool entry which gives the annotation's own type. 0 and -1 are bad answers for that. I suspect javap is actually finding target_path items (possibly ill-formed) and showing them as type_index. So yes, please file a bug. Alex > cheers > /Joel > > --- 8< --- > > import java.lang.annotation.*; > import java.util.*; > import java.lang.reflect.*; > > /* > * @test > */ > public class LostTypePath {} > > class Super {} > class Sub extends @Foo Super {} > > class Generic {} > class GenericSub extends Generic<@Foo B> {} > > class Outer { public static class Inner {}} > class SubInner extends Outer . @Foo Inner {} > > interface IOuter { public interface IInner {}} > class Impl implements IOuter . @Foo IInner {} > > @Target(ElementType.TYPE_USE) > @Retention(RetentionPolicy.RUNTIME) > @interface Foo {} > From joel.borggren.franck at gmail.com Thu Jan 28 20:05:31 2016 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Thu, 28 Jan 2016 21:05:31 +0100 Subject: Bug in encoding type annotations for supertype_targets In-Reply-To: <56AA6D95.1040200@oracle.com> References: <56AA6D95.1040200@oracle.com> Message-ID: Hi Alex, Actually I suspect the target_info is correct, a supertype_target with a supertype_index of 65535 for the class cases but read into a signed char, and 0 for the 0:th interface. This isn't the type_index entry later in type_annotation structure, Javap just has a non-standard notation (another bug perhaps?) Created: https://bugs.openjdk.java.net/browse/JDK-8148504 cheers /Joel On Thu, Jan 28, 2016 at 8:35 PM, Alex Buckley wrote: > Hi Joel, > > On 1/28/2016 10:45 AM, Joel Borggr?n-Franck wrote: >> >> While working on the core reflection code for type annotation I >> discovered what I believe is a javac bug. It looks like javac omits >> the type_path structure for nested types in supertype and implemets >> targets. In the example below, when looking at GenericSub in javap I >> get this encoding of @Foo: >> >> RuntimeVisibleTypeAnnotations: >> 0: #18(): CLASS_EXTENDS, type_index=-1, location=[TYPE_ARGUMENT(0)] >> >> as expected, but when looking at either Impl or SubInner I get: >> >> RuntimeVisibleTypeAnnotations: >> 0: #15(): CLASS_EXTENDS, type_index=0 >> >> or >> >> RuntimeVisibleTypeAnnotations: >> 0: #14(): CLASS_EXTENDS, type_index=-1 >> >> Note the missing type_path (location in javap) for the nesting, which >> I think table Table 4.7.20.2-E in the vm spec implies. >> >> I can file a bug if you want me to. > > > I agree that the "Outer . @Foo Inner"-style terms are legal, and should have > a target_path item generated. > > To be precise, the supertype_target item belongs to the target_info item, > not the target_path item. supertype_target encodes which type is of interest > among the one or more types specified after 'extends'/'implements'. All your > sample programs have exactly one type in their 'extends'/'implements' > clauses, so I'd be fairly confident that supertype_target is correct. What > is more likely to be wrong is (as you say) the target_path item which > encodes the "structural" location of a type annotation within a > nested/parameterized/array type. > > The type_index items are surprising too. type_index is not about the > location of a type annotation, but about the annotation itself ("@Foo"). It > encodes the constant pool entry which gives the annotation's own type. 0 and > -1 are bad answers for that. I suspect javap is actually finding target_path > items (possibly ill-formed) and showing them as type_index. > > So yes, please file a bug. > > Alex > > >> cheers >> /Joel >> >> --- 8< --- >> >> import java.lang.annotation.*; >> import java.util.*; >> import java.lang.reflect.*; >> >> /* >> * @test >> */ >> public class LostTypePath {} >> >> class Super {} >> class Sub extends @Foo Super {} >> >> class Generic {} >> class GenericSub extends Generic<@Foo B> {} >> >> class Outer { public static class Inner {}} >> class SubInner extends Outer . @Foo Inner {} >> >> interface IOuter { public interface IInner {}} >> class Impl implements IOuter . @Foo IInner {} >> >> @Target(ElementType.TYPE_USE) >> @Retention(RetentionPolicy.RUNTIME) >> @interface Foo {} >> > From alex.buckley at oracle.com Thu Jan 28 20:12:31 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 28 Jan 2016 12:12:31 -0800 Subject: Bug in encoding type annotations for supertype_targets In-Reply-To: References: <56AA6D95.1040200@oracle.com> Message-ID: <56AA762F.1050800@oracle.com> Yes, we are agreeing that i) target_info (in particular, the supertype_target variant) is likely emitted correctly, and ii) target_path is not. It also seems that javap is printing "type_index=..." for the target_info item (not target_path as I said before). Alex On 1/28/2016 12:05 PM, Joel Borggr?n-Franck wrote: > Hi Alex, > > Actually I suspect the target_info is correct, a supertype_target with > a supertype_index of 65535 for the class cases but read into a signed > char, and 0 for the 0:th interface. This isn't the type_index entry > later in type_annotation structure, Javap just has a non-standard > notation (another bug perhaps?) > > Created: https://bugs.openjdk.java.net/browse/JDK-8148504 > > cheers > /Joel > > On Thu, Jan 28, 2016 at 8:35 PM, Alex Buckley wrote: >> Hi Joel, >> >> On 1/28/2016 10:45 AM, Joel Borggr?n-Franck wrote: >>> >>> While working on the core reflection code for type annotation I >>> discovered what I believe is a javac bug. It looks like javac omits >>> the type_path structure for nested types in supertype and implemets >>> targets. In the example below, when looking at GenericSub in javap I >>> get this encoding of @Foo: >>> >>> RuntimeVisibleTypeAnnotations: >>> 0: #18(): CLASS_EXTENDS, type_index=-1, location=[TYPE_ARGUMENT(0)] >>> >>> as expected, but when looking at either Impl or SubInner I get: >>> >>> RuntimeVisibleTypeAnnotations: >>> 0: #15(): CLASS_EXTENDS, type_index=0 >>> >>> or >>> >>> RuntimeVisibleTypeAnnotations: >>> 0: #14(): CLASS_EXTENDS, type_index=-1 >>> >>> Note the missing type_path (location in javap) for the nesting, which >>> I think table Table 4.7.20.2-E in the vm spec implies. >>> >>> I can file a bug if you want me to. >> >> >> I agree that the "Outer . @Foo Inner"-style terms are legal, and should have >> a target_path item generated. >> >> To be precise, the supertype_target item belongs to the target_info item, >> not the target_path item. supertype_target encodes which type is of interest >> among the one or more types specified after 'extends'/'implements'. All your >> sample programs have exactly one type in their 'extends'/'implements' >> clauses, so I'd be fairly confident that supertype_target is correct. What >> is more likely to be wrong is (as you say) the target_path item which >> encodes the "structural" location of a type annotation within a >> nested/parameterized/array type. >> >> The type_index items are surprising too. type_index is not about the >> location of a type annotation, but about the annotation itself ("@Foo"). It >> encodes the constant pool entry which gives the annotation's own type. 0 and >> -1 are bad answers for that. I suspect javap is actually finding target_path >> items (possibly ill-formed) and showing them as type_index. >> >> So yes, please file a bug. >> >> Alex >> >> >>> cheers >>> /Joel >>> >>> --- 8< --- >>> >>> import java.lang.annotation.*; >>> import java.util.*; >>> import java.lang.reflect.*; >>> >>> /* >>> * @test >>> */ >>> public class LostTypePath {} >>> >>> class Super {} >>> class Sub extends @Foo Super {} >>> >>> class Generic {} >>> class GenericSub extends Generic<@Foo B> {} >>> >>> class Outer { public static class Inner {}} >>> class SubInner extends Outer . @Foo Inner {} >>> >>> interface IOuter { public interface IInner {}} >>> class Impl implements IOuter . @Foo IInner {} >>> >>> @Target(ElementType.TYPE_USE) >>> @Retention(RetentionPolicy.RUNTIME) >>> @interface Foo {} >>> >> From maurizio.cimadamore at oracle.com Thu Jan 28 21:37:28 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2016 21:37:28 +0000 Subject: RFR (XS): 8147949: NetBeans cannot open langtools repository because of the reserved work "aux" In-Reply-To: <56A67390.6030106@oracle.com> References: <56A67390.6030106@oracle.com> Message-ID: <56AA8A18.2020207@oracle.com> Looks good Maurizio On 25/01/16 19:12, Jan Lahoda wrote: > Hello, > > As reported in the bug: > https://bugs.openjdk.java.net/browse/JDK-8147949 > > The NetBeans' project for langtools contains references to directory > named "aux", which is causing problems on Windows. On a closer look, > the "aux" references shouldn't be needed, so I propose to remove them > altogether. > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8147949/webrev.00/index.html > > Thanks, > Jan From erik.joelsson at oracle.com Fri Jan 29 13:32:06 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 14:32:06 +0100 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56AB69D6.7060801@oracle.com> On 2016-01-27 14:55, Aleksey Shipilev wrote: > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ In what context do we need pre-JDK 9 bytecode for java.base and jdk.compiler? /Erik From aleksey.shipilev at oracle.com Fri Jan 29 13:51:39 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 29 Jan 2016 16:51:39 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56AB69D6.7060801@oracle.com> References: <56A8CC64.3080500@oracle.com> <56AB69D6.7060801@oracle.com> Message-ID: <56AB6E6B.2000103@oracle.com> (dropping corelibs-dev and hotspot-dev) On 01/29/2016 04:32 PM, Erik Joelsson wrote: > On 2016-01-27 14:55, Aleksey Shipilev wrote: >> c) (XS) Build changes that force emitting the "legacy" inline >> StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is >> expected): >> http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > In what context do we need pre-JDK 9 bytecode for java.base and > jdk.compiler? Circularity issues, one critical and one manageable. Critical: java.base is excepted to let JDK bootstrap properly, otherwise processing a String concat expression within the j.l.invoke infrastructure that handles ISC would fail because of the circularity. Manageable: jdk.compiler is excepted to test the rest of JDK properly first. The bug in ISC that breaks a compiler would introduce breakages in many things that are compiled with it, sometimes during the compilation itself. Which, in best case, fails some limited amount of regression tests, but frequently fails the OpenJDK build itself. We may want to reconsider this going forward, after ISC stabilizes: https://bugs.openjdk.java.net/browse/JDK-8148605 Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From joel.borggren.franck at gmail.com Sun Jan 31 16:37:41 2016 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Sun, 31 Jan 2016 17:37:41 +0100 Subject: Bug in encoding type annotations for supertype_targets In-Reply-To: <56AA762F.1050800@oracle.com> References: <56AA6D95.1040200@oracle.com> <56AA762F.1050800@oracle.com> Message-ID: So when debugging this in javac I realized I'm probably wrong, and this looks like a reflection issue once again. In both "erroneous" cases above the class or the interface is statically nested, so there is only one type where the annotation can appear (the innermost type). I checked a similar case on fields, public class Outer { public static class Inner { Outer . @TA Outer foo; } } and javac omits the type_path here as well. I'm not sure this was a conscious choice, but due to how javac treats statically nested classes I think this will be consistent across the board. This means I'll have to sort out the nesting on the reflective side. What do you think? cheers /Joel On Thu, Jan 28, 2016 at 9:12 PM, Alex Buckley wrote: > Yes, we are agreeing that i) target_info (in particular, the > supertype_target variant) is likely emitted correctly, and ii) target_path > is not. > > It also seems that javap is printing "type_index=..." for the target_info > item (not target_path as I said before). > > Alex > > > On 1/28/2016 12:05 PM, Joel Borggr?n-Franck wrote: >> >> Hi Alex, >> >> Actually I suspect the target_info is correct, a supertype_target with >> a supertype_index of 65535 for the class cases but read into a signed >> char, and 0 for the 0:th interface. This isn't the type_index entry >> later in type_annotation structure, Javap just has a non-standard >> notation (another bug perhaps?) >> >> Created: https://bugs.openjdk.java.net/browse/JDK-8148504 >> >> cheers >> /Joel >> >> On Thu, Jan 28, 2016 at 8:35 PM, Alex Buckley >> wrote: >>> >>> Hi Joel, >>> >>> On 1/28/2016 10:45 AM, Joel Borggr?n-Franck wrote: >>>> >>>> >>>> While working on the core reflection code for type annotation I >>>> discovered what I believe is a javac bug. It looks like javac omits >>>> the type_path structure for nested types in supertype and implemets >>>> targets. In the example below, when looking at GenericSub in javap I >>>> get this encoding of @Foo: >>>> >>>> RuntimeVisibleTypeAnnotations: >>>> 0: #18(): CLASS_EXTENDS, type_index=-1, location=[TYPE_ARGUMENT(0)] >>>> >>>> as expected, but when looking at either Impl or SubInner I get: >>>> >>>> RuntimeVisibleTypeAnnotations: >>>> 0: #15(): CLASS_EXTENDS, type_index=0 >>>> >>>> or >>>> >>>> RuntimeVisibleTypeAnnotations: >>>> 0: #14(): CLASS_EXTENDS, type_index=-1 >>>> >>>> Note the missing type_path (location in javap) for the nesting, which >>>> I think table Table 4.7.20.2-E in the vm spec implies. >>>> >>>> I can file a bug if you want me to. >>> >>> >>> >>> I agree that the "Outer . @Foo Inner"-style terms are legal, and should >>> have >>> a target_path item generated. >>> >>> To be precise, the supertype_target item belongs to the target_info item, >>> not the target_path item. supertype_target encodes which type is of >>> interest >>> among the one or more types specified after 'extends'/'implements'. All >>> your >>> sample programs have exactly one type in their 'extends'/'implements' >>> clauses, so I'd be fairly confident that supertype_target is correct. >>> What >>> is more likely to be wrong is (as you say) the target_path item which >>> encodes the "structural" location of a type annotation within a >>> nested/parameterized/array type. >>> >>> The type_index items are surprising too. type_index is not about the >>> location of a type annotation, but about the annotation itself ("@Foo"). >>> It >>> encodes the constant pool entry which gives the annotation's own type. 0 >>> and >>> -1 are bad answers for that. I suspect javap is actually finding >>> target_path >>> items (possibly ill-formed) and showing them as type_index. >>> >>> So yes, please file a bug. >>> >>> Alex >>> >>> >>>> cheers >>>> /Joel >>>> >>>> --- 8< --- >>>> >>>> import java.lang.annotation.*; >>>> import java.util.*; >>>> import java.lang.reflect.*; >>>> >>>> /* >>>> * @test >>>> */ >>>> public class LostTypePath {} >>>> >>>> class Super {} >>>> class Sub extends @Foo Super {} >>>> >>>> class Generic {} >>>> class GenericSub extends Generic<@Foo B> {} >>>> >>>> class Outer { public static class Inner {}} >>>> class SubInner extends Outer . @Foo Inner {} >>>> >>>> interface IOuter { public interface IInner {}} >>>> class Impl implements IOuter . @Foo IInner {} >>>> >>>> @Target(ElementType.TYPE_USE) >>>> @Retention(RetentionPolicy.RUNTIME) >>>> @interface Foo {} >>>> >>> > From robert.olofsson at khelekore.org Tue Jan 19 19:08:22 2016 From: robert.olofsson at khelekore.org (Robert Olofsson) Date: Tue, 19 Jan 2016 19:08:22 -0000 Subject: Trying to build a more hackable compiler... Message-ID: <20160119200819.129514a0@nuccy.khelekore.org> Hi! Some time ago I started reading the code for javac and I realized that it is not a project that is easy to work on. I also realized that there are other people that want a compiler that is easier to hack. A few of the things that are requested are: * Grammar based parser * Better multi threading I did try to make a few patches for javac to at least make it better multi threaded, but realized that this was really hard to do, at least for the code I looked at. Too much global state in the lexer and parser. I realized that I actually did take a few compiler related courses so time to build something on my own, as a proof of concept. In case you want to take a look: https://github.com/robert-olofsson/parjac Initial thoughts: * Making lexing + parsing run in parallel is easy * Setting classes on types in parallel is easy * Checking other semantics in parallel is easy * Writing bytecode in parallel is easy Parsing a reasonably big code tree (27195 files with 11022 of them being java) and outputting class files containing hello-world like methods with the correct signatures is quite a lot faster than javac doing a full compile and my computer is a nuc i7, so not many cores. Sure, this is a bit of apples vs oranges, but it still indicates that it is quite possible to fulfill the wishes of a grammar based multi threaded compiler. The heavy part is currently parsing. I do know of the antlr-javac experiment, but it seems to have died, not sure what will happen to it. My experiments with antlr indicated that it is too hard to use for a java 8 grammar and it seems like it ended up being slower than ordinary javac. If this is considered advertising a non javac-compiler I do apologize, my end goal is to make javac (based on current code or some other code) be a better compiler and for now I only want to show that it seems possible to make it better. /robo