From jonathan.gibbons at oracle.com Wed Feb 1 01:50:00 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 31 Jan 2017 17:50:00 -0800 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 In-Reply-To: <44e84136-1fb0-3b4d-a186-452262b2392c@oracle.com> References: <5887662B.8030702@oracle.com> <68c9883f-ecb7-eadb-d504-6621c278a4c7@oracle.com> <3e93b404-5521-a576-d4a7-37e548c83d61@oracle.com> <588899B0.6030502@oracle.com> <7c91a098-5124-e42f-e365-d25f0f981f94@oracle.com> <5888A70B.3000901@oracle.com> <44e84136-1fb0-3b4d-a186-452262b2392c@oracle.com> Message-ID: <58913EC8.9040205@oracle.com> On 01/25/2017 05:42 AM, Claes Redestad wrote: > > > On 01/25/2017 02:24 PM, Jan Lahoda wrote: >> On 25.1.2017 13:59, Claes Redestad wrote: >>> >>> >>> On 01/25/2017 01:27 PM, Jan Lahoda wrote: >>>> On 25.1.2017 12:29, Maurizio Cimadamore wrote: >>>>> >>>>> >>>>> On 25/01/17 10:27, Claes Redestad wrote: >>>>>> Hi, >>>>>> >>>>>> this might be a pre-existing issue, but doesn't this need to take >>>>>> Multi- >>>>>> Release JARs into account and walk the (most) appropriate subtree? >>>>> My understanding (Jan corrects me if I'm wrong) is that javac >>>>> delegates >>>>> MR-jar questions to the underlying nio file system. So, given the >>>>> cache >>>>> is implemented using a nio file walker, the code should be already >>>>> doing >>>>> the appropriate thing? >>>> >>>> Yes, we defer the MR-jar handling to the JarFileSystem. I am not sure >>>> if the handling there should be improved, but I don't think this patch >>>> changes anything. We only keep (valid) package names, and while we >>>> will currently only get packages in the "default" version, I believe >>>> listing also works only for such packages currently. >>> >>> Right, it should work for the default case of compiling at the >>> current JDKs >>> runtime level, and there's code in BaseFileManager that allows setting >>> of the >>> "multi-release" attribute that'd instruct the JarFileSystem to do >>> the right >>> thing when compiling for another release... >>> >>> What I was wondering about is whether the env per jar file is set >>> appropriately, >>> i.e., does --source/--target mean we're compiling against the >>> appropriate code, >>> and - with this patch - do we see the appropriate set of packages in >>> each jar? >> >> If the jar contains a new package specific for e.g. version 9, >> listing of that package won't work (both before or after this patch). >> Not completely sure if that's intended, but I think that's something >> that should be solved in the JarFS. > > If packages for the current release won't show up then I'd consider > that a bug; > are you sure this is the case? The alternative, that packages > specific to 9 > would show up in the listing when compiling for --release 8 would be > equally > bad. > > JarFileSystem already has code which seems to be doing the right thing > given > the right environment input: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f2325d80b37c/src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java#l66 > > > ... thus I think this is a question of whether the > --source/--release/--target > is (or should be) flowing into setting of the "multi-release" > property. Obviously > there's some value being set here, it's just not easy to see it's the > correct one. > > Thanks! > > /Claes Generally the spec for javac with regard to multi-release jars is that javac will pass down the effective target level, and otherwise totally delegate to the JarFileSystem as to what packages should be listed. I do not think javac (or any other tools, except maybe the jar tool) should be in the business of understanding the internal structure and constraints of multi-release jars. -- Jon > >> >> Jan >> >>> >>> Sorry for going out on a tangent here, the patch itself looks really >>> good to me. :-) >>> >>> Thanks! >>> >>> /Claes >>> >>>> >>>> Thanks, >>>> Jan >>>> >>>>> >>>>> Maurizio >>>>>> >>>>>> Thanks! >>>>>> >>>>>> /Claes >>>>>> >>>>>> On 2017-01-24 15:35, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> As reported: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171294 >>>>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010596.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> javac has a problem with compiling with many jars on classpath. The >>>>>>> problem is twofold: >>>>>>> a) there is JavacFileManager.ArchiveContainer.pathCache, and this >>>>>>> cache >>>>>>> keeps entries not only for path that are in the given >>>>>>> archive/jar, but >>>>>>> also for those that are not in it, which may consume too much >>>>>>> memory >>>>>>> >>>>>>> b) when listing a package, for each archive/jar, an equivalent of >>>>>>> Files.exists(Path.resolve(String)) is done, which takes some >>>>>>> time, and >>>>>>> this is repeated a lot of times (and most of the time, the package >>>>>>> does >>>>>>> not exist in the given jar). >>>>>>> >>>>>>> The proposed patch is basically Maurizio's patch that lists >>>>>>> packages on >>>>>>> opening and then can quickly decide if a given archive/jar contains >>>>>>> the >>>>>>> given package or not. The biggest change from the original patch is >>>>>>> that >>>>>>> the packages are computed immediately when the ArchiveContainer is >>>>>>> created, as opposed to compute them lazily. The reason is that the >>>>>>> Containers are created lazily, and are used immediately after being >>>>>>> created. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8171294/webrev.00/ >>>>>>> >>>>>>> How does this look? >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>> >>> > From jonathan.gibbons at oracle.com Wed Feb 1 01:52:01 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 31 Jan 2017 17:52:01 -0800 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 In-Reply-To: <5887662B.8030702@oracle.com> References: <5887662B.8030702@oracle.com> Message-ID: <58913F41.2060506@oracle.com> On 01/24/2017 06:35 AM, Jan Lahoda wrote: > Hi, > > As reported: > https://bugs.openjdk.java.net/browse/JDK-8171294 > http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010596.html > > > javac has a problem with compiling with many jars on classpath. The > problem is twofold: > a) there is JavacFileManager.ArchiveContainer.pathCache, and this > cache keeps entries not only for path that are in the given > archive/jar, but also for those that are not in it, which may consume > too much memory > > b) when listing a package, for each archive/jar, an equivalent of > Files.exists(Path.resolve(String)) is done, which takes some time, and > this is repeated a lot of times (and most of the time, the package > does not exist in the given jar). > > The proposed patch is basically Maurizio's patch that lists packages > on opening and then can quickly decide if a given archive/jar contains > the given package or not. The biggest change from the original patch > is that the packages are computed immediately when the > ArchiveContainer is created, as opposed to compute them lazily. The > reason is that the Containers are created lazily, and are used > immediately after being created. > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8171294/webrev.00/ > > How does this look? > > Thanks, > Jan The basic patch looks look. The extended discussion with respect to multi-release jars, and whether the jar file system is reporting the correct packages to javac is a separate discussion. -- Jon From joe.darcy at oracle.com Thu Feb 2 03:50:23 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 1 Feb 2017 19:50:23 -0800 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> <588FC902.9070008@oracle.com> Message-ID: <017629cb-e8ed-d14f-527b-67c61cc620ad@oracle.com> Hi Bernard, Just pushed your test under 8173798: Tests for printing modules. Thanks again for the test, -Joe On 1/31/2017 4:59 AM, B. Blaser wrote: > Hi Joe, > > 2017-01-31 0:15 GMT+01:00 Joseph D. Darcy : >> Hi Bernard, >> >> Thanks for patch for the test. >> >> We've largely abandoned the bug number based scheme for categorizing tests; >> it became cumbersome to find the tests we were looking for as the set of >> tests grew. >> >> Since the functionality in question is related to the annotation processing >> implementation in javac, I think a location under >> test/tools/javac/processing/model/util would be more appropriate. >> >> Also for a source-based test, it would be more complete to also examine doc >> comments and annotations. If you make those amendments, I can push the test >> as follow-up work (since I've already pushed the code change). >> >> Thanks, >> >> -Joe > Thanks for your comments. > Please, find next the updated test. > > Bernard > > From maurizio.cimadamore at oracle.com Thu Feb 2 11:24:34 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 2 Feb 2017 11:24:34 +0000 Subject: JDK-8162704 In-Reply-To: References: Message-ID: This issue is resolved in JDK 9 - the only issue being that it takes more VM stack size than in the past. I've been able to compile the attached test case in 1.5 seconds, but I have to bump up the compiler stack size as follows: javac -J-Xss2M CompilerIssue.java Cheers Maurizio On 24/11/16 12:33, Wieland, Jacob wrote: > > Is anybody looking into this very weird issue: > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8162704 > > Bug ID: JDK-8162704 deeply nested expression stumps the > compiler-checking algorithm > > bugs.java.com > Component: tools - Sub-Component: javac > > BR, Jacob > > > > > > Spirent Communications e-mail confidentiality. > ------------------------------------------------------------------------ > This e-mail contains confidential and / or privileged information > belonging to Spirent Communications plc, its affiliates and / or > subsidiaries. If you are not the intended recipient, you are hereby > notified that any disclosure, copying, distribution and / or the > taking of any action based upon reliance on the contents of this > transmission is strictly forbidden. If you have received this message > in error please notify the sender by return e-mail and delete it from > your system. > > Spirent Communications plc > Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United > Kingdom. > Tel No. +44 (0) 1293 767676 > Fax No. +44 (0) 1293 767677 > > Registered in England Number 470893 > Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 > 9XN, United Kingdom. > > Or if within the US, > > Spirent Communications, > 27349 Agoura Road, Calabasas, CA, 91301, USA. > Tel No. 1-818-676- 2300 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Feb 2 11:41:30 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 2 Feb 2017 11:41:30 +0000 Subject: JDK-8162704 In-Reply-To: References: Message-ID: On 02/02/17 11:24, Maurizio Cimadamore wrote: > > This issue is resolved in JDK 9 - the only issue being that it takes > more VM stack size than in the past. > > > I've been able to compile the attached test case in 1.5 seconds, but I > have to bump up the compiler stack size as follows: > > > javac -J-Xss2M CompilerIssue.java > Sorry, I was trying out the wrong test case. With the correct test case JDK 9 javac finishes in 2 seconds w/o any need to increase stack size. Maurizio > > > Cheers > Maurizio > > > On 24/11/16 12:33, Wieland, Jacob wrote: >> >> Is anybody looking into this very weird issue: >> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8162704 >> >> Bug ID: JDK-8162704 deeply nested expression stumps the >> compiler-checking algorithm >> >> bugs.java.com >> Component: tools - Sub-Component: javac >> >> BR, Jacob >> >> >> >> >> >> Spirent Communications e-mail confidentiality. >> ------------------------------------------------------------------------ >> This e-mail contains confidential and / or privileged information >> belonging to Spirent Communications plc, its affiliates and / or >> subsidiaries. If you are not the intended recipient, you are hereby >> notified that any disclosure, copying, distribution and / or the >> taking of any action based upon reliance on the contents of this >> transmission is strictly forbidden. If you have received this message >> in error please notify the sender by return e-mail and delete it from >> your system. >> >> Spirent Communications plc >> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United >> Kingdom. >> Tel No. +44 (0) 1293 767676 >> Fax No. +44 (0) 1293 767677 >> >> Registered in England Number 470893 >> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, >> RH10 9XN, United Kingdom. >> >> Or if within the US, >> >> Spirent Communications, >> 27349 Agoura Road, Calabasas, CA, 91301, USA. >> Tel No. 1-818-676- 2300 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Feb 2 11:52:34 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 2 Feb 2017 11:52:34 +0000 Subject: JDK-8162704 In-Reply-To: References: Message-ID: <38e1678d-ce92-ad36-8571-88f082cdceab@oracle.com> I believe the cause was this: https://bugs.openjdk.java.net/browse/JDK-8078093 That is, the speculative attribution framework introduced as part of JDK 8 to handle lambda expressions and method reference in overload resolution context caused a combinatorial explosion of type-checking calls. This has been addressed as part of JEP-215 [1]. Maurizio [1] - http://openjdk.java.net/jeps/215 On 02/02/17 11:45, Wieland, Jacob wrote: > > Hi, > > > that is good to hear, can I ask what the cause of the problem was? > > > BR, > > >  > > > > > > > *Dr. Jacob Wieland* > > /Senior Software Engineer/ > > main +49.30.7261919.34 > > mobile +49.173.6446443 > > > jacob.wieland at spirent.com > > > www.spirent.com > > > > > > > > > Follow us on: > > > > > > > Spirent Communications > >  | > | > > > > > > > Michaelkirchstra?e 17/18 > > 10179 Berlin, Germany > > > > *+++++ N E W S F L A S H +++++* > > Spirent Communications and Testing Technologies join forces to become > your test automation power-house. Read more at http://conta.cc/1S62BEY. > > ------------------------------------------------------------------------ > *From:* Maurizio Cimadamore > *Sent:* Thursday, February 2, 2017 12:41:30 PM > *To:* Wieland, Jacob; Oracle Java Compiler Developers > *Subject:* Re: JDK-8162704 > > > > On 02/02/17 11:24, Maurizio Cimadamore wrote: >> >> This issue is resolved in JDK 9 - the only issue being that it takes >> more VM stack size than in the past. >> >> >> I've been able to compile the attached test case in 1.5 seconds, but >> I have to bump up the compiler stack size as follows: >> >> >> javac -J-Xss2M CompilerIssue.java >> > Sorry, I was trying out the wrong test case. With the correct test > case JDK 9 javac finishes in 2 seconds w/o any need to increase stack > size. > > Maurizio >> >> >> Cheers >> Maurizio >> >> >> On 24/11/16 12:33, Wieland, Jacob wrote: >>> >>> Is anybody looking into this very weird issue: >>> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8162704 >>> >>> Bug ID: JDK-8162704 deeply nested expression stumps the >>> compiler-checking algorithm >>> >>> bugs.java.com >>> Component: tools - Sub-Component: javac >>> >>> BR, Jacob >>> >>> >>> >>> >>> >>> Spirent Communications e-mail confidentiality. >>> ------------------------------------------------------------------------ >>> This e-mail contains confidential and / or privileged information >>> belonging to Spirent Communications plc, its affiliates and / or >>> subsidiaries. If you are not the intended recipient, you are hereby >>> notified that any disclosure, copying, distribution and / or the >>> taking of any action based upon reliance on the contents of this >>> transmission is strictly forbidden. If you have received this >>> message in error please notify the sender by return e-mail and >>> delete it from your system. >>> >>> Spirent Communications plc >>> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United >>> Kingdom. >>> Tel No. +44 (0) 1293 767676 >>> Fax No. +44 (0) 1293 767677 >>> >>> Registered in England Number 470893 >>> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, >>> RH10 9XN, United Kingdom. >>> >>> Or if within the US, >>> >>> Spirent Communications, >>> 27349 Agoura Road, Calabasas, CA, 91301, USA. >>> Tel No. 1-818-676- 2300 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Feb 2 17:05:02 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 2 Feb 2017 18:05:02 +0100 Subject: [PATCH] 8035271: Incorrect code attribute indentation Message-ID: Hi, Next is a small fix to preserve the same code attribute indentation for all javap options (issue 8035271), along with a test. Bernard diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java @@ -571,13 +571,17 @@ } else if (code != null) { if (options.showDisassembled) { println("Code:"); + indent(+1); // Same as CodeWriter.write() codeWriter.writeInstrs(code); codeWriter.writeExceptionTable(code); + indent(-1); } if (options.showLineAndLocalVariableTables) { + indent(+1); // Same as CodeWriter.write() attrWriter.write(code, code.attributes.get(Attribute.LineNumberTable), constant_pool); attrWriter.write(code, code.attributes.get(Attribute.LocalVariableTable), constant_pool); + indent(-1); } } diff --git a/test/tools/javap/CodeAttributeIndentation.java b/test/tools/javap/CodeAttributeIndentation.java new file mode 100644 --- /dev/null +++ b/test/tools/javap/CodeAttributeIndentation.java @@ -0,0 +1,63 @@ +/* + * @test + * @bug 8035271 + * @summary Same code attribute indentation for all options. + * @library /tools/lib + * @modules jdk.compiler/com.sun.tools.javac.api + * jdk.compiler/com.sun.tools.javac.main + * jdk.jdeps/com.sun.tools.javap + * @build toolbox.ToolBox toolbox.JavacTask toolbox.JavapTask + * @run main CodeAttributeIndentation + */ + +import toolbox.ToolBox; +import toolbox.JavacTask; +import toolbox.JavapTask; +import toolbox.Task.OutputKind; + +public class CodeAttributeIndentation { + public static void main(String... args) { + String LS = System.getProperty("line.separator"); + + String src = + "public class A {" + LS + + " public void a() {}" + LS + + "}"; + + String expected = + "Compiled from \"A.java\"" + LS + + "public class A {" + LS + + " public A();" + LS + + " Code:" + LS + + " 0: aload_0" + LS + + " 1: invokespecial #1 " + + "// Method java/lang/Object.\"\":()V" + LS + + " 4: return" + LS + + " LineNumberTable:" + LS + + " line 1: 0" + LS + + " LocalVariableTable:" + LS + + " Start Length Slot Name Signature" + LS + + " 0 5 0 this LA;" + LS + + LS + + " public void a();" + LS + + " Code:" + LS + + " 0: return" + LS + + " LineNumberTable:" + LS + + " line 2: 0" + LS + + " LocalVariableTable:" + LS + + " Start Length Slot Name Signature" + LS + + " 0 1 0 this LA;" + LS + + "}" + LS; + + ToolBox tb = new ToolBox(); + + new JavacTask(tb).options("-g").sources(src).run(); + + String actual = new JavapTask(tb).options("-c", "-l").classes("A.class") + .run().getOutput(OutputKind.DIRECT); + + if (!actual.equals(expected)) + throw new AssertionError("Incorrect code attribute indentation: " + + LS + actual); + } +} From Jacob.Wieland at spirent.com Thu Feb 2 11:45:59 2017 From: Jacob.Wieland at spirent.com (Wieland, Jacob) Date: Thu, 2 Feb 2017 11:45:59 +0000 Subject: JDK-8162704 In-Reply-To: References: , Message-ID: Hi, that is good to hear, can I ask what the cause of the problem was? BR, [X] Dr. Jacob Wieland Senior Software Engineer main +49.30.7261919.34 mobile +49.173.6446443 jacob.wieland at spirent.com www.spirent.com Follow us on: Spirent Communications [X]|[X]|[X] Michaelkirchstra?e 17/18 10179 Berlin, Germany +++++ N E W S F L A S H +++++ Spirent Communications and Testing Technologies join forces to become your test automation power-house. Read more at http://conta.cc/1S62BEY. ________________________________ From: Maurizio Cimadamore Sent: Thursday, February 2, 2017 12:41:30 PM To: Wieland, Jacob; Oracle Java Compiler Developers Subject: Re: JDK-8162704 On 02/02/17 11:24, Maurizio Cimadamore wrote: This issue is resolved in JDK 9 - the only issue being that it takes more VM stack size than in the past. I've been able to compile the attached test case in 1.5 seconds, but I have to bump up the compiler stack size as follows: javac -J-Xss2M CompilerIssue.java Sorry, I was trying out the wrong test case. With the correct test case JDK 9 javac finishes in 2 seconds w/o any need to increase stack size. Maurizio Cheers Maurizio On 24/11/16 12:33, Wieland, Jacob wrote: Is anybody looking into this very weird issue: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8162704 Bug ID: JDK-8162704 deeply nested expression stumps the compiler-checking algorithm bugs.java.com Component: tools - Sub-Component: javac BR, Jacob Spirent Communications e-mail confidentiality. ------------------------------------------------------------------------ This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. Spirent Communications plc Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Tel No. +44 (0) 1293 767676 Fax No. +44 (0) 1293 767677 Registered in England Number 470893 Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Or if within the US, Spirent Communications, 27349 Agoura Road, Calabasas, CA, 91301, USA. Tel No. 1-818-676- 2300 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Feb 2 17:41:27 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 02 Feb 2017 09:41:27 -0800 Subject: [PATCH] 8035271: Incorrect code attribute indentation In-Reply-To: References: Message-ID: <58936F47.60105@oracle.com> Bernard, In other tests with significant amounts of golden text, we have found it more readable to use \n in the golden strings, and use a single .replaceAll on the string to change the \n to the platform newline character. This avoids having to use + LS + at the end of each line. I will look at your changeset in full context, but comments like "// Same as CodeWriter.write()" may be meaningful now, but may be less relevant a year or two down the road, prompting questions like "why does this need to be stated?". Separately, I note that the window of opportunity for fixes like this in JDK 9 is rapidly closing, and at some point, we will have to push such fixes to the JDK 10 repos that were recently opened. -- Jon On 02/02/2017 09:05 AM, B. Blaser wrote: > Hi, > > Next is a small fix to preserve the same code attribute indentation > for all javap options (issue 8035271), along with a test. > > Bernard > > diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java > b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java > --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java > +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java > @@ -571,13 +571,17 @@ > } else if (code != null) { > if (options.showDisassembled) { > println("Code:"); > + indent(+1); // Same as CodeWriter.write() > codeWriter.writeInstrs(code); > codeWriter.writeExceptionTable(code); > + indent(-1); > } > > if (options.showLineAndLocalVariableTables) { > + indent(+1); // Same as CodeWriter.write() > attrWriter.write(code, > code.attributes.get(Attribute.LineNumberTable), constant_pool); > attrWriter.write(code, > code.attributes.get(Attribute.LocalVariableTable), constant_pool); > + indent(-1); > } > } > > diff --git a/test/tools/javap/CodeAttributeIndentation.java > b/test/tools/javap/CodeAttributeIndentation.java > new file mode 100644 > --- /dev/null > +++ b/test/tools/javap/CodeAttributeIndentation.java > @@ -0,0 +1,63 @@ > +/* > + * @test > + * @bug 8035271 > + * @summary Same code attribute indentation for all options. > + * @library /tools/lib > + * @modules jdk.compiler/com.sun.tools.javac.api > + * jdk.compiler/com.sun.tools.javac.main > + * jdk.jdeps/com.sun.tools.javap > + * @build toolbox.ToolBox toolbox.JavacTask toolbox.JavapTask > + * @run main CodeAttributeIndentation > + */ > + > +import toolbox.ToolBox; > +import toolbox.JavacTask; > +import toolbox.JavapTask; > +import toolbox.Task.OutputKind; > + > +public class CodeAttributeIndentation { > + public static void main(String... args) { > + String LS = System.getProperty("line.separator"); > + > + String src = > + "public class A {" + LS + > + " public void a() {}" + LS + > + "}"; > + > + String expected = > + "Compiled from \"A.java\"" + LS + > + "public class A {" + LS + > + " public A();" + LS + > + " Code:" + LS + > + " 0: aload_0" + LS + > + " 1: invokespecial #1 " + > + "// Method java/lang/Object.\"\":()V" + LS + > + " 4: return" + LS + > + " LineNumberTable:" + LS + > + " line 1: 0" + LS + > + " LocalVariableTable:" + LS + > + " Start Length Slot Name Signature" + LS + > + " 0 5 0 this LA;" + LS + > + LS + > + " public void a();" + LS + > + " Code:" + LS + > + " 0: return" + LS + > + " LineNumberTable:" + LS + > + " line 2: 0" + LS + > + " LocalVariableTable:" + LS + > + " Start Length Slot Name Signature" + LS + > + " 0 1 0 this LA;" + LS + > + "}" + LS; > + > + ToolBox tb = new ToolBox(); > + > + new JavacTask(tb).options("-g").sources(src).run(); > + > + String actual = new JavapTask(tb).options("-c", > "-l").classes("A.class") > + .run().getOutput(OutputKind.DIRECT); > + > + if (!actual.equals(expected)) > + throw new AssertionError("Incorrect code attribute indentation: " + > + LS + actual); > + } > +} From joe.darcy at oracle.com Fri Feb 3 08:15:49 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 3 Feb 2017 00:15:49 -0800 Subject: JDK 10 RFR of JDK-8173595: Update TestSourceVersion once VERSION_MAJOR is updated to 10 Message-ID: <005495d0-1834-7136-a43a-5cfc48eca1d9@oracle.com> Hello, Now that VERSION_MAJOR has been updated to 10 (JDK-8029942), the test tools/javac/processing/model/TestSourceVersion.java should be updated in its testing of SourceVersion.latestSupported(). Patch below. Thanks, -Joe --- a/test/tools/javac/processing/model/TestSourceVersion.java Fri Jan 27 16:22:08 2017 -0800 +++ b/test/tools/javac/processing/model/TestSourceVersion.java Fri Feb 03 00:15:13 2017 -0800 @@ -45,7 +45,7 @@ private static void testLatestSupported() { if (SourceVersion.latest() != RELEASE_10 || - SourceVersion.latestSupported() != RELEASE_9) + SourceVersion.latestSupported() != RELEASE_10) throw new RuntimeException("Unexpected release value(s) found:\n" + "latest:\t" + SourceVersion.latest() + "\n" + "latestSupported:\t" + SourceVersion.latestSupported()); From david.holmes at oracle.com Fri Feb 3 11:35:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Feb 2017 21:35:11 +1000 Subject: JDK 10 RFR of JDK-8173595: Update TestSourceVersion once VERSION_MAJOR is updated to 10 In-Reply-To: <005495d0-1834-7136-a43a-5cfc48eca1d9@oracle.com> References: <005495d0-1834-7136-a43a-5cfc48eca1d9@oracle.com> Message-ID: <6a14462d-ed73-6996-e342-03649618426a@oracle.com> Looks good. I think there will be a few things like this that need updating. We already found one internal hotspot test that used version 10 as an invalid version :) Thanks, David On 3/02/2017 6:15 PM, joe darcy wrote: > Hello, > > Now that VERSION_MAJOR has been updated to 10 (JDK-8029942), the test > > tools/javac/processing/model/TestSourceVersion.java > > should be updated in its testing of SourceVersion.latestSupported(). > Patch below. > > Thanks, > > -Joe > > --- a/test/tools/javac/processing/model/TestSourceVersion.java Fri Jan > 27 16:22:08 2017 -0800 > +++ b/test/tools/javac/processing/model/TestSourceVersion.java Fri Feb > 03 00:15:13 2017 -0800 > @@ -45,7 +45,7 @@ > > private static void testLatestSupported() { > if (SourceVersion.latest() != RELEASE_10 || > - SourceVersion.latestSupported() != RELEASE_9) > + SourceVersion.latestSupported() != RELEASE_10) > throw new RuntimeException("Unexpected release value(s) > found:\n" + > "latest:\t" + > SourceVersion.latest() + "\n" + > "latestSupported:\t" + > SourceVersion.latestSupported()); > From joe.darcy at oracle.com Fri Feb 3 18:29:26 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 3 Feb 2017 10:29:26 -0800 Subject: JDK 10 RFR of JDK-8173595: Update TestSourceVersion once VERSION_MAJOR is updated to 10 In-Reply-To: <6a14462d-ed73-6996-e342-03649618426a@oracle.com> References: <005495d0-1834-7136-a43a-5cfc48eca1d9@oracle.com> <6a14462d-ed73-6996-e342-03649618426a@oracle.com> Message-ID: <350ed0b2-ab94-2b49-d1e9-068bee4ad591@oracle.com> On 2/3/2017 3:35 AM, David Holmes wrote: > Looks good. > > I think there will be a few things like this that need updating. We > already found one internal hotspot test that used version 10 as an > invalid version :) Yep; I'll be sending out reviews for a few similar issues over in core-libs and security libs. A bit short-sighted for some new tests in libs written in 9 to use 10 as an invalid version ;-) -Joe From bsrbnd at gmail.com Mon Feb 6 14:02:46 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 6 Feb 2017 15:02:46 +0100 Subject: [PATCH] 8035271: Incorrect code attribute indentation In-Reply-To: <58936F47.60105@oracle.com> References: <58936F47.60105@oracle.com> Message-ID: Jonathan, 2017-02-02 18:41 GMT+01:00 Jonathan Gibbons : > Bernard, > > In other tests with significant amounts of golden text, we have found it > more > readable to use \n in the golden strings, and use a single .replaceAll > on the string to change the \n to the platform newline character. This > avoids having to use + LS + at the end of each line. > > I will look at your changeset in full context, but comments like > "// Same as CodeWriter.write()" may be meaningful now, but may be less > relevant a year or two down the road, prompting questions like "why does > this need to be stated?". > > Separately, I note that the window of opportunity for fixes like this in JDK > 9 > is rapidly closing, and at some point, we will have to push such fixes to > the > JDK 10 repos that were recently opened. > > -- Jon Thanks for your answer, I agree with your comments. Please, find next the updated patch. Bernard > On 02/02/2017 09:05 AM, B. Blaser wrote: >> >> Hi, >> >> Next is a small fix to preserve the same code attribute indentation >> for all javap options (issue 8035271), along with a test. >> >> Bernard diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java @@ -571,13 +571,17 @@ } else if (code != null) { if (options.showDisassembled) { println("Code:"); + indent(+1); codeWriter.writeInstrs(code); codeWriter.writeExceptionTable(code); + indent(-1); } if (options.showLineAndLocalVariableTables) { + indent(+1); attrWriter.write(code, code.attributes.get(Attribute.LineNumberTable), constant_pool); attrWriter.write(code, code.attributes.get(Attribute.LocalVariableTable), constant_pool); + indent(-1); } } diff --git a/test/tools/javap/CodeAttributeIndentation.java b/test/tools/javap/CodeAttributeIndentation.java new file mode 100644 --- /dev/null +++ b/test/tools/javap/CodeAttributeIndentation.java @@ -0,0 +1,65 @@ +/* + * @test + * @bug 8035271 + * @summary Same code attribute indentation for all options. + * @library /tools/lib + * @modules jdk.compiler/com.sun.tools.javac.api + * jdk.compiler/com.sun.tools.javac.main + * jdk.jdeps/com.sun.tools.javap + * @build toolbox.ToolBox toolbox.JavacTask toolbox.JavapTask + * @run main CodeAttributeIndentation + */ + +import toolbox.ToolBox; +import toolbox.JavacTask; +import toolbox.JavapTask; +import toolbox.Task.OutputKind; + +public class CodeAttributeIndentation { + public static void main(String... args) { + String LS = System.getProperty("line.separator"); + + String src = ( + "public class A {\n" + + " public void a() {}\n" + + "}" + ).replaceAll("\n", LS); + + String expected = ( + "Compiled from \"A.java\"\n" + + "public class A {\n" + + " public A();\n" + + " Code:\n" + + " 0: aload_0\n" + + " 1: invokespecial #1 " + + "// Method java/lang/Object.\"\":()V\n" + + " 4: return\n" + + " LineNumberTable:\n" + + " line 1: 0\n" + + " LocalVariableTable:\n" + + " Start Length Slot Name Signature\n" + + " 0 5 0 this LA;\n" + + "\n" + + " public void a();\n" + + " Code:\n" + + " 0: return\n" + + " LineNumberTable:\n" + + " line 2: 0\n" + + " LocalVariableTable:\n" + + " Start Length Slot Name Signature\n" + + " 0 1 0 this LA;\n" + + "}\n" + ).replaceAll("\n", LS); + + ToolBox tb = new ToolBox(); + + new JavacTask(tb).options("-g").sources(src).run(); + + String actual = new JavapTask(tb).options("-c", "-l").classes("A.class") + .run().getOutput(OutputKind.DIRECT); + + if (!actual.equals(expected)) + throw new AssertionError("Incorrect code attribute indentation: " + + LS + actual); + } +} From jan.lahoda at oracle.com Mon Feb 6 15:53:58 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 6 Feb 2017 16:53:58 +0100 Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module Message-ID: <58989C16.80404@oracle.com> Hi, I'd like to ask for a review of a patch that merges the -Xmodule: functionality into --patch-module. After this patch, the input source files are matched against modules patched with --patch-module, and are compiled as-if they were part of the module they are patching. (In the multi-module mode, patches for more than one module can be compiled, in the single-module mode, patches for only one module can be compiled.) Removal of the -Xmodule: option will need adjustments in several repositories, as tests in multiple repositories are currently using -Xmodule:, and also jtreg is using the option. The current patch hence preserves the existing -Xmodule: functionality, although the option is hidden and no longer announced in help. I think it would be good to push the javac/langtools change proposed below, and then continue with other repositories. The langtools patch is here: http://cr.openjdk.java.net/~jlahoda/8173777/langtools.00/ (note it also contains changes to jshell and javadoc). Proposed jdk repository changes are here: http://cr.openjdk.java.net/~jlahoda/8173777/jdk.00/ How does this look? Any feedback is welcome. Thanks, Jan From jan.lahoda at oracle.com Mon Feb 6 18:41:49 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 6 Feb 2017 19:41:49 +0100 Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module In-Reply-To: <58989C16.80404@oracle.com> References: <58989C16.80404@oracle.com> Message-ID: <5898C36D.30902@oracle.com> I've updated the jdk repository webrev to wrap long lines: http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/ Jan On 6.2.2017 16:53, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of a patch that merges the -Xmodule: > functionality into --patch-module. After this patch, the input source > files are matched against modules patched with --patch-module, and are > compiled as-if they were part of the module they are patching. (In the > multi-module mode, patches for more than one module can be compiled, in > the single-module mode, patches for only one module can be compiled.) > > Removal of the -Xmodule: option will need adjustments in several > repositories, as tests in multiple repositories are currently using > -Xmodule:, and also jtreg is using the option. The current patch hence > preserves the existing -Xmodule: functionality, although the option is > hidden and no longer announced in help. I think it would be good to push > the javac/langtools change proposed below, and then continue with other > repositories. > > The langtools patch is here: > http://cr.openjdk.java.net/~jlahoda/8173777/langtools.00/ > > (note it also contains changes to jshell and javadoc). > > Proposed jdk repository changes are here: > http://cr.openjdk.java.net/~jlahoda/8173777/jdk.00/ > > How does this look? > > Any feedback is welcome. > > Thanks, > Jan From cushon at google.com Mon Feb 6 18:45:54 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 6 Feb 2017 10:45:54 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: References: <586C5753.903@oracle.com> <5877F921.80803@oracle.com> Message-ID: Hi, have you had a chance to look at the latest version of the patch? And would it make sense to defer to 10? On Sat, Jan 14, 2017 at 3:37 PM, Liam Miller-Cushon wrote: > On Thu, Jan 12, 2017 at 1:46 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> Is there any good reason not to do so? > > > I don't think so, thanks. I had thought that it would add implementation > complexity and wasn't as obviously useful as supporting top-level and array > elements values. However I realized that matchAnnoToTree can be generalized > to search recursively for values, so it ends up being simpler. And as you > point out, it offers the best flexibility. > > I have uploaded a new version of the patch that searches recursively: > http://cr.openjdk.java.net/~cushon/6388543/webrev.01/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Feb 6 20:42:50 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Feb 2017 20:42:50 +0000 Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module In-Reply-To: <5898C36D.30902@oracle.com> References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com> Message-ID: <206f4364-1d18-fed8-840a-f655b235b943@oracle.com> On 06/02/2017 18:41, Jan Lahoda wrote: > I've updated the jdk repository webrev to wrap long lines: > http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/ > > Jan This looks okay to me. -Alan From jonathan.gibbons at oracle.com Mon Feb 6 23:40:12 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 06 Feb 2017 15:40:12 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: References: <586C5753.903@oracle.com> <5877F921.80803@oracle.com> Message-ID: <5899095C.7060908@oracle.com> On 02/06/2017 10:45 AM, Liam Miller-Cushon wrote: > Hi, have you had a chance to look at the latest version of the patch? > > And would it make sense to defer to 10? > > On Sat, Jan 14, 2017 at 3:37 PM, Liam Miller-Cushon > wrote: > > On Thu, Jan 12, 2017 at 1:46 PM, Jonathan Gibbons > > > wrote: > > Is there any good reason not to do so? > > > I don't think so, thanks. I had thought that it would add > implementation complexity and wasn't as obviously useful as > supporting top-level and array elements values. However I realized > that matchAnnoToTree can be generalized to search recursively for > values, so it ends up being simpler. And as you point out, it > offers the best flexibility. > > I have uploaded a new version of the patch that searches recursively: > http://cr.openjdk.java.net/~cushon/6388543/webrev.01/ > > > http://cr.openjdk.java.net/~cushon/6388543/webrev.01/test/tools/javac/processing/messager/6388543/T6388543.java.html Nit: in the @modules, you don't need to specify java.compiler as well as jdk.compiler, since the latter requires the former. Nit: it is not common to see javax.* imports sorted before java.* imports. Otherwise, looks OK. I think this is small and safe enough for 9. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Feb 7 01:51:41 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 6 Feb 2017 17:51:41 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: <5899095C.7060908@oracle.com> References: <586C5753.903@oracle.com> <5877F921.80803@oracle.com> <5899095C.7060908@oracle.com> Message-ID: Thanks for the review! I fixed the nits, here's the latest version: http://cr.openjdk.java.net/~cushon/6388543/webrev.02/ The changeset is attached. On Mon, Feb 6, 2017 at 3:40 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > > On 02/06/2017 10:45 AM, Liam Miller-Cushon wrote: > > Hi, have you had a chance to look at the latest version of the patch? > > And would it make sense to defer to 10? > > On Sat, Jan 14, 2017 at 3:37 PM, Liam Miller-Cushon > wrote: > >> On Thu, Jan 12, 2017 at 1:46 PM, Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >>> Is there any good reason not to do so? >> >> >> I don't think so, thanks. I had thought that it would add implementation >> complexity and wasn't as obviously useful as supporting top-level and array >> elements values. However I realized that matchAnnoToTree can be generalized >> to search recursively for values, so it ends up being simpler. And as you >> point out, it offers the best flexibility. >> >> I have uploaded a new version of the patch that searches recursively: >> http://cr.openjdk.java.net/~cushon/6388543/webrev.01/ >> > > > http://cr.openjdk.java.net/~cushon/6388543/webrev.01/test/ > tools/javac/processing/messager/6388543/T6388543.java.html > Nit: in the @modules, you don't need to specify java.compiler as well as > jdk.compiler, since the latter requires the former. > Nit: it is not common to see javax.* imports sorted before java.* imports. > > Otherwise, looks OK. > > I think this is small and safe enough for 9. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6388543.patch Type: text/x-patch Size: 10121 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Tue Feb 7 02:05:01 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 06 Feb 2017 18:05:01 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: References: <586C5753.903@oracle.com> <5877F921.80803@oracle.com> <5899095C.7060908@oracle.com> Message-ID: <58992B4D.3010509@oracle.com> reviewed, built, tested and pushed -- Jon On 02/06/2017 05:51 PM, Liam Miller-Cushon wrote: > Thanks for the review! I fixed the nits, here's the latest version: > > http://cr.openjdk.java.net/~cushon/6388543/webrev.02/ > > > The changeset is attached. > > On Mon, Feb 6, 2017 at 3:40 PM, Jonathan Gibbons > > wrote: > > > > On 02/06/2017 10:45 AM, Liam Miller-Cushon wrote: >> Hi, have you had a chance to look at the latest version of the >> patch? >> >> And would it make sense to defer to 10? >> >> On Sat, Jan 14, 2017 at 3:37 PM, Liam Miller-Cushon >> > wrote: >> >> On Thu, Jan 12, 2017 at 1:46 PM, Jonathan Gibbons >> > > wrote: >> >> Is there any good reason not to do so? >> >> >> I don't think so, thanks. I had thought that it would add >> implementation complexity and wasn't as obviously useful as >> supporting top-level and array elements values. However I >> realized that matchAnnoToTree can be generalized to search >> recursively for values, so it ends up being simpler. And as >> you point out, it offers the best flexibility. >> >> I have uploaded a new version of the patch that searches >> recursively: >> http://cr.openjdk.java.net/~cushon/6388543/webrev.01/ >> >> >> > > http://cr.openjdk.java.net/~cushon/6388543/webrev.01/test/tools/javac/processing/messager/6388543/T6388543.java.html > > Nit: in the @modules, you don't need to specify java.compiler as > well as jdk.compiler, since the latter requires the former. > Nit: it is not common to see javax.* imports sorted before java.* > imports. > > Otherwise, looks OK. > > I think this is small and safe enough for 9. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 7 13:23:49 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Feb 2017 13:23:49 +0000 Subject: 8173393: Module system implementation refresh (2/2017) Message-ID: We've been accumulating changes in the jake forest for the last few weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so this update will need to get approval via the FC-extension process. The changes this time are significantly smaller than previous updates. Much of this update is API and javadoc cleanup. There are a few new methods, and a few methods have been renamed/changed, but it's otherwise small potatoes. The webrevs with the changes are here: http://cr.openjdk.java.net/~alanb/8173393/1/ Note that the webrevs are against jdk-9+155 because that is what jake is currently at. I will re-generate the webrevs later in the week once jdk-9+156 is promoted before eventually merging with jdk9/dev in advance of the eventual push. One other thing to note is that the hotspot+jdk repos have the changes for JDK-8171855, this is only because that change was backed up in jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This means that the only non-test change in the hotspot repo is to methodHandles.cpp. In the langtools repo then most of the changes are mechanical, with the only real update being cleanup to jdeps and the change to javac + javap to use the right values for the requires flags (the issue that R?mi brought up on jigsaw-dev last week when sync'ing up ASM). In the jdk repo then ignore the DEBUG_ADD_OPENS changes in ModuleBootstrap, that is not intended for JDK 9. There are a few small bug fixes, and a few more startup improvements from Claes. There are a small number of tests that aren't in jake yet for this update but they should be before I refresh the webrev later in the week. -Alan From maurizio.cimadamore at oracle.com Tue Feb 7 14:39:30 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 7 Feb 2017 14:39:30 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: Langtools changes look good to me. Maurizio On 07/02/17 13:23, Alan Bateman wrote: > We've been accumulating changes in the jake forest for the last few > weeks and it's time to bring the changes to jdk9/dev, to make > jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so > this update will need to get approval via the FC-extension process. > > The changes this time are significantly smaller than previous updates. > Much of this update is API and javadoc cleanup. There are a few new > methods, and a few methods have been renamed/changed, but it's > otherwise small potatoes. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8173393/1/ > > Note that the webrevs are against jdk-9+155 because that is what jake > is currently at. I will re-generate the webrevs later in the week once > jdk-9+156 is promoted before eventually merging with jdk9/dev in > advance of the eventual push. > > One other thing to note is that the hotspot+jdk repos have the changes > for JDK-8171855, this is only because that change was backed up in > jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This > means that the only non-test change in the hotspot repo is to > methodHandles.cpp. > > In the langtools repo then most of the changes are mechanical, with > the only real update being cleanup to jdeps and the change to javac + > javap to use the right values for the requires flags (the issue that > R?mi brought up on jigsaw-dev last week when sync'ing up ASM). > > In the jdk repo then ignore the DEBUG_ADD_OPENS changes in > ModuleBootstrap, that is not intended for JDK 9. > > There are a few small bug fixes, and a few more startup improvements > from Claes. There are a small number of tests that aren't in jake yet > for this update but they should be before I refresh the webrev later > in the week. > > -Alan > From daniel.fuchs at oracle.com Tue Feb 7 15:24:38 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 7 Feb 2017 15:24:38 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: <6eb4c3be-7ffb-ac1c-d5db-41878da0b2b4@oracle.com> Hi Alan, jaxp and stack walking class (and test) changes look OK to me. best regards, -- daniel On 07/02/17 13:23, Alan Bateman wrote: > We've been accumulating changes in the jake forest for the last few > weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157 > if possible. JDK 9 is the first phase of rampdown and so this update > will need to get approval via the FC-extension process. > > The changes this time are significantly smaller than previous updates. > Much of this update is API and javadoc cleanup. There are a few new > methods, and a few methods have been renamed/changed, but it's otherwise > small potatoes. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8173393/1/ > > Note that the webrevs are against jdk-9+155 because that is what jake is > currently at. I will re-generate the webrevs later in the week once > jdk-9+156 is promoted before eventually merging with jdk9/dev in advance > of the eventual push. > > One other thing to note is that the hotspot+jdk repos have the changes > for JDK-8171855, this is only because that change was backed up in > jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This > means that the only non-test change in the hotspot repo is to > methodHandles.cpp. > > In the langtools repo then most of the changes are mechanical, with the > only real update being cleanup to jdeps and the change to javac + javap > to use the right values for the requires flags (the issue that R?mi > brought up on jigsaw-dev last week when sync'ing up ASM). > > In the jdk repo then ignore the DEBUG_ADD_OPENS changes in > ModuleBootstrap, that is not intended for JDK 9. > > There are a few small bug fixes, and a few more startup improvements > from Claes. There are a small number of tests that aren't in jake yet > for this update but they should be before I refresh the webrev later in > the week. > > -Alan > From jan.lahoda at oracle.com Tue Feb 7 18:11:16 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 7 Feb 2017 19:11:16 +0100 Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module In-Reply-To: <206f4364-1d18-fed8-840a-f655b235b943@oracle.com> References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com> <206f4364-1d18-fed8-840a-f655b235b943@oracle.com> Message-ID: <589A0DC4.5020409@oracle.com> Hi, Thanks. I did two small updates to the patches: -for langtools repository, I added unwrapping to ClientCodeWrapper.WrappedJavaFileManager.getLocationForModule - the incoming JavaFileObject is unwrapped, so that we don't pass our wrappers to the client's code. Direct link: http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java.udiff.html -for jdk repository, I fixed the: test/javax/xml/jaxp/common/8035437/run.sh to use a platform specific path separator. This is based on code from jdk/test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh Direct link: http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/test/javax/xml/jaxp/common/8035437/run.sh.udiff.html (Sorry that I missed this before.) Updated webrevs: -langtools repository: http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/ -jdk repository: http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/ Thanks, Jan On 6.2.2017 21:42, Alan Bateman wrote: > > > On 06/02/2017 18:41, Jan Lahoda wrote: >> I've updated the jdk repository webrev to wrap long lines: >> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/ >> >> Jan > This looks okay to me. > > -Alan > From daniel.smith at oracle.com Tue Feb 7 18:54:05 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 7 Feb 2017 11:54:05 -0700 Subject: spec clarification: wildcard array element signature In-Reply-To: <581BC745.5050803@oracle.com> References: <580E52CC.4030408@oracle.com> <5474bf92-130f-36aa-8435-03e392be4f0c@oracle.com> <581BC745.5050803@oracle.com> Message-ID: <35317E7D-5D0E-4633-ABA0-D540153BB2F9@oracle.com> > On Nov 3, 2016, at 5:24 PM, Alex Buckley wrote: > > On 10/24/2016 2:35 PM, Maurizio Cimadamore wrote: >> On 24/10/16 19:28, Alex Buckley wrote: >> Regarding the other issue about wildcards being replaced in supertypes, >> I think there are two options - none of which is particularly appealing: >> >> 1. fix javac (and other compilers) so that the signature attribute only >> speaks about types in the source code, w/o attempting to do any >> membership computation - this should ensure that non-denotable types >> should not crop up in the process - unfortunately, doing so will change >> the signature attribute of real code out there - and the compatibility >> impact potentially large (the difference will be visible in core >> reflection). > > The Signature attribute, in particular a class type signature (JVMS8 4.7.9.1), is defined in terms of binary names, as alluded to by your comment about Field.getGenericType aligning with Field.getType. > > Therefore, Signature must be able to encode A.I (so to speak) rather than the B.I type literally found in source code. > > That means rejecting option 1, and choosing option 2: > >> 2. keep javac as is - live with 'weird' signatures and plug resulting >> soundness issues (esp. around separate compilation) ? > > Which means a change to the JVMS TypeArgument production, and corresponding enhancement to ParameterizedType.getActualTypeArguments() [thanks Liam]. > > Dan, any objection to this? Sorry, didn't see this originally, thanks for pointing me to it. Yes, I object! "?[]" is not a type. It's meaningless. It is always wrong to perform substitutions that replace type variables with wildcards. javac has a history of doing so, and those cases need to be fixed. The compiler's internal representation of wildcards should not even allow such an attempt at substitution to compile (e.g., a class Wildcard should not extend a class Type), but alas, we have a lot of legacy violating this rule. Liam's program raises issues related to two existing spec bugs: JDK-8030746: 4.10: Define subtyping for inner classes of parameterized types JDK-8016196: Inference: define supertype parameterization for wildcard-parameterized types These are part of our type system cleanup effort; when addressed, we'll have a clear answer for how to interpret "B.I" and, thus, how to record it in bytecode. (Preview: the answer is probably "A.I".) Suggest closing JDK-8172742 as "Not an Issue"?the JVMS grammar is fine. ?Dan From alex.buckley at oracle.com Tue Feb 7 19:38:41 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 07 Feb 2017 11:38:41 -0800 Subject: spec clarification: wildcard array element signature In-Reply-To: <35317E7D-5D0E-4633-ABA0-D540153BB2F9@oracle.com> References: <580E52CC.4030408@oracle.com> <5474bf92-130f-36aa-8435-03e392be4f0c@oracle.com> <581BC745.5050803@oracle.com> <35317E7D-5D0E-4633-ABA0-D540153BB2F9@oracle.com> Message-ID: <589A2241.5060503@oracle.com> On 2/7/2017 10:54 AM, Dan Smith wrote: > Yes, I object! "?[]" is not a type. It's meaningless. > > It is always wrong to perform substitutions that replace type > variables with wildcards. javac has a history of doing so, and those > cases need to be fixed. The compiler's internal representation of > wildcards should not even allow such an attempt at substitution to > compile (e.g., a class Wildcard should not extend a class Type), but > alas, we have a lot of legacy violating this rule. Am I right to say that this is what javac is doing in the recent snipper from Stephan Herrmann? :- --- public class Bug494198 { class Inner {...} } Bug494198 outer = ... ... outer.new Inner() {...} final class Bug494198$1 extends ***Bug494198<>***.Inner --- > Liam's program raises issues related to two existing spec bugs: > JDK-8030746: 4.10: Define subtyping for inner classes of > parameterized types JDK-8016196: Inference: define supertype > parameterization for wildcard-parameterized types > > These are part of our type system cleanup effort; when addressed, > we'll have a clear answer for how to interpret "B.I" and, thus, > how to record it in bytecode. (Preview: the answer is probably "A extends Object[]>.I".) > > Suggest closing JDK-8172742 as "Not an Issue"?the JVMS grammar is > fine. OK -- please close it with an explanation for Liam and Stephan's benefit. Alex From mandy.chung at oracle.com Tue Feb 7 20:32:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 7 Feb 2017 12:32:52 -0800 Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module In-Reply-To: <589A0DC4.5020409@oracle.com> References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com> <206f4364-1d18-fed8-840a-f655b235b943@oracle.com> <589A0DC4.5020409@oracle.com> Message-ID: > On Feb 7, 2017, at 10:11 AM, Jan Lahoda wrote: > > Updated webrevs: > -langtools repository: > http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/ test/tools/jdeps/jdkinternals/RemovedJDKInternals.java change looks okay to me. > -jdk repository: > http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/ Looks okay too. Mandy From daniel.smith at oracle.com Tue Feb 7 20:57:54 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 7 Feb 2017 13:57:54 -0700 Subject: spec clarification: wildcard array element signature In-Reply-To: <589A2241.5060503@oracle.com> References: <580E52CC.4030408@oracle.com> <5474bf92-130f-36aa-8435-03e392be4f0c@oracle.com> <581BC745.5050803@oracle.com> <35317E7D-5D0E-4633-ABA0-D540153BB2F9@oracle.com> <589A2241.5060503@oracle.com> Message-ID: <69AC195E-A1C8-46FB-B771-2C19E8A2EF61@oracle.com> > On Feb 7, 2017, at 12:38 PM, Alex Buckley wrote: > > On 2/7/2017 10:54 AM, Dan Smith wrote: >> Yes, I object! "?[]" is not a type. It's meaningless. >> >> It is always wrong to perform substitutions that replace type >> variables with wildcards. javac has a history of doing so, and those >> cases need to be fixed. The compiler's internal representation of >> wildcards should not even allow such an attempt at substitution to >> compile (e.g., a class Wildcard should not extend a class Type), but >> alas, we have a lot of legacy violating this rule. > > Am I right to say that this is what javac is doing in the recent snipper from Stephan Herrmann? :- > > --- > public class Bug494198 { class Inner {...} } > > Bug494198 outer = ... > ... outer.new Inner() {...} > > final class Bug494198$1 > extends ***Bug494198<>***.Inner > --- Yep, same issue. Odd that javac uses capture in this case while using a wildcard in the other case, but it comes down to the same lack of a spec. >> Liam's program raises issues related to two existing spec bugs: >> JDK-8030746: 4.10: Define subtyping for inner classes of >> parameterized types JDK-8016196: Inference: define supertype >> parameterization for wildcard-parameterized types >> >> These are part of our type system cleanup effort; when addressed, >> we'll have a clear answer for how to interpret "B.I" and, thus, >> how to record it in bytecode. (Preview: the answer is probably "A> extends Object[]>.I".) >> >> Suggest closing JDK-8172742 as "Not an Issue"?the JVMS grammar is >> fine. > > OK -- please close it with an explanation for Liam and Stephan's benefit. Done. ?Dan From lois.foltan at oracle.com Tue Feb 7 22:48:46 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 07 Feb 2017 17:48:46 -0500 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: <589A4ECE.80308@oracle.com> Hotspot changes look good to me. Lois On 2/7/2017 8:23 AM, Alan Bateman wrote: > We've been accumulating changes in the jake forest for the last few > weeks and it's time to bring the changes to jdk9/dev, to make > jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so > this update will need to get approval via the FC-extension process. > > The changes this time are significantly smaller than previous updates. > Much of this update is API and javadoc cleanup. There are a few new > methods, and a few methods have been renamed/changed, but it's > otherwise small potatoes. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8173393/1/ > > Note that the webrevs are against jdk-9+155 because that is what jake > is currently at. I will re-generate the webrevs later in the week once > jdk-9+156 is promoted before eventually merging with jdk9/dev in > advance of the eventual push. > > One other thing to note is that the hotspot+jdk repos have the changes > for JDK-8171855, this is only because that change was backed up in > jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This > means that the only non-test change in the hotspot repo is to > methodHandles.cpp. > > In the langtools repo then most of the changes are mechanical, with > the only real update being cleanup to jdeps and the change to javac + > javap to use the right values for the requires flags (the issue that > R?mi brought up on jigsaw-dev last week when sync'ing up ASM). > > In the jdk repo then ignore the DEBUG_ADD_OPENS changes in > ModuleBootstrap, that is not intended for JDK 9. > > There are a few small bug fixes, and a few more startup improvements > from Claes. There are a small number of tests that aren't in jake yet > for this update but they should be before I refresh the webrev later > in the week. > > -Alan > From jonathan.gibbons at oracle.com Wed Feb 8 00:05:37 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 07 Feb 2017 16:05:37 -0800 Subject: RFR: Message-ID: <589A60D1.7010404@oracle.com> Please review a small test-only fix to reorganize some test files into a module/package hierarchy. There is no change to the functionality of the tests; but the cleanup is needed prior to some javac and jtreg changes. JBS: https://bugs.openjdk.java.net/browse/JDK-8174140 Webrev: http://cr.openjdk.java.net/~jjg/8174140/webrev.00/ -- Jon From jonathan.gibbons at oracle.com Wed Feb 8 00:07:07 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 07 Feb 2017 16:07:07 -0800 Subject: RFR: 8174140 Move test files into package hierarchy In-Reply-To: <589A60D1.7010404@oracle.com> References: <589A60D1.7010404@oracle.com> Message-ID: <589A612B.6020507@oracle.com> Resend with proper Subject: line. On 02/07/2017 04:05 PM, Jonathan Gibbons wrote: > Please review a small test-only fix to reorganize some test files into > a module/package hierarchy. > > There is no change to the functionality of the tests; but the cleanup > is needed prior to some javac and jtreg changes. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8174140 > Webrev: http://cr.openjdk.java.net/~jjg/8174140/webrev.00/ > > -- Jon From joe.darcy at oracle.com Wed Feb 8 00:13:44 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 07 Feb 2017 16:13:44 -0800 Subject: RFR: 8174140 Move test files into package hierarchy In-Reply-To: <589A612B.6020507@oracle.com> References: <589A60D1.7010404@oracle.com> <589A612B.6020507@oracle.com> Message-ID: <589A62B8.9000505@oracle.com> Looks fine. -Joe On 2/7/2017 4:07 PM, Jonathan Gibbons wrote: > Resend with proper Subject: line. > > On 02/07/2017 04:05 PM, Jonathan Gibbons wrote: >> Please review a small test-only fix to reorganize some test files >> into a module/package hierarchy. >> >> There is no change to the functionality of the tests; but the cleanup >> is needed prior to some javac and jtreg changes. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8174140 >> Webrev: http://cr.openjdk.java.net/~jjg/8174140/webrev.00/ >> >> -- Jon > From mandy.chung at oracle.com Wed Feb 8 00:37:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 7 Feb 2017 16:37:52 -0800 Subject: RFR: 8174140 Move test files into package hierarchy In-Reply-To: <589A612B.6020507@oracle.com> References: <589A60D1.7010404@oracle.com> <589A612B.6020507@oracle.com> Message-ID: Looks fine. Mandy > On Feb 7, 2017, at 4:07 PM, Jonathan Gibbons wrote: > > Resend with proper Subject: line. > > On 02/07/2017 04:05 PM, Jonathan Gibbons wrote: >> Please review a small test-only fix to reorganize some test files into a module/package hierarchy. >> >> There is no change to the functionality of the tests; but the cleanup is needed prior to some javac and jtreg changes. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8174140 >> Webrev: http://cr.openjdk.java.net/~jjg/8174140/webrev.00/ >> >> -- Jon > From paul.sandoz at oracle.com Wed Feb 8 03:10:53 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Feb 2017 19:10:53 -0800 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <589A4ECE.80308@oracle.com> References: <589A4ECE.80308@oracle.com> Message-ID: <4389C801-3848-433C-8302-2BBF82546304@oracle.com> Hi, Just minor stuff in the JDK area (i browsed quickly through the tests). Paul. java.lang.module.Configuration ? 321 * @implNote In the implementation then observability of modules may depend s/then/the ModuleDescriptor ? 2662 private static > 2663 int compare(Set s1, Set s2) { 2664 Iterator iterator1 = new TreeSet<>(s1).iterator(); 2665 Iterator iterator2 = new TreeSet<>(s2).iterator(); 2666 while (iterator1.hasNext()) { 2667 if (!iterator2.hasNext()) 2668 return 1; // s1 has more elements 2669 T e1 = iterator1.next(); 2670 T e2 = iterator2.next(); 2671 int c = e1.compareTo(e2); 2672 if (c != 0) 2673 return c; 2674 } 2675 if (iterator2.hasNext()) { 2676 return -1; // s2 has more elements 2677 } else { 2678 return 0; 2679 } 2680 } Potential optimisation. Convert the sets to arrays, sort ?em, then use Arrays.compare. BuiltinClassLoader ? 925 private ModuleReader moduleReaderFor(ModuleReference mref) { 926 return moduleToReader.computeIfAbsent(mref, m -> createModuleReader(m)); 927 } Use this:: createModuleReader jdk.internal.module.Builder ? 279 Set modifiers; 280 if (open || synthetic) { 281 modifiers = new HashSet<>(); 282 if (open) modifiers.add(ModuleDescriptor.Modifier.OPEN); 283 if (synthetic) modifiers.add(ModuleDescriptor.Modifier.SYNTHETIC); 284 modifiers = Collections.unmodifiableSet(modifiers); 285 } else { 286 modifiers = Collections.emptySet(); 287 } It would be nice to use the small collection methods given the sizes. The following might work: Set modifiers; int n = (open ? 1 : 0) + (synthetic ? 1 : 0); if (n > 0) { ModuleDescriptor.Modifier[] ms = new ModuleDescriptor.Modifier[n]; if (open) ms[?n] = ModuleDescriptor.Modifier.OPEN; if (synthetic) ms[?n] = ModuleDescriptor.Modifier.SYNTHETIC; modifiers = Set.of(ms); } else { modifiers = Set.of(); } test/tools/jar/modularJar/Basic.java ? 331 @Test(enabled = false) 332 public void partialUpdateFooMainClass() throws IOException { Just checking if that test still needs to be disabled. ? Separately, we missed the opportunity to add lexicographical comparison and mismatch to List (we added them for arrays). Paul. > On 7 Feb 2017, at 14:48, Lois Foltan wrote: > > Hotspot changes look good to me. > Lois > > On 2/7/2017 8:23 AM, Alan Bateman wrote: >> We've been accumulating changes in the jake forest for the last few weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so this update will need to get approval via the FC-extension process. >> >> The changes this time are significantly smaller than previous updates. Much of this update is API and javadoc cleanup. There are a few new methods, and a few methods have been renamed/changed, but it's otherwise small potatoes. >> >> The webrevs with the changes are here: >> http://cr.openjdk.java.net/~alanb/8173393/1/ >> >> Note that the webrevs are against jdk-9+155 because that is what jake is currently at. I will re-generate the webrevs later in the week once jdk-9+156 is promoted before eventually merging with jdk9/dev in advance of the eventual push. >> >> One other thing to note is that the hotspot+jdk repos have the changes for JDK-8171855, this is only because that change was backed up in jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This means that the only non-test change in the hotspot repo is to methodHandles.cpp. >> >> In the langtools repo then most of the changes are mechanical, with the only real update being cleanup to jdeps and the change to javac + javap to use the right values for the requires flags (the issue that R?mi brought up on jigsaw-dev last week when sync'ing up ASM). >> >> In the jdk repo then ignore the DEBUG_ADD_OPENS changes in ModuleBootstrap, that is not intended for JDK 9. >> >> There are a few small bug fixes, and a few more startup improvements from Claes. There are a small number of tests that aren't in jake yet for this update but they should be before I refresh the webrev later in the week. >> >> -Alan >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Alan.Bateman at oracle.com Wed Feb 8 11:37:48 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Feb 2017 11:37:48 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <4389C801-3848-433C-8302-2BBF82546304@oracle.com> References: <589A4ECE.80308@oracle.com> <4389C801-3848-433C-8302-2BBF82546304@oracle.com> Message-ID: <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> On 08/02/2017 03:10, Paul Sandoz wrote: > Hi, > > Just minor stuff in the JDK area (i browsed quickly through the tests). Thanks, a few comments below. > > Paul. > > > java.lang.module.Configuration > ? > > 321 * @implNote In the implementation then observability of modules may depend > > s/then/the "then" should be okay, it could also be "then the" (that might be what you mean). > : > > Potential optimisation. Convert the sets to arrays, sort ?em, then use Arrays.compare. Yes, that could work. It's a real corner case to have to do this but we can do better for such cases. > > > BuiltinClassLoader > ? > > 925 private ModuleReader moduleReaderFor(ModuleReference mref) { > 926 return moduleToReader.computeIfAbsent(mref, m -> createModuleReader(m)); > 927 } > > Use this:: createModuleReader I'll defer to Claes on this, mostly because #classes triggered to load here is observable in startup tests. > > > jdk.internal.module.Builder > ? > > 279 Set modifiers; > 280 if (open || synthetic) { > 281 modifiers = new HashSet<>(); > 282 if (open) modifiers.add(ModuleDescriptor.Modifier.OPEN); > 283 if (synthetic) modifiers.add(ModuleDescriptor.Modifier.SYNTHETIC); > 284 modifiers = Collections.unmodifiableSet(modifiers); > 285 } else { > 286 modifiers = Collections.emptySet(); > 287 } > > It would be nice to use the small collection methods given the sizes. The following might work: This is jlink plugin and would be really odd to have modules with the synthetic modifier. There are no open modules in the JDK images but a custom image may include some so point taken, this could be more efficient. > : > > > test/tools/jar/modularJar/Basic.java > ? > > 331 @Test(enabled = false) > 332 public void partialUpdateFooMainClass() throws IOException { > > Just checking if that test still needs to be disabled. There are fixes going into jdk9/dev for the jar tool that should allow us to re-enable this, it all depends on when the changes will meet up. If we have to push with that test disabled then I'll make sure there is a bug. > : > > ? > > Separately, we missed the opportunity to add lexicographical comparison and mismatch to List (we added them for arrays). > Yes. -Alan. From claes.redestad at oracle.com Wed Feb 8 14:49:31 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 8 Feb 2017 15:49:31 +0100 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> References: <589A4ECE.80308@oracle.com> <4389C801-3848-433C-8302-2BBF82546304@oracle.com> <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> Message-ID: <1d866af6-939f-8767-d772-610f3d63182a@oracle.com> Hi, On 2017-02-08 12:37, Alan Bateman wrote: >> >> >> BuiltinClassLoader >> ? >> >> 925 private ModuleReader moduleReaderFor(ModuleReference mref) { >> 926 return moduleToReader.computeIfAbsent(mref, m -> >> createModuleReader(m)); >> 927 } >> >> Use this:: createModuleReader > I'll defer to Claes on this, mostly because #classes triggered to load > here is observable in startup tests. From a startup perspective all alternatives are more or less equal here, and generally speaking a lambda and a method reference are equal as long as they're both non-capturing. A detail I had missed here, though, is that the createModuleReader method could be made static to ensure the lambda is actually non-capturing (otherwise it'll unnecessarily allocate an object preserving this). So I'd make createModuleReader static and then pick and choose between m -> createModuleReader(m) and BuiltinClassLoader::createModuleReader Thanks! /Claes From Alan.Bateman at oracle.com Wed Feb 8 15:04:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Feb 2017 15:04:05 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <1d866af6-939f-8767-d772-610f3d63182a@oracle.com> References: <589A4ECE.80308@oracle.com> <4389C801-3848-433C-8302-2BBF82546304@oracle.com> <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> <1d866af6-939f-8767-d772-610f3d63182a@oracle.com> Message-ID: <12cb8986-b9f4-55a2-afa9-0a2053328a7a@oracle.com> On 08/02/2017 14:49, Claes Redestad wrote: > > From a startup perspective all alternatives are more or less equal > here, and generally speaking a lambda and a method reference are equal > as long as they're both non-capturing. > > A detail I had missed here, though, is that the createModuleReader > method could be made static to ensure the lambda is actually > non-capturing (otherwise it'll unnecessarily allocate an object > preserving this). Yes, good point, this can of course be static. -Alan From vitalyd at gmail.com Wed Feb 8 19:23:48 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 8 Feb 2017 14:23:48 -0500 Subject: Java 9 ea154 javac compiler error - legit or bug? Message-ID: Hi all, Given the following code: import java.util.ArrayList; import java.util.Collection; public class Foo { static T foo(Class c, Collection baz) { return null; } static void bar(String c) { } @SuppressWarnings("unchecked") public static void main(String[] args) { // this works bar(foo(String.class, new ArrayList())); // this works with a warning String s = foo(String.class, new ArrayList()); bar(s); // this causes an error on JDK9 bar(foo(String.class, new ArrayList())); } } javac 9-ea (build 9-ea+154) fails with this interesting error (on the last line in main, as the comments there indicate): Foo.java:23: error: method bar in class Foo cannot be applied to given types; bar(foo(String.class, new ArrayList())); ^ required: String found: String reason: argument mismatch; Object cannot be converted to String 1 error Java 8 compiles fine, and the other 2 lines compile in the same java 9 build as well. Is this a javac bug or legit? It seems like a compiler error. At a minimum, the diagnostic output "required String, found String" is confusing. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Wed Feb 8 19:39:26 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 8 Feb 2017 11:39:26 -0800 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> References: <589A4ECE.80308@oracle.com> <4389C801-3848-433C-8302-2BBF82546304@oracle.com> <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> Message-ID: > On 8 Feb 2017, at 03:37, Alan Bateman wrote: > > On 08/02/2017 03:10, Paul Sandoz wrote: > >> Hi, >> >> Just minor stuff in the JDK area (i browsed quickly through the tests). > Thanks, a few comments below. > >> >> Paul. >> >> >> java.lang.module.Configuration >> ? >> >> 321 * @implNote In the implementation then observability of modules may depend >> >> s/then/the > "then" should be okay, it could also be "then the" (that might be what you mean). > Given the way i recall JavaDoc renders impl notes they tend to stand on their own rather as sections than be dependent on the flow of paragraphs previous to them. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mandy.chung at oracle.com Wed Feb 8 20:46:17 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Feb 2017 12:46:17 -0800 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: <6C61972D-F35A-4223-B1C1-2F16A1F7BEE0@oracle.com> I reviewed your updated webrev: http://cr.openjdk.java.net/~alanb/8173393/2 src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java 285 m.descriptor.packages().forEach(builder::opens); This is not needed. I took it out. We probably will do another pass on the APIs to tag with @spec JPMS. IllegalCallerException and the following in MethodHandles don?t have the tag. 667 public static final int UNCONDITIONAL = PACKAGE << 2; 841 public Lookup dropLookupMode(int modeToDrop) { IIRC no specific spec change to ResourceBundle.Control.toBundleName. So @revised and @spec can be dropped. Otherwise looks fine to me. I reviewed changes in jdk.jdeps in langtools and all other repos. Mandy From jan.lahoda at oracle.com Wed Feb 8 20:46:31 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 8 Feb 2017 21:46:31 +0100 Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module In-Reply-To: <589A0DC4.5020409@oracle.com> References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com> <206f4364-1d18-fed8-840a-f655b235b943@oracle.com> <589A0DC4.5020409@oracle.com> Message-ID: <589B83A7.9020207@oracle.com> Hi, Based on some (offline) feedback and further testing, I've updated the langtools patch. The new webrev is here: http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/ Delta webrev compared to .01: http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/delta/webrev/index.html The changes in this updated version: -the previous version didn't allow the same file to be under both --patch-module and --module-source-path. The updated version allows this, and the --patch-module will prevail. This is currently only allowed when both --patch-module and --module-source-path agree on the name of the module, but this could be trivially removed if desired. -for incremental compilation, the previous version required that the class output is also specified in --patch-module. The updated version will automatically use class output to read classfiles for patch modules (by virtue of ModuleSymbol.patchOutputLocation). -the previous version didn't (always) report an error for module-info on --patch-module in multi-module mode. This should be fixed now, and there should be an error for module-info on patch location even in multi-module mode. I was looking at explicit uses of -Xmodule: in other repositories, and there are some in the hotspot repository. All these appear to use a utility from the top-level repository: test/lib/jdk/test/lib/InMemoryJavaCompiler.java (there are other tests that use @compile/module in various repositories, including hotspot, but these need to be coordinated with jtreg). For now, I propose to tweak the utility to interpret -Xmodule: itself: http://cr.openjdk.java.net/~jlahoda/8173777/top-level.00/ Eventually, we could stop using -Xmodule: inside this utility and pass the module name explicitly, e.g. encoded in the className, but for now this seems acceptable to me. Feedback is welcome. Thanks! Jan On 7.2.2017 19:11, Jan Lahoda wrote: > Hi, > > Thanks. > > I did two small updates to the patches: > -for langtools repository, I added unwrapping to > ClientCodeWrapper.WrappedJavaFileManager.getLocationForModule - the > incoming JavaFileObject is unwrapped, so that we don't pass our wrappers > to the client's code. Direct link: > http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java.udiff.html > > > -for jdk repository, I fixed the: > test/javax/xml/jaxp/common/8035437/run.sh > to use a platform specific path separator. This is based on code from > jdk/test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh > Direct link: > http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/test/javax/xml/jaxp/common/8035437/run.sh.udiff.html > > > (Sorry that I missed this before.) > > Updated webrevs: > -langtools repository: > http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/ > -jdk repository: > http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/ > > Thanks, > Jan > > On 6.2.2017 21:42, Alan Bateman wrote: >> >> >> On 06/02/2017 18:41, Jan Lahoda wrote: >>> I've updated the jdk repository webrev to wrap long lines: >>> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/ >>> >>> Jan >> This looks okay to me. >> >> -Alan >> From karen.kinnear at oracle.com Wed Feb 8 20:58:01 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 8 Feb 2017 15:58:01 -0500 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: Hotspot changes look good. thanks, Karen > On Feb 7, 2017, at 8:23 AM, Alan Bateman wrote: > > We've been accumulating changes in the jake forest for the last few weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so this update will need to get approval via the FC-extension process. > > The changes this time are significantly smaller than previous updates. Much of this update is API and javadoc cleanup. There are a few new methods, and a few methods have been renamed/changed, but it's otherwise small potatoes. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8173393/1/ > > Note that the webrevs are against jdk-9+155 because that is what jake is currently at. I will re-generate the webrevs later in the week once jdk-9+156 is promoted before eventually merging with jdk9/dev in advance of the eventual push. > > One other thing to note is that the hotspot+jdk repos have the changes for JDK-8171855, this is only because that change was backed up in jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This means that the only non-test change in the hotspot repo is to methodHandles.cpp. > > In the langtools repo then most of the changes are mechanical, with the only real update being cleanup to jdeps and the change to javac + javap to use the right values for the requires flags (the issue that R?mi brought up on jigsaw-dev last week when sync'ing up ASM). > > In the jdk repo then ignore the DEBUG_ADD_OPENS changes in ModuleBootstrap, that is not intended for JDK 9. > > There are a few small bug fixes, and a few more startup improvements from Claes. There are a small number of tests that aren't in jake yet for this update but they should be before I refresh the webrev later in the week. > > -Alan > From robert.field at oracle.com Wed Feb 8 21:38:06 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 08 Feb 2017 13:38:06 -0800 Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module In-Reply-To: <589B83A7.9020207@oracle.com> References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com> <206f4364-1d18-fed8-840a-f655b235b943@oracle.com> <589A0DC4.5020409@oracle.com> <589B83A7.9020207@oracle.com> Message-ID: <589B8FBE.3060600@oracle.com> JShell changes to the memory file manager are unchanged in this update and so still look good. -Robert On 02/08/17 12:46, Jan Lahoda wrote: > Hi, > > Based on some (offline) feedback and further testing, I've updated the > langtools patch. The new webrev is here: > http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/ > > Delta webrev compared to .01: > http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/delta/webrev/index.html > > > The changes in this updated version: > -the previous version didn't allow the same file to be under both > --patch-module and --module-source-path. The updated version allows > this, and the --patch-module will prevail. This is currently only > allowed when both --patch-module and --module-source-path agree on the > name of the module, but this could be trivially removed if desired. > > -for incremental compilation, the previous version required that the > class output is also specified in --patch-module. The updated version > will automatically use class output to read classfiles for patch > modules (by virtue of ModuleSymbol.patchOutputLocation). > > -the previous version didn't (always) report an error for module-info > on --patch-module in multi-module mode. This should be fixed now, and > there should be an error for module-info on patch location even in > multi-module mode. > > I was looking at explicit uses of -Xmodule: in other repositories, and > there are some in the hotspot repository. All these appear to use a > utility from the top-level repository: > test/lib/jdk/test/lib/InMemoryJavaCompiler.java > (there are other tests that use @compile/module in various > repositories, including hotspot, but these need to be coordinated with > jtreg). For now, I propose to tweak the utility to interpret -Xmodule: > itself: > http://cr.openjdk.java.net/~jlahoda/8173777/top-level.00/ > > Eventually, we could stop using -Xmodule: inside this utility and pass > the module name explicitly, e.g. encoded in the className, but for now > this seems acceptable to me. > > Feedback is welcome. > > Thanks! > > Jan > > > On 7.2.2017 19:11, Jan Lahoda wrote: >> Hi, >> >> Thanks. >> >> I did two small updates to the patches: >> -for langtools repository, I added unwrapping to >> ClientCodeWrapper.WrappedJavaFileManager.getLocationForModule - the >> incoming JavaFileObject is unwrapped, so that we don't pass our wrappers >> to the client's code. Direct link: >> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java.udiff.html >> >> >> >> -for jdk repository, I fixed the: >> test/javax/xml/jaxp/common/8035437/run.sh >> to use a platform specific path separator. This is based on code from >> jdk/test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh >> Direct link: >> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/test/javax/xml/jaxp/common/8035437/run.sh.udiff.html >> >> >> >> (Sorry that I missed this before.) >> >> Updated webrevs: >> -langtools repository: >> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/ >> -jdk repository: >> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/ >> >> Thanks, >> Jan >> >> On 6.2.2017 21:42, Alan Bateman wrote: >>> >>> >>> On 06/02/2017 18:41, Jan Lahoda wrote: >>>> I've updated the jdk repository webrev to wrap long lines: >>>> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/ >>>> >>>> Jan >>> This looks okay to me. >>> >>> -Alan >>> From bsrbnd at gmail.com Wed Feb 8 22:02:39 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 8 Feb 2017 23:02:39 +0100 Subject: JDK 8148716: Variable proxy duplicate Message-ID: Hi, Javac fails to compile the following example because it creates twice the same variable proxy (jdk 8148716): class A { public static void main(String... args) { new A().a(); } void a() { String x = "abc"; class B { public int b() { return x.length(); } }; Runnable r = () -> { class C { void c() { // free var x in a() System.out.println(new B().b()); // free var x in lambda() System.out.println(x.length()); } } new C().c(); }; r.run(); } } ... once for x in a() and once for x in lambda(). The fix below prevents free variable duplicate regardless of the owner (Lower.FreeVarCollector.addFreeVar()), ensuring no proxy duplication (see proxies.getSymbolsByName() in Lower.initField()). Needs to be well tested... Any comment is welcome! Thanks, Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java @@ -289,7 +289,7 @@ */ private void addFreeVar(VarSymbol v) { for (List l = fvs; l.nonEmpty(); l = l.tail) - if (l.head == v) return; + if (l.head.name == v.name) return; fvs = fvs.prepend(v); } From maurizio.cimadamore at oracle.com Thu Feb 9 01:00:12 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 Feb 2017 01:00:12 +0000 Subject: JDK 8148716: Variable proxy duplicate In-Reply-To: References: Message-ID: <11e172f4-5b25-65bc-be20-db90eadf16f5@oracle.com> Hi, I believe that to be a duplicate of https://bugs.openjdk.java.net/browse/JDK-8169345 for which we have a fix in the works which we'll push to 10 soon. Srikanth and I decided to go for a more radical rewriting in the area, making a lot of the logic in the code (now implicit in the use of the Scope data structure) more explicit and less prone to errors of this sort. Thanks Maurizio On 08/02/17 22:02, B. Blaser wrote: > Hi, > > Javac fails to compile the following example because it creates twice > the same variable proxy (jdk 8148716): > > class A { > public static void main(String... args) { > new A().a(); > } > > void a() { > String x = "abc"; > > class B { > public int b() { return x.length(); } > }; > > Runnable r = () -> { > class C { > void c() { > // free var x in a() > System.out.println(new B().b()); > // free var x in lambda() > System.out.println(x.length()); > } > } > new C().c(); > }; > r.run(); > } > } > > ... once for x in a() and once for x in lambda(). > > The fix below prevents free variable duplicate regardless of the owner > (Lower.FreeVarCollector.addFreeVar()), ensuring no proxy duplication > (see proxies.getSymbolsByName() in Lower.initField()). > > Needs to be well tested... > > Any comment is welcome! > > Thanks, > Bernard > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > @@ -289,7 +289,7 @@ > */ > private void addFreeVar(VarSymbol v) { > for (List l = fvs; l.nonEmpty(); l = l.tail) > - if (l.head == v) return; > + if (l.head.name == v.name) return; > fvs = fvs.prepend(v); > } From maurizio.cimadamore at oracle.com Thu Feb 9 01:38:41 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 Feb 2017 01:38:41 +0000 Subject: Java 9 ea154 javac compiler error - legit or bug? In-Reply-To: References: Message-ID: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> Hi, it seems like the behavior you observed started in b83 - as a result of this: https://bugs.openjdk.java.net/browse/JDK-8078093 I believe the error is correct (although the diagnostic has always been broken since b83 in the 'verbose' mode - the non-verbose mode - w/o -Xdiags:verbose is fine). That is, the call to 'foo' is unchecked, so the return type should be erased. There seems to be an inconsistency in how javac handles this in method context compared to assignment context, and that needs to be looked at. Thanks Maurizio On 08/02/17 19:23, Vitaly Davidovich wrote: > Hi all, > > Given the following code: > > import java.util.ArrayList; > import java.util.Collection; > > public class Foo { > static T foo(Class c, Collection baz) { > return null; > } > > static void bar(String c) { > > } > > @SuppressWarnings("unchecked") > public static void main(String[] args) { > // this works > bar(foo(String.class, new ArrayList())); > > // this works with a warning > String s = foo(String.class, new ArrayList()); > bar(s); > > // this causes an error on JDK9 > bar(foo(String.class, new ArrayList())); > } > } > > javac 9-ea (build 9-ea+154) fails with this interesting error (on the > last line in main, as the comments there indicate): > > Foo.java:23: error: method bar in class Foo cannot be applied to given > types; > bar(foo(String.class, new ArrayList())); > ^ > required: String > found: String > reason: argument mismatch; Object cannot be converted to String > 1 error > > Java 8 compiles fine, and the other 2 lines compile in the same java 9 > build as well. > > Is this a javac bug or legit? It seems like a compiler error. At a > minimum, the diagnostic output "required String, found String" is > confusing. > > Thanks > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Thu Feb 9 04:09:16 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 09 Feb 2017 04:09:16 +0000 Subject: Java 9 ea154 javac compiler error - legit or bug? In-Reply-To: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> References: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> Message-ID: Hi Maurizio, Thanks for the reply. So you're saying the example using assignment context shouldn't compile either? Also, the call to 'foo' is unchecked in the wildcard argument, but it has a concrete type in the first argument. Are you saying that any unchecked param results in return type erasure? Thanks On Wed, Feb 8, 2017 at 8:38 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > it seems like the behavior you observed started in b83 - as a result of > this: > > https://bugs.openjdk.java.net/browse/JDK-8078093 > > I believe the error is correct (although the diagnostic has always been > broken since b83 in the 'verbose' mode - the non-verbose mode - w/o > -Xdiags:verbose is fine). That is, the call to 'foo' is unchecked, so the > return type should be erased. There seems to be an inconsistency in how > javac handles this in method context compared to assignment context, and > that needs to be looked at. > > Thanks > > > Maurizio > > > > On 08/02/17 19:23, Vitaly Davidovich wrote: > > Hi all, > > Given the following code: > > import java.util.ArrayList; > import java.util.Collection; > > public class Foo { > static T foo(Class c, Collection baz) { > return null; > } > > static void bar(String c) { > > } > > @SuppressWarnings("unchecked") > public static void main(String[] args) { > // this works > bar(foo(String.class, new ArrayList())); > > // this works with a warning > String s = foo(String.class, new ArrayList()); > bar(s); > > // this causes an error on JDK9 > bar(foo(String.class, new ArrayList())); > } > } > > javac 9-ea (build 9-ea+154) fails with this interesting error (on the last > line in main, as the comments there indicate): > > Foo.java:23: error: method bar in class Foo cannot be applied to given > types; > bar(foo(String.class, new ArrayList())); > ^ > required: String > found: String > reason: argument mismatch; Object cannot be converted to String > 1 error > > Java 8 compiles fine, and the other 2 lines compile in the same java 9 > build as well. > > Is this a javac bug or legit? It seems like a compiler error. At a > minimum, the diagnostic output "required String, found String" is confusing. > > Thanks > > > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Feb 9 13:02:54 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 9 Feb 2017 14:02:54 +0100 Subject: JDK 8148716: Variable proxy duplicate In-Reply-To: <11e172f4-5b25-65bc-be20-db90eadf16f5@oracle.com> References: <11e172f4-5b25-65bc-be20-db90eadf16f5@oracle.com> Message-ID: Hi, 2017-02-09 2:00 GMT+01:00 Maurizio Cimadamore : > Hi, > I believe that to be a duplicate of > > https://bugs.openjdk.java.net/browse/JDK-8169345 > > for which we have a fix in the works which we'll push to 10 soon. > > Srikanth and I decided to go for a more radical rewriting in the area, > making a lot of the logic in the code (now implicit in the use of the Scope > data structure) more explicit and less prone to errors of this sort. > > Thanks > Maurizio As this problem seems to be present since jdk6 (issue 8169345 you pointed me to), it would perhaps be interesting to have a temporary fix which could be eventually backported, or at least corrected in jdk9. To make things more explicit and to have a quite safer patch, I can suggest to incorporate the name of the variable's owner to the proxy name, as below. The rewriting you are working on is probably better, but the following fix could perhaps make things work until jdk10...? What's your opinion on that? Thanks, Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java @@ -308,7 +308,7 @@ Symbol sym = _sym; if (sym.kind == VAR || sym.kind == MTH) { while (sym != null && sym.owner != owner) - sym = proxies.findFirst(proxyName(sym.name)); + sym = proxies.findFirst(proxyName(sym)); if (sym != null && sym.owner == owner) { VarSymbol v = (VarSymbol)sym; if (v.getConstValue() == null) { @@ -1095,7 +1095,7 @@ return makeLit(sym.type, cv); } // Otherwise replace the variable by its proxy. - sym = proxies.findFirst(proxyName(sym.name)); + sym = proxies.findFirst(proxyName(sym)); Assert.check(sym != null && (sym.flags_field & FINAL) != 0); tree = make.at(tree.pos).Ident(sym); } @@ -1394,8 +1394,12 @@ /** The name of a free variable proxy. */ - Name proxyName(Name name) { - return names.fromString("val" + target.syntheticNameChar() + name); + Name proxyName(Symbol s) { + String sep = target.syntheticNameChar() + ""; + if (s.owner != null && s.owner.name != null) + sep = sep + s.owner.name + sep; + + return names.fromString("val" + sep + s.name); } /** Proxy definitions for all free variables in given list, in reverse order. @@ -1414,7 +1418,7 @@ for (List l = freevars; l.nonEmpty(); l = l.tail) { VarSymbol v = l.head; VarSymbol proxy = new VarSymbol( - flags, proxyName(v.name), v.erasure(types), owner); + flags, proxyName(v), v.erasure(types), owner); proxies.enter(proxy); JCVariableDecl vd = make.at(pos).VarDef(proxy, null); vd.vartype = access(vd.vartype); @@ -2717,7 +2721,7 @@ if (fvs.nonEmpty()) { List addedargtypes = List.nil(); for (List l = fvs; l.nonEmpty(); l = l.tail) { - final Name pName = proxyName(l.head.name); + final Name pName = proxyName(l.head); m.capturedLocals = m.capturedLocals.prepend((VarSymbol) (proxies.findFirst(pName))); From maurizio.cimadamore at oracle.com Thu Feb 9 13:28:55 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 Feb 2017 13:28:55 +0000 Subject: JDK 8148716: Variable proxy duplicate In-Reply-To: References: <11e172f4-5b25-65bc-be20-db90eadf16f5@oracle.com> Message-ID: <814d6eca-90fc-6dc1-bdfd-d1d1912347c2@oracle.com> On 09/02/17 13:02, B. Blaser wrote: > Hi, > > 2017-02-09 2:00 GMT+01:00 Maurizio Cimadamore : >> Hi, >> I believe that to be a duplicate of >> >> https://bugs.openjdk.java.net/browse/JDK-8169345 >> >> for which we have a fix in the works which we'll push to 10 soon. >> >> Srikanth and I decided to go for a more radical rewriting in the area, >> making a lot of the logic in the code (now implicit in the use of the Scope >> data structure) more explicit and less prone to errors of this sort. >> >> Thanks >> Maurizio > As this problem seems to be present since jdk6 (issue 8169345 you > pointed me to), it would perhaps be interesting to have a temporary > fix which could be eventually backported, or at least corrected in > jdk9. > > To make things more explicit and to have a quite safer patch, I can > suggest to incorporate the name of the variable's owner to the proxy > name, as below. The rewriting you are working on is probably better, > but the following fix could perhaps make things work until jdk10...? > > What's your opinion on that? Hi right now it's late to be making risky changes - which is why the fix was targeted for 10. Once the fix will have been in 10 for some time, we will consider backporting what we have to 9. Thanks Maurizio > > Thanks, > Bernard > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > @@ -308,7 +308,7 @@ > Symbol sym = _sym; > if (sym.kind == VAR || sym.kind == MTH) { > while (sym != null && sym.owner != owner) > - sym = proxies.findFirst(proxyName(sym.name)); > + sym = proxies.findFirst(proxyName(sym)); > if (sym != null && sym.owner == owner) { > VarSymbol v = (VarSymbol)sym; > if (v.getConstValue() == null) { > @@ -1095,7 +1095,7 @@ > return makeLit(sym.type, cv); > } > // Otherwise replace the variable by its proxy. > - sym = proxies.findFirst(proxyName(sym.name)); > + sym = proxies.findFirst(proxyName(sym)); > Assert.check(sym != null && (sym.flags_field & FINAL) != 0); > tree = make.at(tree.pos).Ident(sym); > } > @@ -1394,8 +1394,12 @@ > > /** The name of a free variable proxy. > */ > - Name proxyName(Name name) { > - return names.fromString("val" + target.syntheticNameChar() + name); > + Name proxyName(Symbol s) { > + String sep = target.syntheticNameChar() + ""; > + if (s.owner != null && s.owner.name != null) > + sep = sep + s.owner.name + sep; > + > + return names.fromString("val" + sep + s.name); > } > > /** Proxy definitions for all free variables in given list, in > reverse order. > @@ -1414,7 +1418,7 @@ > for (List l = freevars; l.nonEmpty(); l = l.tail) { > VarSymbol v = l.head; > VarSymbol proxy = new VarSymbol( > - flags, proxyName(v.name), v.erasure(types), owner); > + flags, proxyName(v), v.erasure(types), owner); > proxies.enter(proxy); > JCVariableDecl vd = make.at(pos).VarDef(proxy, null); > vd.vartype = access(vd.vartype); > @@ -2717,7 +2721,7 @@ > if (fvs.nonEmpty()) { > List addedargtypes = List.nil(); > for (List l = fvs; l.nonEmpty(); l = l.tail) { > - final Name pName = proxyName(l.head.name); > + final Name pName = proxyName(l.head); > m.capturedLocals = > m.capturedLocals.prepend((VarSymbol) > (proxies.findFirst(pName))); From maurizio.cimadamore at oracle.com Thu Feb 9 13:31:04 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 Feb 2017 13:31:04 +0000 Subject: Java 9 ea154 javac compiler error - legit or bug? In-Reply-To: References: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> Message-ID: <648523fd-ff25-9488-b182-7463e0bbee6b@oracle.com> Hi Vitaly, the situation is a tad convoluted; basically there's a long-standing javac discrepancy which allowed javac to erase the return type of an unchecked call *after* some type inference has been performed. This behavior is well described here: https://bugs.openjdk.java.net/browse/JDK-8135087 In your example, that means that, since the first actual argument to 'foo' has type Class and the first formal is Class, javac is able to infer that T = String - which gives you a fully instantiated 'foo' with signature: String foo(Class c, Collection baz) Then, as an unchecked conversion has been required for this method call (for the second argument), javac proceeds to erase the signature - but there's nothing to do! That is, erasure(String) = String, so the invocation type of the inner most call has a return type 'String'. That's different from what the spec says - as the spec wants to erase the *declared signature* of the method if an unchecked conversion occurs - in which case the invocation return type would be just Object (and a compiler error would be issued). This discrepancy will be addressed as part of JDK 10. That said, JDK-8078093 accidentally introduced a change in this area - in method context the current javac implementation would erase the declared signature; while this behavior is compatible with what the spec say, as you observed, it's completely inconsistent with what javac does in assignment context, and it's also inconsistent with almost everything else javac does (hence the weird error you get 'expected: String - found: String'). This is just a plain bug - the fix for 8078093 was never meant to alter behavior of type-checking with unchecked calls and generic methods. In the short term we plan to restore the original behavior (as with JDK 8). In the medium term we plan to get rid of this discrepancy for good. So, should the program compile? If you follow the spec literally, no, it shouldn't. But the aim is to keep stuff like this working, until we come up with a more general cleanup in this area. I hope this clarifies the issue. Meanwhile, I filed this bug: https://bugs.openjdk.java.net/browse/JDK-8174249 to keep track of this issue. Maurizio On 09/02/17 04:09, Vitaly Davidovich wrote: > Hi Maurizio, > > Thanks for the reply. So you're saying the example using assignment > context shouldn't compile either? Also, the call to 'foo' is unchecked > in the wildcard argument, but it has a concrete type in the first > argument. Are you saying that any unchecked param results in return > type erasure? > > Thanks > > On Wed, Feb 8, 2017 at 8:38 PM Maurizio Cimadamore > > wrote: > > Hi, > it seems like the behavior you observed started in b83 - as a > result of this: > > https://bugs.openjdk.java.net/browse/JDK-8078093 > > I believe the error is correct (although the diagnostic has always > been broken since b83 in the 'verbose' mode - the non-verbose mode > - w/o -Xdiags:verbose is fine). That is, the call to 'foo' is > unchecked, so the return type should be erased. There seems to be > an inconsistency in how javac handles this in method context > compared to assignment context, and that needs to be looked at. > > Thanks > > > Maurizio > > > > On 08/02/17 19:23, Vitaly Davidovich wrote: >> Hi all, >> >> Given the following code: >> >> import java.util.ArrayList; >> import java.util.Collection; >> >> public class Foo { >> static T foo(Class c, Collection baz) { >> return null; >> } >> >> static void bar(String c) { >> >> } >> >> @SuppressWarnings("unchecked") >> public static void main(String[] args) { >> // this works >> bar(foo(String.class, new ArrayList())); >> >> // this works with a warning >> String s = foo(String.class, new ArrayList()); >> bar(s); >> >> // this causes an error on JDK9 >> bar(foo(String.class, new ArrayList())); >> } >> } >> >> javac 9-ea (build 9-ea+154) fails with this interesting error (on >> the last line in main, as the comments there indicate): >> >> Foo.java:23: error: method bar in class Foo cannot be applied to >> given types; >> bar(foo(String.class, new ArrayList())); >> ^ >> required: String >> found: String >> reason: argument mismatch; Object cannot be converted to String >> 1 error >> >> Java 8 compiles fine, and the other 2 lines compile in the same >> java 9 build as well. >> >> Is this a javac bug or legit? It seems like a compiler error. At >> a minimum, the diagnostic output "required String, found String" >> is confusing. >> >> Thanks >> >> > > -- > Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Thu Feb 9 16:39:12 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 09 Feb 2017 16:39:12 +0000 Subject: Java 9 ea154 javac compiler error - legit or bug? In-Reply-To: <648523fd-ff25-9488-b182-7463e0bbee6b@oracle.com> References: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> <648523fd-ff25-9488-b182-7463e0bbee6b@oracle.com> Message-ID: Hi Maurizio, Thanks for the elaboration - much appreciated. Which EA build do you think will have a fix for this issue? On Thu, Feb 9, 2017 at 8:31 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi Vitaly, > the situation is a tad convoluted; basically there's a long-standing javac > discrepancy which allowed javac to erase the return type of an unchecked > call *after* some type inference has been performed. This behavior is well > described here: > > https://bugs.openjdk.java.net/browse/JDK-8135087 > > In your example, that means that, since the first actual argument to 'foo' > has type Class and the first formal is Class, javac is able to > infer that T = String - which gives you a fully instantiated 'foo' with > signature: > > String foo(Class c, Collection baz) > > Then, as an unchecked conversion has been required for this method call > (for the second argument), javac proceeds to erase the signature - but > there's nothing to do! That is, erasure(String) = String, so the invocation > type of the inner most call has a return type 'String'. That's different > from what the spec says - as the spec wants to erase the *declared > signature* of the method if an unchecked conversion occurs - in which case > the invocation return type would be just Object (and a compiler error would > be issued). This discrepancy will be addressed as part of JDK 10. > > That said, JDK-8078093 accidentally introduced a change in this area - in > method context the current javac implementation would erase the declared > signature; while this behavior is compatible with what the spec say, as you > observed, it's completely inconsistent with what javac does in assignment > context, and it's also inconsistent with almost everything else javac does > (hence the weird error you get 'expected: String - found: String'). This is > just a plain bug - the fix for 8078093 was never meant to alter behavior of > type-checking with unchecked calls and generic methods. > > In the short term we plan to restore the original behavior (as with JDK > 8). In the medium term we plan to get rid of this discrepancy for good. > > So, should the program compile? If you follow the spec literally, no, it > shouldn't. But the aim is to keep stuff like this working, until we come up > with a more general cleanup in this area. > > I hope this clarifies the issue. > > Meanwhile, I filed this bug: > https://bugs.openjdk.java.net/browse/JDK-8174249 > > to keep track of this issue. > > Maurizio > > > > On 09/02/17 04:09, Vitaly Davidovich wrote: > > Hi Maurizio, > > Thanks for the reply. So you're saying the example using assignment > context shouldn't compile either? Also, the call to 'foo' is unchecked in > the wildcard argument, but it has a concrete type in the first argument. > Are you saying that any unchecked param results in return type erasure? > > Thanks > > On Wed, Feb 8, 2017 at 8:38 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > > Hi, > it seems like the behavior you observed started in b83 - as a result of > this: > > https://bugs.openjdk.java.net/browse/JDK-8078093 > > I believe the error is correct (although the diagnostic has always been > broken since b83 in the 'verbose' mode - the non-verbose mode - w/o > -Xdiags:verbose is fine). That is, the call to 'foo' is unchecked, so the > return type should be erased. There seems to be an inconsistency in how > javac handles this in method context compared to assignment context, and > that needs to be looked at. > > Thanks > > > Maurizio > > > > On 08/02/17 19:23, Vitaly Davidovich wrote: > > Hi all, > > Given the following code: > > import java.util.ArrayList; > import java.util.Collection; > > public class Foo { > static T foo(Class c, Collection baz) { > return null; > } > > static void bar(String c) { > > } > > @SuppressWarnings("unchecked") > public static void main(String[] args) { > // this works > bar(foo(String.class, new ArrayList())); > > // this works with a warning > String s = foo(String.class, new ArrayList()); > bar(s); > > // this causes an error on JDK9 > bar(foo(String.class, new ArrayList())); > } > } > > javac 9-ea (build 9-ea+154) fails with this interesting error (on the last > line in main, as the comments there indicate): > > Foo.java:23: error: method bar in class Foo cannot be applied to given > types; > bar(foo(String.class, new ArrayList())); > ^ > required: String > found: String > reason: argument mismatch; Object cannot be converted to String > 1 error > > Java 8 compiles fine, and the other 2 lines compile in the same java 9 > build as well. > > Is this a javac bug or legit? It seems like a compiler error. At a > minimum, the diagnostic output "required String, found String" is confusing. > > Thanks > > > > -- > Sent from my phone > > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 9 21:28:35 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Feb 2017 21:28:35 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> On 07/02/2017 13:23, Alan Bateman wrote: > I will re-generate the webrevs later in the week once jdk-9+156 is > promoted before eventually merging with jdk9/dev in advance of the > eventual push. I've sync'ed up jake to jdk-9+156 and re-generated the webrevs: http://cr.openjdk.java.net/~alanb/8173393/3/ Assuming that nothing significant comes up then these are the changes that I'd like to push to jdk9/dev for jdk-9+157. -Alan From maurizio.cimadamore at oracle.com Thu Feb 9 22:03:13 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 Feb 2017 22:03:13 +0000 Subject: Java 9 ea154 javac compiler error - legit or bug? In-Reply-To: References: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> <648523fd-ff25-9488-b182-7463e0bbee6b@oracle.com> Message-ID: On 09/02/17 16:39, Vitaly Davidovich wrote: > Hi Maurizio, > > Thanks for the elaboration - much appreciated. > > Which EA build do you think will have a fix for this issue? I've just pushed this today, so - finger crossed - it should make the next one (157) Maurizio > > On Thu, Feb 9, 2017 at 8:31 AM Maurizio Cimadamore > > wrote: > > Hi Vitaly, > the situation is a tad convoluted; basically there's a > long-standing javac discrepancy which allowed javac to erase the > return type of an unchecked call *after* some type inference has > been performed. This behavior is well described here: > > https://bugs.openjdk.java.net/browse/JDK-8135087 > > In your example, that means that, since the first actual argument > to 'foo' has type Class and the first formal is Class, > javac is able to infer that T = String - which gives you a fully > instantiated 'foo' with signature: > > String foo(Class c, Collection baz) > > Then, as an unchecked conversion has been required for this method > call (for the second argument), javac proceeds to erase the > signature - but there's nothing to do! That is, erasure(String) = > String, so the invocation type of the inner most call has a return > type 'String'. That's different from what the spec says - as the > spec wants to erase the *declared signature* of the method if an > unchecked conversion occurs - in which case the invocation return > type would be just Object (and a compiler error would be issued). > This discrepancy will be addressed as part of JDK 10. > > That said, JDK-8078093 accidentally introduced a change in this > area - in method context the current javac implementation would > erase the declared signature; while this behavior is compatible > with what the spec say, as you observed, it's completely > inconsistent with what javac does in assignment context, and it's > also inconsistent with almost everything else javac does (hence > the weird error you get 'expected: String - found: String'). This > is just a plain bug - the fix for 8078093 was never meant to alter > behavior of type-checking with unchecked calls and generic methods. > > In the short term we plan to restore the original behavior (as > with JDK 8). In the medium term we plan to get rid of this > discrepancy for good. > > So, should the program compile? If you follow the spec literally, > no, it shouldn't. But the aim is to keep stuff like this working, > until we come up with a more general cleanup in this area. > > I hope this clarifies the issue. > > Meanwhile, I filed this bug: > > https://bugs.openjdk.java.net/browse/JDK-8174249 > > to keep track of this issue. > > Maurizio > > > > On 09/02/17 04:09, Vitaly Davidovich wrote: >> Hi Maurizio, >> >> Thanks for the reply. So you're saying the example using >> assignment context shouldn't compile either? Also, the call to >> 'foo' is unchecked in the wildcard argument, but it has a >> concrete type in the first argument. Are you saying that any >> unchecked param results in return type erasure? >> >> Thanks >> >> On Wed, Feb 8, 2017 at 8:38 PM Maurizio Cimadamore >> > > wrote: >> >> Hi, >> it seems like the behavior you observed started in b83 - as a >> result of this: >> >> https://bugs.openjdk.java.net/browse/JDK-8078093 >> >> I believe the error is correct (although the diagnostic has >> always been broken since b83 in the 'verbose' mode - the >> non-verbose mode - w/o -Xdiags:verbose is fine). That is, the >> call to 'foo' is unchecked, so the return type should be >> erased. There seems to be an inconsistency in how javac >> handles this in method context compared to assignment >> context, and that needs to be looked at. >> >> Thanks >> >> >> Maurizio >> >> >> >> On 08/02/17 19:23, Vitaly Davidovich wrote: >>> Hi all, >>> >>> Given the following code: >>> >>> import java.util.ArrayList; >>> import java.util.Collection; >>> >>> public class Foo { >>> static T foo(Class c, Collection baz) { >>> return null; >>> } >>> >>> static void bar(String c) { >>> >>> } >>> >>> @SuppressWarnings("unchecked") >>> public static void main(String[] args) { >>> // this works >>> bar(foo(String.class, new ArrayList())); >>> >>> // this works with a warning >>> String s = foo(String.class, new ArrayList()); >>> bar(s); >>> >>> // this causes an error on JDK9 >>> bar(foo(String.class, new ArrayList())); >>> } >>> } >>> >>> javac 9-ea (build 9-ea+154) fails with this interesting >>> error (on the last line in main, as the comments there >>> indicate): >>> >>> Foo.java:23: error: method bar in class Foo cannot be >>> applied to given types; >>> bar(foo(String.class, new ArrayList())); >>> ^ >>> required: String >>> found: String >>> reason: argument mismatch; Object cannot be converted to >>> String >>> 1 error >>> >>> Java 8 compiles fine, and the other 2 lines compile in the >>> same java 9 build as well. >>> >>> Is this a javac bug or legit? It seems like a compiler >>> error. At a minimum, the diagnostic output "required String, >>> found String" is confusing. >>> >>> Thanks >>> >>> >> >> -- >> Sent from my phone > > -- > Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Thu Feb 9 22:04:47 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 09 Feb 2017 22:04:47 +0000 Subject: Java 9 ea154 javac compiler error - legit or bug? In-Reply-To: References: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> <648523fd-ff25-9488-b182-7463e0bbee6b@oracle.com> Message-ID: Awesome - thanks! On Thu, Feb 9, 2017 at 5:03 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 09/02/17 16:39, Vitaly Davidovich wrote: > > Hi Maurizio, > > Thanks for the elaboration - much appreciated. > > Which EA build do you think will have a fix for this issue? > > I've just pushed this today, so - finger crossed - it should make the next > one (157) > > > Maurizio > > > On Thu, Feb 9, 2017 at 8:31 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > > Hi Vitaly, > the situation is a tad convoluted; basically there's a long-standing javac > discrepancy which allowed javac to erase the return type of an unchecked > call *after* some type inference has been performed. This behavior is well > described here: > > https://bugs.openjdk.java.net/browse/JDK-8135087 > > In your example, that means that, since the first actual argument to 'foo' > has type Class and the first formal is Class, javac is able to > infer that T = String - which gives you a fully instantiated 'foo' with > signature: > > String foo(Class c, Collection baz) > > Then, as an unchecked conversion has been required for this method call > (for the second argument), javac proceeds to erase the signature - but > there's nothing to do! That is, erasure(String) = String, so the invocation > type of the inner most call has a return type 'String'. That's different > from what the spec says - as the spec wants to erase the *declared > signature* of the method if an unchecked conversion occurs - in which case > the invocation return type would be just Object (and a compiler error would > be issued). This discrepancy will be addressed as part of JDK 10. > > That said, JDK-8078093 accidentally introduced a change in this area - in > method context the current javac implementation would erase the declared > signature; while this behavior is compatible with what the spec say, as you > observed, it's completely inconsistent with what javac does in assignment > context, and it's also inconsistent with almost everything else javac does > (hence the weird error you get 'expected: String - found: String'). This is > just a plain bug - the fix for 8078093 was never meant to alter behavior of > type-checking with unchecked calls and generic methods. > > In the short term we plan to restore the original behavior (as with JDK > 8). In the medium term we plan to get rid of this discrepancy for good. > > So, should the program compile? If you follow the spec literally, no, it > shouldn't. But the aim is to keep stuff like this working, until we come up > with a more general cleanup in this area. > > I hope this clarifies the issue. > > Meanwhile, I filed this bug: > https://bugs.openjdk.java.net/browse/JDK-8174249 > > to keep track of this issue. > > Maurizio > > > > On 09/02/17 04:09, Vitaly Davidovich wrote: > > Hi Maurizio, > > Thanks for the reply. So you're saying the example using assignment > context shouldn't compile either? Also, the call to 'foo' is unchecked in > the wildcard argument, but it has a concrete type in the first argument. > Are you saying that any unchecked param results in return type erasure? > > Thanks > > On Wed, Feb 8, 2017 at 8:38 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > > Hi, > it seems like the behavior you observed started in b83 - as a result of > this: > > https://bugs.openjdk.java.net/browse/JDK-8078093 > > I believe the error is correct (although the diagnostic has always been > broken since b83 in the 'verbose' mode - the non-verbose mode - w/o > -Xdiags:verbose is fine). That is, the call to 'foo' is unchecked, so the > return type should be erased. There seems to be an inconsistency in how > javac handles this in method context compared to assignment context, and > that needs to be looked at. > > Thanks > > > Maurizio > > > > On 08/02/17 19:23, Vitaly Davidovich wrote: > > Hi all, > > Given the following code: > > import java.util.ArrayList; > import java.util.Collection; > > public class Foo { > static T foo(Class c, Collection baz) { > return null; > } > > static void bar(String c) { > > } > > @SuppressWarnings("unchecked") > public static void main(String[] args) { > // this works > bar(foo(String.class, new ArrayList())); > > // this works with a warning > String s = foo(String.class, new ArrayList()); > bar(s); > > // this causes an error on JDK9 > bar(foo(String.class, new ArrayList())); > } > } > > javac 9-ea (build 9-ea+154) fails with this interesting error (on the last > line in main, as the comments there indicate): > > Foo.java:23: error: method bar in class Foo cannot be applied to given > types; > bar(foo(String.class, new ArrayList())); > ^ > required: String > found: String > reason: argument mismatch; Object cannot be converted to String > 1 error > > Java 8 compiles fine, and the other 2 lines compile in the same java 9 > build as well. > > Is this a javac bug or legit? It seems like a compiler error. At a > minimum, the diagnostic output "required String, found String" is confusing. > > Thanks > > > > -- > Sent from my phone > > > -- > Sent from my phone > > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Fri Feb 10 02:55:03 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 10 Feb 2017 10:55:03 +0800 Subject: RFR of JDK-8174695: Fix @since in module-info.java in dev/langtools repo Message-ID: <6dfaf6c3-27f8-93b6-ce0e-b0a8d4b87f00@oracle.com> Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8174695 webrev: http://cr.openjdk.java.net/~mli/8174695/webrev.00/ Thank you -Hamlin From peter.levart at gmail.com Fri Feb 10 10:00:00 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 Feb 2017 11:00:00 +0100 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> References: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> Message-ID: <88645880-d2fb-9c46-dfae-637047f370a3@gmail.com> Hi Alan, On 02/09/2017 10:28 PM, Alan Bateman wrote: > On 07/02/2017 13:23, Alan Bateman wrote: > >> I will re-generate the webrevs later in the week once jdk-9+156 is >> promoted before eventually merging with jdk9/dev in advance of the >> eventual push. > I've sync'ed up jake to jdk-9+156 and re-generated the webrevs: > http://cr.openjdk.java.net/~alanb/8173393/3/ > > Assuming that nothing significant comes up then these are the changes > that I'd like to push to jdk9/dev for jdk-9+157. > > -Alan First, just a nit... java.lang.module.Resolver: 320 private void addFoundModule(ModuleReference mref) { 321 ModuleDescriptor descriptor = mref.descriptor(); 322 nameToReference.put(descriptor.name(), mref); 323 324 if (descriptor.osName().isPresent() 325 || descriptor.osArch().isPresent() 326 || descriptor.osVersion().isPresent()) 327 checkTargetConstraints(descriptor); 328 } ...perhaps more correct would be to reverse the order: 1st check target constraints and then add descriptor to map. Otherwise in case of check failure, you end up with a Resolver instance that is poisoned with incompatible module descriptor. Maybe you always throw away such Resolver if this method fails, but maybe someone will sometime try to recover and continue to use the Resolver for rest of modules? ...then something more involving... java.lang.reflect.AccessibleObject::canAccess could share access cache with internal method checkAccess. In particular since one might use this new method in scenarios like: Method method = ...; if (method.canAccess(target)) { method.invoke(target, ...); } else { ... Here's what you could do: http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.01/ Regards, Peter From Alan.Bateman at oracle.com Fri Feb 10 13:49:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 13:49:53 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <88645880-d2fb-9c46-dfae-637047f370a3@gmail.com> References: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> <88645880-d2fb-9c46-dfae-637047f370a3@gmail.com> Message-ID: On 10/02/2017 10:00, Peter Levart wrote: > > First, just a nit... > > java.lang.module.Resolver: > > 320 private void addFoundModule(ModuleReference mref) { > 321 ModuleDescriptor descriptor = mref.descriptor(); > 322 nameToReference.put(descriptor.name(), mref); > 323 > 324 if (descriptor.osName().isPresent() > 325 || descriptor.osArch().isPresent() > 326 || descriptor.osVersion().isPresent()) > 327 checkTargetConstraints(descriptor); > 328 } > > ...perhaps more correct would be to reverse the order: 1st check > target constraints and then add descriptor to map. Otherwise in case > of check failure, you end up with a Resolver instance that is poisoned > with incompatible module descriptor. Maybe you always throw away such > Resolver if this method fails, but maybe someone will sometime try to > recover and continue to use the Resolver for rest of modules? Yes, fair point, it would be better to do this check first. I don't think we have any issue now because this is an internal class and the resolver is always thrown away after an exception. The ModuleTarget attribute isn't completely firmed up yet so I expect we will be back to this code soon. > > > ...then something more involving... > > java.lang.reflect.AccessibleObject::canAccess could share access cache > with internal method checkAccess. In particular since one might use > this new method in scenarios like: > > Method method = ...; > > if (method.canAccess(target)) { > method.invoke(target, ...); > } else { or the other usage I would expect to see is: if (method.canAccess(target) || method.tryAccessible()) { .. } > ... > > Here's what you could do: > > http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.01/ > Good idea. Do you want to create an issue for this and follow-up on core-libs-dev? The changes are in jdk9/dev now so it can follow. A minor nit is that the InternalError was useful to catch bad changes, a NPE could work too but it should never happen. -Alan From peter.levart at gmail.com Fri Feb 10 16:38:59 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 Feb 2017 17:38:59 +0100 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> <88645880-d2fb-9c46-dfae-637047f370a3@gmail.com> Message-ID: <79a3a721-64e1-e526-1e51-9dc4b897c0a9@gmail.com> On 02/10/2017 02:49 PM, Alan Bateman wrote: >> Here's what you could do: >> >> http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.01/ >> > Good idea. Do you want to create an issue for this and follow-up on > core-libs-dev? The changes are in jdk9/dev now so it can follow. A > minor nit is that the InternalError was useful to catch bad changes, a > NPE could work too but it should never happen. > > -Alan Ok, will create an issue and a follow-up change. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Mon Feb 13 09:46:36 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 13 Feb 2017 17:46:36 +0800 Subject: RFR of JDK-8174695: Fix @since in module-info.java in dev/langtools repo In-Reply-To: <6dfaf6c3-27f8-93b6-ce0e-b0a8d4b87f00@oracle.com> References: <6dfaf6c3-27f8-93b6-ce0e-b0a8d4b87f00@oracle.com> Message-ID: Is some one available to review the below change? Thank you -Hamlin On 2017/2/10 10:55, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8174695 > > webrev: http://cr.openjdk.java.net/~mli/8174695/webrev.00/ > > > Thank you > > -Hamlin > From maurizio.cimadamore at oracle.com Mon Feb 13 11:19:54 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 Feb 2017 11:19:54 +0000 Subject: RFR of JDK-8174695: Fix @since in module-info.java in dev/langtools repo In-Reply-To: References: <6dfaf6c3-27f8-93b6-ce0e-b0a8d4b87f00@oracle.com> Message-ID: <44c96d88-92f3-f149-0346-46ab72f04433@oracle.com> Looks good Maurizio On 13/02/17 09:46, Hamlin Li wrote: > Is some one available to review the below change? > > Thank you > > -Hamlin > > > On 2017/2/10 10:55, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8174695 >> >> webrev: http://cr.openjdk.java.net/~mli/8174695/webrev.00/ >> >> >> Thank you >> >> -Hamlin >> > From forax at univ-mlv.fr Mon Feb 13 15:12:42 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 13 Feb 2017 16:12:42 +0100 (CET) Subject: Fwd: Package resolution when compiling jdk.aot against jdk.vm.ci In-Reply-To: <37f4d965-ed2f-5511-f75b-d2a6a1a9334d@redhat.com> References: <1b04b4f9-043b-7da1-3c10-1910f3fb5945@redhat.com> <37f4d965-ed2f-5511-f75b-d2a6a1a9334d@redhat.com> Message-ID: <1530361676.383249.1486998762831.JavaMail.zimbra@u-pem.fr> Hi Jon, this is from the graal-dev mailing list, is there a way to improve the error message of javac when a class is not visible because the package is not exported ? R?mi ----- Mail transf?r? ----- De: "Andrew Haley" ?: graal-dev at openjdk.java.net Envoy?: Lundi 13 F?vrier 2017 15:44:23 Objet: Re: Package resolution when compiling jdk.aot against jdk.vm.ci Sorry, found it: diff --git a/src/jdk.vm.ci/share/classes/module-info.java b/src/jdk.vm.ci/share/classes/module-info.java --- a/src/jdk.vm.ci/share/classes/module-info.java +++ b/src/jdk.vm.ci/share/classes/module-info.java @@ -35,6 +35,7 @@ jdk.vm.ci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory; exports jdk.vm.ci.aarch64 to + jdk.aot, jdk.vm.compiler; exports jdk.vm.ci.amd64 to jdk.aot, One thought: it would be nice if javac were a bit more helpful: simply saying "not found" is rather baffling. "Not exported" would be super. Andrew. From joe.darcy at oracle.com Mon Feb 13 18:48:26 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 13 Feb 2017 10:48:26 -0800 Subject: JDK 9 RFR to Fix javax.lang.model javadoc link issues Message-ID: Hello, Please review the patch below to fix two bad links in the javax.lang.model javadoc. Thanks, -Joe diff -r c73b98b79148 src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java --- a/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java Mon Feb 13 10:29:04 2017 -0800 +++ b/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java Mon Feb 13 10:45:40 2017 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -92,7 +92,7 @@ * same set of strings as the annotation. If the class is not so * annotated, an empty set is returned. * - * If the {@link ProcessingEvironment#getSourceVersion source + * If the {@link ProcessingEnvironment#getSourceVersion source * version} does not support modules, in other words if it is less * than or equal to {@link SourceVersion#RELEASE_8 RELEASE_8}, * then any leading {@link Processor#getSupportedAnnotationTypes diff -r c73b98b79148 src/java.compiler/share/classes/javax/annotation/processing/Processor.java --- a/src/java.compiler/share/classes/javax/annotation/processing/Processor.java Mon Feb 13 10:29:04 2017 -0800 +++ b/src/java.compiler/share/classes/javax/annotation/processing/Processor.java Mon Feb 13 10:45:40 2017 -0800 @@ -291,7 +291,7 @@ * @apiNote When running in an environment which supports modules, * processors are encouraged to include the module prefix when * describing their supported annotation types. The method {@link - * AbstractProcessor.getSupportedAnnotationTypes + * AbstractProcessor#getSupportedAnnotationTypes * AbstractProcessor.getSupportedAnnotationTypes} provides support * for stripping off the module prefix when running in an * environment without modules. From mandy.chung at oracle.com Mon Feb 13 18:52:53 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 13 Feb 2017 10:52:53 -0800 Subject: JDK 9 RFR to Fix javax.lang.model javadoc link issues In-Reply-To: References: Message-ID: <65948EFA-AA3F-45A2-82CF-BF677321F2DA@oracle.com> +1 Mandy > On Feb 13, 2017, at 10:48 AM, joe darcy wrote: > > Hello, > > Please review the patch below to fix two bad links in the javax.lang.model javadoc. > > Thanks, > > -Joe > > > diff -r c73b98b79148 src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java > --- a/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java Mon Feb 13 10:29:04 2017 -0800 > +++ b/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java Mon Feb 13 10:45:40 2017 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -92,7 +92,7 @@ > * same set of strings as the annotation. If the class is not so > * annotated, an empty set is returned. > * > - * If the {@link ProcessingEvironment#getSourceVersion source > + * If the {@link ProcessingEnvironment#getSourceVersion source > * version} does not support modules, in other words if it is less > * than or equal to {@link SourceVersion#RELEASE_8 RELEASE_8}, > * then any leading {@link Processor#getSupportedAnnotationTypes > diff -r c73b98b79148 src/java.compiler/share/classes/javax/annotation/processing/Processor.java > --- a/src/java.compiler/share/classes/javax/annotation/processing/Processor.java Mon Feb 13 10:29:04 2017 -0800 > +++ b/src/java.compiler/share/classes/javax/annotation/processing/Processor.java Mon Feb 13 10:45:40 2017 -0800 > @@ -291,7 +291,7 @@ > * @apiNote When running in an environment which supports modules, > * processors are encouraged to include the module prefix when > * describing their supported annotation types. The method {@link > - * AbstractProcessor.getSupportedAnnotationTypes > + * AbstractProcessor#getSupportedAnnotationTypes > * AbstractProcessor.getSupportedAnnotationTypes} provides support > * for stripping off the module prefix when running in an > * environment without modules. > From joe.darcy at oracle.com Mon Feb 13 20:04:37 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 13 Feb 2017 12:04:37 -0800 Subject: JDK 9 RFR Enable doclint reference checking for the java.compiler module Message-ID: Hello, Please review the small patch below to enable the "reference" category of doclint checking (@see and @link tags, etc.) for the java.compiler module which hosts the packages javax.lang.model.*, javax.annotation.processing, and javax.tools. Thanks, -Joe diff -r 4eb77fb98952 make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk Fri Feb 10 08:21:20 2017 -0800 +++ b/make/CompileJavaModules.gmk Mon Feb 13 12:02:21 2017 -0800 @@ -85,7 +85,7 @@ ################################################################################ -java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' +java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' ################################################################################ From joe.darcy at oracle.com Mon Feb 13 20:06:51 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 13 Feb 2017 12:06:51 -0800 Subject: JDK 9 RFR Fix bad javadoc link in javax.tools.JavaFileManager Message-ID: Hello, Please review the patch below to fix a bad javadoc link in JavaFileManager, listLocationsForModule*s* vs listLocationsForModule. To avoid these problems in the future, I just sent out for review a build change to enable the doclint reference check for the java.compiler module. Thanks, -Joe diff -r b87052a3056f src/java.compiler/share/classes/javax/tools/JavaFileManager.java --- a/src/java.compiler/share/classes/javax/tools/JavaFileManager.java Mon Feb 13 11:51:51 2017 -0800 +++ b/src/java.compiler/share/classes/javax/tools/JavaFileManager.java Mon Feb 13 12:04:58 2017 -0800 @@ -130,7 +130,7 @@ * It is not possible to directly list the classes in a module-oriented * location. Instead, you can get a package-oriented location for any specific module * using methods like {@link JavaFileManager#getLocationForModule} or - * {@link JavaFileManager#listLocationsForModule}. + * {@link JavaFileManager#listLocationsForModules}. */ interface Location { /** From jonathan.gibbons at oracle.com Mon Feb 13 20:11:18 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 Feb 2017 12:11:18 -0800 Subject: JDK 9 RFR Fix bad javadoc link in javax.tools.JavaFileManager In-Reply-To: References: Message-ID: <58A212E6.1040907@oracle.com> Looks OK to me. Thanks. -- Jon On 02/13/2017 12:06 PM, joe darcy wrote: > Hello, > > Please review the patch below to fix a bad javadoc link in > JavaFileManager, listLocationsForModule*s* vs listLocationsForModule. > > To avoid these problems in the future, I just sent out for review a > build change to enable the doclint reference check for the > java.compiler module. > > Thanks, > > -Joe > > diff -r b87052a3056f > src/java.compiler/share/classes/javax/tools/JavaFileManager.java > --- a/src/java.compiler/share/classes/javax/tools/JavaFileManager.java > Mon Feb 13 11:51:51 2017 -0800 > +++ b/src/java.compiler/share/classes/javax/tools/JavaFileManager.java > Mon Feb 13 12:04:58 2017 -0800 > @@ -130,7 +130,7 @@ > * It is not possible to directly list the classes in a > module-oriented > * location. Instead, you can get a package-oriented location for > any specific module > * using methods like {@link > JavaFileManager#getLocationForModule} or > - * {@link JavaFileManager#listLocationsForModule}. > + * {@link JavaFileManager#listLocationsForModules}. > */ > interface Location { > /** > From jonathan.gibbons at oracle.com Tue Feb 14 03:27:09 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 Feb 2017 19:27:09 -0800 Subject: JDK 9 RFR to Fix javax.lang.model javadoc link issues In-Reply-To: References: Message-ID: <58A2790D.7040106@oracle.com> Looks good. -- Jon On 02/13/2017 10:48 AM, joe darcy wrote: > Hello, > > Please review the patch below to fix two bad links in the > javax.lang.model javadoc. > > Thanks, > > -Joe > > > diff -r c73b98b79148 > src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java > --- > a/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java > Mon Feb 13 10:29:04 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java > Mon Feb 13 10:45:40 2017 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -92,7 +92,7 @@ > * same set of strings as the annotation. If the class is not so > * annotated, an empty set is returned. > * > - * If the {@link ProcessingEvironment#getSourceVersion source > + * If the {@link ProcessingEnvironment#getSourceVersion source > * version} does not support modules, in other words if it is less > * than or equal to {@link SourceVersion#RELEASE_8 RELEASE_8}, > * then any leading {@link Processor#getSupportedAnnotationTypes > diff -r c73b98b79148 > src/java.compiler/share/classes/javax/annotation/processing/Processor.java > --- > a/src/java.compiler/share/classes/javax/annotation/processing/Processor.java > Mon Feb 13 10:29:04 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/annotation/processing/Processor.java > Mon Feb 13 10:45:40 2017 -0800 > @@ -291,7 +291,7 @@ > * @apiNote When running in an environment which supports modules, > * processors are encouraged to include the module prefix when > * describing their supported annotation types. The method {@link > - * AbstractProcessor.getSupportedAnnotationTypes > + * AbstractProcessor#getSupportedAnnotationTypes > * AbstractProcessor.getSupportedAnnotationTypes} provides support > * for stripping off the module prefix when running in an > * environment without modules. > From erik.joelsson at oracle.com Tue Feb 14 08:14:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Feb 2017 09:14:13 +0100 Subject: JDK 9 RFR Enable doclint reference checking for the java.compiler module In-Reply-To: References: Message-ID: <3136fb32-d3b7-cd55-d5fc-388995135897@oracle.com> Looks good. /Erik On 2017-02-13 21:04, joe darcy wrote: > Hello, > > Please review the small patch below to enable the "reference" category > of doclint checking (@see and @link tags, etc.) for the java.compiler > module which hosts the packages javax.lang.model.*, > javax.annotation.processing, and javax.tools. > > Thanks, > > -Joe > > diff -r 4eb77fb98952 make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk Fri Feb 10 08:21:20 2017 -0800 > +++ b/make/CompileJavaModules.gmk Mon Feb 13 12:02:21 2017 -0800 > @@ -85,7 +85,7 @@ > > ################################################################################ > > > -java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference > '-Xdoclint/package:java.*,javax.*' > +java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > > ################################################################################ > > > From cushon at google.com Thu Feb 16 02:33:01 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 15 Feb 2017 18:33:01 -0800 Subject: question about JDK-8063054 (incorrect raw type warnings for method references) Message-ID: I've seen JDK-8063054 [1] crop up a few times, and did some investigation that I thought I'd share in case it's useful. To summarize the bug, javac emits spurious rawtypes warnings for some method references: class Test { void test(Box> b) { Number n = b.map(Box::get).get(); } interface Func { T apply(S arg); } interface Box { T get(); Box map(Func f); } } ... javac -fullversion -Xlint:rawtypes Test.java javac full version "9-ea+156" Test.java:3: warning: [rawtypes] found raw type: Box Number n = b.map(Box::get).get(); I think the cause is related to the fix for JDK-8012685 [2]. Logic was added to skip rawtype warnings on method references if the qualifier can be inferred. This is done by testing if the inferred type is parameterized: http://hg.openjdk.java.net/jdk9/dev/langtools/annotate/33d1937af1a3/src/share/classes/com/sun/tools/javac/comp/Attr.java#l2738 In the example above, the inferred type of Box is `capture of ? extends Test.Box`. It isn't raw, but it also isn't trivially parameterized, so it fails the check in Attr and still results in a rawtypes warning. I think the fix might be as simple as replacing `!desc.getParameterTypes().head.isParameterized()` with something that handles capture variables. Thanks, Liam [1] https://bugs.openjdk.java.net/browse/JDK-8063054 [2] https://bugs.openjdk.java.net/browse/JDK-8012685 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Feb 16 10:35:36 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 16 Feb 2017 10:35:36 +0000 Subject: question about JDK-8063054 (incorrect raw type warnings for method references) In-Reply-To: References: Message-ID: <532edc20-8715-4b17-15a0-36b99f23bed9@oracle.com> On 16/02/17 02:33, Liam Miller-Cushon wrote: > I think the fix might be as simple as replacing > `!desc.getParameterTypes().head.isParameterized()` with something that > handles capture variables. Hi Liam, I think your analysis is correct - isParameterized would not work for non-class types, so something else is required here. I believe intersection types like Serializable & Comparable might also end up with the same problem - and, presumably, synthetic inner class types. Maurizio From joe.darcy at oracle.com Wed Feb 22 01:37:58 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 21 Feb 2017 17:37:58 -0800 Subject: JDK 9 RFR of 8175335: Improve handling of module types in javax.lang.model.util.Types Message-ID: <764d69ad-d318-b846-0c73-663f3455dc09@oracle.com> Hello, Please review the small spec and implementation changes for 8175335: Improve handling of module types in javax.lang.model.util.Types http://cr.openjdk.java.net/~darcy/8175335.0/ which treats pseudo-types for modules similarly to the pseudo-types for packages. Thanks, -Joe From jonathan.gibbons at oracle.com Wed Feb 22 01:41:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 21 Feb 2017 17:41:31 -0800 Subject: JDK 9 RFR of 8175335: Improve handling of module types in javax.lang.model.util.Types In-Reply-To: <764d69ad-d318-b846-0c73-663f3455dc09@oracle.com> References: <764d69ad-d318-b846-0c73-663f3455dc09@oracle.com> Message-ID: <58ACEC4B.1080607@oracle.com> OK. Quibble, you don't need java.compiler in the jtreg @modules directive, since that is implied by jdk.compiler. -- Jon On 02/21/2017 05:37 PM, joe darcy wrote: > Hello, > > Please review the small spec and implementation changes for > > 8175335: Improve handling of module types in > javax.lang.model.util.Types > http://cr.openjdk.java.net/~darcy/8175335.0/ > > which treats pseudo-types for modules similarly to the pseudo-types > for packages. > > Thanks, > > -Joe > From alex.buckley at oracle.com Wed Feb 22 02:35:34 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 21 Feb 2017 18:35:34 -0800 Subject: JDK 9 RFR of 8175335: Improve handling of module types in javax.lang.model.util.Types In-Reply-To: <764d69ad-d318-b846-0c73-663f3455dc09@oracle.com> References: <764d69ad-d318-b846-0c73-663f3455dc09@oracle.com> Message-ID: <58ACF8F6.2020608@oracle.com> On 2/21/2017 5:37 PM, joe darcy wrote: > Please review the small spec and implementation changes for > > 8175335: Improve handling of module types in > javax.lang.model.util.Types > http://cr.openjdk.java.net/~darcy/8175335.0/ > > which treats pseudo-types for modules similarly to the pseudo-types for > packages. Three specific comments: - Types::erasure(TypeMirror) is one of the family. It should throw IAE on a module type as well as a package type. - Types::getNoType(TypeKind) could say "To obtain a pseudo-type for packages or modules, call asType() on the result of Elements.getPackageElement(CharSequence) or Elements.getModuleElement(CharSequence)." - TypeMirror's spec fails to mention module types in "pseudo-types corresponding to packages and to the keyword void." A general comment: The methods in Types that throw IAE could be clarified. Where they now say "if given a type for an executable, package, or module", they really mean "if given a mirror that does not represent a suitable type for the operation". The Types spec could say "Utility methods for operating on types. Most methods operate on primitive types, reference types (including array types and the null type), intersection types, and the pseudo-type 'void'. Executable types and the pseudo-types for packages and modules are generally out of scope for these methods." Alex From joe.darcy at oracle.com Wed Feb 22 17:48:18 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 22 Feb 2017 09:48:18 -0800 Subject: JDK 9 RFR of 8175335: Improve handling of module types in javax.lang.model.util.Types In-Reply-To: <58ACF8F6.2020608@oracle.com> References: <764d69ad-d318-b846-0c73-663f3455dc09@oracle.com> <58ACF8F6.2020608@oracle.com> Message-ID: Hi Alex, Thanks for the careful reading. Revised webrev uploaded as http://cr.openjdk.java.net/~darcy/8175335.1/ Details comments below. On 2/21/2017 6:35 PM, Alex Buckley wrote: > On 2/21/2017 5:37 PM, joe darcy wrote: >> Please review the small spec and implementation changes for >> >> 8175335: Improve handling of module types in >> javax.lang.model.util.Types >> http://cr.openjdk.java.net/~darcy/8175335.0/ >> >> which treats pseudo-types for modules similarly to the pseudo-types for >> packages. > > Three specific comments: > > - Types::erasure(TypeMirror) is one of the family. It should throw IAE > on a module type as well as a package type. Diff old vs new changes: 152c152 < * @throws IllegalArgumentException if given a package type --- > * @throws IllegalArgumentException if given a type for a package or module (The implementation class was already updated to the new spec in the original webrev.) > > - Types::getNoType(TypeKind) could say "To obtain a pseudo-type for > packages or modules, call asType() on the result of > Elements.getPackageElement(CharSequence) or > Elements.getModuleElement(CharSequence)." Diff old vs new changes: 209,211c209,216 < * For packages, use < * {@link Elements#getPackageElement(CharSequence)}{@code .asType()} < * instead. --- > * > *

To get the pseudo-type corresponding to a package or module, > * call {@code asType()} on the element modeling the {@linkplain > * PackageElement package} or {@linkplain ModuleElement > * module}. Names can be converted to elements for packages or > * modules using {@link Elements#getPackageElement(CharSequence)} > * or {@link Elements#getModuleElement(CharSequence)}, > * respectively. > > - TypeMirror's spec fails to mention module types in "pseudo-types > corresponding to packages and to the keyword void." Patched as follows: --- a/src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java Thu Feb 16 14:47:39 2017 -0800 +++ b/src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java Tue Feb 21 23:47:00 2017 -0800 @@ -36,7 +36,7 @@ * array types, type variables, and the null type. * Also represented are wildcard type arguments, * the signature and return types of executables, - * and pseudo-types corresponding to packages and to the keyword {@code void}. + * and pseudo-types corresponding to packages, modules, and to the keyword {@code void}. * *

Types should be compared using the utility methods in {@link * Types}. There is no guarantee that any particular type will always > > A general comment: > > The methods in Types that throw IAE could be clarified. Where they now > say "if given a type for an executable, package, or module", they > really mean "if given a mirror that does not represent a suitable type > for the operation". The Types spec could say "Utility methods for > operating on types. Most methods operate on primitive types, reference > types (including array types and the null type), intersection types, > and the pseudo-type 'void'. Executable types and the pseudo-types for > packages and modules are generally out of scope for these methods." The general comment is valid, but I'd prefer to keep this bug about getting modules-as-types consistent with packages-as-types and leave the broader clarification you suggest to a future release. I've filed JDK-8175386: "Clarify exception behavior of Types utility methods" to track that work. Cheers, -Joe From alex.buckley at oracle.com Wed Feb 22 19:00:39 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Feb 2017 11:00:39 -0800 Subject: JDK 9 RFR of 8175335: Improve handling of module types in javax.lang.model.util.Types In-Reply-To: References: <764d69ad-d318-b846-0c73-663f3455dc09@oracle.com> <58ACF8F6.2020608@oracle.com> Message-ID: <58ADDFD7.7090501@oracle.com> All looks good. (Trivial: TypeMirror spec says "and to the keyword {@code void}" -- the "to" is unnecessary.) Alex On 2/22/2017 9:48 AM, joe darcy wrote: > Hi Alex, > > Thanks for the careful reading. > > Revised webrev uploaded as > > http://cr.openjdk.java.net/~darcy/8175335.1/ > > Details comments below. > > > On 2/21/2017 6:35 PM, Alex Buckley wrote: >> On 2/21/2017 5:37 PM, joe darcy wrote: >>> Please review the small spec and implementation changes for >>> >>> 8175335: Improve handling of module types in >>> javax.lang.model.util.Types >>> http://cr.openjdk.java.net/~darcy/8175335.0/ >>> >>> which treats pseudo-types for modules similarly to the pseudo-types for >>> packages. >> >> Three specific comments: >> >> - Types::erasure(TypeMirror) is one of the family. It should throw IAE >> on a module type as well as a package type. > > Diff old vs new changes: > > 152c152 > < * @throws IllegalArgumentException if given a package type > --- > > * @throws IllegalArgumentException if given a type for a package > or module > > (The implementation class was already updated to the new spec in the > original webrev.) > >> >> - Types::getNoType(TypeKind) could say "To obtain a pseudo-type for >> packages or modules, call asType() on the result of >> Elements.getPackageElement(CharSequence) or >> Elements.getModuleElement(CharSequence)." > > Diff old vs new changes: > > 209,211c209,216 > < * For packages, use > < * {@link Elements#getPackageElement(CharSequence)}{@code .asType()} > < * instead. > --- > > * > > *

To get the pseudo-type corresponding to a package or module, > > * call {@code asType()} on the element modeling the {@linkplain > > * PackageElement package} or {@linkplain ModuleElement > > * module}. Names can be converted to elements for packages or > > * modules using {@link Elements#getPackageElement(CharSequence)} > > * or {@link Elements#getModuleElement(CharSequence)}, > > * respectively. > > >> >> - TypeMirror's spec fails to mention module types in "pseudo-types >> corresponding to packages and to the keyword void." > > Patched as follows: > > --- > a/src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java > Thu Feb 16 14:47:39 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java > Tue Feb 21 23:47:00 2017 -0800 > @@ -36,7 +36,7 @@ > * array types, type variables, and the null type. > * Also represented are wildcard type arguments, > * the signature and return types of executables, > - * and pseudo-types corresponding to packages and to the keyword {@code > void}. > + * and pseudo-types corresponding to packages, modules, and to the > keyword {@code void}. > * > *

Types should be compared using the utility methods in {@link > * Types}. There is no guarantee that any particular type will always > > >> >> A general comment: >> >> The methods in Types that throw IAE could be clarified. Where they now >> say "if given a type for an executable, package, or module", they >> really mean "if given a mirror that does not represent a suitable type >> for the operation". The Types spec could say "Utility methods for >> operating on types. Most methods operate on primitive types, reference >> types (including array types and the null type), intersection types, >> and the pseudo-type 'void'. Executable types and the pseudo-types for >> packages and modules are generally out of scope for these methods." > > The general comment is valid, but I'd prefer to keep this bug about > getting modules-as-types consistent with packages-as-types and leave the > broader clarification you suggest to a future release. I've filed > JDK-8175386: "Clarify exception behavior of Types utility methods" to > track that work. > > Cheers, > > -Joe > From joe.darcy at oracle.com Thu Feb 23 19:13:27 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 23 Feb 2017 11:13:27 -0800 Subject: JDK 9 RFR of JDK-8175786: Fix small doc issues Message-ID: <6489142e-6b39-1c4f-79ed-5fd425e815fd@oracle.com> Hello, Further scrutiny of of javax.lang.model specification revealed a few doc issues which should be fixed. Patch below. The class AbstractTypeVisitor6 already has the correct "{@code v.visit(av, p)}" text. I'm also using this bug as an opportunity to fix an incorrect summary in the recently pushed test TestPseudoTypeHandling.java. Thanks, -Joe diff -r a7c2b2d0894c src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java --- a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java Wed Feb 22 12:01:15 2017 -0800 +++ b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java Thu Feb 23 11:10:39 2017 -0800 @@ -75,8 +75,9 @@ * originating source of information about the type. For example, * if the information about the type is originating from a source * file, the elements will be returned in source code order. - * (However, in that case the the ordering of elements, such as a - * default constructor, is not specified.) + * (However, in that case the the ordering of {@linkplain + * Elements.Origin#MANDATED implicitly declared} elements, such as + * default constructors, is not specified.) * * @return the enclosed elements in proper order, or an empty list if none * diff -r a7c2b2d0894c src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java --- a/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java Wed Feb 22 12:01:15 2017 -0800 +++ b/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java Thu Feb 23 11:10:39 2017 -0800 @@ -79,9 +79,9 @@ protected AbstractAnnotationValueVisitor6() {} /** - * Visits an annotation value as if by passing itself to that + * Visits any annotation value as if by passing itself to that * value's {@link AnnotationValue#accept accept}. The invocation - * {@code v.visit(av)} is equivalent to {@code av.accept(v, p)}. + * {@code v.visit(av, p)} is equivalent to {@code av.accept(v, p)}. * @param av {@inheritDoc} * @param p {@inheritDoc} */ diff -r a7c2b2d0894c src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java --- a/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java Wed Feb 22 12:01:15 2017 -0800 +++ b/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java Thu Feb 23 11:10:39 2017 -0800 @@ -81,7 +81,7 @@ /** * Visits any program element as if by passing itself to that * element's {@link Element#accept accept} method. The invocation - * {@code v.visit(elem)} is equivalent to {@code elem.accept(v, + * {@code v.visit(elem, p)} is equivalent to {@code elem.accept(v, * p)}. * * @param e the element to visit diff -r a7c2b2d0894c test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java --- a/test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java Wed Feb 22 12:01:15 2017 -0800 +++ b/test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java Thu Feb 23 11:10:39 2017 -0800 @@ -24,7 +24,7 @@ /* * @test * @bug 8175335 - * @summary Test Elements.getPackageOf + * @summary Test Types methods on module and package TypeMirrors * @author Joseph D. Darcy * @library /tools/javac/lib * @modules jdk.compiler From jonathan.gibbons at oracle.com Thu Feb 23 20:19:08 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 23 Feb 2017 12:19:08 -0800 Subject: JDK 9 RFR of JDK-8175786: Fix small doc issues In-Reply-To: <6489142e-6b39-1c4f-79ed-5fd425e815fd@oracle.com> References: <6489142e-6b39-1c4f-79ed-5fd425e815fd@oracle.com> Message-ID: <58AF43BC.9090004@oracle.com> Looks OK to me. -- Jon On 02/23/2017 11:13 AM, joe darcy wrote: > Hello, > > Further scrutiny of of javax.lang.model specification revealed a few > doc issues which should be fixed. > > Patch below. > > The class AbstractTypeVisitor6 already has the correct "{@code > v.visit(av, p)}" text. > > I'm also using this bug as an opportunity to fix an incorrect summary > in the recently pushed test TestPseudoTypeHandling.java. > > Thanks, > > -Joe > > diff -r a7c2b2d0894c > src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > --- > a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Wed Feb 22 12:01:15 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Thu Feb 23 11:10:39 2017 -0800 > @@ -75,8 +75,9 @@ > * originating source of information about the type. For example, > * if the information about the type is originating from a source > * file, the elements will be returned in source code order. > - * (However, in that case the the ordering of elements, such as a > - * default constructor, is not specified.) > + * (However, in that case the the ordering of {@linkplain > + * Elements.Origin#MANDATED implicitly declared} elements, such as > + * default constructors, is not specified.) > * > * @return the enclosed elements in proper order, or an empty > list if none > * > diff -r a7c2b2d0894c > src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java > --- > a/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java > Wed Feb 22 12:01:15 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java > Thu Feb 23 11:10:39 2017 -0800 > @@ -79,9 +79,9 @@ > protected AbstractAnnotationValueVisitor6() {} > > /** > - * Visits an annotation value as if by passing itself to that > + * Visits any annotation value as if by passing itself to that > * value's {@link AnnotationValue#accept accept}. The invocation > - * {@code v.visit(av)} is equivalent to {@code av.accept(v, p)}. > + * {@code v.visit(av, p)} is equivalent to {@code av.accept(v, p)}. > * @param av {@inheritDoc} > * @param p {@inheritDoc} > */ > diff -r a7c2b2d0894c > src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java > --- > a/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java > Wed Feb 22 12:01:15 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java > Thu Feb 23 11:10:39 2017 -0800 > @@ -81,7 +81,7 @@ > /** > * Visits any program element as if by passing itself to that > * element's {@link Element#accept accept} method. The invocation > - * {@code v.visit(elem)} is equivalent to {@code elem.accept(v, > + * {@code v.visit(elem, p)} is equivalent to {@code elem.accept(v, > * p)}. > * > * @param e the element to visit > diff -r a7c2b2d0894c > test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java > --- > a/test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java > Wed Feb 22 12:01:15 2017 -0800 > +++ > b/test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java > Thu Feb 23 11:10:39 2017 -0800 > @@ -24,7 +24,7 @@ > /* > * @test > * @bug 8175335 > - * @summary Test Elements.getPackageOf > + * @summary Test Types methods on module and package TypeMirrors > * @author Joseph D. Darcy > * @library /tools/javac/lib > * @modules jdk.compiler > From jan.lahoda at oracle.com Thu Feb 23 21:25:37 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 23 Feb 2017 22:25:37 +0100 Subject: JDK 9 RFR of JDK-8175786: Fix small doc issues In-Reply-To: <6489142e-6b39-1c4f-79ed-5fd425e815fd@oracle.com> References: <6489142e-6b39-1c4f-79ed-5fd425e815fd@oracle.com> Message-ID: <58AF5351.4040406@oracle.com> Seems OK to me. Jan On 23.2.2017 20:13, joe darcy wrote: > Hello, > > Further scrutiny of of javax.lang.model specification revealed a few doc > issues which should be fixed. > > Patch below. > > The class AbstractTypeVisitor6 already has the correct "{@code > v.visit(av, p)}" text. > > I'm also using this bug as an opportunity to fix an incorrect summary in > the recently pushed test TestPseudoTypeHandling.java. > > Thanks, > > -Joe > > diff -r a7c2b2d0894c > src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > --- > a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Wed Feb 22 12:01:15 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Thu Feb 23 11:10:39 2017 -0800 > @@ -75,8 +75,9 @@ > * originating source of information about the type. For example, > * if the information about the type is originating from a source > * file, the elements will be returned in source code order. > - * (However, in that case the the ordering of elements, such as a > - * default constructor, is not specified.) > + * (However, in that case the the ordering of {@linkplain > + * Elements.Origin#MANDATED implicitly declared} elements, such as > + * default constructors, is not specified.) > * > * @return the enclosed elements in proper order, or an empty list > if none > * > diff -r a7c2b2d0894c > src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java > > --- > a/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java > Wed Feb 22 12:01:15 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java > Thu Feb 23 11:10:39 2017 -0800 > @@ -79,9 +79,9 @@ > protected AbstractAnnotationValueVisitor6() {} > > /** > - * Visits an annotation value as if by passing itself to that > + * Visits any annotation value as if by passing itself to that > * value's {@link AnnotationValue#accept accept}. The invocation > - * {@code v.visit(av)} is equivalent to {@code av.accept(v, p)}. > + * {@code v.visit(av, p)} is equivalent to {@code av.accept(v, p)}. > * @param av {@inheritDoc} > * @param p {@inheritDoc} > */ > diff -r a7c2b2d0894c > src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java > > --- > a/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java > Wed Feb 22 12:01:15 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java > Thu Feb 23 11:10:39 2017 -0800 > @@ -81,7 +81,7 @@ > /** > * Visits any program element as if by passing itself to that > * element's {@link Element#accept accept} method. The invocation > - * {@code v.visit(elem)} is equivalent to {@code elem.accept(v, > + * {@code v.visit(elem, p)} is equivalent to {@code elem.accept(v, > * p)}. > * > * @param e the element to visit > diff -r a7c2b2d0894c > test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java > --- > a/test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java > Wed Feb 22 12:01:15 2017 -0800 > +++ > b/test/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java > Thu Feb 23 11:10:39 2017 -0800 > @@ -24,7 +24,7 @@ > /* > * @test > * @bug 8175335 > - * @summary Test Elements.getPackageOf > + * @summary Test Types methods on module and package TypeMirrors > * @author Joseph D. Darcy > * @library /tools/javac/lib > * @modules jdk.compiler > From vitalyd at gmail.com Thu Feb 23 22:05:21 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2017 22:05:21 +0000 Subject: Java 9 ea154 javac compiler error - legit or bug? In-Reply-To: References: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> <648523fd-ff25-9488-b182-7463e0bbee6b@oracle.com> Message-ID: Hi Maurizio, Just wanted to follow up and confirm that 157 fixes the issue - thanks again for the lightning turnaround! On Thu, Feb 9, 2017 at 5:04 PM Vitaly Davidovich wrote: > Awesome - thanks! > > On Thu, Feb 9, 2017 at 5:03 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > > > On 09/02/17 16:39, Vitaly Davidovich wrote: > > Hi Maurizio, > > Thanks for the elaboration - much appreciated. > > Which EA build do you think will have a fix for this issue? > > I've just pushed this today, so - finger crossed - it should make the next > one (157) > > > Maurizio > > > On Thu, Feb 9, 2017 at 8:31 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > > Hi Vitaly, > the situation is a tad convoluted; basically there's a long-standing javac > discrepancy which allowed javac to erase the return type of an unchecked > call *after* some type inference has been performed. This behavior is well > described here: > > https://bugs.openjdk.java.net/browse/JDK-8135087 > > In your example, that means that, since the first actual argument to 'foo' > has type Class and the first formal is Class, javac is able to > infer that T = String - which gives you a fully instantiated 'foo' with > signature: > > String foo(Class c, Collection baz) > > Then, as an unchecked conversion has been required for this method call > (for the second argument), javac proceeds to erase the signature - but > there's nothing to do! That is, erasure(String) = String, so the invocation > type of the inner most call has a return type 'String'. That's different > from what the spec says - as the spec wants to erase the *declared > signature* of the method if an unchecked conversion occurs - in which case > the invocation return type would be just Object (and a compiler error would > be issued). This discrepancy will be addressed as part of JDK 10. > > That said, JDK-8078093 accidentally introduced a change in this area - in > method context the current javac implementation would erase the declared > signature; while this behavior is compatible with what the spec say, as you > observed, it's completely inconsistent with what javac does in assignment > context, and it's also inconsistent with almost everything else javac does > (hence the weird error you get 'expected: String - found: String'). This is > just a plain bug - the fix for 8078093 was never meant to alter behavior of > type-checking with unchecked calls and generic methods. > > In the short term we plan to restore the original behavior (as with JDK > 8). In the medium term we plan to get rid of this discrepancy for good. > > So, should the program compile? If you follow the spec literally, no, it > shouldn't. But the aim is to keep stuff like this working, until we come up > with a more general cleanup in this area. > > I hope this clarifies the issue. > > Meanwhile, I filed this bug: > https://bugs.openjdk.java.net/browse/JDK-8174249 > > to keep track of this issue. > > Maurizio > > > > On 09/02/17 04:09, Vitaly Davidovich wrote: > > Hi Maurizio, > > Thanks for the reply. So you're saying the example using assignment > context shouldn't compile either? Also, the call to 'foo' is unchecked in > the wildcard argument, but it has a concrete type in the first argument. > Are you saying that any unchecked param results in return type erasure? > > Thanks > > On Wed, Feb 8, 2017 at 8:38 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > > Hi, > it seems like the behavior you observed started in b83 - as a result of > this: > > https://bugs.openjdk.java.net/browse/JDK-8078093 > > I believe the error is correct (although the diagnostic has always been > broken since b83 in the 'verbose' mode - the non-verbose mode - w/o > -Xdiags:verbose is fine). That is, the call to 'foo' is unchecked, so the > return type should be erased. There seems to be an inconsistency in how > javac handles this in method context compared to assignment context, and > that needs to be looked at. > > Thanks > > > Maurizio > > > > On 08/02/17 19:23, Vitaly Davidovich wrote: > > Hi all, > > Given the following code: > > import java.util.ArrayList; > import java.util.Collection; > > public class Foo { > static T foo(Class c, Collection baz) { > return null; > } > > static void bar(String c) { > > } > > @SuppressWarnings("unchecked") > public static void main(String[] args) { > // this works > bar(foo(String.class, new ArrayList())); > > // this works with a warning > String s = foo(String.class, new ArrayList()); > bar(s); > > // this causes an error on JDK9 > bar(foo(String.class, new ArrayList())); > } > } > > javac 9-ea (build 9-ea+154) fails with this interesting error (on the last > line in main, as the comments there indicate): > > Foo.java:23: error: method bar in class Foo cannot be applied to given > types; > bar(foo(String.class, new ArrayList())); > ^ > required: String > found: String > reason: argument mismatch; Object cannot be converted to String > 1 error > > Java 8 compiles fine, and the other 2 lines compile in the same java 9 > build as well. > > Is this a javac bug or legit? It seems like a compiler error. At a > minimum, the diagnostic output "required String, found String" is confusing. > > Thanks > > > > -- > Sent from my phone > > > -- > Sent from my phone > > > -- > Sent from my phone > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Feb 23 22:16:20 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Feb 2017 22:16:20 +0000 Subject: Java 9 ea154 javac compiler error - legit or bug? In-Reply-To: References: <596c93af-0213-05cd-2cd9-9630024ba8d0@oracle.com> <648523fd-ff25-9488-b182-7463e0bbee6b@oracle.com> Message-ID: <6f08d463-3883-e1b7-0da0-d5e53538e3c6@oracle.com> Phew - thanks! Maurizio On 23/02/17 22:05, Vitaly Davidovich wrote: > Hi Maurizio, > > Just wanted to follow up and confirm that 157 fixes the issue - thanks > again for the lightning turnaround! > > On Thu, Feb 9, 2017 at 5:04 PM Vitaly Davidovich > wrote: > > Awesome - thanks! > > On Thu, Feb 9, 2017 at 5:03 PM Maurizio Cimadamore > > wrote: > > > On 09/02/17 16:39, Vitaly Davidovich wrote: >> Hi Maurizio, >> >> Thanks for the elaboration - much appreciated. >> >> Which EA build do you think will have a fix for this issue? > I've just pushed this today, so - finger crossed - it should > make the next one (157) > > > Maurizio > >> >> On Thu, Feb 9, 2017 at 8:31 AM Maurizio Cimadamore >> > > wrote: >> >> Hi Vitaly, >> the situation is a tad convoluted; basically there's a >> long-standing javac discrepancy which allowed javac to >> erase the return type of an unchecked call *after* some >> type inference has been performed. This behavior is well >> described here: >> >> https://bugs.openjdk.java.net/browse/JDK-8135087 >> >> In your example, that means that, since the first actual >> argument to 'foo' has type Class and the first >> formal is Class, javac is able to infer that T = >> String - which gives you a fully instantiated 'foo' with >> signature: >> >> String foo(Class c, Collection baz) >> >> Then, as an unchecked conversion has been required for >> this method call (for the second argument), javac >> proceeds to erase the signature - but there's nothing to >> do! That is, erasure(String) = String, so the invocation >> type of the inner most call has a return type 'String'. >> That's different from what the spec says - as the spec >> wants to erase the *declared signature* of the method if >> an unchecked conversion occurs - in which case the >> invocation return type would be just Object (and a >> compiler error would be issued). This discrepancy will be >> addressed as part of JDK 10. >> >> That said, JDK-8078093 accidentally introduced a change >> in this area - in method context the current javac >> implementation would erase the declared signature; while >> this behavior is compatible with what the spec say, as >> you observed, it's completely inconsistent with what >> javac does in assignment context, and it's also >> inconsistent with almost everything else javac does >> (hence the weird error you get 'expected: String - found: >> String'). This is just a plain bug - the fix for 8078093 >> was never meant to alter behavior of type-checking with >> unchecked calls and generic methods. >> >> In the short term we plan to restore the original >> behavior (as with JDK 8). In the medium term we plan to >> get rid of this discrepancy for good. >> >> So, should the program compile? If you follow the spec >> literally, no, it shouldn't. But the aim is to keep stuff >> like this working, until we come up with a more general >> cleanup in this area. >> >> I hope this clarifies the issue. >> >> Meanwhile, I filed this bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8174249 >> >> to keep track of this issue. >> >> Maurizio >> >> >> >> On 09/02/17 04:09, Vitaly Davidovich wrote: >>> Hi Maurizio, >>> >>> Thanks for the reply. So you're saying the example >>> using assignment context shouldn't compile either? Also, >>> the call to 'foo' is unchecked in the wildcard argument, >>> but it has a concrete type in the first argument. Are >>> you saying that any unchecked param results in return >>> type erasure? >>> >>> Thanks >>> >>> On Wed, Feb 8, 2017 at 8:38 PM Maurizio Cimadamore >>> >> > wrote: >>> >>> Hi, >>> it seems like the behavior you observed started in >>> b83 - as a result of this: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8078093 >>> >>> I believe the error is correct (although the >>> diagnostic has always been broken since b83 in the >>> 'verbose' mode - the non-verbose mode - w/o >>> -Xdiags:verbose is fine). That is, the call to 'foo' >>> is unchecked, so the return type should be erased. >>> There seems to be an inconsistency in how javac >>> handles this in method context compared to >>> assignment context, and that needs to be looked at. >>> >>> Thanks >>> >>> >>> Maurizio >>> >>> >>> >>> On 08/02/17 19:23, Vitaly Davidovich wrote: >>>> Hi all, >>>> >>>> Given the following code: >>>> >>>> import java.util.ArrayList; >>>> import java.util.Collection; >>>> >>>> public class Foo { >>>> static T foo(Class c, Collection >>>> baz) { >>>> return null; >>>> } >>>> >>>> static void bar(String c) { >>>> >>>> } >>>> >>>> @SuppressWarnings("unchecked") >>>> public static void main(String[] args) { >>>> // this works >>>> bar(foo(String.class, new ArrayList())); >>>> >>>> // this works with a warning >>>> String s = foo(String.class, new ArrayList()); >>>> bar(s); >>>> >>>> // this causes an error on JDK9 >>>> bar(foo(String.class, new ArrayList())); >>>> } >>>> } >>>> >>>> javac 9-ea (build 9-ea+154) fails with this >>>> interesting error (on the last line in main, as the >>>> comments there indicate): >>>> >>>> Foo.java:23: error: method bar in class Foo cannot >>>> be applied to given types; >>>> bar(foo(String.class, new ArrayList())); >>>> ^ >>>> required: String >>>> found: String >>>> reason: argument mismatch; Object cannot be >>>> converted to String >>>> 1 error >>>> >>>> Java 8 compiles fine, and the other 2 lines compile >>>> in the same java 9 build as well. >>>> >>>> Is this a javac bug or legit? It seems like a >>>> compiler error. At a minimum, the diagnostic >>>> output "required String, found String" is confusing. >>>> >>>> Thanks >>>> >>>> >>> >>> -- >>> Sent from my phone >> >> -- >> Sent from my phone > > -- > Sent from my phone > > -- > Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sun Feb 26 10:32:43 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 26 Feb 2017 18:32:43 +0800 Subject: On 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.ec modules Message-ID: Hi All I'm looking at this bug and have several questions: 1. jdk.jartool is newly introduced in jdk9 (well, all modules are new) but the main class inside it -- sun.security.tools.policytool.PolicyTool -- is already deprecated. Can I also add @deprecated/@Deprecated to the module-info.java of this module? 2. I try to run javadoc on this single module but see the following error. Not sure what it means. Shall I provide more arguments? $ javadoc --module jdk.jartool -d /tmp javadoc: error - fatal error encountered: java.lang.IllegalArgumentException: location is not an output location or a module-oriented location: CLASS_PATH javadoc: error - Please file a bug against the javadoc tool via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include error messages and the following diagnostic in your report. Thank you. java.lang.IllegalArgumentException: location is not an output location or a module-oriented location: CLASS_PATH at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.checkModuleOrientedOrOutputLocation(JavacFileManager.java:1114) at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getLocationForModule(JavacFileManager.java:955) at jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.getModuleLocation(ElementsTable.java:796) at jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.scanSpecifiedItems(ElementsTable.java:352) at jdk.javadoc/jdk.javadoc.internal.tool.JavadocTool.getEnvironment(JavadocTool.java:189) at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:591) at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:424) at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:341) at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63) at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52) Thanks Max From Alan.Bateman at oracle.com Sun Feb 26 11:58:41 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Feb 2017 11:58:41 +0000 Subject: On 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.ec modules In-Reply-To: References: Message-ID: On 26/02/2017 10:32, Wang Weijun wrote: > Hi All > > I'm looking at this bug and have several questions: > > 1. jdk.jartool is newly introduced in jdk9 (well, all modules are new) > but the main class inside it -- > sun.security.tools.policytool.PolicyTool -- is already deprecated. Can > I also add @deprecated/@Deprecated to the module-info.java of this > module? Do you mean jdk.policytool (not jdk.jartool)? I don't see an issue adding @Deprecated although it will be visible in the javadoc (jdk.policy doesn't export an API to it seem unlikely that anyone will `requires jdk.policytool` and see the compile-time warning). -Alan > > 2. I try to run javadoc on this single module but see the following > error. Not sure what it means. Shall I provide more arguments? > > $ javadoc --module jdk.jartool -d /tmp > javadoc: error - fatal error encountered: > java.lang.IllegalArgumentException: location is not an output location > or a module-oriented location: CLASS_PATH > javadoc: error - Please file a bug against the javadoc tool via the > Java bug reporting page > (http://bugreport.java.com) after checking the Bug Database > (http://bugs.java.com) > for duplicates. Include error messages and the following diagnostic in > your report. Thank you. > java.lang.IllegalArgumentException: location is not an output location > or a module-oriented location: CLASS_PATH > at > jdk.compiler/com.sun.tools.javac.file.JavacFileManager.checkModuleOrientedOrOutputLocation(JavacFileManager.java:1114) > at > jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getLocationForModule(JavacFileManager.java:955) > at > jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.getModuleLocation(ElementsTable.java:796) > at > jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.scanSpecifiedItems(ElementsTable.java:352) > at > jdk.javadoc/jdk.javadoc.internal.tool.JavadocTool.getEnvironment(JavadocTool.java:189) > at > jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:591) > at > jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:424) > at > jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:341) > at > jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63) > at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52) > > Thanks > Max From weijun.wang at oracle.com Mon Feb 27 03:31:55 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 27 Feb 2017 11:31:55 +0800 Subject: --module-source-path does not accept symlink Message-ID: $ mkdir -p s/z $ echo "module z { }" > s/z/module-info.java $ javac --module-source-path s -d /tmp s/z/module-info.java $ ln -s s t $ javac --module-source-path t -d /tmp t/z/module-info.java t/z/module-info.java:1: error: module not found on module source path module z { } ^ 1 error Is this a bug? I find this issue when I was running jib and my /var/tmp/jib_myname is a symlink to another jib directory in another Linux installation. Thanks Max From weijun.wang at oracle.com Mon Feb 27 03:41:11 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 27 Feb 2017 11:41:11 +0800 Subject: --module-source-path does not accept symlink In-Reply-To: References: Message-ID: <130ea960-5ea2-f672-0519-ccfa38fec42f@oracle.com> Looks like this is a regression of the latest changeset in langtools: 8173914: StandardJavaFileManager.setLocationForModule http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a42d01aa6c9e The 2nd javac call succeeds if I backout the change. --Max On 02/27/2017 11:31 AM, Weijun Wang wrote: > $ mkdir -p s/z > $ echo "module z { }" > s/z/module-info.java > $ javac --module-source-path s -d /tmp s/z/module-info.java > $ ln -s s t > $ javac --module-source-path t -d /tmp t/z/module-info.java > t/z/module-info.java:1: error: module not found on module source path > module z { } > ^ > 1 error > > Is this a bug? > > I find this issue when I was running jib and my /var/tmp/jib_myname is a > symlink to another jib directory in another Linux installation. > > Thanks > Max From Jacob.Wieland at spirent.com Fri Feb 24 09:17:22 2017 From: Jacob.Wieland at spirent.com (Wieland, Jacob) Date: Fri, 24 Feb 2017 09:17:22 +0000 Subject: throwing static exceptions sometimes VERY slow! Message-ID: Hi, I am observing a very strange behavior. In our generated code (due to various reasons I won't go into here unless I have to, but trust me, they are legit), we throw static exceptions for control flow purposes, This seems to work fine and without performance loss most of the time. However, we are observing now that every few seconds, a throw sometimes takes up between 1,5 and 2.5 seconds! (in contrast to the normal almost non-measurable time). It does not seem to be GC related, the only idea that I have is the jitter. So, my question is. Is this a known (and for some strange reason maybe even accepted) behavior or is this a bug that I should file with Oracle (or you guys). BR [X] Dr. Jacob Wieland Senior Software Engineer main +49.30.7261919.34 mobile +49.173.6446443 jacob.wieland at spirent.com www.spirent.com Follow us on: Spirent Communications [X]|[X]|[X] Michaelkirchstra?e 17/18 10179 Berlin, Germany +++++ N E W S F L A S H +++++ Spirent Communications and Testing Technologies join forces to become your test automation power-house. Read more at http://conta.cc/1S62BEY. Spirent Communications e-mail confidentiality. ------------------------------------------------------------------------ This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. Spirent Communications plc Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Tel No. +44 (0) 1293 767676 Fax No. +44 (0) 1293 767677 Registered in England Number 470893 Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Or if within the US, Spirent Communications, 27349 Agoura Road, Calabasas, CA, 91301, USA. Tel No. 1-818-676- 2300 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Feb 27 21:10:09 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 27 Feb 2017 13:10:09 -0800 Subject: On 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.ec modules In-Reply-To: References: Message-ID: <58B495B1.5090909@oracle.com> Max, Your second point is part pilot error, and part javadoc bug. You need to provide some source files, and javadoc needs to handle this case better. That being said, providing source files is easier said than done, right now. If you use -sourcepath or --module-source-path, you must be prepared to provide *all* the source code for the modules in question. We are working to make it possible/easy to use --patch-module-path so that you can give partial sources to complement the rest of the module's content found on the overall module path. javadoc folk, This looks like a problem with the location handling in ElementsTable. It may be a combination of using --module and no --module-source-path. -- Jon On 02/26/2017 02:32 AM, Wang Weijun wrote: > Hi All > > I'm looking at this bug and have several questions: > > 1. jdk.jartool is newly introduced in jdk9 (well, all modules are new) > but the main class inside it -- > sun.security.tools.policytool.PolicyTool -- is already deprecated. Can > I also add @deprecated/@Deprecated to the module-info.java of this > module? > > 2. I try to run javadoc on this single module but see the following > error. Not sure what it means. Shall I provide more arguments? > > $ javadoc --module jdk.jartool -d /tmp > javadoc: error - fatal error encountered: > java.lang.IllegalArgumentException: location is not an output location > or a module-oriented location: CLASS_PATH > javadoc: error - Please file a bug against the javadoc tool via the > Java bug reporting page > (http://bugreport.java.com) after checking the Bug Database > (http://bugs.java.com) > for duplicates. Include error messages and the following diagnostic in > your report. Thank you. > java.lang.IllegalArgumentException: location is not an output location > or a module-oriented location: CLASS_PATH > at > jdk.compiler/com.sun.tools.javac.file.JavacFileManager.checkModuleOrientedOrOutputLocation(JavacFileManager.java:1114) > at > jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getLocationForModule(JavacFileManager.java:955) > at > jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.getModuleLocation(ElementsTable.java:796) > at > jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.scanSpecifiedItems(ElementsTable.java:352) > at > jdk.javadoc/jdk.javadoc.internal.tool.JavadocTool.getEnvironment(JavadocTool.java:189) > at > jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:591) > at > jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:424) > at > jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:341) > at > jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63) > at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52) > > Thanks > Max From steff.nicolas at gmail.com Sat Feb 4 07:57:46 2017 From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=) Date: Sat, 04 Feb 2017 07:57:46 -0000 Subject: Incremental compilation and annotation processing Message-ID: Hi folks, just to let you know that gradle is working on making incremental compilation work in java builds even in the case where annotation processing is performed. I was thinking you might be interested to know about it. S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Feb 27 21:33:54 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Feb 2017 21:33:54 +0000 Subject: throwing static exceptions sometimes VERY slow! In-Reply-To: References: Message-ID: <5ba5db17-833b-04aa-fe93-be848fb1f560@oracle.com> Hi Jacob, did you mean to send this to hotspot-dev @ o.j.n, or is there something javac related in your question that I misunderstood? Thanks Maurizio On 24/02/17 09:17, Wieland, Jacob wrote: > > Hi, > > > I am observing a very strange behavior. > > > In our generated code (due to various reasons I won't go into here > unless I have to, but trust me, they are legit), we throw static > exceptions for control flow purposes, This seems to work fine and > without performance loss most of the time. However, we are observing > now that every few seconds, a throw sometimes takes up between 1,5 and > 2.5 seconds! (in contrast to the normal almost non-measurable time). > > > It does not seem to be GC related, the only idea that I have is the > jitter. > > > So, my question is. Is this a known (and for some strange reason maybe > even accepted) behavior or is this a bug that I should file with > Oracle (or you guys). > > > BR > > >  > > > > > > > *Dr. Jacob Wieland* > > /Senior Software Engineer/ > > main +49.30.7261919.34 > > mobile +49.173.6446443 > > > jacob.wieland at spirent.com > > > www.spirent.com > > > > > > > > > Follow us on: > > > > > > > Spirent Communications > >  | > | > > > > > > > Michaelkirchstra?e 17/18 > > 10179 Berlin, Germany > > > > *+++++ N E W S F L A S H +++++* > > Spirent Communications and Testing Technologies join forces to become > your test automation power-house. Read more at http://conta.cc/1S62BEY. > > > > > > Spirent Communications e-mail confidentiality. > ------------------------------------------------------------------------ > This e-mail contains confidential and / or privileged information > belonging to Spirent Communications plc, its affiliates and / or > subsidiaries. If you are not the intended recipient, you are hereby > notified that any disclosure, copying, distribution and / or the > taking of any action based upon reliance on the contents of this > transmission is strictly forbidden. If you have received this message > in error please notify the sender by return e-mail and delete it from > your system. > > Spirent Communications plc > Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United > Kingdom. > Tel No. +44 (0) 1293 767676 > Fax No. +44 (0) 1293 767677 > > Registered in England Number 470893 > Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 > 9XN, United Kingdom. > > Or if within the US, > > Spirent Communications, > 27349 Agoura Road, Calabasas, CA, 91301, USA. > Tel No. 1-818-676- 2300 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Mon Feb 27 21:54:26 2017 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 27 Feb 2017 21:54:26 +0000 Subject: Incremental compilation and annotation processing In-Reply-To: References: Message-ID: Can you elaborate more? Dagger is always interested in this, especially since we have a pretty broad processor. I think the Android plugin had some issues in this area with Instant Run and instead opted to disable it when using processors like Dagger? On Mon, Feb 27, 2017, 4:12 PM St?phane NICOLAS wrote: > Hi folks, > > just to let you know that gradle is working on making incremental > compilation work in java builds even in the case where annotation > processing is performed. > > I was thinking you might be interested to know about it. > > S. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steff.nicolas at gmail.com Tue Feb 28 10:52:40 2017 From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=) Date: Tue, 28 Feb 2017 10:52:40 -0000 Subject: Incremental compilation and annotation processing In-Reply-To: References: Message-ID: https://github.com/gradle/gradle/issues/1320 @Ron it is interesting for all annotation processors on Android. It s not only instant run, but all compilations using annotations processors are not incremental. I said I was interested to contribute but didn't hear any news from gradle. Feel free to comment there too ;) Le lun. 27 f?vr. 2017 22:54, Ron Shapiro a ?crit : > Can you elaborate more? > > Dagger is always interested in this, especially since we have a pretty > broad processor. I think the Android plugin had some issues in this area > with Instant Run and instead opted to disable it when using processors like > Dagger? > > > On Mon, Feb 27, 2017, 4:12 PM St?phane NICOLAS > wrote: > > Hi folks, > > just to let you know that gradle is working on making incremental > compilation work in java builds even in the case where annotation > processing is performed. > > I was thinking you might be interested to know about it. > > S. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: